re:Invent 2024: AWSがEventBridge Pipesでアプリ統合を簡素化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Integrating applications with Amazon EventBridge Pipes (API218)
この動画では、AWSの200以上のサービスを接続する際に必要となる統合コード（Glue Code）の課題と、その解決策としてのAmazon EventBridge Pipesについて解説しています。Amazon EventBridge Pipesはソースとターゲットをシンプルに接続でき、フィルタリング、エンリッチメント、トランスフォーメーションといった機能を提供します。実際のデモでは、Kinesis間でのデータ転送や、SQSからStep Functionsへの連携において、ZendeskのAPI Destinationを活用したエンリッチメントの実装例が示されています。従来のGlue Codeでは必要だった認証やエラー処理、パフォーマンステストなどの実装が不要になり、より効率的なサービス連携が実現できることが具体的に示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EventBridge Pipesの紹介：サービス連携の新たな可能性
ご紹介ありがとうございます。プレゼンテーションを始める前に、皆様にご協力をお願いしたいことがあります。まだ何のことかわからないかもしれませんが、私がある言葉を言ったら、できるだけ大きな声でブーイングをお願いします。今日のその言葉は「Glue Code」です。これは本当に嫌なもので、深夜2時に何か問題が起きた時に私たちを起こすものです。もう一度言います：Glue Code。もっと多くの人にブーイングしていただいても構いません。このような敵対的な観客に対して、セキュリティが警戒するくらいがちょうどいいですね。
私はJeff Orieculaと申します。Amazon EventBridgeチームのSenior Technical Product Managerで、特にPipesを担当しています。 ここで、AWSのサービスを5つ挙げられる方はいらっしゃいますか？何人かいますね。10個は？20個は？ AWSは200以上の異なるサービスを提供しています。これらのサービスをビルディングブロックとして組み合わせることで、完全なアプリケーションを作ることができます。これにより、インフラストラクチャーの準備やデータセンターの運用といった差別化につながらない重労働を心配することなく、アプリケーションの差別化要因に集中できるため、より速くイノベーションを実現できます。
これらのサービスは非常に強力で、適切な仕事に適切なツールを使用することができます。これらのビルディングブロックを組み合わせると、スケーラブルで信頼性が高く、回復力のあるソリューションが得られ、ニーズの変化に応じてさらにビルディングブロックを追加することができます。 これらのブロックを接続するのは、ボックス間に線を引くだけなので、とても簡単そうに見えます。ここでは、あるKinesisストリームから別のストリームにイベントを渡している例を示しています。例えば、巨大なKinesisストリームから、コンシューマーが処理しきれないことを防ぐために、イベントの一部を小さなKinesisストリームにコピーしたい場合などが考えられます。
ここで見えていないのは、このKinesisデータを一方のストリームから他方に移動させるために必要なコード、つまり私たちが統合コードまたはGlue Codeと呼ぶものです。 このGlue Codeは、差別化につながる処理は何も行わず、単にイベントをある場所から別の場所に転送するだけです。Glue Codeはそれほど悪くは見えませんが、実際に書いて保守する段階になると話は変わってきます。例えば、テクノロジーにはそれぞれ独自の特徴があります。Amazon Kinesis Data Streamsを使用する場合、Kinesis Client Libraryを理解し、Shardを理解し、順序を維持するためのSequence IDを理解する必要があります。
例えば、何らかの理由でAmazon SQSに切り替えたい場合、状況は全く異なります。 エラー処理やリトライ、認証、レート制御、パフォーマンステスト、負荷に対応するための適切なメモリ割り当ての確認など、さらに多くの考慮が必要です。デプロイメントについても心配しなければなりません。そして最悪なのは、気付かなかった小さなバグがあり、CEOから午前4時に起こされて本番システムの修正を求められることです。
Amazon EventBridge Pipesについてご紹介させていただきます。これは各種サービスを接続するもので、左側にソース、右側にターゲットがあり、とてもシンプルです。しかし、EventBridgeの素晴らしい点は中間で行われる処理にあります。これは完全にオプションですが、非常に優れた機能です。フィルタリングでは、ソースからターゲットに配信されるイベントを選択できます。Pipesの注目すべき点として、フィルタにマッチしたイベントに対してのみ課金される点が挙げられます。これからお見せするデモの場合、費用は約0.0008セントほどです。エンリッチメントステップでは、ソースからのイベントに追加データを付加してからターゲットに渡すことができます。トランスフォーメーションは、ソースが送信するイベントがターゲットの期待するフォーマットと異なる場合に使用します。
ターゲットが求める形式に合わせるためにトランスフォーメーションを使用できます。さて、もう十分説明したでしょうか？ライブデモをご覧になりたい方はいらっしゃいますか？冗談です。まだ説明が足りませんね。 これから見ていただく内容について、もう少し説明が必要です。
EventBridge Pipesのライブデモ：Eコマースとサポートシステムの実践例
ある状況を想定してみましょう。あなたが世界的な巨大Eコマース企業で働いているとします。ウェブサイトのリンクがクリックされるたびにデータが送られる巨大なKinesisストリームがあります。このKinesisストリームにコンシューマーを接続しようとしていますが、うまく機能していません。完全にオーバーワhelm状態なのです。そこで考えたアイデアは、この巨大なKinesisストリームの代わりに、Pipeを使ってウェブサイトのセールスセクションからのイベントを取得し、より小さなKinesisストリームに送ることです。そしてそこにコンシューマーを接続するというものです。
それではデモに移りましょう。ライブデモあるあるですが、もちろん私のコンピューターはスリープ状態になってしまいました。何か問題が起きるとすれば、起きるものですよね。 OK、少し良くなってきました。もう少し作業が必要ですが。 まずは、この擬似的なクリックストリームデータを見てみましょう。後ろの方の皆さん、これは読めますでしょうか？ ここには500件のレコードがありますが、その中に私が本当に必要とする2つのレコードが埋め込まれています。ここでハイライトされているのが、acme.com/saleです。
では、これらのイベントをコンシューマーのKinesisストリームにフィルタリングするPipeを構築してみましょう。 大きなクリックストリームから始めて、EventBridge Pipesタブに移動し、接続をクリックします。 クールな名前を付けましょう - qya click processorです。 開始位置については、タイピングを少し減らすためにtrim horizonを使用します。 ここにフィルターがあり、 セールスデータを含むものだけをフィルタリングしたいと思います。幸い、チートシートを用意してありますので、これを貼り付けて、少し拡大して見やすくしましょう。
後ろの席からは確実に見えないと思いますが、ここで私が探しているのは、Page オブジェクト内の Data オブジェクト内にある ACME.com/sale というこのプレフィックスです。次のステップに進みましょう。 ズームアウトしますね。今回は Enrichment はスキップしますが、2つのデモを試してみたいと思います。 ターゲットとしては、私の Small Clickstream を使用します。 SmallClickStream を選択して、ランダムな Partition Key を設定し、この Pipe を作成しましょう。
Pipe の作成中に、コンソールに戻って、この大きな Kinesis ストリームに500件のレコードを投入してみましょう。 これでよさそうですね。Failed Record Count はゼロです。何が起こったか見てみましょう。Big Kinesis ストリームに戻ります。 時間はどうでしょうか？ちょうど良いですね。1340です。レコードがあるか確認してみましょう。あ、未来の時間になっていますね。問題ありません。 1339に多くのレコードがありますね。
SmallClickStream に移動して、こちらで何が起きたか見てみましょう。同じく1339を見てみます。まだ何もありませんね。大丈夫です。また何もありません。最初の Pipe が開始するまでに時間がかかることがありますから。 ここに2つのレコードがあります。これを取得して、 何が見えるか確認してみましょう。これをコピーして Base64 デコーダーに 貼り付けてデコードします。見てください、Sale ウェブサイトがあり、 ここで皆さん、大きな拍手をお願いします。 これは見逃せませんね。実際に入ってきたか確認してみましょう。1339ですね。よし。以前にも同じことがありました。1338が解決策かもしれません。デモの最後にもう一度確認して、実際に表示されるか見てみましょう。
スライドに戻りましょう。繰り返しになりますが、フィルタリング機能を使って Kinesis から Kinesis へ Pipe で接続しています。さて、もう少し面白いものをお見せしましょう。 再び、この大規模 Eコマース企業で働いているという設定ですが、今回はサポート組織にいます。最初のデモがうまくいかなかったので、これは都合が良いですね。でも大丈夫です。サポート組織で SQS からフィルタリングを使用していますが、今回は SQS キューにチケット ID とチケットステータスしかありません。Step Functions の処理に必要なのはチケット自体です。そこで Enrichment を使用して、Zendesk API にアクセスし、チケット ID を送信して、チケット全体を取得し、それを Pipes が Step Functions に転送します。
もう一度この魔法のボタンを押して、これを実行してみましょう。 事前に Support Ticket Processor という Pipe を設定しておきました。このケースで重要なのは、API Destination を使用している Enrichment ステップです。この API Destination がどのようなものか見てみましょう。 編集モードに入ります。 ここでは API Destination とエンドポイントを設定しました。この JSON の前にアスタリスクがあることにお気づきでしょうか。アスタリスクが何をするのか、後ほど詳しく説明します。ここでは GET を設定し、Invocation Rate Limit を300に設定しています。 認証には既存の Connection を使用しています。この Connection には Zendesk の API キーだけが含まれています。
あのスターとstar.jsonを覚えていますか。ここでキャンセルしてPipeに移動しましょう。 Enrichmentに直接進み、編集モードに入ります。これで特別なトリックは何もなく、とても簡単だということがお分かりいただけると思います。
このEnrichmentでは、Path Parameterを指定しています。 実際のイベントがどのように見えるか確認しておくと良いでしょう。これがSQSにフィードするものです。typeとticket IDだけを持っています。 Pipeに戻りますが、Path Parameterをフィードして、それをbodyのticket IDに入れて返します。 そうすると何が起こるかというと、先ほど見たスターの部分にそのticket IDが置き換えられます。例えば、このエンドポイントでは、1.jsonならID 1、21.jsonならID 21というように置き換わります。
ここでZendeskにログインしてみましょう。 すべてのチケットに移動します。Step Functionsで確認したいチケットは、オープン状態の最初のチケット「sample ticket, meet the ticket」と、解決済み状態のチケット「your demo is broken」です。これは先ほど見たようなフィルターで実現します。 画面は小さいですが、シンプルに「support ticket opened」または「support ticket resolved」というタイプを探しています。 実行する準備が整いました。
失敗することなくSQSに送信されました。Step Functionsに移動しましょう。ここではすべてのチケットが表示されるはずです。 2つのExecutionが表示されています。これは良い兆候です。1つを開いてinputを確認してみましょう。 PipeがStep Functionsにデータをフィードしていることが分かります。 少し表示を小さくしてみましょう。 Step Functionsのinputには、新規状態のチケット「sample ticket, meet the ticket」と、 Zendeskから取得したすべてのチケット情報が含まれていることが分かります。
ここまでで、SQSから Step Functionsまでの流れを、フィルタリングステップと途中でイベントを強化するAPI Destinationを使って示しました。AWSは 200以上の異なるサービスを提供しています。これらのソースをビルディングブロックとして組み合わせることができ、Pipesを使えばグルーコードなしでこれらのブロックを接続できます。私の名前はJeffです。 ご清聴ありがとうございました。また次回お会いできることを楽しみにしています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion