画像アップロード処理と配信のスケーラブル設計
旅行レビューサイトを運営する企業が、利用者が旅先の写真を自由にアップロードして検索できる画像サービスを構築しています。繁忙期のピークには世界中から最大 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 による自前の進捗管理も不要な複雑さを持ち込みます。
コンテナと自己管理型 Kafka の運用負荷削減
ペット用品を扱う中堅の EC 事業者は、アプリケーションサービスをコンテナ化し、パブリック IP を持つ複数の Amazon EC2 インスタンスへ直接デプロイして運用しています。同じ EC2 インスタンス群には自前で構築した Apache Kafka クラスターも同居しています。PostgreSQL データベースはすでに Amazon RDS for PostgreSQL へ移行済みです。同社は看板商品の新モデル発売により、プラットフォーム上の注文が大幅に増加すると見込んでいます。運用上のオーバーヘッドを削減しつつ新モデルのリリースを支えるには、現在のアーキテクチャにどの変更を加えるべきですか。
解説を読む（正解: D）
運用上のオーバーヘッドを減らしながらトラフィック増に備えるには、自社で管理している構成要素をマネージドサービスへ置き換え、同時にスケーリングを自動化することが基本方針になります。コンテナ化済みのアプリケーションは Amazon EKS のコントロールプレーンに任せ、データプレーンを AWS Fargate にすればワーカーノードのパッチ適用やキャパシティー管理そのものが不要になり、Application Load Balancer と組み合わせて需要に応じた自動スケーリングも実現できます。自前運用の Apache Kafka は Amazon MSK に移すことで、ブローカーの構築、バージョンアップ、障害ノードの置換といった運用作業が AWS 側に移ります。読み取り負荷の増加に対しては RDS のリードレプリカを追加することで参照クエリを分散でき、静的コンテンツを Amazon CloudFront 経由で Amazon S3 から配信すればオリジンへの負荷とデータ転送コストを同時に抑えられます。これらをすべて満たすのが選択肢 D です。選択肢 A と B は EC2 と Auto Scaling グループの自己管理を続ける点で運用負荷が残り、さらに既存の Kafka ベースのアプリケーションを Kinesis Data Streams に置き換えるには大規模なコード改修が必要になります。加えて静的コンテンツを S3 から直接配信するだけでは CDN によるキャッシュ効果が得られません。選択肢 C は EC2 上に Kubernetes クラスターを自前構築するため、コントロールプレーンとノードの両方を運用し続けることになり、目的である運用負荷の削減に逆行します。
3 層モノリスの移行でスケーラビリティと運用負荷を両立する
ある自治体の外郭団体は、自前のデータセンターで 3 層構成のイベントチケット販売システムを運用しています。フロントエンドは Apache HTTP Server 群、中間層は Tomcat 上の単一の Java モノリシックアプリケーション、ストレージ層は PostgreSQL データベースです。先日の人気公演の抽選開始時にシステムがダウンし、住民はチケットを購入できませんでした。事後分析では 3 層すべてが過負荷となり、アプリケーションが応答を停止し、データベースは読み取り処理で容量上限に達していたことが判明しました。同団体は今後も同様の大型公演を複数予定しています。ソリューションアーキテクトは、スケーラビリティを最大化しつつ運用上の労力を最小限に抑える AWS 移行計画を立てる必要があります。この要件を満たす手順の組み合わせはどれですか。3 つ選択してください。
複数選択問題です (正解 3 つ)。選んでから判定してください。
解説を読む（正解: A、C、E）
抽選開始時のような瞬間的なトラフィック集中に耐えるには、各層をそれぞれ独立してスケールさせつつ、インフラの面倒を AWS 側に任せることが重要です。まず静的コンテンツは Amazon S3 に置いて Amazon CloudFront から配信すれば、エッジで実質無制限にスケールし、サーバー管理も不要になります (選択肢 A)。次に Java モノリスは、コード変更をほとんど伴わずに AWS Elastic Beanstalk へ再ホストでき、Elastic Beanstalk が Auto Scaling グループ、ロードバランサー、プラットフォーム更新をまとめて管理してくれるため、最小の労力でスケールアウトできるようになります (選択肢 C)。読み取り容量が上限に達したという課題は、AWS DMS で Amazon Aurora PostgreSQL へ移行し、Aurora Auto Scaling で負荷に応じてリードレプリカを自動増減させることで解消できます (選択肢 E)。選択肢 B は誤りで、EC2 への再ホストでは OS やミドルウェアのパッチ適用が残り、EFS を挟む構成は静的配信としては CloudFront より遅くコストも高いため、運用負荷を最小化するという要件に反します。選択肢 D も誤りで、マイクロサービス化とコンテナ化はスケーラビリティこそ高いものの、モノリスの分解という大規模なアプリケーション改修が必要であり、労力を最小限に抑えるという条件に合致しません。選択肢 F も誤りで、単一の大きな EC2 インスタンスへのスケールアップは単一障害点を残したままであり、読み取り負荷をスケールアウトで吸収できず、データベース管理の運用負荷もそのまま残ります。