キーバリューとドキュメントの両モデルに対応するデータベース
新規に立ち上げる SaaS のバックエンドで、ユーザープロファイルは ID をキーとした単純な参照で取得し、通知設定は入れ子構造を含む JSON ドキュメントとして保存したいと考えています。いずれも一桁ミリ秒台の読み書き性能が求められ、項目の属性はリリース後も頻繁に追加される見込みです。サーバーやパッチ適用の管理は避け、トラフィックに応じて自動的にスケールする必要があります。最も適したデータベースを 1 つ選択してください。
解説を読む（正解: C）
Amazon DynamoDB は、キーバリューモデルとドキュメントモデルの両方をサポートするフルマネージドの NoSQL データベースです。項目はパーティションキー (と必要に応じてソートキー) で識別され、属性値としてマップやリストといった入れ子構造の JSON 相当のデータを保持できます。スキーマレスなので属性の追加が容易で、規模にかかわらず一桁ミリ秒台のレイテンシーを実現し、オンデマンドキャパシティーモードを選べばトラフィックに応じた自動スケールとサーバー管理不要の運用が可能です。したがって C が最適です。A の Amazon RDS for MySQL はリレーショナルデータベースで、事前定義のスキーマが前提となり、インスタンスサイズの管理やスケール操作も必要になるため、頻繁な属性追加と自動スケールの要件に合いません。B の Aurora PostgreSQL 互換エディションは JSONB 型でドキュメントを扱えますが、本質的にはリレーショナルデータベースであり、キーバリューストアとして設計されたものではなく、クラスターの容量管理も必要です。D の Amazon Redshift は分析用途の列指向データウェアハウスで、大量データの集計に最適化されており、オンラインでの高頻度な単一項目アクセスには適していません。
リアルタイム更新ランキングのサーバーレス設計
eスポーツの試合配信プラットフォームを運営する企業は、視聴者がハイライトクリップに投票し、その結果を順位表としてリアルタイムに表示する機能を追加します。同時接続するクライアントは数十万規模になる見込みで、投票が入るたびに各クライアントの画面へ最新の順位を即座に反映させる必要があります。投票データの保存先には、書き込みスループットに応じて自動的にスケールし、複数アベイラビリティーゾーンで冗長化されたマネージドなデータストアを利用したいと考えています。運用負荷を最小限に抑えつつこの要件を満たす構成はどれですか。
解説を読む（正解: B）
リアルタイムに変化するデータを多数のクライアントへ届ける場合、クライアント側からのポーリングはリクエスト数と表示遅延の両方を増やし、規模が大きくなるほど非効率になります。AWS AppSyncはマネージドなGraphQL APIサービスで、クエリとミューテーションに加えてサブスクリプションを備えており、データが更新された瞬間にWebSocket経由で接続中のクライアントへ更新をプッシュできます。データソースとしてAmazon DynamoDBを直接指定でき、DynamoDBはスループットに応じた自動スケールと複数アベイラビリティーゾーンでの冗長化をマネージドで提供します。
投票のたびにAppSyncのミューテーションでDynamoDBを更新し、順位表を購読しているクライアントへサブスクリプションで配信すれば、サーバーを管理することなく数十万接続規模のリアルタイム更新を実現できます。したがってBが要件に最も合致します。
Aは誤りです。Amazon EMRはバッチ処理や大規模分析に適したサービスで、投票ごとの即時反映には向かず、クラスター運用の負荷も増えます。Dも誤りです。REST APIとDynamoDBの直接統合自体は可能ですが、クライアントのポーリング方式では更新の遅延とリクエスト数の増大が避けられません。Cも誤りです。Lambda関数URLを定期的に呼び出す方式も同じくポーリングであり、30秒間隔ではリアルタイム性の要件を満たせません。
予測できない負荷変動に対応する画像処理基盤の刷新
旅行写真の投稿アプリを運営する企業が、Amazon EBS ボリュームを接続した Amazon EC2 インスタンス上で画像のリサイズと解析を行い、写真とタイトルなどの関連情報を保存しています。ユーザー数の急増に伴い処理が滞るようになりましたが、同時投稿数は時間帯にかかわらず不規則に変動しており、事前に予測することが困難です。ソリューションアーキテクトは、運用負荷を抑えつつ負荷変動に自動で追随できる構成へ刷新するよう求められました。
最も適切な改善案はどれですか。
解説を読む（正解: D）
予測が困難で不規則に変動するワークロードでは、リクエスト単位で自動的にスケールし、実行時間に対してのみ課金されるサーバーレス構成が最も適しています。AWS Lambda は同時実行数に応じて自動的に水平スケールし、インスタンスのサイジングやパッチ適用、EBS ボリュームの容量管理が不要になるため、運用負荷を抑えながら急激な投稿の増減に追随できます。画像本体のようなバイナリは実質無制限に拡張できるオブジェクトストレージである Amazon S3 に保存し、タイトルや撮影日時、解析結果といった構造化されたメタデータは、スループットを自動で拡張できる Amazon DynamoDB に保存するのが定石です。したがって、Lambda で写真を処理し、写真を S3、メタデータを DynamoDB に保存する構成が要件を満たします。Amazon Kinesis Data Streams はシャード単位でキャパシティーを設計するストリーミング取り込みサービスで、1 レコードの上限が 1 MB であるため画像本体の受け渡しには適さず、変動する負荷に対してシャード数の調整も必要になります。Amazon Data Firehose もストリーミングデータを S3 などへ配信するためのサービスであり、画像そのものの解析処理を行うものではないうえ、メタデータを検索可能な形で保持する用途にも向きません。EC2 の Auto Scaling をスケジュールスケーリングで運用する案は、負荷の増減する時間帯があらかじめ分かっているワークロードに有効な手法であり、予測できない不規則な変動には追随できません。