サーバーレス画像処理パイプラインの信頼性向上 不動産ポータルを運営する企業が、物件写真の投稿機能を提供しています。利用者がアップロードした画像は Amazon S3 に保存され、S3 イベント通知が AWS Lambda 関数を呼び出してサムネイル生成とメタデータ抽出を行い、結果をプロビジョンドモードの Amazon DynamoDB テーブルに書き込みます。最近、内覧予約が集中する週末に「アップロードした写真が反映されない」という問い合わせが増えました。開発者がログを調査したところ、数千人が同時に投稿した時間帯に、Lambda の同時実行クォータへの到達と、DynamoDB へのデータ保存時の性能不足が同時に発生していることが判明しました。アプリケーションのパフォーマンスと信頼性を高める手順の組み合わせはどれですか。2 つ選択してください。
A DynamoDB テーブルの読み込みキャパシティーユニット (RCU) を評価して調整する。 B DynamoDB テーブルの書き込みキャパシティーユニット (WCU) を評価して調整する。 C Lambda 関数の処理性能を高めるために Amazon ElastiCache のキャッシュレイヤーを追加する。 D Amazon S3 と Lambda 関数の間に Amazon Simple Queue Service (Amazon SQS) キューを配置し、失敗したイベントの再処理ロジックを実装する。 E S3 Transfer Acceleration を有効にして、利用者に低レイテンシーのアップロードを提供する。
判定する 複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: B、D） S3 イベント通知から Lambda を直接呼び出す構成では、同時実行がアカウントのクォータに達するとスロットリングが発生し、限られた再試行の後にイベントが失われる可能性があります。ここに Amazon SQS を挟むと、イベントはキューに保持され、Lambda はポーリングによって自分の処理能力に見合ったペースで取り出せます。処理に失敗したメッセージは可視性タイムアウトの経過後に再配信され、規定回数を超えたものはデッドレターキューへ退避できるため、選択肢 D はスパイク時の取りこぼしを根本から解消します。もう一方の症状である「データ保存時の性能不足」は、プロビジョンドモードの DynamoDB で書き込み要求が確保済みスループットを超えたときに発生するスロットリングであり、書き込み側の容量である WCU を実測に基づいて見直す (あるいはオンデマンドモードへ切り替える) 選択肢 B が正解です。選択肢 A の RCU は読み込み容量であり、問題は書き込み側で起きているため効果がありません。選択肢 C の ElastiCache は読み取りを高速化するキャッシュであり、Lambda の同時実行クォータにも DynamoDB の書き込みスロットリングにも作用しません。選択肢 E の S3 Transfer Acceleration は遠隔地からのアップロード転送を高速化する機能で、アップロード後の処理パイプラインの詰まりとは無関係です。
画像アップロード処理と配信のスケーラブル設計 旅行レビューサイトを運営する企業が、利用者が旅先の写真を自由にアップロードして検索できる画像サービスを構築しています。繁忙期のピークには世界中から最大 1 万人が同時に画像をアップロードします。アップロードされた画像には撮影地名のテキストが重ねて合成され、加工後の画像が同社のウェブサイト上で公開されます。ソリューションアーキテクトが実装すべき設計はどれですか。
A アップロードされた画像を Amazon Elastic File System (Amazon EFS) に保存する。各画像に関するアプリケーションログを Amazon CloudWatch Logs に送信する。CloudWatch Logs を参照して処理対象の画像を判断する Amazon EC2 インスタンスのフリートを作成し、加工後の画像を Amazon EFS 上の別ディレクトリに置く。Amazon CloudFront を有効化し、オリジンをフリート内の 1 台の EC2 インスタンスに設定する。 B アップロードされた画像を Amazon S3 バケットに保存し、Amazon Simple Notification Service (Amazon SNS) へメッセージを送る S3 イベント通知を設定する。Application Load Balancer (ALB) の背後に Amazon EC2 インスタンスのフリートを作成し、Amazon SNS からメッセージをプルして画像を加工し Amazon Elastic File System (Amazon EFS) に置く。SNS のメッセージ量の Amazon CloudWatch メトリクスで EC2 インスタンスをスケールアウトする。Amazon CloudFront を有効化し、オリジンを EC2 インスタンス前段の ALB に設定する。 C アップロードされた画像を、Amazon EC2 スポットインスタンスのフリートにマウントした共有 Amazon Elastic Block Store (Amazon EBS) ボリュームに保存する。各画像と処理済みかどうかを保持する Amazon DynamoDB テーブルを作成する。Amazon EventBridge ルールで EC2 インスタンスをスケールアウトする。Amazon CloudFront を有効化し、オリジンを EC2 フリート前段の Elastic Load Balancer に設定する。 D アップロードされた画像を Amazon S3 バケットに保存し、Amazon Simple Queue Service (Amazon SQS) キューへメッセージを送る S3 イベント通知を設定する。SQS キューからメッセージを取得して画像を加工し、別の S3 バケットに置く Amazon EC2 インスタンスのフリートを作成する。キューの深さの Amazon CloudWatch メトリクスで EC2 インスタンスをスケールアウトする。Amazon CloudFront を有効化し、オリジンを加工済み画像を格納した S3 バケットに設定する。
解説を読む（正解: D） ユーザーからのアップロードを受けて非同期に加工し、その結果を世界中へ配信するワークロードでは、オブジェクトストレージへの直接保存、キューによる処理の疎結合化とキュー長に基づくスケーリング、CDN による配信という 3 点が定石になります。正解の構成では、アップロード先を Amazon S3 とし、S3 イベント通知で Amazon SQS にメッセージを送ります。ワーカーの EC2 フリートはキューからメッセージを取得して画像にテキストを合成し、結果を別の S3 バケットへ書き戻します。SQS の可視性タイムアウトと再配信により、ワーカーが途中で落ちてもメッセージは失われず処理がやり直されます。スケーリングはキューの深さ (ApproximateNumberOfMessagesVisible) の CloudWatch メトリクスに基づいて行えば、ピーク時の 1 万ユーザーの同時アップロードにも追随できます。配信は加工済み画像を格納した S3 バケットを Amazon CloudFront のオリジンにすることで、エッジキャッシュから世界中の閲覧者へ低遅延で届けられます。EFS と CloudWatch Logs を使う選択肢は、ログを処理待ちキューの代用にするという不適切な設計であり、さらに CloudFront のオリジンをフリート内の 1 台の EC2 インスタンスにしている点が明確な単一障害点になります。SNS を使う選択肢は、SNS がプッシュ型でメッセージを保持しないため EC2 側から「プルする」ことができず、処理失敗時の再試行も担保されません。共有 EBS ボリュームを使う選択肢は、EBS を多数のインスタンスから自由に共有できるという前提自体が誤っており (Multi-Attach は同一アベイラビリティーゾーン内かつ限定的な用途)、スポットインスタンスの中断や DynamoDB による自前の進捗管理も不要な複雑さを持ち込みます。
書き込みスパイクを吸収する疎結合アーキテクチャ ある地方自治体が、住民向けの健診予約サイトを AWS 上で運用しており、バックエンドは Amazon RDS for PostgreSQL の DB インスタンスです。サイトには住民の連絡先や希望日時を登録するフォームがあり、地元テレビでの告知直後に予測不能な大量アクセスと書き込みが集中すると見込まれています。ソリューションアーキテクトは、既存のデータモデルを一切変更せず、送信された登録がデータベースにコミットされる前に失われないようにする必要があります。この要件を満たす構成はどれですか。
A 告知の直前に DB インスタンスをより大きなクラスへスケールアップし、イベント終了後にスケールダウンする B Amazon ElastiCache for Memcached を DB インスタンスの前段に配置して書き込みキャパシティを増強する C データストアを Amazon DynamoDB へ移行し、Auto Scaling でスループットキャパシティを管理する D Amazon SQS でアプリケーション層とデータベース層を分離し、キューからアイテムを取り出して DB インスタンスへ書き込む AWS Lambda 関数を構成する
解説を読む（正解: D） 予測不能な書き込みスパイクに対して「1 件も落とさない」ことを保証するには、リクエストを受け付ける層と永続化する層を切り離し、間に耐久性のあるバッファを挟むのが定石です。Amazon SQS はメッセージを複数のアベイラビリティーゾーンに冗長化して保持するため、データベースの処理能力を超える流量が来ても、キューに滞留させたうえで一定のペースで書き込めます。選択肢 D は AWS Lambda がキューをポーリングして RDS へ書き込むため、データモデルを変更せずにバッファリングを実現でき、失敗したメッセージも可視性タイムアウト後に再処理されます。選択肢 B の ElastiCache for Memcached は読み取りをキャッシュする仕組みであり、データベースの書き込みスループットを増やす効果はありません。選択肢 C は Amazon DynamoDB への移行を伴い、リレーショナルなデータモデルを作り直すことになるため「データモデルを変更しない」という前提に反します。選択肢 A のスケールアップはインスタンスクラス変更時に再起動を伴ううえ、必要なピーク性能を事前に見積もれないため、想定を下回るサイズを選んだ場合に書き込みが失われるリスクが残ります。