Q1 — 単一選択既存の業務WebアプリケーションをAWS上で再設計します。
アプリケーションはLinuxコンテナとして実行でき、複数の実行単位から同じPOSIXファイルを共有する必要があります。データベースはPostgreSQLで、基盤OSやデータベースソフトウェアを直接管理する要件はありません。
ピーク時2,000リクエスト/秒でp95レイテンシー300ミリ秒以下を満たし、OSとデータベースの定常運用も減らしたいと考えています。候補構成の性能試験ではAの組み合わせがp95 240ミリ秒を満たしました。
最も適切なターゲットアーキテクチャはどれですか。
A. Amazon ECS on AWS Fargate、Amazon EFS、Amazon RDS for PostgreSQLを組み合わせ、代表負荷でp95要件を満たした構成を採用する
B. Amazon ECS on AWS Fargateだけを使用し、共有ファイルは各タスクのエフェメラルストレージへ永続化し、PostgreSQLも各タスク内で実行する
C. Amazon EC2上でアプリケーションとPostgreSQLをすべて自己管理し、共有ファイルは各EC2のローカル領域へ個別に保存する
D. Amazon OpenSearch Serviceを正規データベースとして使用し、PostgreSQLと共有ファイルの要件を検索インデックスへ統合する
答えと解説
答え：A
ターゲットアーキテクチャでは、コンピューティングだけでなく、コンテナ、ストレージ、データベース、運用、性能を一続きで満たす必要があります。
Aはコンテナ実行、永続共有ファイル、PostgreSQL、運用負荷削減を組み合わせ、提示された性能要件も満たしています。個別サービスではなく、ワークロード全体として成立する組み合わせを選択します。
Q2 — 単一選択Amazon ECS on AWS Fargateで動作するアプリケーションが、一時処理ファイルと、複数タスクから共有してタスク置換後も保持する必要がある業務ファイルを扱います。
状態の配置として最も適切なものはどれですか。
A. 一時処理ファイルはFargateのエフェメラルストレージに置き、タスクを越えて保持・共有するファイルはAmazon EFSへ分離する
B. 一時処理ファイルと永続共有ファイルをすべてFargateのエフェメラルストレージへ置き、タスク停止後も保持される前提にする
C. 永続共有ファイルだけを各Fargateタスクへ個別コピーし、どのコピーを正規状態とするかは障害発生後に決定する
D. 共有ファイル要件を無視してAmazon S3の通常のオブジェクトAPIへ保存先だけ変更し、アプリケーションは変更しない
答えと解説
答え：A
一時データと、コンピューティングのライフサイクルを越えて保持するデータは分けて扱います。
タスク内の一時領域は一時処理へ使用し、複数タスクから共有しながら永続化する必要があるファイルは、Amazon EFSなどの永続共有ストレージへ分離します。
Q3 — 単一選択ターゲット候補では、Amazon ECS on AWS Fargate、Amazon EFS、Amazon RDSを使用します。
アプリケーション、ストレージ、データベースにはそれぞれ担当チームがいますが、障害が複数の構成要素にまたがる場合の初動担当、切り分け順序、エスカレーション先が定義されていません。
本番アーキテクチャを確定する前に行うべき対応として最も適切なものはどれですか。
A. 各サービスの担当チームが存在すれば十分なので、構成要素をまたぐ障害対応の流れは定義しない
B. ワークロード全体の初動担当、構成要素間の切り分け順序、エスカレーション先、復旧確認までを運用モデルとして定義する
C. AWS Fargateを利用しているため、EFSやRDSを含む障害の一次切り分けもすべてAWSだけが担当するものとする
D. 障害発生後に関係するチームを判断し、それまではワークロード全体の運用責任を設定しない
答えと解説
答え：B
各サービスの運用担当を個別に決めただけでは、複数の構成要素にまたがるワークロード全体の運用は完成しません。
ターゲットアーキテクチャでは、障害検知から初期切り分け、担当へのエスカレーション、復旧確認までをつないだ運用モデルを定義します。
Q4 — 単一選択LinuxコンテナをAmazon ECS on AWS Fargateへ移行する。複数タスクから同じ業務ファイルを共有し、タスク置換後もデータを保持するためAmazon EFSを使用する。ところがターゲット設計にはFargate Linuxプラットフォームバージョン1.3.0が指定され、一時領域へ置き換える案も出ている。共有永続性を維持しながら変更範囲を最小化する対応はどれか。
A. Linuxプラットフォームバージョン1.4.0以降へ更新し、Amazon EFSを共有永続ストレージとして利用する
B. 1.3.0のままAmazon EFSを利用し、プラットフォームバージョンの対応条件は考慮しない
C. Amazon EFSをタスクの一時領域へ置き換え、タスク置換後の共有データ保持要件はアプリケーション側で吸収する
D. Amazon RDSを追加すればFargateとAmazon EFSの対応条件が不要になるため、1.3.0を維持する
答えと解説
答え：A
Amazon ECS on AWS FargateのLinuxタスクでAmazon EFSを使用するには、プラットフォームバージョン1.4.0以降が必要です。共有永続ファイルという要件を維持したまま、対応するプラットフォームバージョンへ更新します。
Q5 — 単一選択Amazon ECS on AWS Fargate、Amazon EFS、Amazon RDS for PostgreSQLで構成されたシステムを、設計担当者とは別のチームが引き継ぐことになりました。
新しい担当者は構成図だけを見て、「なぜ共有ファイルをAmazon S3ではなくAmazon EFSへ配置したのか」を確認したいと考えています。現在のワークロード要件に変更はありません。
ターゲットアーキテクチャの判断根拠を最も適切に利用する方法はどれですか。
A. Amazon EFSが採用済みであること自体を設計理由とし、当時のワークロード要件や検証結果は確認しない
B. Amazon EFSに対応付けて記録された共有POSIXファイル要件と成立確認結果を確認し、その構成要素を選択した設計意図を再確認する
C. 設計担当者が不在なら既存の判断根拠は利用せず、すべてのAWSサービスを理由なく最初から選定し直す
D. Amazon EFSとAmazon S3はいずれもストレージサービスなので、保存方式やアプリケーション要件を確認せず同等の選択肢として扱う
答えと解説
答え：B
ターゲットアーキテクチャの判断根拠は、構成を選んだ時点だけで使うものではありません。
構成要素と、その役割、満たす要件、互換性や性能の確認結果を対応付けて残しておけば、後から別の担当者が構成を見た場合でも、なぜその構成要素が採用されたのかを再現できます。
このシナリオでは要件変更は発生していないため、影響範囲を再評価する問題ではありません。Amazon EFSに対応付けられた共有POSIXファイル要件と成立確認結果を参照し、既存のターゲットアーキテクチャの設計意図を確認します。