こんにちは！SRE兼クラウドアーキテクトの私です。
インフラやネットワークの世界に一歩踏み出したばかりの皆さん、「ロードバランサー」や「ALB（Application Load Balancer）」という言葉、そして「ポート80番と443番」という数字の並びを見て、なんだか難しそうだなぁ……と身構えてしまっていませんか？
大丈夫です！最初は誰もがチンプンカンプンですし、アルファベットの羅列を見るだけで頭がクラクラするのは当然のことです。
今回は、クラウドの世界で最もよく使われる門番である「ALB」のリスナー設定、特に「HTTP（80番）」と「HTTPS（443番）」の組み合わせについて、身近な例えを交えながら一緒に優しく紐解いていきましょう。一歩ずつ進めば必ず理解できますので、リラックスして読んでくださいね。
—
1. そもそもALBってなに？現実の世界に例えてみよう
突然ですが、皆さん海外旅行などで大きな「ホテル」に泊まったときのことを想像してみてください。
そのホテルには、世界中から毎日何千人もの宿泊客がやってきます。もし、ホテルの入り口がたった一つしかなくて、そこにフロント係が一人だけしかいなかったらどうなるでしょう？ 大行列ができて、チェックインするだけで何時間も待たされてしまいますよね。
そこでホテル側は、「総合案内カウンター（ロビー）」をドーンと大きく作りました。
そこには専属のコンシェルジュたちがたくさん待機していて、やってきたお客さんを「あちらのA棟のエレベーターへどうぞ！」「B棟のレストランへはこちらです！」と、テキパキと空いている部屋やスタッフへ案内してくれます。
クラウドの世界における ALB（Application Load Balancer） は、まさにこの「超優秀な総合案内カウンター」そのものです。
インターネットの荒海を渡ってきたユーザーからのリクエスト（＝お客さん）を最初に受け止め、裏側で動いている複数のWebサーバー（＝お部屋）へ、バランスよく振り分けてあげる役割を持っています。
—
2. ポート80番と443番って、いったいなに？
ALBという総合案内カウンターには、お客さんを受け付けるための「窓口（ドア）」がいくつもあります。その中でも代表的なのが、ポート80番とポート443番です。
これも身近なものに例えてみましょう。市役所の窓口を思い浮かべてみてください。
- 80番窓口（HTTP）： 「身分証明書はいりません！誰でも気軽にお話しできる、気軽なご相談窓口」
- 443番窓口（HTTPS）： 「プライバシーを守るため、本人確認と厳重なカギ（暗号化）がかかった、安全なお手続き窓口」
インターネットの世界でも全く同じです。
- ポート80番（HTTP）： 通信の中身が暗号化されていない、丸見えの状態の道（Webの基本）です。今どきはセキュリティの観点から、そのままでは危ないのであまり使われません。
- ポート443番（HTTPS）： 通信が暗号化され、鍵がガッチリとかかっている安全な道です。現在のWebサイトの「絶対的な標準」となっています。
「じゃあ、危ないなら80番なんて無くしちゃえばいいのに！」と思いますよね。その通り、今のモダンなWebインフラでは、「80番にやってきたお客さんを、すべて安全な443番へ強制的に引越し（リダイレクト）させる」というおもてなしの構成が黄金律になっています。
—
3. ALBのリスナー設定はどうなっているの？
それでは、AWSなどのクラウド上で、この「80番と443番の連携プレー」をどのように設定するのか、実際の仕組みを覗いてみましょう。
ALBには「リスナー（Listener）」という設定項目があります。これは文字通り、「ALBの耳（リスナー）」であり、「どのドアで、どんなお客さんの声を待ち受けるか」を決める場所です。
今回は、以下のような優しくて安全な仕組みを作ります。
1. ユーザーがブラウザのURLに http://example.com （80番）と入力してアクセスしてきたら、ALBが「あ、危ないからこっちの安全な道に行ってね！」と、自動的に https://example.com （443番）へ案内し直す（HTTP to HTTPS リダイレクト）。
2. ユーザーが最初から https://example.com （443番）にアクセスしてきたら、SSL/TLS証明書という「身分証明書」を使って通信を安全にほどき、裏側のWebサーバーへ優しくパスする。
設定のイメージをつかもう
実際にインフラを構築するときは、AWSの管理画面（コンソール）や、Terraformなどのコードを使って以下のような設定を行います。ここでは、皆さんが現場でそのまま参考にできるよう、設定の構造を分かりやすく書き出してみました。
{
"LoadBalancerName": "my-friendly-alb",
"Listeners": [
{
"Port": 80,
"Protocol": "HTTP",
"DefaultActions": [
{
"Type": "redirect",
"RedirectConfig": {
"Protocol": "HTTPS",
"Port": "443",
"StatusCode": "HTTP_301" // 「永久に引っ越しましたよ」という意味のステータスコード
}
}
]
},
{
"Port": 443,
"Protocol": "HTTPS",
"SslPolicy": "ELBSecurityPolicy-TLS13-1-2-2021-06",
"Certificates": [
{
"CertificateArn": "arn:aws:acm:ap-northeast-1:123456789012:certificate/abc-123-xyz"
}
],
"DefaultActions": [
{
"Type": "forward",
"TargetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-servers/999"
}
]
}
]
}なんだか英語が並んでいて難しそうに見えますが、中身を日本語のコメントと一緒に眺めてみると、先ほどお話しした「ホテルの窓口案内」がそのままコードになっているだけだということが分かりますよね！
- 上半分のブロック（Port 80）は、「HTTPで来たら、問答無用で443へリダイレクト（お引越し）しなさい」という命令です。
- 下半分のブロック（Port 443）は、「HTTPSで来たら、SSL証明書を使って安全に受け止め、裏側のターゲットグループ（実際のWebサーバーたち）へバトンタッチしなさい」という命令です。
—
4. 現場のSREがこっそり教える、よくある落とし穴
最後に、私たちが実際の現場で「あ、やっちゃったな……」と頭を抱えがちな、初心者がハマりやすいポイントをこっそりシェアしておきますね。
セキュリティグループの穴あけを忘れずに！
ALBのリスナー設定をいくら完璧にしても、ALBの目の前にある「セキュリティグループ（仮想の防火壁）」で、ポート80番と443番の扉が閉まっていたら、お客さんはそもそもALBの建物に入ることができません。
インターネット（0.0.0.0/0）からの通信に対して、必ず TCP 80 と TCP 443 の通行許可（インバウンドルール）を忘れないであげてくださいね。
裏側のサーバーはHTTPでいいの？（SSLオフロード）
「443番で暗号化して通信するなら、裏側のWebサーバーも全部HTTPSに設定しなきゃいけないの？」と心配になる初学者は多いのですが、実はそんなことありません。
ALBが443番の暗号化をパカッと解除して中身を安全に確認し、裏側のサーバーへはスッキリした HTTP (ポート80など) で渡してあげる（これを SSLオフロード と呼びます）のが、クラウドインフラストラクチャでは非常にポピュラーな構成です。これにより、Webサーバー側の証明書管理の手間をグッと減らすことができます。
—
まとめ
いかがでしたでしょうか？
今回は、クラウドの顔であるALBにおける「HTTPリスナー（80番）」と「HTTPSリスナー（443番）」の役割と構成について、身近な例えを交えてお話ししました。
- ALB は、たくさんのお客さんを適切なサーバーへ案内する優秀な総合案内カウンター。
- ポート80（HTTP） は、暗号化されていない気軽な窓口。
- ポート443（HTTPS） は、鍵がかかった安全なメインの窓口。
- 実務では、80番にきたうっかりさんを、安全な443番へお引越し（リダイレクト）させるのが定番の技！
最初は複雑に見えるクラウドのネットワークも、一つひとつの部品が「現実世界でどんな役割をしているのか」をイメージできるようになると、パズルがカチッとはまるように楽しくなってきます。
あなたのインフラ学習の旅が、安全でワクワクする冒険になりますように。
それでは、また次回の技術ブログでお会いしましょう！SREチームより愛を込めて。
コメント