Amazon Web Services ブログ
GoDaddy がマルチリージョンのイベント駆動型プラットフォームをスケールで実装した方法
ドメイン登録とウェブホスティングサービスの大手グローバルプロバイダーである GoDaddy は、1997 年の設立以来、8,400 万を超えるドメインと 2,200 万人の顧客にサービスを提供してきました。さまざまな社内システムの中で、Customer Signal Platform は、顧客データや製品データを収集、分析、処理してビジネス成果を向上させるためのツールを提供します。GoDaddy では、このプラットフォームを使用することにより、自社のウェブサイトにおけるユーザーの訪問とインタラクションを追跡し、有意義なイベントデータを使用して顧客体験と全体的なビジネスパフォーマンスを向上させることができます。
現在、Customer Signal Platform は毎日 4 億件のイベントを処理しています。統合の拡大に応じて、GoDaddy は、近い将来に 1 日あたり 20 億イベントの処理を目指しています。
Customer Signal Platform を構築する際、GoDaddy はシステムアーキテクチャに 3 つの主要な要件を課しました。
- 運用負荷を最小限に抑えること。
- トラフィックの変化に応じて自動的にスケールすること。
- 高い可用性を実現し、すべての顧客シグナルを確実にキャプチャすること。
Amazon EventBridge イベントバス
多くのオプションを要件に照らし合わせて評価した結果、GoDaddy は、Amazon EventBridge イベントバスを使用して Customer Signal Platform を実装することを決定しました。EventBridge イベントバスは、イベントの受信、フィルタリング、変換、ルーティング、配信に使用できるサーバーレスイベントバスです。EventBridge はサーバーレスなので最小限の設定で始めることができ、自動的にスケールします。これで GoDaddy の最初の 2 つの要件が満たされます。
3 番目の要件を満たすには、ビジネス継続性を提供し、イベントがクライアントによって作成された瞬間から分析対象のプラットフォームに到達するまで失われないようにする必要がありました。EventBridge イベントバスには、この要件を念頭に置いてアプリケーションを構築するのに役立つ多くの機能が搭載されています。
GoDaddy が活用した主な機能はグローバルエンドポイントでした。EventBridge のグローバルエンドポイントを使用すると、高い信頼性を備えたシンプルな方法でイベント駆動型アプリケーションのビジネス継続性を向上させことができます。2022 年に追加されたこの新機能では、マルチリージョンのイベント駆動型アプリケーションを構築できます。
EventBridge のグローバルエンドポイント
グローバルエンドポイントを使用すると、アプリケーションからイベントが送信されるマネージド DNS エンドポイントを EventBridge で設定できます。次に、2 つの異なる AWS リージョンに 2 つのカスタムイベントバスを設定する必要があります。1 つはプライマリリージョンで、もう 1 つはフェイルオーバー (セカンダリリージョン) です。イベントのフェイルオーバーは、Amazon Route 53 のヘルスチェックで示されたヘルスに基づいて決定されます。ヘルスチェックが正常であれば、イベントはグローバルエンドポイントからプライマリリージョンのカスタムイベントバスにルーティングされます。ヘルスチェックが正常でない場合、グローバルエンドポイントはイベントをセカンダリリージョンのイベントバスに送信します。
グローバルエンドポイントの最もシンプルな構成はアクティブ/アーカイブ構成です。この構成では、ビジネス継続性とシンプルさを同時に実現できます。アクティブ/アーカイブ構成は 2 つの異なるリージョンを定義します。プライマリリージョンは、アプリケーションがデプロイされ、すべてのビジネスプロセスが実行されている場所です。アーカイブリージョンでは、カスタムバスのみがデプロイされ、すべてのイベントがアーカイブされます。
さらに、それぞれのリージョンのバスの間には双方向のレプリケーションルールがあります。通常、エラーがなければ、プライマリリージョンのカスタムバスに到着したイベントは、セカンダリリージョンのアーカイブカスタムバスに自動的にレプリケートされます。
フェイルオーバーの場合、グローバルエンドポイントはイベントをセカンダリリージョンにリダイレクトします。リダイレクトされたイベントは、別の機会に処理するためにアーカイブされます。
GoDaddy におけるグローバルエンドポイントの実装
GoDaddy ではビジネス継続性を維持しながら運用負荷を最小限に抑えるソリューションが必要とされていたので、グローバルエンドポイントとアクティブ/アーカイブ構成が採用されました。このアプローチでは、イベント処理ロジックをプライマリリージョンに配置し、問題が発生した場合に備えてセカンダリリージョンをセットアップできます。
この構成では、30 日間セカンダリリージョンにアーカイブされたイベントは期限切れになります。フェイルオーバーの場合、リアルタイムで処理する必要がないため、イベントはアーカイブに収集されます。24 時間 (レプリケーションルールの保持期間) 以内に問題が解決すると、イベントはプライマリリージョンに自動的に送信されます。24 時間以上経過した後に問題が解決した場合、イベントをプライマリーリージョンに再生する必要があります。
次の図は、現在のソリューションの概要を示しています。ソリューションは 2 つのリージョンを使用します。米国西部 (オレゴン) がプライマリリージョンで、イベントのプライマリコンシューマーであるデータレイクが配置されています。米国東部 (バージニア北部) はセカンダリリージョンです。イベントはさまざまなクライアントで生成され、クライアントから Amazon API Gateway に送信されます。GoDaddy は 2 つのリージョンに 2 つの API Gateway をデプロイしました。イベントは、最小のレイテンシーでクライアントから API Gateway に送信されます。そのために、GoDaddy では Amazon Route 53 で提供されるレイテンシーベースのルーティングを使用しています。その後、イベントは AWS Lambda 関数に送信されます。AWS Lambda はイベントを検証し、DNS レベルで EventBridge グローバルエンドポイントに転送します。
グローバルエンドポイントはアクティブ/アーカイブ設定で構成され、フェイルオーバーは Amazon CloudWatch アラームを監視する Route 53 ヘルスチェックによってトリガーされるように設定されています。そのアラームは、プライマリリージョンの IngestionToInvocationStartLatency メトリクスを監視します。
IngestionToInvocationStartLatency は、イベントが EventBridge によって取り込まれた時点からターゲットが設定済みのルールで初めて呼び出される時点までのイベントの処理時間を示すサービスレベルのメトリクスです。このメトリクスはバス内のすべてのルールで測定され、EventBridge サービスの状態を示します。30 秒を超える高レイテンシーが続く場合はサービスが中断しています。
システムが正常状態になると、イベントはグローバルエンドポイントからプライマリリージョンのカスタムイングレスイベントバスに転送されます。そのカスタムイベントバスではレプリケーションが有効化されているので、バスに到着したすべてのイベントは、セカンダリリージョンのカスタムイングレスイベントバスに自動的にレプリケートされます。
イングレスイベントバスによって受信されたすべてのイベントは、エンリッチメント関数に送信されます。この関数は基本的な検証と認証を行い、イベントデータのエンリッチメントを行ってさまざまなクライアントからのすべてのイベントが標準であることを保証します。
次にイベントはデータプラットフォームのイベントバスに転送され、さまざまなコンシューマーターゲットに送信されます。主なターゲットは、すべてのイベントを分析するデータレイクソリューションです。
ソリューションのインパクト
GoDaddy にとってビジネス継続性は重要であり、プラットフォームの問題によって顧客からのシグナルが失われることはありません。GoDaddy では、追加の運用オーバーヘッドを発生させることなく、Customer Signal Platform で処理するイベントの数を 1 日あたり 4 億件から 20 億件に拡大できると確信しています。
現在では、1 日あたり数億件に上るイベントを確実にシステムで処理できるようになり、GoDaddy は成長を続けることができます。下の図は、通常の日にグローバルエンドポイントによって取り込まれたイベントの数を示しています。
GoDaddy で使用されているアクティブ/アーカイブパターンはイベントの損失が防止されていますが、サービスが中断した場合でもイベントの処理の遅延を最小限に抑えるべき特定のユースケースが既に現れ始めています。イベントはセカンダリリージョンにレプリケートされるため、最も重要なコンシューマーを両方のリージョンにデプロイし、ミッションクリティカルなシステムでアクティブ/アクティブ構成に有効にすることができます。アクティブ/アクティブ構成により、プライマリリージョンとセカンダリリージョンの両方でイベントを並行して処理できるため、中断時でもイベントの処理が簡素化され、ビジネスの継続が可能になります。
Customer Signal Platform を構築するときのビジョンは、信頼性、スケーラビリティ、保守性に関する GoDaddy の厳しい基準を満たすと同時に、デベロッパーがビジネスニーズに集中できるようにプラットフォームのセルフサービスを維持することでした。GoDaddy は、このソリューションを構築するために Amazon EventBridge のグローバルエンドポイントとサーバーレステクノロジーを選択しました。
GoDaddy の Customer Signal Platform は、サーバーレステクノロジーによって実現するユースケースを示す好例です。GoDaddy は、差別化されていない手間のかかる作業を可能な限り多く処理するためにクラウドを活用することで、マルチリージョン戦略のイベントバスを設定する運用の複雑さを軽減するとともに、リージョンの障害が発生した場合のフェイルオーバーメカニズムを実装し、レプリケーションを有効にすることでイベントの損失を防止しています。グローバルエンドポイントのアクティブ/アーカイブ構成では、構成の変更を最小限に抑えてお客様のアプリケーションの可用性を向上させることができます。
EventBridge のグローバルエンドポイントを使い始める場合は、イベント駆動型アプリケーションに関するトークをチェックしてください。EventBridge のグローバルエンドポイントをフェイルオーバーイベントに使用する方法の実用的なデモについては、この Serverless Land リポジトリを参照してください。
— Marcia
原文はこちらです。