サーバーレス画像処理パイプラインの信頼性向上
不動産ポータルを運営する企業が、物件写真の投稿機能を提供しています。利用者がアップロードした画像は 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 は遠隔地からのアップロード転送を高速化する機能で、アップロード後の処理パイプラインの詰まりとは無関係です。
グローバル公開に向けた読み取り中心サイトの応答時間短縮
料理動画のサブスクリプションサイトを運営するメディア企業が、今月から初めて世界同時配信を開始します。現在のサイトは、ウェブ層の前段に Application Load Balancer、ウェブ層とアプリケーション層に Amazon EC2 インスタンスのフリート、バックエンドに Amazon Aurora MySQL という構成です。ページの多くはレシピ画像やサムネイルなどの静的コンテンツを含んでおり、トラフィックのほぼすべてが読み取りです。同社は配信開始直後にインターネットトラフィックが大幅に急増すると予想しており、最初の 1 週間はパフォーマンスを最優先とする方針です。世界中のユーザーに対するシステム応答時間を短縮するために取るべき手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: D、E）
世界中のユーザーの応答時間を短縮するには、ユーザーに近い場所でコンテンツを返すことと、動的処理とデータ読み取りをユーザーに近いリージョンで完結させることの両方が必要です。Amazon CloudFront は世界中のエッジロケーションで静的コンテンツをキャッシュし、動的リクエストも AWS のバックボーン経由でオリジンへ転送するため、初回アクセス以外のラウンドトリップを大幅に短縮できます。これを Route 53 のレイテンシーベースルーティングと組み合わせれば、ユーザーは最も速いリージョンのスタックへ誘導され、Auto Scaling グループが急増するトラフィックを吸収します (E)。さらに Aurora Global Database は専用のストレージ層レプリケーションによって、通常 1 秒未満の遅延でセカンダリリージョンに読み取り可能なクラスターを提供するため、読み取り中心のワークロードを各リージョンでローカルに処理でき、静的アセットを S3 のクロスリージョンレプリケーションで各地に配置すればオリジンまでの距離も縮まります (D)。A はウェブサーバーを S3 に置き換えるとしていますが、本サイトは動的サイトであり静的ホスティングだけでは成立せず、Aurora の論理レプリケーションは Global Database より遅延が大きく運用も煩雑です。B の AWS Direct Connect はオンプレミス拠点と AWS を結ぶ専用線サービスであり、インターネット経由でアクセスする一般消費者の応答時間には寄与しません。C は Aurora から RDS for MySQL への移行でむしろ読み取りスケーラビリティが下がり、サブネット配置の変更はセキュリティ上の話でレイテンシーとは無関係です。
廃止候補ワークロードの特定
通信事業者が 1,100 台のオンプレミスサーバーの移行を計画しています。過去のプロジェクトで構築されたまま放置されているサーバーが相当数含まれていると推測されており、移行を開始する前にそれらを廃止 (リタイア) して移行対象そのものを減らしたいと考えています。すべてのサーバーには AWS Application Discovery Agent が導入済みで、90 日分の性能データとネットワーク接続データが収集されています。移行チームは、CPU とメモリの使用率が継続的に極めて低く、かつ他システムからの受信 TCP 接続が一切観測されていないサーバーを廃止候補として抽出したいと考えています。追加の開発と運用の手間を最小限に抑えてこれを実現する方法はどれですか。
解説を読む（正解: A）
AWS Application Discovery Service のエージェントは、システム構成と時系列の性能データに加えて、実行中のプロセスと TCP および UDP のネットワーク接続を収集します。さらにデータ探索機能を有効にすると、収集されたこれらの詳細データが Amazon S3 バケットに継続的にエクスポートされ、AWS Glue のデータカタログが自動で作成されて Amazon Athena から SQL でクエリできるようになります。A はこの仕組みをそのまま利用し、性能データと接続データを結合して「使用率が低く、かつ受信接続が観測されないサーバー」という廃止候補の条件をクエリ 1 本で表現できるため、追加のエージェント導入も独自開発も不要で要件に最も適合します。B は既にエージェントが入っている環境にもう 1 種類のエージェントを追加する二重投資であるうえ、CloudWatch エージェントはサーバー間の受信 TCP 接続の有無というトポロジー情報を収集しないため、廃止判定の中核となる条件を満たせません。C は使われていない可能性のあるサーバーまで先に移行してしまう方式で、移行工数とライセンス、EC2 の稼働コストを無駄に消費するため、移行対象を事前に減らすという目的に反します。D の Migration Evaluator は総保有コストの比較を目的としたサービスで、想定コストの低さは単にスペックが小さいことを意味するに過ぎず、実際に利用されているかどうかの判断材料にはなりません。