多言語の Web アプリを最短でリリースするデプロイ基盤 広告代理店の社内システム部門が、Ruby、Python、Java、Node.js など異なる言語で書かれた 12 本の Web アプリケーションを AWS 上でホストしています。各アプリは追加開発や新規リリースが頻繁に発生しており、アプリごとにデプロイ手順が異なるためリリース工数が肥大化していることが課題です。アーキテクトとして、既存アプリの大幅な書き換えを避けつつ、リリースまでの時間を最短化する方法を検討しています。最も適した方法はどれですか。
A 各アプリを個別の Docker イメージにパッケージし、EC2・ELB・Auto Scaling を一から定義した AWS CloudFormation テンプレートでリリースする B 各アプリを個別の Docker イメージにパッケージし、AWS Elastic Beanstalk の Docker プラットフォームにデプロイする C 各アプリを AWS CodeBuild でビルドし、成果物を AWS Lambda 関数として公開する D 各アプリを EC2 の AMI に焼き込み、リリースのたびに手動で AMI を作り直してインスタンスを置き換える
解説を読む（正解: B） AWS Elastic Beanstalk は、アプリケーションのコードやコンテナイメージをアップロードするだけで、EC2 インスタンス、Elastic Load Balancing、Auto Scaling グループ、モニタリングといった実行環境一式を自動的に構築・運用してくれるサービスです。Docker プラットフォームを選択すれば、言語やランタイムの違いをコンテナイメージの中に閉じ込められるため、Ruby、Python、Java、Node.js が混在していてもデプロイ手順を一本化でき、リリースのたびにアプリ固有の環境構築作業を繰り返す必要がなくなります。ローリングデプロイや、環境 URL のスワップによる Blue/Green 相当の切り替えも標準機能として提供されており、既存アプリを大きく書き換えることなくリリースまでの時間を最短化できます。したがって各アプリをコンテナ化して Elastic Beanstalk にデプロイする案が要件に最も合致します。AWS CloudFormation テンプレートを一から記述する案は、インフラをコードとして管理できる利点はあるものの、ネットワーク、ロードバランサー、スケーリングポリシーまで自分で定義する必要があり、リリースを早めたいという目的に対して初期工数が過大です。AWS CodeBuild でビルドして AWS Lambda 関数として公開する案は、既存の Web アプリケーションをサーバーレス向けに作り替える改修が前提となるため、短期でのリリース短縮にはつながりません。リリースのたびに AMI を手動で作り直す案は、ビルド時間が長く手作業も多いため、現在の課題である工数肥大をさらに悪化させる選択です。
Web アプリを最小運用で展開するプラットフォーム インフラ専任者がいない 5 名の開発チームが、Python で書かれた社内向け Web アプリケーションと、Docker イメージとしてパッケージ済みの別アプリケーションを AWS 上で公開します。チームはロードバランサーと Auto Scaling を含む実行環境をコマンド 1 つで払い出したいと考えており、OS やミドルウェアの構成、キャパシティー調整、デプロイのローリング更新はプラットフォーム側に任せたいと考えています。最も適したサービスを 1 つ選択してください。
A Amazon EC2 の起動テンプレート、Application Load Balancer、Auto Scaling グループを個別に作成して環境を組み立てる B Amazon ECR にコンテナイメージを保存し、ECR から直接アプリケーションを公開する C Amazon EKS クラスターを構築し、Deployment と Service のマニフェストを作成して公開する D AWS Elastic Beanstalk にアプリケーションバージョンをアップロードし、Web サーバー環境を作成する
解説を読む（正解: D） AWS Elastic Beanstalk は、アプリケーションのソースコードやコンテナ定義をアップロードするだけで、EC2 インスタンス、Application Load Balancer、Auto Scaling グループ、モニタリング設定までを含む実行環境を自動的にプロビジョニングするサービスです。Python や Java、Node.js などの言語プラットフォームに加えて Docker プラットフォームにも対応しているため、ソースコードのアプリとコンテナ化済みのアプリの双方を同じ手順で展開できます。バージョン管理されたデプロイやローリング更新もマネジメントコンソールや CLI から実行できるため、インフラ専任者がいないチームの要件に最も合致する選択肢 D が正解です。選択肢 B の Amazon ECR はコンテナイメージの保管庫にすぎず、そこから直接アプリケーションを公開して外部にサービスする機能はありません。選択肢 C の Amazon EKS は Kubernetes の知識とクラスター運用が前提となり、少人数でインフラ専任者のいないチームには学習コストと運用負荷が過大です。選択肢 A は起動テンプレート、ロードバランサー、Auto Scaling グループを個別に構築・維持する方式で、技術的には要件を満たせますが、設定と保守の手間が Elastic Beanstalk と比べて明確に大きく、「コマンド 1 つで払い出したい」という要望に反します。
運用負荷を抑えた Web アプリケーションの展開方式 社員 200 名の会計事務所が、社内向けの経費精算 Web アプリケーションを AWS 上に展開しようとしています。アプリケーションは Linux 上で動作する一般的な Web スタックで構築されており、専任のインフラエンジニアはいません。要件として、アプリケーションの稼働状況やヘルス状態を確認できる運用ダッシュボードが標準で提供されること、そして OS やミドルウェアへのパッチ適用を担当者が手作業で行わなくて済むことが挙げられています。開発者はビルド済みのアプリケーションをアップロードするだけでデプロイを完結させたいと考えています。この要件を満たす最も適切な展開方法はどれですか。
A AWS CloudFormation テンプレートで EC2 インスタンスと Application Load Balancer を定義し、EC2 のユーザーデータスクリプトでアプリケーションを配置する B Amazon EC2 を起動して AWS Systems Manager Patch Manager でパッチ適用を自動化し、デプロイスクリプトと監視ダッシュボードを自作する C AWS Elastic Beanstalk にアプリケーションバンドルをアップロードし、マネージドプラットフォーム更新を有効にして運用する D Amazon ECS on EC2 のクラスターを構築してアプリケーションをコンテナ化し、コンテナインスタンスの AMI 更新を自社で運用する
解説を読む（正解: C） AWS Elastic Beanstalk は、アプリケーションのコードやバンドルをアップロードするだけで、EC2 インスタンス、Auto Scaling グループ、ロードバランサー、セキュリティグループといった実行環境一式を自動的にプロビジョニングしてくれる PaaS 型のサービスです。Java、PHP、Python、Node.js、Ruby、.NET、Docker などのプラットフォームがあらかじめ用意されており、インフラの詳細を意識せずにデプロイできます。マネージドコンソールにはアプリケーションのヘルス状態、リクエスト数、レイテンシー、直近のイベントログを一覧できる運用ダッシュボードが標準で備わっており、追加開発なしで稼働状況を把握できます。さらにマネージドプラットフォーム更新を有効にすれば、OS やミドルウェアのマイナーバージョン・パッチの適用を指定したメンテナンスウィンドウ内で AWS が自動実行するため、手作業のパッチ配布が不要になります。専任インフラ担当がいない本問の状況に最も適合します。誤りの選択肢について、CloudFormation とユーザーデータスクリプトによる構成は環境の再現性は得られますが、パッチ適用の仕組みも監視ダッシュボードも自分で設計・実装する必要があり要件を満たせません。EC2 に Patch Manager を設定する案はパッチの自動化はできるものの、デプロイの仕組みとダッシュボードを自作する手間が残ります。Amazon ECS on EC2 はコンテナ化の作業に加え、コンテナインスタンスの AMI 更新を自社で運用し続ける必要があり、運用負荷を下げたいという要件と逆行します。