こんにちは！SRE兼クラウドアーキテクトの私です。
クラウドの世界に飛び込んだばかりの頃、「ロードバランサー」という言葉だけでもお腹いっぱいになりそうなのに、AWSを見れば「ALBだ」「NLBだ」「GLBだ」とアルファベットのオンパレード。さらにその中の設定項目を見てみると、「ターゲットグループ？」「ヘルスチェックのプロトコル？」……もうそっとブラウザを閉じたくなる気持ち、痛いほどよく分かりますよね。
でも、大丈夫です！一歩ずつ、身近な例えを交えながら一緒に紐解いていけば、決して怖いものではありません。今回は、数あるロードバランサーの中でも「超高速かつ大量のトラフィックをさばく筋肉担当」である NLB（Network Load Balancer）のターゲットグループとヘルスチェック に焦点を当てて、その裏側の仕組みを優しく解説していきましょう！
—
1. そもそもNLBってどんな子？（身近な例えで理解する）
まずは、NLBが現実世界でどんな役割を果たしているのか、イメージを膨らませてみましょう。
例えば、あなたがとても人気のある「巨大な郵便局（Webアプリケーションのサーバー群）」の窓口係のリーダーだと想像してください。毎日、何万通もの手紙（パケット）が世界中から届きます。
この郵便局の入り口に立つのが NLB です。NLBの仕事は、届いた手紙の中身（手紙の文章や宛先）をじっくり読むことではありません。「とにかく早く、正確に、裏で控えているたくさんの配達員（ターゲットサーバー）へ手紙を振り分けること」が仕事です。
レイヤー4（トランスポート層）と呼ばれるこの世界では、NLBは中身を開けず、封筒の表書き（IPアドレスやポート番号）だけを見て、秒速で荷物をさばいていきます。ALB（アプリケーションロードバランサー）が手紙の宛先や中身の「おねだり内容（URLやCookie）」を見て賢く仕分けする「コンシェルジュ」だとすれば、NLBは筋肉隆々の「超高速フォークリフト運転手」といったところです。
—
2. ターゲットグループと「健康診断」の重要性
さて、フォークリフトの運転手であるNLBは、裏で待機している配達員（ターゲットサーバー）たちに次々と荷物を渡していきます。ここで一つの疑問が湧きますよね。
「もし、ある配達員が居眠りしていたり、お腹を壊して倒れていたらどうなるの？」
当然、その人に荷物を渡してしまったら、荷物は行方不明になり、お客さん（ユーザー）は大激怒です。そうならないように、NLBは定期的に裏の配達員たちの健康状態をチェックしています。これが 「ヘルスチェック（死活監視）」 です。
そして、そのチェックを受ける配達員たちの控室が 「ターゲットグループ」 です。NLBは、このターゲットグループに登録されているサーバーたちに向かって、定期的に「生きてますか〜？」と声をかけ続けます。
—
3. ヘルスチェックのメカニズム：TCP vs HTTP/HTTPS
NLBのヘルスチェックには、いくつかの方法（プロトコル）が用意されています。代表的な TCP、HTTP、HTTPS の3つについて、それぞれの動きを覗いてみましょう。
① TCPヘルスチェック（一番シンプルで力強い方法）
最も基本的なのがTCPによるチェックです。これは、人間で言うところの「とりあえずドアをノックしてみる」という行動に似ています。
1. ノックする（SYN送信）: NLBが、ターゲットサーバーの指定されたポート（例えば 80 番や 443 番など）に対して、「おーい」と声をかけます（TCPの SYN パケット）。
2. 返事をする（SYN-ACK返信）: サーバーが正常に動いていれば、「はい、ここにいますよ！」と返事を返します（SYN-ACK パケット）。
3. 握手完了（ACK返信）: NLBが「よし、繋がったね」と最終的な挨拶を返して（ACK）、接続が確立します。
この一連の流れ（TCP 3wayハンドシェイク）が綺麗に完了すれば、「このサーバーは元気だな！」と判断して合格（Healthy）にします。もし、サーバーが落ちていてノックしても無反応だったり、「今忙しいんで無理です！」と拒否されたり（RSTが返ってくるなど）すると、不合格（Unhealthy）の判定を下します。
② HTTP / HTTPSヘルスチェック（アプリの中身まで踏み込む方法）
TCPチェックだけでも「ポートが開いているか」は分かりますが、これだけだと少し不安な時があります。例えば、「Webサーバーのプログラム自体は起動しているけれど、データベースとの接続が切れていて、画面が真っ白（エラー500）になっている」という状態です。
TCPチェックでは「ポートは開いているから合格！」と勘違いしてしまいます。そこで登場するのが HTTP / HTTPSヘルスチェック です。
これは、NLBがただノックするだけでなく、実際に「ちょっと、このページ（例: /healthz や /index.html）を見せてよ」とリクエストを投げる方法です。
サーバーが「はい、どうぞ！」と返してくれたときの HTTPステータスコード を見て判断します。
- 200番台（例:
200 OK）が返ってきた -> 「よし、アプリもバッチリ動いているな！」（合格） - 500番台や404番などが返ってきた -> 「おや、中身のアプリがおかしいぞ……」（不合格）
このように、レイヤー7（アプリケーション層）の視点まで交えて、より確実に「サービスが利用可能か」を判定できるのが、HTTP/HTTPSヘルスチェックの強みです。
—
4. 実務で役立つ！AWS CLIを使ったターゲットグループの設定例
「理屈は分かったけれど、実際の現場ではどうやって設定するの？」
そんな声にお応えして、AWS CLIを使ってNLBのターゲットグループを作成し、ヘルスチェックを設定する具体的なコード例を見てみましょう。ここでは、より実用的なHTTPヘルスチェックを行う例を取り上げます。
# ターゲットグループを作成するコマンド
aws elbv2 create-target-group \
--name my-app-tcp-target-group \
--protocol TCP \
--port 80 \
--target-type instance \
--vpc-id vpc-1234567890abcdef0 \
--health-check-protocol HTTP \
--health-check-port 80 \
--health-check-path /healthz \
--matcher HttpCode=200 \
--healthy-threshold-count 3 \
--unhealthy-threshold-count 3 \
--health-check-interval-seconds 30 \
--health-check-timeout-seconds 10パラメーターの意味を優しく解説！
--protocol TCP/--port 80: ユーザーからのトラフィックを受け渡す際のプロトコルとポートです。NLB本体はTCPで通信を受け付けます。--health-check-protocol HTTP: 健康診断にはHTTPプロトコルを使います（TCPだけでなくHTTPも選べるのがNLBの便利なところです！）。--health-check-path /healthz: サーバーの健康状態を確認するためにNLBがアクセスするURLのパスです。アプリ側で/healthzというエンドポイントを用意しておき、正常なら200 OKを返すように実装しておきます。--matcher HttpCode=200: 健康であるとみなすHTTPステータスコードを指定します。ここでは200を指定しています。--healthy-threshold-count 3: 「不合格だったサーバーが、何回連続でテストに合格したら『復活した！』とみなすか」の回数です（ここでは3回連続成功で合格）。--unhealthy-threshold-count 3: 「元気だったサーバーが、何回連続でテストに失敗したら『ダウンした！』とみなすか」の回数です（ここでは3回連続失敗で切り離し）。--health-check-interval-seconds 30: 健康診断を行うインターバル（間隔）です。30秒に1回、テストが行われます。
このように、現場の要件に合わせて「何秒おきに、どこへ、どうやってテストするか」を細かくチューニングできるのがインフラエンジニアの腕の見せ所です。
—
5. 現場のトラブルシューティング：よくあるハマりポイント
最後に、実務でNLBのヘルスチェックを構築・運用する際によくある「罠」と、その回避方法を現場の視点からこっそりお伝えします。
ハマりポイント1: セキュリティグループ（SG）の穴あき忘れ
「設定は完璧なはずなのに、なぜかターゲットが全部Unhealthy（不合格）になる……！」
これはインフラエンジニアが人生で一度は通る通過儀礼です。
NLBは、マネージドサービスであるため、NLB自体のIPアドレスが固定とは限りません（厳密にはElastic IPを付与することもできますが）。そのため、ターゲットサーバー側のセキュリティグループで、「どこからの通信を許可するか」を適切に設定する必要があります。特にHTTP/HTTPSヘルスチェックを行う場合は、VPC内のプライベートIP範囲や、NLBが配置されているサブネットからのトラフィック（ポート80や443）が、ターゲットサーバーにちゃんと届くようにルールをあらかじめ空けておきましょう。
ハマりポイント2: ヘルスチェックのパス（/healthz など）の応答速度
アプリ側で重いデータベースの処理を挟んでいるようなヘルスチェック用エンドポイントを作ってしまうと大変なことになります。NLBからの「生きてる？」という問いかけに対して、アプリがモタモタしているうちにタイムアウト（--health-check-timeout-seconds で設定した秒数）を超えてしまい、「元気なのに不合格判定（誤検知）」を受けてしまう現象が起きます。
ヘルスチェック用のパスは、データベースを見に行かずメモリ上のフラグを返すだけにするなど、「極限まで軽量に、秒速で200を返す作り」にするのがプロの定跡です。
—
まとめ
今回は、NLBのターゲットグループとヘルスチェックの仕組みについて、パケットの往復から現実世界の例え、そして実務で使える設定例まで一気に駆け抜けてみましたがいかがでしたでしょうか？
- NLB は、レイヤー4で超高速にパケットをさばく筋肉担当のフォークリフト運転手。
- ターゲットグループ は、配達員たちが待機する控室。
- ヘルスチェック は、TCPのノックやHTTPのステータス確認を通じて、配達員たちの健康状態を常に監視する大切な仕組み。
難しい用語やパラメーターも、一つひとつの意味を紐解いていけば、決して怖くありません。「なぜこの設定が必要なんだっけ？」と立ち止まったときは、いつでも今日の記事を思い出してみてくださいね。
それでは、また次回の技術解説でお会いしましょう！皆さんのクラウドライフが快適で安定したものでありますように！
コメント