【SOA-C03】WEB問題集:信頼性とビジネス継続性編

WEB問題集

SOA-C03#1(reliability)

3 層 Web アプリは ALB、Auto Scaling Group の EC2、RDS で稼働しています。CPU 使用率が常に 30% 程度ですがアクセス急増時にレスポンスが悪化します。スケーリングを需要変動に追従させる最適な方法はどれですか。

ディスカッション 0

正解:A

正解の根拠

予測スケーリングは過去 14 日のメトリクス傾向から需要を機械学習し、需要発生前にキャパシティを増やします。ターゲット追跡を併用することで、予測外のスパイクにも反応的に対処でき、需要追従性が最大化されます。

スケーリングポリシー比較

方式予測性反応性
Stepなし
Target Trackingなし
Predictive + Target
Scheduled手動定義

設定例

aws autoscaling put-scaling-policy 
  --auto-scaling-group-name web-asg 
  --policy-name predictive 
  --policy-type PredictiveScaling 
  --predictive-scaling-configuration file://config.json

不正解の理由

  • B: 常時 2 倍のオーバープロビジョン方式はコスト最適化を著しく損なう副作用があり、需要追従の効率性に劣る構成です。
  • C: 手動スケジュール調整方式はスケーラビリティに劣る副作用があり、見落としリスクと突発スパイク時の対応漏れが発生します。
  • D: ステップ単独方式は事前準備機能が無い副作用があり、急増時にウォームアップ遅延が発生する反応型の運用となります。

参考:Predictive Scaling

SOA-C03#2(reliability)

RDS for PostgreSQL の単一 AZ 構成を本番運用に移行します。フェイルオーバー時間を最短化し、AZ 障害時にも自動で切替したい要件です。最適な構成はどれですか。

ディスカッション 0

正解:B

正解の根拠

RDS Multi-AZ DB クラスターは 2 つの読み取り可能スタンバイを別 AZ に持ち、フェイルオーバーは通常 35 秒未満で完了します。Multi-AZ DB インスタンスより高速かつ読み取りスケールも可能で、AZ 障害時の自動切替に最適です。

RDS HA 構成の比較

構成フェイルオーバー読み取り
Single-AZ + Read Replica手動昇格
Multi-AZ DB Instance60-120 秒不可
Multi-AZ DB Cluster35 秒未満2 台で可
スナップショット分〜時間不可

不正解の理由

  • C: 手動昇格は RTO が長くなります。
  • A: DB Instance は DB Cluster よりフェイルオーバーが遅いです。
  • D: スナップショットリストアは RTO が大きく、自動切替できません。

参考:Multi-AZ DB Cluster

SOA-C03#3(reliability)

S3 バケット上の重要オブジェクトを誤削除や上書きから保護したいと考えています。WORM 要件で 1 年間は変更を一切認めない必要があります。どの組み合わせが適切ですか。

(2つ選択)

ディスカッション 0

正解:B, E

正解の根拠

S3 Object Lock はバケットでバージョニング有効化が前提条件で、コンプライアンスモードでは root を含む誰もが指定期間中に削除・上書きできません。バージョニング + Object Lock の組み合わせで WORM が成立します。

S3 保護機能の比較

機能用途
バージョニングバージョン保持(前提条件)
Object Lock コンプライアンスWORM・全員不可
Object Lock ガバナンス特権ユーザのみ解除可
MFA Delete削除に MFA 必要だが WORM ではない

不正解の理由

  • A: レプリケーションは可用性向上が目的で、ソース改ざんが伝播する副作用があり WORM 要件は満たしません。
  • C: MFA Delete は削除に MFA を要求するだけで、上書き制御や不変保管は対象外となる副作用が残ります。
  • D: ライフサイクルはストレージクラス遷移機能で、Glacier 上でも改ざん防止の仕組みが別途必要となります。

参考:S3 Object Lock

SOA-C03#4(reliability)

運用エンジニアは DynamoDB テーブルを別リージョンへリアルタイムにレプリケーションし、双方向に書き込み可能な構成を求めています。最小実装はどれですか。

ディスカッション 0

正解:D

正解の根拠

DynamoDB Global Tables はマルチリージョンのアクティブ・アクティブレプリケーションを提供します。すべてのリージョンで読み書き可能で、衝突は最後の書き込みが優先されるため、追加実装なくマルチリージョン構成が完成します。

マルチリージョン手法の比較

方式双方向運用負荷
Global Tablesあり
Streams + Lambda自前
バックアップ復元非同期RPO 大
S3 経由該当外該当外

不正解の理由

  • C: 自前 Lambda 実装は運用負荷が大きいです。
  • A: バックアップは RPO・RTO が大きくリアルタイムではありません。
  • B: S3 レプリケーションは DynamoDB 用途には適しません。

参考:DynamoDB Global Tables

SOA-C03#5(reliability)

運用チームはユーザー向け Web サービスを 2 つのリージョンでアクティブ・スタンバイ構成にします。ヘルスチェックに失敗したら DNS レベルで自動的にスタンバイに切替たい場合、最適な Route 53 構成はどれですか。

ディスカッション 0

正解:D

正解の根拠

Route 53 のフェイルオーバールーティングはプライマリにヘルスチェックを関連付け、失敗時にセカンダリへ自動切替します。アクティブ・スタンバイ DR モデルに最適で、手動操作が不要です。

ルーティングポリシーの比較

ポリシー用途
Failoverアクティブ/スタンバイ DR
Weighted段階移行・A/B
Latency最寄り選択
Multivalue簡易ロードバランス

不正解の理由

  • C: 手動切替は RTO に悪影響です。
  • A: レイテンシは両系を常時稼働させる用途で、スタンバイには不適です。
  • B: 複数値回答は分散用で、フェイルオーバー専用ではありません。

参考:フェイルオーバールーティング