Uncategorized

#43

 

了解しました。いただいたHTMLをもとに、指定の形式で整理しました。

■問題文

ある企業は AWS クラウドへの移行を計画しています。同社は、Windows サーバーと Linux サーバーで多くのアプリケーションをホストしています。サーバーの中には、物理サーバーもあれば、仮想サーバーもあります。同社は、オンプレミス環境で数種類のデータベースを使用しています。同社は、オンプレミスサーバーとアプリケーションの正確なインベントリーがありません。

同社は、移行中にリソースのサイズを適切に設定したいと考えています。ソリューションアーキテクトは、ネットワーク接続とアプリケーションの関係に関する情報を取得する必要があります。ソリューションアーキテクトは、会社の現在の環境を評価し、移行計画を作成する必要があります。

移行計画を策定するために必要な情報をソリューションアーキテクトに提供するソリューションを選択してください。

■選択肢

A. Migration Evaluator を使用して、AWS に環境の評価をリクエストします。AWS Application Discovery Service Agentless Collector を使用して、詳細を Migration Evaluator Quick Insights レポートにインポートします。

B. AWS Migration Hub を使用し、AWS Application Discovery Agent をサーバーにインストールします。Migration Hub Strategy Recommendations アプリケーションデータコレクターをデプロイします。Migration Hub Strategy Recommendations を使用してレポートを作成します。

C. AWS Migration Hub を使用し、サーバー上で AWS Application Discovery Service Agentless Collector を実行します。AWS Application Migration Service を使用して、サーバーとデータベースをグループ化します。Migration Hub Strategy Recommendations を使用してレポートを作成します。

D. AWS Migration Hub のインポートツールを使用して、オンプレミス環境の詳細を読み込みます。Migration Hub Strategy Recommendations を使用してレポートを作成します。

■問題文の要件の概要

  • オンプレ環境のサーバー（物理・仮想、Windows・Linux）とアプリケーションの正確なインベントリーがない
  • ネットワーク接続やアプリケーション間の依存関係を把握する必要がある
  • 適切なリソースサイズの決定が必要
  • 自動で情報収集し、移行計画作成に役立つレポートを生成できるソリューションが求められる

■正解の選択肢と解説

正解：B
AWS Migration Hub を使用し、AWS Application Discovery Agent を各サーバーにインストールすることで、CPU・メモリ・ディスクI/O・ネットワーク通信の詳細データを継続的に収集可能。
Migration Hub Strategy Recommendations のアプリケーションデータコレクターで収集データを解析し、サーバーやDBの移行パターン（リホスト・リプラットフォーム・リファクター等）と推奨AWSサービスを自動でレポート化できる。
これにより、正確なインベントリー・ネットワークトポロジー・リサイズ指標を一括取得し、効率的に移行計画を策定可能。

■不正解の選択肢の理由

A
Migration Evaluator はコスト見積りに特化し、Agentless Collector はVMware限定。依存関係やプロセス単位の通信情報を取得できず、移行順序やリソース最適化のための十分なデータが得られない。

C
Agentless Collector はプロセス単位やポート依存関係の情報を取得できず精度不足。AWS Application Migration Service はリホスト自動化が目的で、分析や依存関係可視化の機能はないため要件を満たさない。

D
Migration Hub インポートツールは手動取得した静的データの取り込みのみ。リアルタイムなパフォーマンスデータや依存関係情報を自動収集できないため、詳細な移行計画策定には不十分。

■SAP試験で押さえておくべきポイント

  • AWS Migration Hub + AWS Application Discovery Agent は、物理/仮想サーバー問わず詳細な依存関係やリソース使用状況を可視化できる
  • Agent と Agentless の違い：Agentは詳細依存情報取得可、Agentlessは制限あり（主にVMware環境）
  • Migration Evaluator はコスト算定用ツールで依存関係分析には不向き
  • Migration Hub インポートツール は静的データ取り込み用で動的情報は不可
  • 移行計画策定には「依存関係の可視化＋サイジング情報」の両方が重要

この形式であれば、今後の問題も同様に整理できます。
次の問題も送りますか？

■問題文

画像ストレージ サービスを提供する会社は、お客様向けソリューションを AWS にデプロイしたいと考えています。数百万人のお客様がこのソリューションを使用する予定です。このソリューションは、大きな画像ファイルのバッチを受け取り、ファイルのサイズを変更し、Amazon S3 バケットに最大 6 ヶ月間ファイルを保存したのち削除します。

このソリューションでは、需要の大幅な変動に対応する必要があります。また、企業規模での信頼性があり、障害が発生した場合に処理ジョブを再実行する能力を備えている必要があります。

これらの要件を最も費用対効果の高い方法で満たすソリューションを選択してください。

■選択肢

A. AWS Step Functions を使用して、ユーザーが画像を保存するときに発生する S3 イベントを処理します。画像のサイズをその場で変更し、S3 バケット内の元のファイルを置き換える AWS Lambda 関数を実行します。S3 ライフサイクルの有効期限ポリシーを作成して、保存されているすべてのイメージを 6 ヶ月後に期限切れにします。

B. Amazon EventBridge を使用して、ユーザーが画像をアップロードしたときに発生する S3 イベントを処理します。画像のサイズをその場で変更し、S3 バケット内の元のファイルを置き換える AWS Lambda 関数を実行します。S3 ライフサイクルの有効期限ポリシーを作成して、保存されているすべてのイメージを 6 ヶ月後に期限切れにします。

C. S3 イベント通知を使用して、ユーザーが画像を保存したときに AWS Lambda 関数を呼び出します。Lambda 関数を使用して、画像をその場で変更し、元のファイルを S3 バケットに保存します。S3 ライフサイクルポリシーを作成して、保存されているすべてのイメージを 6 ヶ月後に Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) に移動します。

D. Amazon Simple Queue Service (Amazon SQS) を使用して、ユーザーが画像を保存するときに発生する S3 イベントを処理します。画像のサイズを変更する AWS Lambda 関数を実行し、Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) を使用する S3 バケットに変更したファイルを保存します。S3 ライフサイクルポリシーを作成して、保存されているすべての画像を数か月後に S3 Glacier Deep Archive に移動します。

■問題文の要件の概要

  • 数百万人規模のユーザー利用を想定
  • 大容量画像のバッチ処理
  • 保存期間は最大6か月で、その後自動削除
  • 急激な需要変動に対応可能なスケーラビリティ
  • 高信頼性（障害発生時の再試行・再実行が可能）
  • 費用対効果の高い構成

■正解の選択肢と解説

正解：B

  • Amazon EventBridge は S3 の PutObject イベントを取り込み、内部バッファリングと少なくとも1回の確実な配信で需要急増にも対応可能。
  • AWS Lambda がイベントごとに水平スケールして画像をリサイズ。EventBridge の再試行ポリシーとデッドレターキュー（DLQ）で失敗ジョブを再実行し高信頼性を確保。
  • S3 ライフサイクルポリシー により、保存ファイルを6か月後に自動削除しコスト削減。
  • サーバーレス構成でインフラ管理不要、イベント駆動かつコスト効率良く運用可能。

■不正解の選択肢の理由

A

  • Step Functions はイベントごとにステートマシンを起動するため、大量イベント時の状態遷移課金が増大。
  • Lambda の大容量処理はメモリ・タイムアウト制限で失敗リスク高。
  • バルク再実行が難しく費用効率も悪い。

C

  • Standard-IA への移行では削除されないため、6か月後の確実削除要件を満たさない。
  • 元ファイルと変換後ファイルを両方保持する構成はストレージコスト増大。

D

  • SQS 経由は即時性に欠け、リアルタイム画像処理要件に不適。
  • Glacier Deep Archive では取得に数時間かかり、ユーザーアクセス性が損なわれる。

■SAP試験で押さえておくべきポイント

  • EventBridge は高スケーラビリティ・再試行・DLQを備えたイベントルーティングサービス。
  • S3 ライフサイクルポリシー の「移行」と「削除」の違いを理解する。
  • Step Functions は状態管理に強いが、単純な大量イベント処理にはコスト高。
  • SQS は高信頼非同期処理向きだがリアルタイム性は低い。
  • サーバーレス構成で大規模変動に対応しつつコスト最適化を図るのが重要。

この形式で次の問題も同じように整理できます。
もしよければ、この後の問題も連続で処理できますが、まとめてやりますか？

■問題文

企業は、カスタムモバイルアプリを使用してモバイルデバイスからアップロードされる画像データを保存および処理する必要があります。使用のピークは平日の午前 8 時から午後 5 時で、1 分間に数千件のアップロードが行われます。それ以外の時間帯では、このアプリはほとんど使われません。画像処理が完了すると、ユーザーに通知されます。

画像処理が負荷に応じて拡張できるようにするために、最適な組み合わせを選択してください。 (3 つ選択)

■選択肢

A. モバイルソフトウェアから Amazon S3 に直接ファイルをアップロードします。S3 イベント通知を使用して、Amazon MQ キューにメッセージを作成します。

B. モバイルソフトウェアから Amazon S3 に直接ファイルをアップロードします。S3 イベント通知を使用して、Amazon Simple Queue Service (Amazon SQS) 標準キューにメッセージを作成します。

C. キューでメッセージが利用可能になったときに、AWS Lambda 関数を呼び出して画像処理を実行します。

D. S3 バッチ操作ジョブを起動して、キューでメッセージが利用可能になったときに画像処理を実行します。

E. 処理が完了したら、Amazon Simple Notification Service (Amazon SNS) を使用してモバイルアプリにプッシュ通知を送信します。

F. 処理が完了したら、Amazon Simple Email Service (Amazon SES) を使用してモバイルアプリにプッシュ通知を送信します。

■問題文の要件の概要

  • モバイルアプリからの高頻度画像アップロード（ピーク時は数千件/分）
  • オフピークはほぼ利用なし
  • アップロード後に画像処理を行い、ユーザーへ通知
  • 高スループット・自動スケーリング可能な非同期処理基盤が必要
  • 運用負荷を最小化し、コスト効率も確保する構成

■正解の選択肢と解説

正解：B, C, E

B. S3 → SQS 標準キュー

  • モバイルアプリは直接 Amazon S3 にファイルを保存
  • S3 イベント通知で SQS 標準キューにメッセージを送信
  • SQS 標準キューはほぼ無制限のスループットでバーストを吸収し、非同期処理可能

C. SQS → AWS Lambda

  • Lambda が SQS をポーリングし、到着メッセージ数に応じて同時実行数を自動スケール
  • ピーク時は数千並列処理、オフピークはゼロまで縮退しコスト最適化

E. 処理完了後 SNS 通知

  • SNS Mobile Push 機能を使い、APNs/FCM経由でモバイルアプリへリアルタイム通知
  • トピックベース配信により複数プラットフォーム対応・再試行・スケーリングが自動

■不正解の選択肢の理由

A. MQ キュー使用

  • Amazon MQ はブローカー単位で処理能力が固定、水平スケール不可
  • ピーク時に遅延・接続数制限が発生しやすい

D. S3 バッチ操作ジョブ

  • バッチ処理はリアルタイム性に欠け、キューのイベントごと処理に不向き
  • 起動遅延・課金モデルが高トラフィック短時間処理に不適

F. SES で通知

  • SES はメール送信専用でプッシュ通知不可
  • モバイル即時通知要件を満たさない

■SAP試験で押さえておくべきポイント

  • S3 + SQS + Lambda はバースト耐性と自動スケーリングに優れた非同期パターン
  • SQS 標準キュー は高スループット・少なくとも1回配信でピーク負荷対応に最適
  • SNS Mobile Push はプラットフォーム別トークン管理・即時配信が可能
  • MQやバッチはリアルタイム性・スケーラビリティ面で制約あり
  • 非同期パターン選定時はスループット要件・遅延許容度・配信方式を整理すること

この形式なら、残りの問題も同じ要領で整理できます。
次の問題もこのまま続けて処理しましょうか？

■問題文（そのまま）

ある企業のソリューションアーキテクトが、AWS 上で動作するウェブアプリケーションをレビューしています。このアプリケーションは、us-east-1 リージョンの Amazon S3 バケット内の静的アセットを参照しています。同社は、複数の AWS リージョンにわたる回復力を必要としています。同社はすでに、2 番目のリージョンに S3 バケットを作成しています。

運用上のオーバーヘッドが最も少なく、これらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A. 両方の S3 バケットに各オブジェクトを書き込むようにアプリケーションを設定します。各 S3 バケットに加重ルーティングポリシーを使用して、Amazon Route 53 パブリックホストゾーン内にレコードセットを設定します。Route 53 の DNS 名を使用して、アプリケーションからオブジェクトにアクセスできるように構成します。

B. us-east-1 の S3 バケットから 2 番目のリージョンの S3 バケットにオブジェクトをコピーするために AWS Lambda 関数を作成します。オブジェクトが us-east-1 の S3 バケットに書き込まれるたびに、Lambda 関数を呼び出します。2 つの S3 バケットを含むオリジングループを使用して、Amazon CloudFront ディストリビューションを設定します。

C. us-east-1 の S3 バケットにレプリケーションを設定し、2 番目のリージョンの S3 バケットにオブジェクトをレプリケートします。2 つの S3 バケットを含むオリジングループを使用して、Amazon CloudFront ディストリビューションを設定します。

D. us-east-1 の S3 バケットにレプリケーションを設定し、2 番目のリージョンの S3 バケットにオブジェクトをレプリケートします。フェイルオーバーが必要な場合は、アプリケーションコードを更新して、2 番目のリージョンの S3 バケットから S3 オブジェクトをロードします。

■問題文の要件の概要

  • 複数リージョンにわたる回復力（リージョン障害時も提供継続）
  • 既に第2リージョンにS3バケットあり
  • 運用オーバーヘッドを最小化したい
  • 静的アセット配信（S3をオリジンとするWebアプリ）

■正解の選択肢と解説

正解：C

  • S3 レプリケーション（CRR） を使えば、us-east-1 への書き込みを自動で第2リージョンのバケットへ非同期複製。追加コードや運用作業が最小。
  • CloudFront のオリジングループ（オリジンフェイルオーバー） に両S3バケットを登録すると、プライマリ障害時に自動でセカンダリへフェイルオーバー。アプリやDNS切替の手動対応が不要で、運用負荷が最小。
  • 「多リージョン冗長なデータ + 自動フェイルオーバー」をフルマネージド機能だけで実現でき、要件に最も合致。

■不正解の選択肢の理由

A

  • アプリから両バケットへ多重書き込みは実装/保守が重く、整合性リスクも増大。
  • Route 53 の加重ルーティングはフェイルオーバー目的に不適（自動切替の仕組みではない）。結果、運用オーバーヘッドが大きい。

B

  • Lambdaでオブジェクトコピーはイベント数に比例して実行/課金が増え、失敗再試行やスロットリング対応の運用が発生。
  • 同じフェイルオーバーを得るなら、ネイティブのS3レプリケーションの方がシンプルかつ堅牢で低運用。

D

  • データ複製はできるが、障害時にアプリコードを更新して切替えるのは運用的に重く、復旧に時間とリスク。
  • 自動フェイルオーバー要件を満たさない。

■SAP試験で押さえておくべきポイント

  • S3 レプリケーション（SRR/CRR）：バケット間で自動・非同期コピー。設計目標は運用最小化と耐障害性向上。
  • CloudFront オリジンフェイルオーバー：プライマリ障害時に自動でセカンダリへ切替。アプリ/DNS変更不要。
  • Route 53 の加重は負荷分散用途。フェイルオーバーは別ポリシー（ヘルスチェック連携）だが、静的アセットの多リージョン配信には CloudFront の仕組みが適。
  • 「運用最小」を問われたら、フルマネージド + 自動化（S3 レプリケーション + CloudFront オリジングループ）を優先的に検討。

■問題文（そのまま）

小売会社は、ビジネスパートナーである別の会社に一連のデータファイルを提供する必要があります。これらのファイルは、小売会社に属するアカウント A の下の Amazon S3 バケットに保存されます。ビジネスパートナー企業は、その IAM ユーザーの 1 人である User_DataProcessor が、自分の AWS アカウント (アカウント B) からファイルにアクセスすることを望んでいます。

User_DataProcessor が S3 バケットに正常にアクセスできるための手順の組み合わせを選択してください。(2 つ選択)

■選択肢（そのまま）

A. アカウント A の S3 バケットの Cross-Origin Resource Sharing (CORS) 機能を有効にします。

B. アカウント A で、S3 バケットポリシーを次のように設定します。

{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”:[
“arn:aws:s3::: AccountABucketName/*”,
“arn:aws:s3::: AccountABucketName”,
}

C. アカウント A で、S3 バケットポリシーを次のように設定します。

{
“Effect”: “Allow”,
“Principal”: {
“AWS”:”arn:aws:iam::AccountB : user/User_DataProcessor”
},
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”:[
“arn:aws:s3::: AccountABucketName/*”,
“arn:aws:s3::: AccountABucketName”
]
}

D. アカウント B で、User_DataProcessor の権限を次のように設定します。

{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”:[
“arn:aws:s3::: AccountABucketName/*”,
“arn:aws:s3::: AccountABucketName”
}

E. アカウント B で、User_DataProcessor の権限を次のように設定します。

{
“Effect”: “Allow”,
“Principal”: {
“AWS”:”arn:aws:iam::AccountB: user/User_DataProcessor”
},
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”:[
“arn:aws:s3::: AccountABucketName/*”,
“arn:aws:s3::: AccountABucketName”
]
}

■問題文の要件の概要

  • アカウントAのS3バケットを、相手先アカウントBの特定IAMユーザーから読み取り可能にしたい
  • クロスアカウントで最小権限かつ正しいポリシー構成でアクセスを許可する必要

■正解の選択肢と解説

正解：C と D

  • C（バケットポリシー：アカウントA）
    リソース側（S3バケット）のリソースベースポリシーで Principal に相手ユーザー
    arn:aws:iam::AccountB:user/User_DataProcessor を明示し、s3:ListBucket（バケットARN）と
    s3:GetObject（オブジェクトARN）を許可。これでバケット側の受け入れが成立。
  • D（IAMポリシー：アカウントB）
    呼び出し元ユーザー（Identity）にアイデンティティベースポリシーとして、同じ s3:ListBucket と
    s3:GetObject をアカウントAのリソースARNに対して許可。呼び出し元側の許可が成立。
    ※S3は「呼び出し元の許可」かつ「リソース側の許可」の両方が必要（明示拒否が無い前提）。

■不正解の選択肢の理由

  • A（CORS有効化）
    CORSはブラウザのオリジン間制御であり、IAMユーザーのAPI/SDKアクセス権限には無関係。
  • B（バケットポリシーにPrincipal無し）
    リソースベースポリシーでPrincipal欠落は誰にも許可が届かない。さらにJSONも不正。
  • E（IAMポリシーにPrincipal記載）
    アイデンティティベースポリシーにPrincipalは書かない（構文誤り）。Principalは
    S3バケットポリシー等のリソースベースポリシーで用いる。

■SAP試験で押さえておくべきポイント

  • クロスアカウントS3アクセスの基本形：
    1. アカウントA（バケット側）のバケットポリシーで相手のPrincipalを許可
    2. アカウントB（呼び出し側）のIAMポリシーで対象S3リソースへの操作を許可
      → 両者の許可が揃って初めて成功（明示Denyが無いこと）
  • s3:ListBucket はバケットARN、s3:GetObject は**オブジェクトARN（/*）**に付与する
  • CORSと権限管理は別物。ブラウザ対策 ≠ IAM許可
  • リソースベースポリシー（S3バケット等）ではPrincipal必須。IAMポリシーではPrincipal不要（付けない）

この調子で次の問題も送ってください。指定フォーマットでどんどん整理します。

■問題文（そのまま）

企業は、大量の文書をアーカイブし、社内イントラネットを介して従業員が文書にアクセスできるようにすることを計画しています。従業員は、VPC にアタッチされたクライアント VPN サービスを介してシステムにアクセスします。データは一般に公開されず、一般の人がアクセスできないようにする必要があります。

会社が保存している文書は、他の物理メディアに保持されているデータのコピーです。リクエストの数は少なくなります。可用性と取り出しの速度は企業の関心事ではありません。

最も低コストでこれらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A. Amazon S3 バケットを作成します。S3 バケットを設定して、デフォルトで Amazon S3 1 ゾーン – 低頻度アクセス (S3 1 ゾーン – IA) ストレージクラスを使用します。S3 バケットを設定し、ウェブサイトのホスティングに使用します。S3 インターフェースエンドポイントを作成します。そのエンドポイントを介したアクセスのみを許可するように S3 バケットを構成します。

B. Amazon EC2 インスタンスを起動し、ウェブサーバーを実行します。Amazon Elastic File System (Amazon EFS) ファイルシステムをアタッチし、EFS 1 ゾーン – 低頻度アクセス (EFS 1 ゾーン – IA) ストレージクラスにアーカイブされたデータをを保存します。インスタンスのセキュリティグループを構成して、プライベートネットワークからのアクセスのみを許可します。

C. Amazon EC2 インスタンスを起動し、ウェブサーバーを実行します。Amazon Elastic Block Store (Amazon EBS) ボリュームをアタッチして、Cold HDD (sc1) ボリュームタイプでアーカイブされたデータを保存します。インスタンスのセキュリティグループを構成して、プライベートネットワークからのアクセスのみを許可します。

D. Amazon S3 バケットを作成します。S3 バケットを設定して、デフォルトで S3 Glacier Deep Archive ストレージクラスを使用します。ウェブサイトのホスティング用に S3 バケットを設定します。S3 インターフェースエンドポイントを作成します。そのエンドポイントを介したアクセスのみを許可するように S3 バケットを設定します。

■問題文の要件の概要

  • 社内イントラネット経由（クライアントVPN経由）でのみアクセス可能な文書アーカイブ
  • 一般公開禁止（プライベートアクセスのみ）
  • データは他メディアにバックアップがあるため可用性要件は低い
  • アクセス頻度は低い（低頻度アクセス向けのコスト最適化が必要）
  • 即時性は重要でないが、静的Webで配信可能な構成が望ましい
  • 最低コストで実現する必要がある

■正解の選択肢と解説

正解：A

  • S3 1 ゾーン – IA
    • 可用性要件が低い場合、標準IAよりさらに安価な「1ゾーン-IA」が最適。
    • 耐久性は11ナインと変わらないが、AZ障害時にはデータ損失の可能性あり。
  • S3インターフェースエンドポイント（AWS PrivateLink）
    • VPC内にプライベート接続用のENIを作成し、VPN経由でオンプレ・社内端末から安全にアクセス可能。
    • インターネットを経由しないためセキュリティ面で優れる。
  • S3静的ウェブサイトホスティング
    • EC2不要で運用コストを抑え、静的コンテンツを直接配信可能。

■不正解の選択肢の理由

  • B（EC2＋EFS One Zone-IA）
    • EC2の常時稼働コストが高い。
    • EFSはGB単価が高く、アーカイブ用途に不向き。
  • C（EC2＋EBS Cold HDD）
    • EBSはEC2依存であり、可用性とスケーラビリティがS3に劣る。
    • EC2コストが継続発生し、S3 IAより高額。
  • D（S3 Glacier Deep Archive）
    • 復元に12時間以上かかり、静的Web配信の即時性要件を満たさない。
    • 復元前の直接配信は不可。

■SAP試験で押さえておくべきポイント

  • S3ストレージクラス選定
    • アクセス頻度・可用性・即時性要件を基にクラスを選ぶ。
    • 低頻度アクセスで可用性低要求→S3 One Zone-IAが最安クラス。
  • S3とプライベートアクセス
    • VPCからの安全な接続にはゲートウェイエンドポイントまたはインターフェースエンドポイントを選択。
    • オンプレやVPN経由の場合、PrivateLinkベースのインターフェースエンドポイントが有効。
  • Glacier系クラスの制約
    • 復元待機時間があるため、即時配信用途には不適。
  • EC2＋ストレージ構成のコスト評価
    • サーバーレス（S3など）で代替できる場合はEC2常時稼働を避ける。

この形式で、次の問題も同じフォーマットで整理できます。

■問題文（そのまま）

あるオンライン小売企業は、オンプレミスのデータセンターで、ステートフルなウェブベースのアプリケーションと MySQL データベースを 1 台のサーバーでホストしています。同社は、より多くのマーケティングキャンペーンやプロモーションを実施することで、お客様数を増やしたいと考えています。その準備として、同社はアプリケーションとデータベースを AWS に移行し、アーキテクチャの信頼性を高めたいと考えています。

最高レベルの信頼性を提供するソリューションを選択してください。

■選択肢（そのまま）

A. データベースを Amazon RDS MySQL マルチ AZ DB インスタンスに移行します。Application Load Balancer の背後にある Amazon EC2 インスタンスの Auto Scaling グループにアプリケーションをデプロイします。Amazon Neptune にセッションを保存します。

B. データベースを Amazon Aurora MySQL に移行します。Application Load Balancer の背後にある Amazon EC2 インスタンスの Auto Scaling グループにアプリケーションをデプロイします。Amazon ElastiCache for Redis レプリケーショングループにセッションを保存します。

C. データベースを Amazon DocumentDB (MongoDB 互換性あり) に移行します。Network Load Balancer の背後にある Amazon EC2 インスタンスの Auto Scaling グループにアプリケーションをデプロイします。Amazon Kinesis Data Firehose にセッションを保存します。

D. データベースを Amazon RDS MariaDB マルチ AZ DB インスタンスに移行します。Application Load Balancer の背後にある Amazon EC2 インスタンスの Auto Scaling グループにアプリケーションをデプロイします。Amazon ElastiCache for Memcached にセッションを保存します。

■問題文の要件の概要

  • 現状はオンプレ1台構成（アプリ＋MySQL）
  • ステートフルアプリをAWS移行後に高可用性構成へ改善したい
  • 信頼性（可用性・耐障害性）を最優先
  • アプリ、DB、セッション管理の全レイヤーで冗長化・フェイルオーバー対応が必要

■正解の選択肢と解説

正解：B

  • Aurora MySQL
    • ストレージを6コピー、3AZに分散配置
    • クラスタ型構成でプライマリ障害時は数十秒でフェイルオーバー
    • RDS MySQLよりも可用性・スケーラビリティに優れる
  • ALB + EC2 Auto Scaling
    • 複数AZ配置のインスタンスを自動スケール・ヘルスチェックで監視
    • トラフィック急増や障害時でもサービス継続可能
  • ElastiCache for Redis（レプリケーショングループ）
    • マルチAZレプリケーション＋自動フェイルオーバー
    • セッション情報を共有し、EC2間のステートを保持可能
    • Memcachedにない永続化オプションやレプリケーション機能がある

■不正解の選択肢の理由

  • A（RDS MySQL＋Neptune）
    • NeptuneはグラフDBでセッションストアに不適
    • RDS MySQLマルチAZはAuroraよりフェイルオーバーが遅く、信頼性は劣る
  • C（DocumentDB＋Kinesis Data Firehose）
    • DocumentDBはMongoDB互換でMySQLワークロード移行不可
    • Kinesis Firehoseはストリーム配信用途であり、即時セッション管理には不向き
  • D（RDS MariaDB＋Memcached）
    • Memcachedはレプリケーション・フェイルオーバー機能なし
    • 障害時にセッション情報が失われる可能性が高く、信頼性要件を満たせない
    • MariaDBマルチAZはAuroraほどの可用性設計ではない

■SAP試験で押さえておくべきポイント

  • 高可用性アーキテクチャの3層冗長化
    • DB層：AuroraなどのマルチAZ・自動フェイルオーバー対応サービス
    • アプリ層：ALB＋Auto Scalingで複数AZ稼働
    • セッション層：RedisのようなマルチAZ対応インメモリデータストア
  • AuroraとRDSの違い
    • Auroraは分散ストレージ設計でフェイルオーバー高速化
    • 読み取り専用レプリカの追加も高速でスケールアウト容易
  • RedisとMemcachedの違い
    • Redis：レプリケーション・永続化・マルチAZ対応あり
    • Memcached：シンプルだが耐障害性がなく、フェイルオーバーに弱い
  • サービス選定基準
    • 用途に応じて適切なDB・キャッシュサービスを選び、可用性要件とマッチさせる

この形式で、他の問題も整理できます。次の問題も貼っていただければ同様にまとめます。

RELATED POST