Question#26(SAP-C02)

Question#26(SAP-C02)

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

アプリケーションでは、同時にチケット購入フローに入れるアクティブユーザー数を限定しています。対象ユーザーは JSON Web Token(JWT) 内の暗号化された属性によって識別されます。その他のユーザーは、購入可能な容量が空くまで待合室(waiting room)モジュールにリダイレクトされます。 現在、アプリケーションは高負荷を受けています。待合室モジュール自体は設計どおりに動作していますが、待合室への負荷がアプリケーション全体の可用性を阻害し、チケット販売トランザクションに悪影響を与えています。 高負荷時にチケット販売トランザクションの信頼性を最も高めるソリューションはどれですか。

正解:C

本件のボトルネックは、「待合室への大量アクセスがアプリケーション可用性を下げ、販売トランザクションに悪影響」という点です。最も重要な設計目標は、販売系(チケット購入フロー)を待合室系から疎結合化し、独立スケーリングできるようにすること、そして販売系のオリジンへ不要な到達をさせないことです。

選択肢 C は、
  1. 待合室を ECS の別サービスとして独立スケーリングさせ、販売系と障害・負荷分離を図る、
  2. CloudFront Functions(エッジ)で JWT を判定して待合室か販売系かを早期に振り分け、販売系オリジンに無駄なリクエストが到達することを防ぐ、 という二段構えで販売系の信頼性を最大化します。 エッジでの判定により、待合室対象ユーザーのトラフィックが販売系オリジンに入る前に遮断/分流されるため、販売系のバックエンド資源(ECS サービス、タスク、DB 等)を保護できます。さらに、待合室自体は別サービスとして独自にスケールアウトできるので、高負荷時も販売系の影響を最小にできます。
補足:CloudFront では複数オリジンキャッシュ動作(パスパターン)を組み合わせたルーティングが可能で、CloudFront Functions ではViewer リクエストでの軽量な判定・リダイレクトや URI 書き換え(=適切なキャッシュ動作へ誘導)などのエッジ制御が行えます。これにより「待合室用オリジン」と「販売系オリジン」をエッジで切り分ける設計が実現できます。

コメント

コメント

コメントする

目次