Application Load Balancer（ALB）
今回から、いよいよ**「AWSのサービスを組み合わせてシステムを作る」**ところに入っていく。
ここまで勉強してきたのは、
- VPC
- Subnet
- Internet Gateway
- Route Table
- Route Table Association
- NAT Gateway
だった。
これまでは、それぞれの役割を理解してきた。
でも今回は違う。
これらを使って、
«「インターネットからアクセスされたら、どうやってEC2まで通信を届けるのか？」»
を作っていく。
今日のゴールは、この構成。
Internet
│
▼
ALB
│
▼
Target Group
│
├── EC2
├── EC2
└── EC2
ここまで作れるようになると、AWSのネットワークが「サービスの暗記」ではなく、実際に動くシステムとして見えてくる。
まずALBって何？
ALBは、
Application Load Balancer
の略。
簡単に言うと、
«インターネットから来たリクエストを、複数のEC2へ振り分けるサービス»
だ。
例えばEC2が3台あるとする。
┌── EC2-1
│
Internet → ALB ── EC2-2
│
└── EC2-3
ユーザーから見ると、
Internet
↓
ALB
にアクセスしている。
ALBがその後ろにあるEC2へ通信を振り分ける。
まず今回の構成
ここまで作ってきたAWSを整理すると、
VPC
│
├── Internet Gateway
│
├── Public Subnet
│ │
│ ├── ALB
│ └── NAT Gateway
│
└── Private Subnet
│
├── EC2
└── RDS
という構成になっている。
ここで重要なのが、
ALBはどこに置くのか？
ということ。
ALBはインターネットからアクセスされる。
だから、
Internet
↓
ALB
という通信を受けられる場所に配置する必要がある。
そこで、
Public Subnet
に配置する。
TerraformでALBを作る
まず基本形。
resource "aws_lb" "alb" {
name = "sample-alb"
internal = false
load_balancer_type = "application"
subnets = [
aws_subnet.public_a.id,
aws_subnet.public_c.id
]
security_groups = [
aws_security_group.alb.id
]
}
ここから一つずつ見ていこう。
resource "aws_lb" "alb"
resource "aws_lb" "alb" {
これは、
«ALBを作ります»
という宣言。
"aws_lb" がAWSのロードバランサーを作るTerraformリソース。
"alb" はTerraform上で付ける名前。
name
name = "sample-alb"
これは単純。
ALBの名前を
sample-alb
にする。
internal
ここが今回の重要ポイント。
internal = false
最初に見たとき、
「falseって何？」
となった。
でも、ここは英語の感覚に慣れると分かりやすい。
"internal" は、
«内部向けか？»
という意味。
だから、
internal = false
なら、
«内部向けではない»
つまり、
«インターネット向け»
になる。
逆に、
internal = true
なら、
«内部向け»
になる。
君が気付いたポイント
ここは日本語話者だと少しややこしい。
「No」と答えたら「Yes」になるような感覚がある。
でも、
internal = false
は、
«「内部向けではありません」»
という意味。
だから結果として、
Internet-facing ALB
になる。
load_balancer_type
load_balancer_type = "application"
これは、
«Application Load Balancerとして作ります»
という設定。
ALBはApplication Load Balancerなので、
application
と指定する。
そして今回の重要ポイント
subnets = [
aws_subnet.public_a.id,
aws_subnet.public_c.id
]
ここで疑問。
なぜ、
subnet
ではなく、
subnets
なのか？
なぜ複数のSubnetを指定する？
ALBは高可用性を考えて、
複数のAZにまたがって配置する。
例えば、
AZ-A
│
└── Public Subnet A
│
└── ALB
AZ-C
│
└── Public Subnet C
│
└── ALB
という形。
だからTerraformでも、
subnets = [
aws_subnet.public_a.id,
aws_subnet.public_c.id
]
と複数のSubnetを指定する。
ここで今回の君の回答
君の最初の回答は、
«「パブリックサブネットAとCに負荷分散させるため。」»
だった。
これは惜しい。
95点。
なぜなら、ALBがSubnetに負荷分散するわけではないから。
ALBが負荷分散する相手は、
EC2などのターゲット。
例えば、
Internet
↓
ALB
↓
┌──┼──┐
↓ ↓ ↓
EC2 EC2 EC2
という形。
では、なぜSubnetを2つ指定するのか？
答えは、
«ALB自体を複数のAZにまたがって配置し、高可用性を確保するため。»
ここがポイント。
「負荷分散」と「高可用性」は違う
ここはかなり重要。
ALBの役割は、
EC2への負荷分散。
一方、
複数AZにALBを配置する理由は、
高可用性。
つまり、
負荷分散
↓
ALB → 複数のEC2
と、
高可用性
↓
ALB → 複数AZ
は別の話。
SAPでもよく出てきた考え方が、Terraformを書くことで実際の構成として見えてくる。
security_groups
次。
security_groups = [
aws_security_group.alb.id
]
これは、
«ALBに適用するSecurity Groupを指定する»
という意味。
今回はまだSecurity Groupそのものは作っていないので、
「後で作るんだな」
くらいでOK。
そして今回の質問
ここからが今回のレビュー。
Q1
なぜ、
subnets = [
aws_subnet.public_a.id,
aws_subnet.public_c.id
]
と複数のSubnetを指定する？
君の回答
«パブリックサブネットAとCに負荷分散させるため。»
レビュー
95点。
考え方はかなり近い。
ただし、
ALBがSubnetに負荷分散するわけではない。
ALBが負荷分散するのは、
ALB
↓
EC2
EC2
EC2
の部分。
複数Subnetを指定する理由は、
«複数のAZにALBを配置して高可用性を確保するため。»
ここを区別できれば完璧。
Q2
なぜALBはPublic Subnetに置く？
君の回答は、
«「インターネットからサブネットへの通信を負荷分散させるため。」»
だった。
レビュー
90点。
ここも少し修正。
ALBが負荷分散する対象は、
SubnetではなくEC2。
では、なぜPublic Subnetに置くのか？
答えは、
«インターネットからの通信を最初に受け取る必要があるから。»
つまり、
Internet
↓
ALB
↓
EC2
という入口になる。
だからALBは、
インターネットから到達できるPublic Subnet
に配置する。
Q3
そして一番難しかった問題。
internal = false
これは何を意味する？
君の最初の回答は、
«「サブネットへの通信失敗を検知したときに負荷分散？」»
だった。
これは……
40点！
でも、この間違いはかなり良い。
なぜなら「ALBは通信を振り分けるもの」という知識から考えて、自分で答えを組み立てようとしているから。
正解
internal = false
は、
«インターネット向けのALB»
を意味する。
逆に、
internal = true
なら、
«VPC内部向けのALB»
になる。
具体例
例えば、
会社のWebサイト。
Internet
↓
ALB
↓
EC2
これは外部からアクセスされる。
だから、
internal = false
一方、社内システムなら、
社員
↓
VPN
↓
Internal ALB
↓
EC2
のような構成にできる。
この場合は、
internal = true
となる。
今回の君の修正版
その後、君自身で理解を更新してくれた。
«「internalは内部なので、Falseの場合はインターネット公開、TrueはVPCの内部だけ」»
これは100点。
さらに、
«「ALBがサブネットA・Cどちらにもあるから。負荷分散より、高可用性のほうが適切。」»
これも重要な修正。
そして、
«「ALBはサブネットじゃなく、EC2に振り分ける。」»
これが今回一番大きな理解。
今日のまとめ
今回覚えたことを整理すると、
設定| 意味
"aws_lb"| Load Balancerを作成
"name"| ALBの名前
"internal = false"| インターネット向け
"internal = true"| 内部向け
"load_balancer_type = "application""| ALBとして作成
"subnets"| ALBを配置するSubnetを指定
複数AZ| 高可用性のため
"security_groups"| ALBに適用するSG
そして通信の役割は、
Internet
↓
ALB
↓
Target Group
↓
EC2
今日、一番大事だったこと
今回の授業で面白かったのは、
最初の答えが間違っていても、そこから自分で修正できたこと。
例えば、
«「ALBがSubnetに負荷分散する」»
↓
«「ALBはEC2に振り分ける」»
さらに、
«「Subnetを複数指定するのは負荷分散のため」»
↓
«「複数AZに配置して高可用性を確保するため」»
と変わった。
これがただの暗記との違い。
Terraformを「AWSコンソールのコード化」として見る
ここまで来ると、
internal = false
を見たときに、
Terraformの文法として覚える必要がなくなる。
頭の中で、
ALB作成画面
○ Internet-facing
● Internal
……じゃなくて、
「今回はInternet-facingだからfalseだな」
とAWSの設定から逆算できる。
同じように、
subnets = [...]
を見たら、
«「ALBは複数AZに配置するから、Subnetを複数指定するんだな」»
と考えられる。
これが、
AWSの知識 → 構成設計 → Terraform
という流れ。
そして次回
次はいよいよ、
Target Group
ここで、
Internet
↓
ALB
↓
Target Group
↓
EC2
という構成を完成させる。
Target Groupは、
「ALBがどのEC2へ通信を送るのか」
を管理する場所。
さらに、
«「このEC2は正常に動いてる？」»
を確認するHealth Checkも登場する。
つまり次回から、
「ALBを作った」
ではなく、
「ALBから実際にEC2へ通信を届ける」
ところまで進む。
最後に
資格勉強をしていた頃は、
- ALB
- Target Group
- Health Check
- AZ
- Subnet
- Security Group
を、それぞれ別々の知識として覚えていた。
でも今は違う。
Internet
↓
Public Subnet
↓
ALB
↓
Target Group
↓
Private Subnet
↓
EC2
という一つのシステムとして考えられるようになってきた。
これが、資格で覚えた知識が実際のAWS設計につながる瞬間。
そしてTerraformは、その設計を
「コードとして再現するための道具」
になっている。
ここまで来ると、Terraformの文法を一つずつ暗記するより、
«「AWSコンソールなら、今どの設定をしている？」»
と考えながらコードを書く方が圧倒的に理解しやすい。
次回はTarget Group。
いよいよ、
ALBとEC2を本当に接続する。 ☁️🔥