週9アーキテクチャ設計

2026-09-26（土）アーキテクチャ設計（Well-Architected）

この記事の目次
  1. このハンズオンで使うAWSサービスと役割
  2. 操作前に知っておくべき設定項目
  3. よくある詰まりポイント・注意点
  4. このハンズオンが対応する試験論点

1. 【このハンズオンで使うAWSサービスと役割】

本座学ハンズオン（アーキテクチャ設計・弾力性に優れた設計の読み込み）では、これまでの各章で学んできた主要なAWSサービスをパズルのピースのように組み合わせ、システム全体に「弾力性（需要の変動に追従し、自律的に復旧する能力）」を持たせる設計モデルを学びます [p.19, p.23, p.291]。

サービス 役割
Elastic Load Balancing (ELB) ーー 単一障害点（SPOF）の排除と負荷分散 [p.66, p.67]
世界中からアクセスしてくるユーザーのトラフィックを、背後にある複数の仮想サーバー（EC2）へ均等に分配します [p.66, p.67]。特定のサーバーがクラッシュした際も、自動的にそれを検知して切り離すため、システム全体の単一障害点（SPOF）を撲滅する境界線となります [p.66, p.67, p.70]。
Auto Scaling ーー 需要の変動に即応する「弾力的なリソース増減（スケーリング）」 [p.68, p.69]
CloudWatchが計測するサーバー負荷（CPU使用率等）に連動して、稼働するEC2インスタンスの数を自動的に「スケールアウト（拡張）」または「スケールイン（削減）」します [p.68, p.69, p.245]。これにより、人間の手を一切介さずにインフラの供給量を最適化します [p.68, p.69]。
Amazon S3 ＆ Amazon RDS ＆ Amazon DynamoDB ーー ステートレス設計（セッションやデータの外出し）の格納庫 [p.101, p.129, p.143]
EC2インスタンスの内部メモリや物理ディスクにユーザーのログインデータやアップロードファイルを保持させず、これらの外部ストレージ・データベースに「状態（ステート）」を保存します [p.69, p.70]。Webサーバーを「いつ消えても困らない状態（ステートレス）」に保つための大前提となる永続化層です [p.69, p.70]。
Amazon SQS ＆ Amazon SNS ーー コンポーネント間の疎結合（デカップリング）の確立 [p.22, p.220, p.227]
複数の異なるシステム（例：注文受付システムと発送処理システム）を直接通信（密結合）させず、非同期のメッセージを中継させることで、一部のサーバー障害や高負荷遅延がシステム全体へと連鎖・破綻するのを防ぐバッファとして機能します [p.22, p.220]。

2. 【操作前に知っておくべき設定項目】

設計書を作成・評価する際（またはAWSコンソールで構成を定義する際）に、弾力性を保証するために必ず定義すべき重要設計パラメータです。

  • マルチAZ配置（冗長化設計）とアソシエイトサブネット [p.27, p.34, p.70]
    • 1つの物理データセンター（アベイラビリティゾーン：AZ）に大災害が起きてもシステムが停止しないよう、複数の異なるAZにプライベートサブネットを構築し、ELB・EC2・RDS（マルチAZレプリケーション）をまたがって物理配置するようにルートテーブルとサブネット境界を設計定義します [p.27, p.34, p.70, p.131]。
  • Auto Scaling グループのサイズ設定（最小 / 最大 / 希望する容量） [p.68]
    • 最小容量: 平常時に最低限維持する台数（システムの基礎的な可用性を確保） [p.68]。
    • 最大容量: アクセス急増時のコスト過加熱やAPI上限突破を防ぐための「ガードレールとなる最大台数」 [p.68]。
    • 希望する容量: 初期デプロイ時にプロビジョニングを開始する標準台数 [p.68]。
  • スケーリングポリシーの評価指標（トリガー基準） [p.68, p.245]
    • 「どのような状態になったら、何台インスタンスを増やすか（または減らすか）」を決定する基準です [p.68]。一般的に「CPU使用率（標準メトリクス）」などが監視指標（CloudWatch Logs / Alarm）としてマッピングされます [p.68, p.245]。
  • セッション / ファイルのデータ分離エンドポイント設定 [p.69, p.70]
    • Webサーバー（EC2）がステートレスに動くよう、アプリケーションのパラメータ設定でセッション情報の保管先を「Amazon DynamoDB」や「ElastiCache」、ファイルの出力先を「S3」のドメイン名（URLエンドポイント）へ向けるようにパスを完全に分離定義します [p.69, p.107, p.143, p.149]。

3. 【よくある詰まりポイント・注意点】

  • ⚠️ 詰まりどころ①：ステートフルな設計の残存（スケールイン時の大惨事） [p.69]
    • もしEC2インスタンスのローカル内に顧客のログインセッションや一時的な処理用データを保存（ステートフルに設計）していた場合、Auto Scalingの「スケールイン（負荷が下がったため、古いサーバーを自動削除する）」が発動した瞬間に、その削除されたサーバー内にいた顧客データやセッション情報が完全に物理消去されて復旧不能になります [p.69]。
    • 対策: 設計の初期段階から、サーバー内部には「いつ消えてもよい無駄のない一時データ（キャッシュ）」以外は一切書き込ませず、重要な状態は必ず外部サービス（S3、DynamoDB、RDS等）にのみ格納されるステートレス構成を徹底順守します [p.69, p.70]。
  • ⚠️ 注意点②：システム全体の耐障害性は「最も弱いコンポーネント」に引きずられる（部分的なSPOF） [p.27, p.66]
    • Webサーバー（EC2）を複数AZに冗長分散（マルチAZ設計）し、ELBで綺麗にロードバランシング構成を組んでいたとしても、そのすべてのサーバーが裏側で接続している「データベース（Amazon RDS）」がシングルAZ（1箇所のみで稼働）のまま構築されていた場合、そのDBデータセンターがダウンした瞬間にインフラ全体が完全に停止します [p.27, p.66]。
    • 対策: 可用性を設計する際は、「Web、AP、DB、ストレージ」のすべてのレイヤーにわたって一貫して単一障害点（SPOF）を排除（DBもRDSマルチAZ構成をアタッチ）しなければ意味をなさないことを意識してアーキテクチャ図をチェックしてください [p.27, p.66, p.131]。

4. 【このハンズオンが対応する試験論点】

  • 「スケールアップ（垂直スケーリング）」と「スケールアウト（水平スケーリング）」の境界線と選択判断 [p.58, p.66, p.69]
    • 試験では、「急増するワークロードに対して、システムの可用性を最大に維持し、かつコスト効率の良い対応を選択せよ」という設計問題が極めて高い頻度で問われます。
    • スケールアップ（EC2インスタンスタイプを巨大化する） は、サーバー再起動に伴う一時停止（ダウンタイム）が発生し、物理制限の上限に当たるとそれ以上の拡張が不可能になり、かつ単一の巨大サーバーがダウンした際のリスクが極めて大きいため不適合（アンチパターン）となります [p.58, p.66, p.69]。
    • スケールアウト（ELBを前段に置き、標準サイズのEC2を横に並列で増やす） は、無停止での動的スケーリングが可能で、1台が壊れても他が即時カバーできるため、高可用な弾力性設計の絶対的な「黄金のベストプラクティス（最適解）」としてマッピングされます [p.66, p.68, p.69]。
  • 「Design for Failure（障害を前提とした設計）」の具体的な実現能力 [p.70]
    • 「すべてのハードウェアはいずれ壊れる」というクラウド特有の基本設計原則に合致しているかが問われます [p.70]。
    • 1つの物理データセンター（AZ）が完全に停止しても、ELBのヘルスチェックが異常ノードを自動バイパスし [p.67]、Auto Scalingが別のアクティブな健全AZ側へインスタンスを自動プロビジョニング（自己修復・ロールバック）してサービスを継続するトポロジーを構築する力こそ、SAA-C03本試験の配点比率（弾力性に優れたアーキテクチャの設計：26%）を勝ち取るための最大の要点です [p.27, p.68, p.70]。

🔍 弾力性に優れた高可用インフラ設計の座学予習は、これで完璧です！