この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
アノテーション テクニカルサポートの川崎です。
本記事は AWS re:Invent 2022 のセッションレポートとなります。
概要
イベント駆動型アーキテクチャは、分離されたコンポーネントを使用してアプリケーションのスケーリングと保守を容易にする最新のアプリケーションで一般的です。 分離されたイベント駆動型アプリケーションを構築するために、開発者は、Amazon Kinesis、Amazon SQS、Amazon DynamoDB、Amazon API Gateway、AWS Lambda、Amazon ECS など、イベントの発行または消費をサポートする特殊なサービスを利用します。 AWS 全体で異なるサービスを接続するには、開発者が各サービスの API とニュアンスを学習すると同時に、これらのサービスを接続するための統合コードを作成、維持、スケーリングする必要があります。 このセッションでは、EventBridge パイプを活用して、複数のサービスを統合する際の時間、コスト、および複雑さを軽減して、イベント駆動型アーキテクチャを実現する方法を学びます。
セッション動画
アジェンダ
- AWS サービスの統合
- Amazon EventBridge Pipes の紹介
- 一般的なユースケース
- デモ
- EventBridge Pipes のロードマップ (What's next?)
AWS サービスの統合
ビルディングブロック
- 200 以上の AWS サービス
- これらのサービスには、他のどのクラウド プロバイダーよりも多くの機能があります
- イノベーションを加速
- 差別化にフォーカス
専用設計されたサービス (Purpose-built services)
- AMAZON DYNAMODB
- 高性能で低レイテンシーのデータベース
- AWS LAMBDA
- サーバやクラスタなしでコードを実行
- AMAZON KINESIS
- リアルタイム分析
- AMAZON SQS
- 大規模にスケーラブルなキュー
- AMAZON S3
- 任意のサイズのデータを保存
ビルディングブロックを組み立てる
ビルディングブロックを組み立てる
- Amazon DynamoDB
- 統合コード
- Amazon SQS
統合の課題
- 各テクノロジー毎の微妙な差異
- エラー処理
- 順序
- ターゲットに関する考慮事項: 認証、再試行、レート制御
- 性能試験
- デプロイメント
- 運用と監視
統合コードのコスト
- 開発速度の低下
- バグのリスク増加
- 複雑さの増加
- 運用負荷の増加
- 非効率的なポーリング
-
高い TCO (総所有コスト)
特徴/機能
- イベントをフィルタリング
- 使用するイベントのサブセットを提供するフィルターを追加して、アプリケーションが必要なイベントのみを処理
- バッチ イベント
- イベント コンシューマーから取得し、バッチでイベント プロデューサーに配信することで、統合をより効率的に
- イベントの順序付け
- 順序付けが重要なアプリケーションに対して、イベントの順序付けを保証
- 高い同時実行性
- 高い並行性をサポートするため、大量のイベントを迅速に処理
- 高度なエンリッチメント (データ加工)
- AWS Lambda、AWS Step Functions、API Gateway、またはサードパーティ API への API 呼び出し (API Destinations を使用) を使用したエンリッチメントのサポートを提供
利点
- 記述する統合コードを少なく
- イベント プロデューサーとイベント コンシューマーをシームレスに接続する使いやすいインターフェイスを使用して、完全に管理された統合をすばやく構築
- フィルタリングと組み込みの統合でコストを節約
- イベント フィルターと組み込みの統合を使用して、コンピューティングと使用のコストを削減。必要なイベントのみを処理して支払い
- リアルタイムのソースイベント
- 新しいイベントをシームレスにポーリングする EventBridge Pipes を使用して、14 を超える AWS サービスにイベントを配信
- 運用負荷を軽減
- スケーラビリティ、セキュリティ、パッチ適用、およびインフラストラクチャのプロビジョニングについて心配することなく、サービスを確実に接続
- 料金: 64KB リクエスト 100 万件あたり $0.40
なぜ「Pipes」なのか?
- 1973年に Unix に初めて追加 ("|")
- Mary Shaw と Dave Garland の著書 "Software Architecture" のオリジナル・アーキテクチャ・スタイルの 1つ
- Gregor Hohpe の「エンタープライズ統合パターン」
Pipes はEvent Buses とどう違うか?
- Event Buses
- 多くのパブリッシャーから多くのコンシューマへ
- Pipes
- 単一のパブリッシャーから単一のコンシューマへ
待って、これはすべておなじみのように聞こえます...
- Pipes は、Lambda イベント ソース マッピングと同じポーリング インフラストラクチャを共有
- Pipes は、マネージド ポーリングと配信を 14 以上の AWS サービスに拡張
- Lambda イベント ソース マッピングは、150,000 人を超えるユーザー、100 万を超える ESM を展開し、1 秒あたり 100 万のトランザクションを処理する大規模な信頼性を備える
ユースケース
- サポートされているソースとターゲットの組み合わせにより、Pipes は 100 以上の統合を可能にし、追加の統合コードを必要としません
- 次のスライドから、最も一般的なユースケースをいくつか紹介していきます
ユースケース 1: キューを Step Function に接続
- コードを記述せずに Step Function で SQS キューを処理
- Amazon SQS
- Amazon EventBridge Pipes
- AWS Step Functions
ユースケース 2: Kinesis Data Streams の分割
- コードを記述することなく、多重化されたデータ ストリームを複数のドメイン ストリームに分割
-
Amazon Kinesis データ ストリーム
- フィルター
- Amazon EventBridge Pipes
-
Amazon Kinesis データ ストリーム
-
フィルター
- Amazon EventBridge Pipes
- Amazon Kinesis データ ストリーム
ユースケース 3: Kafka から API 宛先へ
- コードを記述せずに、Self-managed の Kafka クラスタを他の AWS サービスおよび HTTP API に接続 *
-
Self-managed Kafka
- フィルター
- Amazon EventBridge Pipes
-
Amazon SageMaker
-
フィルター
- エンリッチメント (データ加工)
- Amazon EventBridge Pipes
- API 宛先
ユースケース 4: DynamoDB から EventBridge へ
- コードを書くことなく、DynamoDB レコードの変更を複数の AWS サービスに発行
-
Amazon DynamoDB
- EventBridge Pipes
- EventBridge Event Buses
- AWS Step Functions
- Amazon SQS
- Amazon API Gateway
-
Amazon SageMaker
-
+15 のサポートされている AWS サービス (HTTP エンドポイントを含む)
EventBridge Pipes のロードマップ (What's next?)
- CloudWatch Logs のサポート
- VPC Endpoints / PrivateLink のサポート
- AWS SDK サービスの統合
- クロスアカウントでサービス提供
- アーカイブとリプレイのサポート
- SAM / CDK(L2) / IDE サポート
要約 - 何を学んだか
- Pipes は、オプションのフィルタリングと エンリッチメント (データ加工) の手順を使用して、データ ソースを宛先に接続
- EventBridge Pipesにより、コードを記述することなく、イベント プロデューサーとコンシューマーの間で 100 を超えるポイント ツー ポイント統合の組み合わせが可能に
- Pipes は、Lambda イベント ソース マッピングと同じポーリング インフラストラクチャを活用
イベント駆動型アプリケーションの EventBridge
- Event Buses
- Pipes
- Schedules
- Schema Registry
入門
- ブログ投稿
- AWS コンソール
4
