AWS認定資格 WEB問題集＆徹底解説

DevOpsエンジニア-プロフェッショナル

正解 C問題
分野1：SDLC の自動化 タスクステートメント1.4：インスタンス・コンテナ・サーバーレス環境向けのデプロイ戦略の実装
要復習（もう一度解きたい問題） 1 2 3 4
次の問題前の問題
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
あるロボティクス関連のスタートアップは、AWS Elastic Beanstalk 上で複数のプログラミング言語のアプリケーションを、予測可能かつ標準化されたデプロイ戦略で運用したいと考えています。Node.js、Java、Go は Elastic Beanstalk の標準プラットフォームで対応していますが、一部のマイクロサービスで採用している Elixir は現時点で標準プラットフォームの対応言語に含まれていません。

この要件を満たす、最も効率的な解決策はどれですか。
  • 非対応言語ごとにカスタムプラットフォームを作成し、アプリケーションの成果物は Amazon S3 にパッケージしてからデプロイする
  • 非対応言語ごとに OS・ランタイム・アプリケーションコードを含むゴールデン AMI を作成し、アプリケーションを更新する際は Beanstalk 環境の設定を新しい AMI に切り替える
  • Elastic Beanstalk の Docker プラットフォーム（ECS マネージド Docker プラットフォームブランチ）でデプロイする構成にし、各言語のアプリケーション（非対応言語を含む）を Docker コンテナとしてビルドして Amazon ECR に格納する
  • 非対応言語のアプリケーションについては、EC2 Image Builder のパイプラインを使って直接 Amazon EC2 Auto Scaling グループ上にプロビジョニングし、Elastic Beanstalk の管理対象から外す
解説 頻出度★★★★★
この問題は、「Elastic Beanstalk 非対応の言語 (Elixir) を含む複数言語 × 予測可能で標準化されたデプロイ」の要件で、アプリケーションを Docker コンテナに包み、言語差を Beanstalk の Docker プラットフォームで吸収するという定石を選べるかがポイントです。

A. 非対応言語ごとにカスタムプラットフォームを作成し、アプリケーションの成果物は Amazon S3 にパッケージしてからデプロイする

Elastic Beanstalk のカスタムプラットフォームは、確かに非対応言語へ対応するための機能でした。しかし Packer による独自 AMI 作成が前提で、言語ごとにプラットフォームを開発・保守し続ける必要があり、「予測可能で標準化された」運用とは正反対です。
さらに AWS 公式ドキュメントは「2022 年 7 月 18 日に Amazon Linux AMI (AL1) に基づくプラットフォームブランチのステータスがすべて廃止に設定され、これにはカスタムプラットフォームが含まれる」「Elastic Beanstalk はカスタムプラットフォームをサポートしていません」と明記しており、現在は選択できません。
古い教材では正解として登場することがあるため、廃止済みである点を必ず覚えておきましょう。

B. 非対応言語ごとに OS・ランタイム・アプリケーションコードを含むゴールデン AMI を作成し、アプリケーションを更新する際は Beanstalk 環境の設定を新しい AMI に切り替える

OS・ランタイム・アプリケーションコードまで含めたゴールデン AMI 方式では、コードを 1 行直すたびに AMI を作り直し、環境設定を差し替えることになります。
ビルド時間が長く、言語ごとに AMI 系列が増えるため、複数言語を「標準化された 1 つのデプロイ戦略」で扱うという要件から遠ざかります。
AMI にはランタイムやミドルウェアなど変更頻度の低い層だけを含めるのが定石で、アプリケーションコードまで焼き込むのはアンチパターンです。

正解

C. Elastic Beanstalk の Docker プラットフォーム（ECS マネージド Docker プラットフォームブランチ）でデプロイする構成にし、各言語のアプリケーション（非対応言語を含む）を Docker コンテナとしてビルドして Amazon ECR に格納する

正解です。アプリケーションを Docker イメージにすれば、言語やランタイムの違いはすべてコンテナの中に閉じ込められ、Elastic Beanstalk から見ればどの言語も「コンテナを起動するだけ」の同じ手順になります。
Elastic Beanstalk の Docker プラットフォーム（ECS マネージド Docker プラットフォームブランチ）は、Elixir のように標準プラットフォームが存在しない言語でもそのまま動かせるため、非対応言語への正攻法です。
イメージを Amazon ECR に集約すれば、ビルドとデプロイのパイプラインも全言語で共通化でき、「予測可能かつ標準化されたデプロイ戦略」という要件を最小の労力で満たせます。

D. 非対応言語のアプリケーションについては、EC2 Image Builder のパイプラインを使って直接 Amazon EC2 Auto Scaling グループ上にプロビジョニングし、Elastic Beanstalk の管理対象から外す

非対応言語だけを Elastic Beanstalk の管理外に出すと、デプロイ方式が 2 系統に分かれ、標準化という要件そのものを放棄することになります。
EC2 Image Builder は AMI のビルドパイプラインを自動化するサービスであり、アプリケーションのデプロイやスケーリング、環境のバージョン管理を Beanstalk のように面倒見てくれるわけではありません。
運用対象が増えるだけで、効率的な解決策とは言えません。

これだけ覚える（記憶フック）
Beanstalk が対応していない言語＝Docker で包む。カスタムプラットフォームは廃止済み、AMI 焼き込みは運用地獄。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
Elixir が Elastic Beanstalk の標準プラットフォームに存在しない 言語差を吸収する正攻法はDocker コンテナ化。Beanstalk の Docker プラットフォームは中身の言語を問わない
→選択肢（C）が正解
予測可能かつ標準化されたデプロイ戦略で運用したい 全言語で同一のビルド・デプロイ手順に揃うことが条件。言語ごとに別方式を作る案は要件違反
→選択肢（A・D）を消す
最も効率的（運用の手間が小さい）な解決策 コードを直すたびにAMI を作り直す方式は、ビルド時間も管理対象も増える
→選択肢（B）を消す
現在も選択可能な手段であること カスタムプラットフォームは AL1 廃止（2022-07-18）とともにサポート終了しており、今は作成できない
→選択肢（A）を消す
Elastic Beanstalk で一元管理し続けたい 管理対象から外す案はBeanstalk による環境管理・デプロイ機能の恩恵を捨てることになる
→選択肢（D）を消す
ひっかけポイント
  • 選択肢 A の「カスタムプラットフォーム」は、非対応言語への対応策として教科書的に語られてきたため最も選びやすい罠。現在は廃止されて利用できず、仮に使えても言語ごとの保守が必要で「標準化」に反する
  • 選択肢 B の「ゴールデン AMI」は正しいプラクティスの名前だが、アプリケーションコードまで含める点が誤り。更新のたびに AMI 再作成が必要になり、デプロイ速度も柔軟性も失う
  • 選択肢 D の EC2 Image Builder はAMI を作るサービスであってデプロイ基盤ではない。名前に Builder とあるからといってアプリのデプロイを担うわけではない
  • 「非対応言語をどう動かすか」だけに目を奪われると、「複数言語を 1 つの標準化された戦略で運用したい」という主目的を見落とす。言語ごとに別解を用意する案はこの時点で全滅する
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「1 つの環境で複数のコンテナを協調動作させたい」 ECS マネージド Docker プラットフォームブランチ（Dockerrun.aws.json v2）の利用が明示的な論点に。
「Beanstalk をやめてコンテナオーケストレーションに寄せたい」 Amazon ECS / AWS Fargate や Amazon EKS への移行が正解軸に変わる。
「標準プラットフォームのままOS 側のパッケージを追加したいだけ」 .ebextensions（設定ファイル）や Buildfile / Procfile によるカスタマイズが正解軸に。
「デプロイ時のダウンタイムをゼロにしたい」 Beanstalk のImmutable デプロイや URL スワップ（Blue/Green）が論点に変わる。
「変更頻度の低いミドルウェアの導入時間を短縮したい」 カスタム AMI（ゴールデン AMI）が有効な打ち手になる。アプリコードは含めないのが原則。
関連サービスの解説 Amazon Elastic Container Registry (Amazon ECR)
AWS Elastic Beanstalk
Amazon EC2 Image Builder
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
Elastic Beanstalk の Docker プラットフォームブランチ（ECS マネージド Docker を含む） Docker コンテナを使用して Elastic Beanstalk コンソールにデプロイする - AWS Elastic Beanstalk
カスタムプラットフォームの廃止（AL1 プラットフォームブランチの廃止に伴うサポート終了） Elastic Beanstalk カスタムプラットフォーム (廃止) - AWS Elastic Beanstalk
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 0%
No.14 解説
あるロボティクス関連のスタートアップは、AWS Elastic Beanstalk 上で複数のプログラミング言語のアプリケーションを、予測可能かつ標準化されたデプロイ戦略で運用したいと考えています。Node.js、Java、Go は Elastic Beanstalk の標準プラットフォームで対応していますが、一部のマイクロサービスで採用している Elixir は現時点で標準プラットフォームの対応言語に含まれていません。

この要件を満たす、最も効率的な解決策はどれですか。
  • 非対応言語ごとにカスタムプラットフォームを作成し、アプリケーションの成果物は Amazon S3 にパッケージしてからデプロイする
  • 非対応言語ごとに OS・ランタイム・アプリケーションコードを含むゴールデン AMI を作成し、アプリケーションを更新する際は Beanstalk 環境の設定を新しい AMI に切り替える
  • Elastic Beanstalk の Docker プラットフォーム（ECS マネージド Docker プラットフォームブランチ）でデプロイする構成にし、各言語のアプリケーション（非対応言語を含む）を Docker コンテナとしてビルドして Amazon ECR に格納する
  • 非対応言語のアプリケーションについては、EC2 Image Builder のパイプラインを使って直接 Amazon EC2 Auto Scaling グループ上にプロビジョニングし、Elastic Beanstalk の管理対象から外す

次の問題前の問題


(会員限定)当問題の評価をお願いします。改善に活用します。
広告

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報