週9アーキテクチャ設計

2026-10-02（金）アーキテクチャ設計（Well-Architected）

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

1. 【この範囲の全体像】

本範囲は、AWS Well-Architected フレームワークの設計原則を実システムへ適用するための、試験で最も配点の高い総合インテグレーション領域です [p.6, p.11, p.290]。

「弾力性（ステートレス設計）」[p.69, p.291]、「高パフォーマンス（キャッシュと負荷分散）」[p.295]、「セキュリティ（最小特権）」[p.298]、「コスト最適化（需給一致）」[p.300] といった対立しがちな要件に対し、最もベストプラクティスに沿った最適な構成をロジカルに選択する能力が問われます [p.297]。

各サービスの個別機能だけでなく、サービス同士を組み合わせたシステム全体の整合性と「なぜその構成にすべきなのか」の理由を深く理解することが合否の絶対境界線となります [p.6]。

2. 【重要キーワード・サービス一覧】

キーワード 説明
疎結合（Loose Coupling）と弾力性（Elasticity） [p.291] システムコンポーネント同士の直接的な依存度を最小化し、メッセージキュー（SQS）やパブサブ（SNS）を仲介させることで、一部の障害が全体へ連鎖するのを防ぎつつ、トラフィックに応じてAuto Scalingで動的に並列スケールアウト（水平拡張）させる設計思想 [p.66, p.220, p.227, p.291]。
単一障害点（SPOF: Single Point of Failure）の排除 [p.66, p.307] 特定のサーバー、データベース、あるいは1つのアベイラビリティゾーン（AZ）など、たった1つのリソースが停止しただけでシステム全体がダウンしてしまう構成を完全に排除すること [p.66, p.307]。マルチAZへの冗長化配置やELBによる負荷分散が必須のアプローチとなります [p.66, p.70, p.307]。
キャッシュ戦略によるボトルネック解消 [p.295, p.297] データベースやストレージへの重複するアクセス要求を、データベースの前段に置いたインメモリキャッシュ（ElastiCache）や、ユーザーに近いエッジロケーション（CloudFront）から超高速（ミリ秒〜マイクロ秒）に返却し、バックエンドの過負荷と回線遅延を極小化する設計 [p.149, p.160, p.295, p.297]。
最小特権の原則（Least Privilege） [p.298] ユーザーやシステムコンポーネントに対し、目的の操作を遂行するために必要な「最小限の実行権限（APIアクション）」のみをIAMポリシーで割り当てること [p.298]。静的なアクセスキーの埋め込み（ハードコード）はセキュリティ違反であり、一時的な認証情報を自動更新する「IAMロール」をアタッチするのが鉄則です [p.62, p.184, p.298, p.310]。
需給の一致（Matching Supply and Demand） [p.300] 事前に予測した最大負荷に合わせて過剰なキャパシティを固定的に調達するのではなく、実際の需要の波（トラフィックの増減）にインフラの供給量を全自動で合致させ、アイドル状態の不要な余剰コストをゼロに抑え込むコスト最適化アプローチ [p.300]。

3. 【試験で問われる比較ポイント】

Well-Architectedの柱に基づく類似機能・アプローチの徹底使い分け [p.131-133, p.220, p.227, p.291]

比較テーマ アプローチA アプローチB 決定的な選定シグナル（試験上のキーワード） [p.307-312]
可用性・障害耐性 [p.131, p.132] RDS Multi-AZ 構成
異なるAZ間で同期レプリケーションを行う [p.131]。		 リードレプリカの増設
マスターDBから非同期レプリケーションを行う [p.132, p.133]。		 🎯 「 データベースの物理障害やAZ全体の被災時、データ損失なしで短時間で全自動フェイルオーバー（自動復旧）させたい 」 ➔ RDS Multi-AZ を選択 [p.131, p.307]（リードレプリカは参照性能を拡張するためだけの機能 [p.132]）。
スケーリング [p.58, p.66, p.291] スケールアップ（垂直拡張）
インスタンス自体のCPUやメモリ性能を上げる [p.58, p.291]。		 スケールアウト（水平拡張）
同一仕様のインスタンス台数を並列に増やす [p.66, p.291]。		 🎯 「 アクセス負荷の変動が予測できない本番Web環境において、単一障害点（SPOF）を排除し自律的な耐障害性を確保したい 」 ➔ ELBと連動した スケールアウト（水平） を選択 [p.66, p.291, p.307]。
結合緩和（非同期） [p.220, p.227] Amazon SQS
1対1（プル型）。ワーカーが自律的にメッセージを引っこ抜く [p.220]。		 Amazon SNS
1対多（プッシュ型）。登録先にメッセージを一斉同報配信する [p.227]。		 🎯 「 突発的なアクセススパイク（書き込み）を受け止めてバッファリングし、後段のシステムを過負荷から確実に保護（負荷平滑化）したい 」 ➔ メッセージ保持能力のある Amazon SQS を選択 [p.220, p.221, p.291]。
セキュリティ・統制 [p.36] セキュリティグループ
ステートフルな通信制御。インスタンス単位に適用する [p.36]。		 ネットワークACL (NACL)
ステートレスな通信制御。サブネット単位に適用する [p.36]。		 🎯 「 特定の悪意あるソースIPアドレス（攻撃元）からの通信を、インフラの入り口で確実に明示的拒否（Deny）して遮断したい 」 ➔ ネットワークACL を選択 [p.36]（セキュリティグループには拒否ルールを書けない [p.36]）。

4. 【ひっかけ注意ポイント】

  • ひっかけ①：データベースの自動復旧・可用性要件に対して「リードレプリカ」を選ばせる罠 [p.131, p.132, p.133]

    • 罠パターン: 「本番データベースの物理障害発生時に、データの不整合やロストを発生させず、数分以内で確実にスタンバイ環境へ全自動フェイルオーバーできる強固な耐障害性アーキテクチャにするため、別アベイラビリティゾーンにリードレプリカをプロビジョニングした。」
    • なぜ間違いか: リードレプリカは 「 非同期レプリケーション 」 でデータを複製するため、マスター障害時にフェイルオーバーさせようとすると、未反映の差分データが消失（データロスト）するリスクを伴います [p.132, p.133]。障害検知後にDNSを全自動で切り替え、同期レプリケーションによって「データロストゼロ」の自動復旧（高可用性）を担う機能境界は、RDS Multi-AZ のみの専門役割です [p.131]。
    • 対策: 高可用・自動復旧には Multi-AZ を選択し、読み取りSelectクエリ過負荷の解消には リードレプリカ を指定して、問題文の課題シグナルと厳密に切り分けてマッピングします [p.131, p.132]。

  • ひっかけ②：OS内部のメモリ（RAM）枯渇を「エージェントなしの標準CloudWatchアラーム」で監視・自動拡張させようとする罠 [p.245, p.247]

    • 罠パターン: 「EC2上で動く業務アプリケーションのメモリリーク（RAMの枯渇）を未然に防ぐため、追加のモジュールインストールなどの運用オーバーヘッドを一切排除して、標準のCloudWatchメトリクス監視アラームを設定し、メモリ使用率が85%を超えたら自動スケーリングする構成にした。」
    • なぜ間違いか: 責任共有モデルに基づき、ハイパーバイザー（OSの外側）から透過的に視認できるのは、CPU使用率、ネットワークI/O、ディスク物理I/Oなどの「外側から見えるパフォーマンスデータ」に制限されています [p.196, p.245, p.247]。ゲストOS内部の完全なプライベート情報である 「メモリ使用率（RAM）」や「特定フォルダのディスク空き容量」は、標準モニタリング機能では100%取得することが不可能 です [p.245, p.247]。
    • 対策: OS内部のメトリクス監視、ログ収集の要件が提示された場合は、必ず対象のEC2インスタンス内部に 「 CloudWatch Agent（エージェント） 」 をデプロイして「カスタムメトリクス」をプッシュ送信する設計を指定してください [p.245, p.247]。

  • ひっかけ③：ステートフルなWebサーバー群に対し、セッション管理をそのままに「Auto Scaling」を単純適用する罠 [p.69, p.291]

    • 罠パターン: 「ユーザーがログインして買い物カゴに商品を入れるECサイトを設計した。アクセスの増減に合わせて費用を最適化するため、EC2にそのままAuto Scalingを設定した。これによりユーザーのセッション状態を維持しながら自動で台数を増減できる。」
    • なぜ間違いか: 各Webサーバー（EC2）の物理メモリ内にログインセッション情報を保持している（ステートフルな）設計のままAuto Scalingを組むと、縮小（スケールイン）時にセッションを保持したEC2が物理削除されたり、ロードバランサーが異なるEC2にリクエストを割り振った瞬間に、ユーザーはセッション切断（強制ログアウト・カートの中身の消失）を起こし、重大なシステム欠陥を招きます [p.69]。
    • 対策: 弾力性に優れた設計を構築する際は、セッションデータを Amazon DynamoDB などの外部データストア、または ElastiCache などの共有インメモリキャッシュに外出し（永続化）して、Webサーバー群を完全に「ステートレス化」する設計をセットで選択します [p.69, p.143, p.149, p.291]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。