AWS EventBridgeでミリ秒レイテンシを実現：Amazon Keyチームによるイベント駆動アーキテクチャへの移行記

なぜイベント駆動アーキテクチャなのか

Amazon Keyチームはスマートホームアクセス管理ソリューションを運用する中で、典型的なマイクロサービス間の強結合問題に直面しました。あるサービスの障害が連鎖的に他のサービスに伝播するデッドロック状態が発生し、単一のデバイスベンダーの問題がシステム全体のパフォーマンスを低下させることもありました。こうした状況で、AWS EventBridgeを中心としたイベント駆動アーキテクチャ（EDA）は自然な選択でした。

本記事では、Amazon Keyチームが実際にどのようにEDAを設計・実装したのか、そのプロセスから得られたインサイトを実務にすぐ活かせる形でまとめました。

参考資料：Mastering millisecond latency and millions of events: The event-driven architecture behind the Amazon Key Suite

コア設計：Single-Bus, Multi-Account パターン

Amazon Keyチームが選択したアーキテクチャは、単一の中央イベントバス（Single Bus）を置き、各サービスチームが自身のAWSアカウントで独立して運用するマルチアカウントパターンです。この設計の主なメリットは以下の通りです。

• 明確な所有権の境界：サービスチームはビジネスロジックに集中し、DevOpsチームがイベントバス、ルール、ターゲットを一元管理します。
• 集中管理によるガバナンス：すべてのイベントルーティングパターンとセキュリティポリシーを一貫して適用できます。
• 運用の簡素化：単一バスによる複雑さの低減と論理的な分離を同時に実現します。
• セキュリティ強化：マルチアカウント構造で自然な分離を提供しつつ、必要な場合はアカウント間のイベントフローを制御します。

3つの主要コンポーネント

1. イベントスキーマリポジトリ（Schema Repository）

Amazon EventBridgeはスキーマ検出・ドキュメント機能を提供しますが、ネイティブのスキーマ検証機能はありません。Amazon Keyチームはこれを解決するために独自のスキーマリポジトリを構築し、**クライアント側検証（Client-side validation）**を選択しました。中央集権型の検証サービスも検討しましたが、追加インフラ管理とネットワークホップによるレイテンシを避けるため、この方式を採用しました。

このリポジトリは単一の真実源（Single Source of Truth）として機能し、スキーマのバージョン管理、変更履歴の追跡、パブリッシャーとサブスクライバー間のデータ互換性の保証に使用されます。

2. クライアントライブラリ（Client Library）

ビルド時にスキーマからコードバインディングを生成し、開発者にタイプセーフなインターフェースを提供します。主な機能は以下の通りです。

• ローカルスキーマに基づく事前検証：イベントがバスに発行される前に有効性をチェックします。
• 自動シリアライズ/デシリアライズ：パブリッシャーとサブスクライバーの両方がデータ変換を意識しなくて済むように抽象化します。
• 開発者体験の向上：共通の統合エラーの90%を標準化されたライブラリで解決しました。

3. サブスクライバー構築ライブラリ（Subscriber Constructs Library）

AWS CDK（Cloud Development Kit）で実装されたこのライブラリは、サブスクライバーアカウントに必要なインフラ（専用イベントバス、IAMロール、モニタリング）を自動プロビジョニングします。チームはビジネスロジックにのみ集中できます。

// サブスクライバーConstructsライブラリの使用例（実際のAmazon Key実装を簡略化）
import { SubscriberConstruct } from '@amazon-key/subscriber-library';

const subscriber = new SubscriberConstruct(this, 'MySubscriber', {
  centralEventBusArn: 'arn:aws:events:us-east-1:123456789012:event-bus/central-bus',
  subscriberAccountId: '210987654321',
  // 購読するイベントパターンを定義
  eventPattern: {
    source: ['com.amazon.key.delivery'],
    'detail-type': ['DeliveryCompleted']
  }
});

// CDKスタックに追加
subscriber.addToStack(this);

パフォーマンスと開発者体験の改善数値

Amazon KeyチームがEDAを導入した後に得られた具体的な成果です。

セキュリティとガバナンス

• 単一コントロールプレーンがすべてのイベントバスインフラを管理（100%）
• 自動化されたセキュリティ準拠チェックで不正なデータ交換パターンを100%ブロック
• リアルタイムモニタリングダッシュボードですべてのイベントフローとスキーマ変更を追跡
• スキーマリポジトリがシステム変更に対する完全な監査証跡を提供

まとめ：実務適用時の注意点

Amazon Keyの事例はイベント駆動アーキテクチャの強力さを示しています。ただし、実際のプロジェクトに適用する前にいくつか考慮すべき点があります。

注意点と限界

1. スキーマリポジトリのメンテナンス：独自構築したスキーマリポジトリは初期構築コストと継続的なメンテナンスが必要です。小規模チームやスタートアップでは、AWS EventBridgeの標準スキーマレジストリで十分な場合があります。
2. クライアントライブラリへの依存：全チームが同じクライアントライブラリを使用する必要があります。バージョン衝突や互換性問題が発生する可能性があります。
3. マルチアカウント管理コスト：アカウントが増えるほどAWS OrganizationsとIAMポリシー管理が複雑になります。十分なDevOpsスキルが必要です。
4. イベントスキーマの進化：下位互換性を保ちながらスキーマを進化させることは依然として難しい課題です。明確な非推奨ポリシーと移行パスが必要です。

次のステップとしての学習方向

• AWS EventBridge公式ドキュメントとベストプラクティスの学習
• イベントスキーマ設計パターン（CloudEvents、AsyncAPI）の理解
• 実際のプロジェクトに小規模なEDAをまず導入して経験を積む

合わせて読みたい記事

• 90日かかっていたインフラ構築を数時間に短縮したサンタンデールのプラットフォームエンジニアリング戦略
• ゲームをリアルタイム生成するAI、Waypoint-1の可能性と動作原理