ここまで作ってきたのは、
Internet
│
▼
ALB
│
▼
EC2
│
▼
RDS Security Group
まで。
そして今日は、いよいよRDS本体に近づいていく。
ただし、RDSはいきなり作らない。
まずは、
「RDSをどこに配置していいのか」
をAWSに教える必要がある。
そこで登場するのが、
DB Subnet Group
今日の構成図
今回考える構成はこう。
VPC
│
├── Private Subnet A
│ │
│ └── RDS
│
└── Private Subnet C
│
└── RDS
「あれ？」
と思ったかもしれない。
RDSは1つなのに、
なんでSubnetが2つ必要なの？
これが今日のテーマ。
まず新しいリソース
RDSを作る前に、
resource "aws_db_subnet_group" "main" {
}
を作る。
DB Subnet Groupって何？
簡単に言うと、
«「RDSを配置していいSubnetの一覧」»
をAWSに教えるためのもの。
例えば、
Private Subnet A
Private Subnet C
の2つを登録する。
イメージすると、
Private Subnet A ──┐
│
▼
DB Subnet Group
▲
│
Private Subnet C ──┘
│
▼
RDS
という感じ。
つまり、
RDSにSubnetを1つ直接指定するのではなく、DB Subnet Groupを指定する。
今日のコード
今回はここまで書いてみる。
resource "aws_db_subnet_group" "main" {
name = "main-db-subnet-group"
subnet_ids = [
]
}
この、
subnet_ids = [
]
の中身を自分で考えてみる。
今日の問題🔥
Q1
なぜ、
subnet_ids
なのだろう？
なぜ、
subnet_id
ではない？
Q2
なぜRDSは、
Public Subnet
ではなく、
Private Subnet
に配置するのだろう？
Q3【今日一番重要】
なぜAWSは、
subnet_id
ではなく、
DB Subnet Group
という仕組みを作ったのだろう？
ヒントは、
高可用性。
今日のゴール
今日理解したいのは、
«「RDSを作る前に、なぜDB Subnet Groupが必要なのか？」»
ということ。
コード自体は短い。
でも、ここにはAWSの重要な設計思想が入っている。
自分で書いたコード
今回、実際にコードを書いてみた。
resource "aws_db_subnet_group" "main" {
name = "main-db-subnet-group"
subnet_ids = [
aws_subnet.private.a.id
]
[
aws_subnet.private.c.id
]
}
そして、問題への回答。
Q1
«複数のサブネットからの通信を通したいから。»
Q2
«パブリックサブネットに置いたら誰でもアクセスできてしまいだめだから、データ保護のためにプライベートサブネットに置く。»
Q3
«RDSに一つのサブネットからしか通信できなかったら、その一つに障害が起きた時にデータにアクセスできなくなってしまうからDBサブネットグループを作った。»
今回のレビュー🔥
今回はかなり良い。
特にQ3では、
「高可用性」
という言葉を自分から使えている。
これはかなり重要な変化。
では、細かく見ていく。
コードレビュー
まずはTerraformのコードから。
今回のコードでは、
subnet_ids = [
aws_subnet.private.a.id
]
[
aws_subnet.private.c.id
]
となっていた。
これは、
1つのリストにまとめる。
正しくは、
subnet_ids = [
aws_subnet.private_a.id,
aws_subnet.private_c.id
]
のようにする。
イメージとしては、
subnet_ids
│
├── Private Subnet A
│
└── Private Subnet C
という1つのリスト。
ここは以前のALBと同じ
実は以前、ALBでも似たようなことをやった。
subnets = [
aws_subnet.public_a.id,
aws_subnet.public_c.id
]
今回のDB Subnet Groupも考え方は同じ。
つまり、
「複数のSubnetをまとめて指定する」
ということ。
AWSのリソースによって指定する属性名は違っても、
«複数の配置場所をまとめて指定する»
という考え方は共通している。
Q1：95点🌟
回答：
«複数のサブネットからの通信を通したいから。»
方向性はかなり良い。
ただし、ここだけ少し修正。
"subnet_ids" は、
通信を通すための設定ではない。
ここが重要。
DB Subnet Groupは、
«RDSを配置できるSubnetを登録するもの»
だから、
«「複数のPrivate SubnetへRDSを配置できるようにするため」»
と考えるとより正確。
つまり、
subnet_ids
↓
RDSを配置できる場所
であって、
subnet_ids
↓
通信を許可する
ではない。
95点！
Q2：100点💯
回答：
«パブリックサブネットに置いたら誰でもアクセスできてしまいだめだから、データ保護のためにプライベートサブネットに置く。»
これはかなり良い。
RDSには、
ユーザーデータ
アプリケーションデータ
業務データ
など、重要なデータが保存される。
そのため、
Internet
↓
RDS
のように直接インターネットへ公開する構成ではなく、
Internet
↓
ALB
↓
EC2
↓
RDS
のように、アプリケーションサーバーを経由してアクセスさせる。
もちろん、Private Subnetに置くだけで安全になるわけではない。
Security Groupなどのアクセス制御も組み合わせて、
必要な通信だけを許可する。
この考え方が大切。
100点！💯
Q3：100点🔥
回答：
«RDSに一つのサブネットからしか通信できなかったら、その一つに障害が起きた時にデータにアクセスできなくなってしまうからDBサブネットグループを作った。»
これ。
今回一番重要なところ。
100点！！
AWSでは、
«障害が起きることを前提に、複数のAZを利用して可用性を高める»
という考え方が非常に重要。
だから、
Private Subnet A
│
│
├──────┐
│ │
▼ ▼
AZ-A AZ-C
│ │
└──┬───┘
│
▼
RDS
のように、異なるAZにまたがるSubnetをDB Subnet Groupへ登録する。
これによって、RDSが利用できる配置先を複数用意できる。
つまり、
1つの場所に依存する
↓
障害時のリスクが高い
複数のAZに分散
↓
可用性を高められる
という考え方。
ここを自分の言葉で説明できているのはかなり良い。
100点！💯
ここで一つだけ重要な補足
今回、少しだけ混同しやすかったのが、
DB Subnet GroupとSecurity Groupの役割。
この2つは全然違う。
Security Group
Security Groupは、
«「誰からの通信を許可するか」»
を決める。
例えば、
EC2 Security Group
│
│ MySQL :3306
▼
RDS Security Group
なら、
EC2からの3306番通信を許可する
ということ。
DB Subnet Group
一方、DB Subnet Groupは、
«「RDSをどこに配置していいか」»
を決める。
例えば、
DB Subnet Group
│
├── Private Subnet A
│
└── Private Subnet C
となる。
つまり、
Security Group
↓
通信を制御する
DB Subnet Group
↓
RDSの配置先を指定する
役割が違う。
ここは今後も絶対に混同しないようにしたい。
今日の点数🌟
項目| 点数
コード| 95点
Q1| 95点
Q2| 100点
Q3| 100点
総合| 🌟98点🌟
かなり高い。
特に今回は、
コードの細かい文法よりも、AWSの設計思想を理解できているか
を重視した。
その意味ではかなり良い回答だった。
「Terraformを書く」から「AWSを設計する」へ
最近の学習を見ていて、一つ大きな変化がある。
最初は、
«「Terraformを書いている」»
という感じだった。
でも今は、
«「AWSの設計をTerraformで表現している」»
という状態に近づいてきた。
今回も、
Private Subnet A
Private Subnet C
を見て、
「高可用性のため？」
と考えられている。
これがかなり大きい。
Terraformのコードを丸暗記するのではなく、
AWSの設計
↓
なぜこの構成なのか？
↓
必要なリソース
↓
Terraform
という順番で考えられるようになっている。
ここまでの構成
ここまで作ってきたものを一度整理してみよう。
Internet
│
▼
ALB
(ALB Security Group)
│
▼
Listener
│
▼
Target Group
│
▼
EC2
(EC2 Security Group)
│
MySQL
:3306
│
▼
RDS Security Group
│
▼
DB Subnet Group
│ │
▼ ▼
Private A Private C
│ │
└──────┬──────┘
│
▼
RDS
ここまで来ると、かなり「AWSのシステム」らしくなってきた。
そして次回
🔥 第16回
いよいよ、
resource "aws_db_instance"
を書く。
つまり、
RDS本体
を作る。
ここまで来ると、
Internet
↓
ALB
↓
EC2
↓
RDS
という一連のシステムを、Terraformで形にできるようになってくる。
今回の学び
今日一番覚えておきたいのは、この2つ。
Security Group
↓
「誰から通信を受ける？」
DB Subnet Group
↓
「どこにRDSを配置できる？」
そして、
Private Subnet A
Private Subnet C
↓
複数AZに配置できる場所を用意
↓
高可用性
という設計思想。
最後に
今回の勉強で特に良かったのは、
「なんで？」を自分で考えてからコードを書いていること。
Terraformは、
コードを覚える
だけなら、たくさん暗記すれば書ける。
でも実務で必要なのは、
この構成なら、
なぜこのSubnet？
なぜこのSecurity Group？
なぜこの通信経路？
なぜ複数AZ？
を説明できること。
今回のQ3は、まさにそこに近づいている。
そして次回はいよいよ、
RDS本体をTerraformで作る。
ここまで作ってきたパーツが、少しずつ一つのシステムとしてつながっていく。
ここからさらに面白くなる。🚀☁️