マルチAZのVPC設計｜基礎を学ぶ

このレッスンでできるようになること。要件文に「単一障害点を排除する」と書かれたとき、VPC のサブネットをどう並べれば答えになるかを判断できるようになります。

要件の文から入る

ある会社が、EC2 の Web 層と RDS を 1 つの VPC で動かしています。今はサブネットが 2 つだけで、どちらも同じアベイラビリティーゾーン (AZ) にあります。監査で「単一障害点を排除すること」を求められました。アプリの改修はできません。何を足しますか。

SAA でこの形が出たら、答えはほぼ決まっています。サブネットを別の AZ にもう一組作り、その上に ELB と RDS のマルチAZ を載せるです。ここで押さえるべきなのは、AZ とサブネットの関係です。サブネットは 1 つの AZ の中にしか存在できません。つまり「AZ をまたぐ」とは、必ず「サブネットを増やす」ことを意味します。VPC 自体はリージョン全体にまたがるので、VPC を増やす必要はありません。ここを取り違えた選択肢が本番でよく並びます。

最小の冗長構成の形

試験で描けるようにしておきたい構成は、次の階層です。

VPC (リージョン全体。CIDR は /16 程度)
- AZ-a
  - パブリックサブネット a (ALB のノード、NAT ゲートウェイ)
  - プライベートサブネット a (EC2 アプリ、RDS プライマリ)
- AZ-c
  - パブリックサブネット c (ALB のノード、NAT ゲートウェイ)
  - プライベートサブネット c (EC2 アプリ、RDS スタンバイ)

ALB は「サブネットを 2 つ以上、別々の AZ から」指定しないと作れません。RDS のマルチAZ も、DB サブネットグループに 2 つ以上の AZ のサブネットが要ります。冗長化のためにマネージドサービスを使うと、結局サブネットを AZ ごとに用意させられるという点が、この章の背骨です。

パブリックとプライベートの線引き

	パブリックサブネット	プライベートサブネット
ルートテーブルの 0.0.0.0/0	インターネットゲートウェイ (IGW)	NAT ゲートウェイ、または無し
置くもの	ALB、NAT ゲートウェイ、踏み台	アプリの EC2、RDS、内部処理
インターネットからの着信	あり得る	直接は届かない

「サブネットが public か private か」を決めるのは、サブネットの設定ではなくルートテーブルの向き先です。IGW に向いていればパブリック、それだけです。この一文が、次のレッスンの NAT の話にそのままつながります。

要件語から構成への対応表

要件文の言い回し	選ぶもの
単一障害点を排除する	複数 AZ にサブネットを分け、ALB と RDS マルチAZ を組む
AZ 障害でも稼働を続ける	Auto Scaling グループの対象サブネットを複数 AZ にする
DB を停止させたくない	RDS マルチAZ (レプリカではない)
読み取りが重い	リードレプリカ (可用性の話ではない)
リージョン障害にも耐える	別リージョンへ複製。AZ を増やしても答えにならない

よくある引っ掛け

1 つめは、リードレプリカを可用性の答えにしてしまうものです。レプリカは読み取りを分散する仕組みで、自動フェイルオーバーの保証は別です。可用性の要件語が出たらマルチAZ です。

2 つめは、同じ AZ にサブネットを 2 つ作る構成です。サブネットは増えていますが、AZ が落ちれば両方巻き添えになるので、単一障害点は残ったままです。数ではなく AZ が分かれているかを見ます。

まとめ

VPC はリージョン全体、サブネットは 1 つの AZ の中にしか置けません
「単一障害点の排除」は、AZ ごとにサブネットを一組ずつ用意することから始まります
ALB と RDS マルチAZ は、そもそも複数 AZ のサブネットを要求します
パブリックとプライベートを分けるのはルートテーブルの向き先です
可用性はマルチAZ、読み取り性能はリードレプリカ。要件語で切り分けます