サーバーレス画像処理パイプラインの信頼性向上
不動産ポータルを運営する企業が、物件写真の投稿機能を提供しています。利用者がアップロードした画像は Amazon S3 に保存され、S3 イベント通知が AWS Lambda 関数を呼び出してサムネイル生成とメタデータ抽出を行い、結果をプロビジョンドモードの Amazon DynamoDB テーブルに書き込みます。最近、内覧予約が集中する週末に「アップロードした写真が反映されない」という問い合わせが増えました。開発者がログを調査したところ、数千人が同時に投稿した時間帯に、Lambda の同時実行クォータへの到達と、DynamoDB へのデータ保存時の性能不足が同時に発生していることが判明しました。アプリケーションのパフォーマンスと信頼性を高める手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: B、D）
S3 イベント通知から Lambda を直接呼び出す構成では、同時実行がアカウントのクォータに達するとスロットリングが発生し、限られた再試行の後にイベントが失われる可能性があります。ここに Amazon SQS を挟むと、イベントはキューに保持され、Lambda はポーリングによって自分の処理能力に見合ったペースで取り出せます。処理に失敗したメッセージは可視性タイムアウトの経過後に再配信され、規定回数を超えたものはデッドレターキューへ退避できるため、選択肢 D はスパイク時の取りこぼしを根本から解消します。もう一方の症状である「データ保存時の性能不足」は、プロビジョンドモードの DynamoDB で書き込み要求が確保済みスループットを超えたときに発生するスロットリングであり、書き込み側の容量である WCU を実測に基づいて見直す (あるいはオンデマンドモードへ切り替える) 選択肢 B が正解です。選択肢 A の RCU は読み込み容量であり、問題は書き込み側で起きているため効果がありません。選択肢 C の ElastiCache は読み取りを高速化するキャッシュであり、Lambda の同時実行クォータにも DynamoDB の書き込みスロットリングにも作用しません。選択肢 E の S3 Transfer Acceleration は遠隔地からのアップロード転送を高速化する機能で、アップロード後の処理パイプラインの詰まりとは無関係です。
画像アップロード処理と配信のスケーラブル設計
旅行レビューサイトを運営する企業が、利用者が旅先の写真を自由にアップロードして検索できる画像サービスを構築しています。繁忙期のピークには世界中から最大 1 万人が同時に画像をアップロードします。アップロードされた画像には撮影地名のテキストが重ねて合成され、加工後の画像が同社のウェブサイト上で公開されます。ソリューションアーキテクトが実装すべき設計はどれですか。
解説を読む（正解: 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 による自前の進捗管理も不要な複雑さを持ち込みます。
Lambda からレガシーデータベースへの接続数の抑制
産業用ポンプメーカーが、受注処理のマイクロサービスを AWS Lambda 関数として実装しています。この関数は、オンプレミスのデータセンターで稼働する商用 SQL データベースにレコードを書き込みますが、そのデータベースはライセンス上、同時接続数が数十に制限されています。キャンペーン時など呼び出しが急増するとデータベースが接続過多で停止し、業務が止まる障害が繰り返し発生しています。VPC とデータセンターの間には AWS Direct Connect 接続が敷設済みです。同社はデータベースを過負荷から保護する必要があります。この要件を満たすソリューションはどれですか。
解説を読む（正解: D）
AWS Lambda は受信イベント量に応じて水平にスケールするため、コネクションプールを前提とする従来型のリレーショナルデータベースに対しては、瞬間的に許容量を超える接続を張ってしまいます。これを防ぐ定石が、キューによるバッファリングと予約済み同時実行 (reserved concurrency) による上限固定の組み合わせです。予約済み同時実行はその関数が同時に実行できる数の上限そのものを定めるため、値をデータベースの最大接続数より小さく設定すれば、どれだけ需要が急増しても接続数は上限内に収まります。さらに Amazon SQS を前段に置くことで、処理待ちの注文はキューに滞留するだけで失われず、可視性タイムアウトと再試行、デッドレターキューによって確実に処理されます。したがって選択肢 D が正解です。選択肢 B はデータベース本体を Aurora Serverless へ移す大規模な移行であり、既存データベースを保護するという要件を超えるうえ、AWS DataSync はファイルおよびオブジェクトの転送サービスであってデータベース移行には使えません (本来は AWS DMS を用います)。選択肢 C の Amazon RDS Proxy は Amazon RDS および Aurora を対象とするマネージドプロキシで、オンプレミスの自己管理データベースにアタッチすることはできません。選択肢 A の Amazon SNS はバッファリングを行わずプッシュ配信するため負荷がそのまま伝播し、プロビジョニングされた同時実行は実行環境を事前に初期化する機能であって同時実行数の上限を定めるものではないため、データベースは保護されません。