イベント駆動型アーキテクチャは、イベントを使用して、1 つ以上のアプリケーションのコンポーネント間で情報を共有します。イベントでは、API リクエストを受け取ったこと、ファイルがストレージプラットフォームにアップロードされたことや、データベースレコードが更新されたことなど、「何かが起こった」ことを教えてくれます。ビジネスイベントは、新しい顧客アカウントが作成された、支払いが成功したなど、お客様の活動に関連する何かを説明します。
独自のアプリケーションのイベント、統合された Software-as-a-Service (SaaS) アプリケーション、AWS のサービスを使用してアプリケーションを接続するには、Amazon EventBridge を使用できます。これは、イベントソースからリアルタイムデータのストリームを提供し、そのデータを AWS Lambda などのターゲットにルーティングするサーバーレスイベントバスです。
イベントは、その情報に興味を持っている人なら誰とでも共有することができる事実を教えてくれます。新しい顧客アカウントが作成されると、既存のインターフェイスを変更することなく、追加される新しいサービスでこの情報を用いることができます。例えば、新しい不正検出システムは、セキュリティチェックを実行し、詐欺行為の可能性を評価するために作成されたすべての新規顧客アカウントを知ることに関心があるかもしれません。
場合によっては、過去のイベントを再処理する必要があることもあります。以下のように、これが有用であるユースケースが数多くあります。
これを簡単にするために、EventBridge はイベントをアーカイブしてリプレイできるようになりました。
アーカイブとリプレイは、AWS プラットフォームからのイベント、SaaS 統合からのイベント、および独自のカスタムイベントを含む、EventBridge が処理するすべてのイベントを処理します。
EventBridge がリプレイ用に別のクォータを保持しているため、リプレイ中は、現在のイベントのスループットには影響しません。リプレイの速度は、1 秒あたりに公開されるイベントの観点から、リージョン内の現在の PutEvents 制限と同じです。PutEvents サービスのクォータを増やすように頼むと、リプレイが速くなります。このように、通常の操作はリプレイの影響を受けません。ただし、リプレイを処理するダウンストリームサービスのパフォーマンスと制限をチェックして、追加のワークロードを処理できるようにする必要があります。
進行中のリプレイは停止できます。停止したリプレイを再開することはできませんが、以前に停止したリプレイから、開始時刻を lastReplayedEvent タイムスタンプに設定して新しいリプレイを作成できます。
アーカイブとリプレイが実際にどのように機能するかを見てみましょう。
イベントアーカイブの作成 EventBridge コンソールで、アプリケーション用のイベントバスを作成します。
次に、単純なイベントマッチングパターンを使用してイベントバスのルールを作成し、customerCreated と等しい DetailType で受信したすべてのイベントを Lambda 関数に送信して、イベント内の顧客データをデータベースに格納します。
次に、イベントバスを選択してから、[アクション] メニューの [アーカイブイベント] を選択します。
アーカイブに名前と説明を付けて、ソースが自分のイベントバスであることをダブルチェックします。ここでは無限の保存期間を選択していますが、保持する日数を選択することができます。その後、イベントはアーカイブから自動的に削除されます。
[次へ] を選択します。オプションで、ルールを作成するときに使用したパターンマッチング構文と同様のパターンマッチング構文でアーカイブするイベントをフィルタリングできます。ここではフィルタを追加せず、ソースからすべてのイベントをアーカイブすることにしました。
さて、この単純な Python コードを使用して、以下のようにバスにいくつかのイベントを置きます。
import jsonimport boto3EVENT_BUS = 'my-event-bus'# Create EventBridge clientevents = boto3.client('events')eventDetail= {'customerId': '123','customerName': 'Danilo','customerData': 'More info...'}# Put an eventresponse = events.put_events(Entries=[{'EventBusName': EVENT_BUS,'Detail': json.dumps(eventDetail),'DetailType': 'customerCreated','Source': 'com.mycompany.myapp'}])print(response['Entries'])前のコードを複数回実行します。数分後、以下のように、私が公開したイベントがアーカイブされていることがわかります。
イベントのリプレイ しばらくしてから、Lambda 関数のコードのバグを発見しました… アドレスが予想よりも長いと、関数はすべてのデータを格納しません (はい、このようなことは起こるものです ?)。新しいイベントが正しく処理されるように、コードを修正します。EventBridge を使用して、古いイベントをリプレイして、既に処理したイベントの結果を修正することもできます。
このアプリケーションは冪等であるため、安全にこれを行うことができます。つまり、結果が変わることなく、同じ入力で複数回実行することができます。この場合、データベース項目は正しい顧客データで上書きされます。回復性に優れたアプリケーションを構築するために、常に冪等インターフェイスを設計することを提案しています。こうすることで、このようなエラーから簡単に回復でき、重複した入力を安全に無視することもできます。
EventBridge は順序保証を提供せず、リプレイはマルチスレッド方式で実行されるため、イベントが元の順序とは異なる順序で配信される可能性があることに注意してください。
アーカイブを選択した状態で、[新しいリプレイを開始] をクリックし、リプレイの名前と説明を入力します。
リプレイのソースが自分のアーカイブであることを確認します。バグが修正された Lambda 関数をトリガーするルールのみをリプレイすることを選択します。
リプレイの開始時刻と終了時刻を定義し (現地時間または UTCを使用できます)、[リプレイを開始] を選択します。
私のアーカイブはそう大きくはありません。リプレイが開始されると、完了するまで数秒しかかかりません。自分のデータベースを見ると、顧客データが正しいことがわかります。これで、バグが修正されました!
今すぐご利用いただけます イベントのアーカイブとリプレイは、中国本土と大阪を除くすべての商用リージョンでご利用いただけます。詳細については、AWS リージョン別のサービスリストをご覧ください。この新しい機能は、コンソール、AWS コマンドラインインターフェイス (CLI)、AWS SDK、および AWS CloudFormation でご利用いただけます。
Amazon EventBridge では、使用した分のみお支払いいただきます。アーカイブおよびリプレイについては、アーカイブされたイベントの数、アーカイブが使用したストレージ、およびリプレイされたメッセージの数で課金されます。コストの詳細と例については、EventBridge の料金表ページをご覧ください。
詳細については、こちらのドキュメントをご覧ください。皆さんがこの新機能をどのように活用するか、ぜひ教えてください。
– Danilo
