479-AWS SAP AWS 「理論・実践・一問道場」CloudFront 関数の活用

type

status

date

slug

summary

理論

高負荷時のアプリケーション信頼性向上のためのアプローチ

アプリケーションが高負荷に直面している場合、特定のモジュールに対する負荷を分散し、信頼性を高めるための効果的なアプローチは次の通りです。

サービスの分割とスケーリング:

アプリケーション内の異なるコンポーネント（例：チケット販売と待機室）を別のサービスとして分け、各サービスに異なるスケーリング構成を適用します。これにより、特定のサービスに過剰な負荷がかかっても、他のサービスに影響を与えることなく、システム全体のパフォーマンスを保つことができます。

CloudFront 関数の活用:

CloudFront 関数を使用して、リクエストをエッジロケーションで高速に処理し、ユーザーがチケット購入可能かどうかを判断することで、バックエンドにかかる負荷を減らします。これにより、リクエストが到達する前に効率的にリダイレクト処理が可能になります。

JWT 情報の使用:

ユーザーを識別するために JWT（JSON Web Token）を使用し、リクエストのフローを制御します。JWT 情報をもとに、特定のユーザーをチケット購入サービスまたは待機室サービスに振り分けることができます。

高可用性とスケーラビリティ:

高可用性とスケーラビリティを実現するために、ECS や EKS を活用し、異なるサービスを適切にスケールアウトさせます。ECS クラスターや EKS クラスター内でのリソースの効率的な管理は、負荷分散やサービス間通信を最適化します。

これらの手法を組み合わせることで、アプリケーションは高負荷時でも安定性を保ちながら、リソースを効果的に利用できるようになります。

実践

略

一問道場

質問 #479

ある会社は、チケット購入アプリケーションの信頼性を向上させる必要があります。アプリケーションは、Amazon Elastic Container Service (Amazon ECS) クラスターで実行されています。会社は、Amazon CloudFront を使用してアプリケーションを提供しています。ECS クラスターの単一の ECS サービスが CloudFront ディストリビューションのオリジンです。

アプリケーションは、特定の数のアクティブユーザーのみがチケット購入フローに入ることを許可します。これらのユーザーは、その JSON Web Token (JWT) に格納された暗号化された属性で識別されます。それ以外のユーザーは、購入のための空き容量が出るまで待機室モジュールにリダイレクトされます。

アプリケーションは高負荷に直面しており、待機室モジュールは設計通りに機能していますが、待機室への負荷がアプリケーションの可用性に影響を与えています。この影響により、アプリケーションのチケット販売取引に悪影響を及ぼしています。

高負荷時にチケット販売取引の信頼性を最も高める解決策はどれですか？

A. 待機室用に ECS クラスター内に別のサービスを作成し、別のスケーリング構成を使用します。チケットサービスが JWT 情報を使用し、リクエストを適切に待機室サービスに転送することを確認します。

B. アプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移行し、待機室モジュールをチケットポッドと分けて別のポッドにします。チケットポッドを StatefulSet の一部にします。チケットポッドが JWT 情報を使用し、リクエストを適切に待機室ポッドに転送することを確認します。

C. 待機室用に ECS クラスター内に別のサービスを作成し、別のスケーリング構成を使用します。CloudFront 関数を作成し、JWT 情報を検査してリクエストをチケットサービスまたは待機室サービスに適切に転送します。

D. アプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移行し、待機室モジュールをチケットポッドと分けて別のポッドにします。AWS App Mesh を使用して、Kubernetes 用の App Mesh コントローラーをプロビジョニングします。mTLS 認証およびサービス間認証を有効にして、チケットポッドと待機室ポッド間の通信を保護します。チケットポッドが JWT 情報を使用し、リクエストを適切に待機室ポッドに転送することを確認します。

解説

C. 待機室用に ECS クラスター内に別のサービスを作成し、別のスケーリング構成を使用します。CloudFront 関数を作成し、JWT 情報を検査してリクエストをチケットサービスまたは待機室サービスに適切に転送します。

解説:

このアプローチは、主に以下の理由で適切とされます：

ECS クラスター内でのサービス分割:

待機室とチケット販売サービスを別の ECS サービスとして分け、それぞれに独自のスケーリング構成を適用します。これにより、待機室の負荷が高くてもチケット販売サービスへの影響を最小化できます。待機室のトラフィックが増えても、チケットサービスはスケールアウトを効率的に管理できます。

CloudFront 関数を使ったリクエストの適切な転送:

CloudFront 関数は、CloudFront のエッジロケーションでリクエストを処理し、パフォーマンス向上に寄与する軽量な関数です。この関数を使って、JWT 情報を検査し、ユーザーがチケット購入可能か、待機室に転送すべきかを判断するロジックを組み込みます。

CloudFront 関数は非常に低レベルで高速に動作するため、リクエストが届いた時点で迅速に判断してリダイレクトすることができます。これにより、アプリケーションのバックエンドに不必要な負荷をかけることなく、最適なサービス（チケットサービスまたは待機室）にリクエストを振り分けることができます。

スケーリングとリソース管理の分離:

待機室サービスのトラフィックとチケットサービスのトラフィックは異なるため、それぞれに別々のスケーリング設定を適用することで、リソースの最適化を図ります。これにより、高負荷時でもシステム全体のパフォーマンスを保つことができます。

運用のシンプルさ:

ECS 内でサービスを分割し、CloudFront 関数でリクエストを適切に処理する方法は、比較的シンプルで管理がしやすいです。特に、AWS サービス（ECS、CloudFront）を活用することで、他の技術やインフラストラクチャを複雑にすることなく、スケーラビリティと信頼性を高めることができます。

他の選択肢との違い:

A の選択肢も似たような構成ですが、CloudFront 関数を使用することは含まれていません。CloudFront 関数を使うことで、リクエストの処理がさらに軽量で効率的になります。

B と D は、EKS や AWS App Mesh などの新しいテクノロジーを導入するため、運用のオーバーヘッドが大きくなります。ECS のままで解決できる問題をわざわざ EKS に移行して、さらに複雑化する必要はありません。

結論:

C の選択肢は、ECS クラスター内でのサービス分割と CloudFront 関数を使った効率的なリクエスト処理により、シンプルで高パフォーマンスな方法です。このアプローチは、待機室サービスとチケットサービスの負荷分散と効率的なリソース管理を実現し、アプリケーションの可用性と信頼性を最も高めることができます。