330-AWS SAP AWS 「理論・実践・一問道場」API Gateway ゲーム

type

status

date

slug

summary

理論

以下は ALB と API Gateway の簡潔な比較です。

特徴	ALB	API Gateway
使用ケース	EC2やLambdaへのリクエスト分散	REST APIの管理とデータ転送
スケーリング	自動スケーリング可能	自動スケーリング
セキュリティ	SSL/TLS、WAF統合	認証、APIキー、IAM、Cognito統合
API管理機能	基本的な負荷分散のみ	詳細なAPI管理（バージョン管理、スロットリング）
キャッシュ	提供なし	レスポンスキャッシュ機能あり
コスト	EC2、Lambdaの使用料	リクエスト数とデータ転送量に基づく

ALB: EC2やLambdaへのリクエスト分散に最適。

API Gateway: 詳細なAPI管理や認証、キャッシュが必要な場合に最適。

区別

ALB (Application Load Balancer) は 1対多 の関係です。

ALBは、1つのロードバランサーが複数のターゲット（EC2インスタンス、コンテナなど）にリクエストを振り分けます。
つまり、1つのエンドポイントに対する複数のリクエストを、複数のバックエンドに分配します。

API Gateway は 多対1 の関係です。

API Gatewayは、**複数のクライアント（例えば、モバイルアプリやウェブアプリ）**からのリクエストを受け付けて、1つのAPI Gatewayエンドポイントを介して処理します。
つまり、多くのクライアントが1つのAPI Gatewayにリクエストを送り、その後バックエンド（例えば、Lambda関数やEC2）に振り分けられます。

このように、ALBは1つのエンドポイントが複数のターゲットに振り分ける形であり、API Gatewayは複数のクライアントが1つのエンドポイントにリクエストを送る形です。

実践

略

一問道場

会社はモバイルゲームを開発しました。このゲームのバックエンドは、オンプレミスのデータセンターにある複数の仮想マシンで実行されています。ビジネスロジックはREST APIを使用して公開され、複数の機能があります。プレイヤーのセッションデータは中央のファイルストレージに格納されています。バックエンドサービスは、スロットリングとライブおよびテストトラフィックの区別のために異なるAPIキーを使用しています。ゲームバックエンドへの負荷は一日を通して変動します。ピーク時にはサーバー容量が不足し、プレイヤーセッションデータを取得する際にレイテンシーの問題もあります。経営陣は、ゲームの変動する負荷に対応し、低レイテンシーのデータアクセスを提供できるクラウドアーキテクチャを提案するようソリューションアーキテクトに求めています。APIモデルは変更しないことが前提です。

どのソリューションがこれらの要件を満たしますか？

A. REST APIをNetwork Load Balancer (NLB)で実装し、ビジネスロジックをNLBの背後にあるAmazon EC2インスタンスで実行します。プレイヤーのセッションデータはAmazon Aurora Serverlessに格納します。

B. REST APIをApplication Load Balancer(ALB)で実装し、ビジネスロジックをAWS Lambdaで実行します。プレイヤーのセッションデータはAmazon DynamoDBのオンデマンドキャパシティで格納します。

C. REST APIをAmazon API Gatewayで実装し、ビジネスロジックをAWS Lambdaで実行します。プレイヤーのセッションデータはAmazon DynamoDBのオンデマンドキャパシティで格納します。

D. REST APIをAWS AppSyncで実装し、ビジネスロジックをAWS Lambdaで実行します。プレイヤーのセッションデータはAmazon Aurora Serverlessに格納します。

解説

この問題では、ゲームの変動する負荷に対応し、低レイテンシーでデータアクセスを提供するアーキテクチャが求められています。特に、APIモデルの変更は避けたいという制約があり、どの選択肢が最適かを評価します。

解説：

A. REST APIをNLBで実装し、ビジネスロジックをEC2インスタンスで実行する

NLB（Network Load Balancer）は、トラフィックの分散を効率的に行うことができますが、通常はステートレスなトラフィック向けであり、REST APIに関しては管理の容易さやAPIルーティングの柔軟さに欠ける部分があります。

EC2インスタンスを使用すると、手動でスケーリングを調整する必要があり、トラフィックのピーク時に自動的にスケールする機能がないため、ゲームの変動する負荷にうまく対応できません。

Aurora Serverlessはスケーラブルですが、低レイテンシーアクセスに最適な設計ではないため、この選択肢は最適ではありません。

B. REST APIをALBで実装し、ビジネスロジックをLambdaで実行する

ALB（Application Load Balancer）は、Webアプリケーション向けに特化したロードバランサーで、APIのURLベースのルーティングや高度なトラフィック管理が可能です。これにより、柔軟なAPI管理が可能となります。

AWS Lambdaはサーバーレスで、トラフィックの変動に応じて自動的にスケールします。リクエスト数に合わせて実行されるため、コスト効率も高く、サーバー管理が不要です。

DynamoDBのオンデマンドキャパシティは、必要なときにスケールし、アクセスが増えるときでも高いパフォーマンスを維持できます。これにより、低レイテンシーのデータアクセスが実現できます。

C. REST APIをAPI Gatewayで実装し、ビジネスロジックをLambdaで実行する

API Gatewayは、REST APIの管理に最適化されたサービスで、非常に高いスケーラビリティと柔軟性を提供します。API Gatewayはリクエストのルーティング、認証、制限などを容易に管理でき、ゲームのような多くのリクエストを効率的に処理できます。

Lambdaと組み合わせることで、スケーラブルなアーキテクチャを提供し、リクエスト数に応じて自動的にスケールします。

DynamoDBのオンデマンドキャパシティは、セッションデータなどのストレージに最適で、高パフォーマンスと低レイテンシーでアクセスできるため、このアーキテクチャは非常に効率的で適しています。

D. REST APIをAppSyncで実装し、ビジネスロジックをLambdaで実行する

AppSyncは、GraphQL APIを管理するためのサービスです。REST APIを使用するという制約があるため、AppSyncは適切な選択肢ではありません。GraphQLはREST APIとは異なるアーキテクチャモデルであるため、この選択肢は要件を満たしません。

結論：

最適な解決策は C の選択肢です。API Gateway と Lambda の組み合わせは、スケーラビリティと低レイテンシーアクセスの両方を提供し、DynamoDBのオンデマンドキャパシティはデータアクセスに非常に適しています。これにより、ゲームの負荷変動にも柔軟に対応でき、性能が求められる環境で最適な解決策となります。