前回は、AWSの高可用性を意識した構成を設計した。
今回はそこから一歩進んで、
«「同じようなAWSリソースを、Terraformで効率よく管理するにはどうするか？」»
を学んでいく。
ここからは、いよいよTerraformらしい機能が登場する。
🗺️ 今日の構成図
会社から、こんな依頼が来たとする。
Internet
│
ALB
│
┌──────┴──────┐
│ │
EC2-1 EC2-2
先週までは、EC2を2台作るために、
resource "aws_instance" "web1" {
...
}
resource "aws_instance" "web2" {
...
}
のように、同じようなコードを2回書いていた。
しかし、これを10台、20台と増やしていくと大変になる。
そこでTerraformには、
同じようなリソースをまとめて作成するための機能
が用意されている。
それが今回学ぶ、
"count"
である。
💻 今日覚えるコード
今回のポイントは、ほぼこれだけ。
resource "aws_instance" "web" {
count = 2
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
}
ここで、
count = 2
と指定すると、
このリソースを2個作成する
という意味になる。
イメージすると、
resource "aws_instance" "web"
│
└── count = 2
│
┌─────┴─────┐
↓ ↓
EC2-1 EC2-2
となる。
📋 今日の問題
Q1
なぜ、
count = 2
を書くんだと思う？
Q2
もし、
count = 10
にしたら何が起きる？
⭐ 今日一番重要
会社から、
«「昨日まではEC2を2台だったけど、今日から3台にして。」»
と言われた。
どちらのほうが保守しやすいと思う？
パターン①
resource "aws_instance" "web1" {
...
}
resource "aws_instance" "web2" {
...
}
resource "aws_instance" "web3" {
...
}
パターン②
resource "aws_instance" "web" {
count = 3
...
}
なぜそう思う？
✍️ 今回の回答
Q1
«こう書くことでインスタンスを2つ作成できるから。また、一つ一つ書く時よりも管理を楽にするため。»
Q2
«インスタンスが10個作成される。»
⭐ 今日一番重要
«パターン②。»
«パターン①はインスタンスごとの設定を一つ一つしないといけないが、パターン②だと一つ作ればすべてに適応させることが出来る。»
🔎 今回のレビュー
今回はほぼ満点。⭐⭐⭐⭐⭐
特に良かったのは、単純に
«"count = 2" → 2台作れる»
と覚えるだけではなく、
«「管理を楽にするため」»
という、Terraformを使う目的まで理解できていること。
ここからTerraformの考え方がかなり変わってくる。
Q1のレビュー
回答：
«こう書くことでインスタンスを2つ作成できるから。また、一つ一つ書く時よりも管理を楽にするため。»
💯 正解。
さらに一歩踏み込むと、
«同じ設定のリソースを複数作るときに、コードの重複をなくすため»
とも言える。
例えば、
resource "aws_instance" "web1" {
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
}
resource "aws_instance" "web2" {
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
}
だと、同じ設定を何度も書いている。
一方、
resource "aws_instance" "web" {
count = 2
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
}
なら、同じ設定を1か所にまとめられる。
これは、
DRY（Don't Repeat Yourself）
という考え方にもつながる。
つまり、
«同じことを何度も書かない»
という、プログラムを書くときにも重要な考え方をTerraformでも利用している。
Q2のレビュー
回答：
«インスタンスが10個作成される。»
💯 正解。
count = 10
なら、
EC2 × 10
が作成される。
ただし、ここからは実務的な視点も必要になる。
EC2を10台作れば、当然、
10台分のAWSリソースが作成される。
そのため、
count = 2
から、
count = 10
に変更することは、単なる数字の変更ではない。
実際にAWS上で作成されるリソース数が増えるため、
- AWS利用料金
- CPU・メモリなどのリソース量
- ネットワーク構成
- ALBのターゲット数
- 運用・監視対象
などにも影響する。
つまり実務では、
«「countを変更したらAWS上で何が変わるか？」»
まで考える。
⭐ 一番重要な問題のレビュー
回答：
«パターン②。パターン①はインスタンスごとの設定を一つ一つしないといけないが、パターン②だと一つ作ればすべてに適応させることが出来る。»
💯 大正解。
この回答で特に重要なのが、
«「一つ作ればすべてに適応させることができる」»
という部分。
まさに"count"のメリットを理解できている。
🔧 保守性を考えてみる
例えば会社から、
«「Webサーバー3台のAMIを新しいバージョンに変更してください。」»
と言われたとする。
パターン①なら、
resource "aws_instance" "web1" {
ami = "ami-new"
}
resource "aws_instance" "web2" {
ami = "ami-new"
}
resource "aws_instance" "web3" {
ami = "ami-new"
}
のように、それぞれ修正する必要がある。
一方、"count"を使えば、
resource "aws_instance" "web" {
count = 3
ami = "ami-new"
instance_type = "t3.micro"
}
と、1か所を変更すればよい。
つまり、
コードの重複を減らす
↓
変更箇所が減る
↓
修正ミスを減らせる
↓
保守しやすくなる
というメリットがある。
🧠 ここで重要な考え方
今回の授業で、
count = 2
という1行を覚えた。
しかし、本当に覚えてほしいのは、この1行そのものではない。
重要なのは、
«「同じようなリソースを何個も個別に書くのではなく、Terraformに繰り返し作らせる」»
という考え方。
今までのTerraformは、
このコード
↓
このAWSリソース
という理解が中心だった。
しかし"count"からは、
このコード
↓
Terraformが繰り返し処理
↓
同じ種類のAWSリソースを複数作成
という考え方が入ってくる。
ここからTerraformが少しずつ、
「AWSを作るための設定ファイル」
から、
「インフラをプログラムのように管理するためのツール」
に見えてくる。
🔍 Terraform上ではどう管理される？
"count = 2"にすると、
resource "aws_instance" "web" {
count = 2
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
}
Terraform上では、複数のインスタンスを区別して管理する。
イメージとしては、
aws_instance.web[0]
aws_instance.web[1]
のようになる。
つまり、
web
├── [0] EC2
└── [1] EC2
という関係になる。
ここで、
«「あれ？同じ"web"なのに、どうやって1台ずつ区別しているの？」»
という疑問が出てくるかもしれない。
そこで登場するのが、
[0]
[1]
[2]
...
というインデックス。
例えば、
count = 3
なら、
aws_instance.web[0]
aws_instance.web[1]
aws_instance.web[2]
という形で、それぞれのインスタンスを区別できる。
💡 そして、ここで一つ限界が出てくる
今回、
count = 3
で、
EC2-1 → t3.micro
EC2-2 → t3.small
EC2-3 → t3.large
のように、それぞれ違う設定にしたい場合を考えてみる。
例えば、
resource "aws_instance" "web" {
count = 3
instance_type = "t3.micro"
}
としたら、
EC2-1 → t3.micro
EC2-2 → t3.micro
EC2-3 → t3.micro
となる。
つまり"count"は、
「同じような設定のリソースを複数作る」
のが得意。
逆に、
EC2-1 → t3.micro
EC2-2 → t3.small
EC2-3 → t3.large
のような、
「それぞれ異なる設定を持つ複数のリソース」
を管理するのは、"count"だけでは扱いにくい。
ここで次の機能が登場する。
"for_each"
🚀 次回予告
次回は、
第20回｜for_each
を学ぶ。
今回の最後に出てきた、
EC2-1 → t3.micro
EC2-2 → t3.small
EC2-3 → t3.large
のように、
同じ種類のリソースだけど、それぞれ設定が違う
というケースをTerraformでどう管理するのかを考える。
例えば、
web-a → t3.micro
web-c → t3.small
api → t3.large
のような構成だ。
"count"が、
«「同じものを複数作る」»
のが得意なのに対して、
"for_each"は、
«「それぞれ違う設定を持つものをまとめて管理する」»
のが得意。
ここまで理解できると、
Terraform
↓
AWSリソースを作る
↓
count
↓
同じものをまとめて作る
↓
for_each
↓
違う設定のものもまとめて管理する
というTerraformの考え方が見えてくる。
🌟 今回のまとめ
今回覚えたのは、
count = 2
という非常にシンプルなコード。
しかし、その裏側にある考え方はかなり重要だった。
"count"とは
同じようなリソースを指定した数だけ作成するための機能。
メリット
- コードの重複を減らせる
- 管理しやすい
- 一括で設定を変更できる
- リソース数の変更が簡単
- Terraformをプログラムのように扱える
そして今回、一番重要だったのは、
«「同じものを大量に作るなら、1個ずつコードを書くのではなく、Terraformに繰り返させる」»
という発想。
これはTerraformを使ううえで非常に重要な考え方になる。
次回は、この考え方をさらに一歩進めて、
「同じ種類だけど、それぞれ設定が違う場合はどうする？」
という問題に挑戦する。
そこで登場するのが、
"for_each"
である。🔥