助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30673
問題を開く
ある会社は、WebSocketを使用したアプリケーションを開発している。アプリケーションへは毎秒500件のリクエストが発生すると予測される。なお、データベースはAmazon DynamoDBを使用する。
AWSのマネージドサービスを使用して実装するには、どのソリューションが最も適切か。

正解

Amazon API GatewayとAWS Lambdaを組み合わせる。DynamoDBをプロビジョニングモードに設定する

解説

Amazon API GatewayはAWSサービスと連携するAPIの作成や管理ができる機能です。API GatewayではREST APIとWebsocket APIの2種類のAPIを作成できます。

AWS Lambda(ラムダ)はサーバーレスでプログラムのコードを実行できるサービスです。Lambdaで実行されるコードを「Lambda関数」といい、Java、Node.js 、Pythonなど様々な開発言語に対応しています。

Amazon DynamoDBはKey-Value型のデータ形式をサポートするNoSQLのデータベースです。Amazon DynamoDBでは、テーブルに対する書き込み・読み込みの量と利用料金が関係しています。
- オンデマンドモード ... 書き込み・読み込みのリクエスト単位で利用料金がかかる
- プロビジョニングモード ... 1秒間に行う書き込み・読み込みの量で利用料金が異なる
オンデマンドモードのオンデマンド(On Demand)とは「要求に応じて」を意味する熟語であり、ユーザーが要求して利用した分だけのサービスが提供されることをいいます。DynamoDBの場合も同様に、リクエストを発行した分だけ料金が請求されます。
プロビジョニングモードは、オンデマンドモードの「どれだけ使ったか」とは反対に、読み込み量と書き込み量を予約しておくモードです。
リクエスト量やキャパシティの要件が予測可能な場合にはプロビジョニングモードを、リクエスト量が不明瞭なケースや利用した分だけの支払いをしたい場合はオンデマンドモードを選択すると、コストを抑えた運用ができます。
設問の場合はリクエスト量が予測されているので、DynamoDBを「プロビジョニングモード」に設定するのが適切です。

Amazon API Gateway、Lambda、DynamoDBはすべてマネージドサービスなので、サーバーのメンテナンスやキャパシティプランニングの必要なく、スケーラブルなアプリケーションを実装できます。

したがって正解は
・Amazon API GatewayとAWS Lambdaを組み合わせる。DynamoDBをプロビジョニングモードに設定する
です。

DynamoDBのプロビジョニングモードの書き込み・読み込みは、「キャパシティユニット」という単位で管理されています。これは1秒間にどれだけ読み込み・書き込みを行うかを予約する設定で、容量が大きいほど料金がかかります。

キャパシティユニットは、テーブル作成時にはWCU、RCUともに 5 に設定されています。キャパシティユニットの変更はいつでも行うことができます。
また、データアクセスの負荷に応じてキャパシティユニットを自動的にスケール(増減)することもできます。常に高いパフォーマンスを維持しておく必要がないため、コストを抑えたい場合に有用です。

その他の選択肢については、以下のとおりです。

・Amazon API GatewayとAWS Lambdaを組み合わせる。DynamoDBをオンデマンドモードに設定する
DynamoDBをオンデマンドモードは、ユーザーが要求して利用した分だけのサービスが提供されます。
リクエスト量の予測ができる場合は「プロビジョニングモード」に設定する方がコスト削減になるので、誤りです。

・Auto Scalingグループを作成し、EC2インスタンスを実行する。DynamoDBをプロビジョニングモードに設定する
EC2は仮想サーバーを提供するサービスであり、マネージドサービスではないので、誤りです。
EC2インスタンスのサーバーの監視や動作状況に応じたスケーリング、セキュリティパッチの適用などの運用をAWSユーザーが実施します。

・Auto Scalingグループを作成し、EC2インスタンスを実行する。DynamoDBをオンデマンドモードに設定する
EC2は仮想サーバーを提供するサービスであり、マネージドサービスではないので、誤りです。
また、リクエスト量の予測ができる場合は「プロビジョニングモード」に設定する方がコスト削減になります。

参考

【AWS Lambda】
AWS Lambda(ラムダ)はサーバーレスでプログラムのコードを実行できるフルマネージドサービスです。サーバーレスとは、EC2インスタンスなどのサーバーを必要とせずリクエスト発生時にだけプログラムが実行されるアーキテクチャのことです。サーバーレスアーキテクチャでは、インフラストラクチャの管理は完全にAWSによって行われます。

Lambdaを利用すると次のようなメリットがあります。
・プログラム実行環境の構築や運用が不要になる
・プログラムはリージョン内の複数のAZに分散して配置される(耐障害性・可用性の向上)
・プログラムへのリクエスト数に応じたスケーリングが自動的に行われる(拡張性の向上)

開発したプログラムを動作させるためには、通常、実行環境となるサーバーが必要です。サーバー管理は構築・運用ともに負担の大きな作業ですが、Lambdaを利用することにより煩雑な業務を行わなくて済むようになりプログラムの開発に集中できます。

【Lambda関数】
Lambdaで実行されるコードを「Lambda関数」といいます。
Lambda関数は以下のような特徴があります。
・開発言語:Java、Node.js、Pythonなど様々な開発言語に対応
・実行時間:最長15分
・課金方式:リクエスト数に基づく課金と実行時間(単価はメモリ量に依存)に基づく課金の合計
・実行タイミング:特定のイベントがトリガーとして発生したときに実行

ユーザーは、Lambda関数を実行するため
・Lambda関数のコード作成と更新、環境変数設定、IAMロール設定など、アプリケーションに関する設定
・Lambda関数を実行するメモリサイズや最大実行時間の指定など、リソースに関する設定
などを行います。

実行時間が15分以上になる処理や常時稼働が必要なアプリケーションには適していないので、EC2インスタンスやコンテナなどで運用する検討が必要です。

Lambdaを1年以上継続して利用する場合は「Compute Savings Plans」で契約すると、サービスを割引価格で利用できます。Compute Savings Plansは1年または3年の期間、一定のサービス使用量(1時間あたりの利用料金)を決めて契約することで、通常よりも低価格になる購入オプションです。

【Lambda関数のトリガー】
Lambda関数実行の起点となるイベントを「トリガー」といいます。以下はトリガーとして設定できるイベントの一例です。
・Amazon S3バケットにオブジェクトが作成された時
・Amazon DynamoDBのテーブルに変更があった時
・Amazon SQSのキューにメッセージが追加された時
・Amazon SNSからトピックが通知された時
・Amazon API Gateway経由で直接Lambda関数が呼び出された時

例えば、ユーザーからアップロードされた画像ファイルがS3バケットに保存(オブジェクトが作成)された時に、Lambda関数が実行されて画像ファイルの情報をDynamoDBに書き込むといった利用方法があります。


【Lambda関数のアクセス権限】
Lambda関数には実行ログを出力するために、CloudWatch Logsへのアクセス権限が割り当てられています。デフォルトではCloudWatch Logs以外へのアクセス権限はないので、Lambda関数から他のAWSサービスへアクセスさせたい場合はアクセス権限の設定が必要です。Lambda関数のアクセス権限は、他のAWSサービスへのアクセス権限を持つIAMロールによって付与します。その際、Well-Architected Frameworkの「最小権限の原則」に基づき、コード実行に必要な最低限の権限のみ割り当てることが推奨されています。

[Lambda関数にDynamoDBへのアクセス権限を割り当てる時のイメージ]


【Lambda関数のVPCアクセス】
作成したLambda関数はLambda専用のセキュアなVPCに配置されます。このLambda専用のVPCからは、インターネットや、インターネットを経由してパブリックサブネット内のAWSリソースにはアクセスできますが、プライベートサブネット内のAWSリソースへはアクセスできません。


Lambda関数からプライベートサブネット内のAWSリソースへアクセスさせたい場合は「VPCアクセス」の設定をします。VPCアクセスではアクセスしたいAWSリソースのあるVPCやサブネットの選択と、Lambda関数のセキュリティグループを設定します。VPCアクセスを設定するとLambda関数がサブネット毎に接続用のENI(Elastic Network Interface)を作成して、プライベートサブネット内のAWSリソースへアクセスします。
VPCアクセスを設定したLambda関数は、ENIを作成したサブネットへアクセスできるようになる代わりに、インターネットへアクセスできなくなります。


VPCアクセスを設定したLambda関数からインターネットへアクセスしたい場合は、プライベートサブネットからインターネットへアクセスする方法と同様に、NATゲートウェイまたはNATインスタンスを経由します。また、インターネットを経由せずにパブリックなAWSリソースへアクセスしたい場合は、VPCエンドポイントを経由します。


【Amazon API Gateway】
Amazon API GatewayはAWSサービスと連携するAPIの作成や管理ができる機能です。API(Application Programming Interface)とは、クライアントからのリクエストをアプリケーションサーバーに送り、アプリケーションサーバーからのレスポンスをクライアントへ返す接続口(インターフェイス)のことです。
下記はAPI Gatewayで作成したHTTP APIの実行例です。クライアントからHTTP(HTTPS)などでAPIを呼び出して、テキストやJSONなどの形式で得たい情報を取得します。


API Gatewayはマネージドサービスなので、Lambdaと組み合わせることで完全にサーバーレスでWebアプリケーションを実行できます。
例えばクライアントからのHTTPリクエストをAPI Gatewayで受信し、それをトリガーとしてLambda関数を実行させ、レスポンスをAPI Gateway経由で返すことができます。

API Gatewayで作成できるAPIは、クライアントとサーバー間の接続方法や機能によって以下の3種類があります。

■REST API(RESTful API)
クライアントからのリクエストに対してレスポンスを返す形式のAPIです。サーバーが扱う情報はURI(URL)で定義されており、クライアントはHTTP(HTTPS)でリクエストを送信することでレスポンスを得ます。
データベースの検索など、クライアントからのリクエストに応答するアプリケーションで使われます。
なお、REST API(RESTful API)とはREST(REpresentational State Transfer)という原則にのっとったAPIのことです。通信の状態が管理されない「ステートレス」な接続方式です。

[REST APIの処理イメージ]


■HTTP API
REST APIよりも低遅延かつコスト効率を高くする目的で設計されたAPIです。REST APIと同じ形式のAPIですが、APIキャッシュ(後述)を利用できないなど細かな差異があります。

■WebSocket API
クライアントとサーバー間でリアルタイムな情報のやり取りを目的とするAPIです。REST APIとは違い、継続的なデータの送受信を行えます。
チャットや株価情報のような常に情報をモニタリングするようなアプリケーションで使われます。
なお、WebSocket APIとはサーバー・クライアント間で双方向のセッションを確立できる技術を利用したAPIのことです。通信の状態を管理される「ステートフル」な接続方式です。

[WebSocket APIの処理イメージ]


【API キャッシュ】
Amazon API Gatewayにはクライアントへ送信したデータを保存する「API キャッシュ」機能があります。REST APIではどのクライアントからでも同一のリクエストであれば同一のレスポンスになります。API キャッシュではクライアントに送ったレスポンスをAPI Gatewayでキャッシュし、再度同一のリクエストを受け取るとキャッシュからデータを返します。API キャッシュから応答を返すことにより、Lambda関数の実行を省略できるのでレスポンス速度が向上します。

【API GatewayのVPCリンク】
Amazon API Gatewayで作成したAPIはユーザーが管理するVPC外に配置されます。そのため、作成したAPIからインターネットを経由してパブリックサブネット内のAWSリソースにはアクセスできますが、プライベートサブネット内のAWSリソースへ直接アクセスすることはできません。



API Gatewayからプライベートサブネット内のAWSリソースへアクセスさせたい場合は「VPCリンク」を作成します。これにより、APIとプライベートサブネット内のリソースとの間でインターネットを経由しないセキュアな通信が可能になります。
VPCリンク作成時に、アクセスしたいAWSリソース(下図の例ではEC2インスタンス)を直接指定することはできません。Network Load Balancerを対象として指定します。※対象として指定できるリソースはAPIの種類により異なります。



【API Gatewayのオーソライザー】
API Gatewayのオーソライザーを使用すると、APIへのアクセス制御を実装することができます。オーソライザーには、Amazon Cognito(*)のユーザープールを使用する方法と、Lambda関数を使用する方法があります。
※ Amazon Cognito: モバイルアプリケーションやWebアプリケーション向けのユーザー認証機能を提供するサービス

前者は、Amazon Cognitoが提供するマネージド型の認証機能を使用するため、開発者は認証プロセスについて自身で管理する必要がありません。
後者は、開発者自身が認証プロセスをLambda関数で作成する必要があります。独自のロジックでAPIへのアクセス制御を実装できるため柔軟性は高くなりますが、セキュリティ対策など管理の複雑さが増加します。



[Cognitoユーザープールを使用したオーソライザーでのアクセス制御のイメージ]


[Lambda関数を使用したオーソライザーでのアクセス制御のイメージ]


【独自ドメイン名の使用】
API Gatewayで作成したAPIへアクセスするためのURLに、独自ドメイン名を設定することができます。独自ドメイン名を使用する場合、API Gateway側で独自ドメイン名の作成時に、AWS Certificate Manager(ACM)で管理されるSSL/TLS証明書を選択します。この時に使用する証明書は、APIのエンドポイントタイプによって異なる場合があります。リージョン別のエンドポイントを使用している場合には、同じリージョンのACMで発行またはインポートされた証明書を使用します。エッジ最適化(CloudFrontを組み合わせて使用する)エンドポイントを使用している場合には、us-east-1リージョンのACMで発行またはインポートされた証明書を使用します。

また、APIへアクセスするためのURLにワイルドカードを含んだ独自ドメイン名を使用することもできます。これにより、1つの独自ドメイン名を作成するだけで、「aaa.example.com」や「bbb.example.com」のようにサブドメインの異なる複数の独自ドメイン名をサポートすることが可能になります。この場合、指定する証明書も、ドメイン名にアスタリスクを含むワイルドカード証明書である必要があります。また、DNSサーバ側のDNSレコードも、ワイルドカードを用いた独自ドメイン名を登録します。

[独自ドメイン名の設定画面]

上に戻る

Amazon API GatewayとAWS Lambdaの組み合わせで毎秒50,000件のリクエストは捌くことは可能なのでしょうか?

公開日 2024/02/03

本問題では「アプリケーションへは毎秒50,000件のリクエストが発生すると予測される」とあり、正解は「Amazon API GatewayとAWS Lambdaを組み合わせる。」となっています。

Amazon API Gatewayのクォータではリクエスト上限が「10,000 リクエスト/秒 (RPS) 」、Lambdaのクォータでは同時実行数が「1,000」となっており、クォータの引き上げ申請を行わない限りリクエストを捌くのは難しく、「Auto Scalingグループを作成し、EC2インスタンスを実行する」の方が現実的に思えました。

あくまでも「マネージドサービスを使うことが最優先で、クォータ引き上げ前提で回答すべき」なのでしょうか。
それとも、今回の設問にあるシーンではそもそも上記クォータを気にする必要がないのでしょうか。
もしご存じの方がいらっしゃれば、ご教示いただきたく存じます。

API Gatewayのクォータ
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/limits.html

Lambdaのクォータ
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html

2024/02/05 18:00

ご対応ありがとうございました。


コメント

この返信に対して
コメントを記入できます

スタッフからの返信

s staff_satomi

2024/02/05 10:50

makoni1128様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。

この投稿に対して返信しませんか?