AWS 11：ロードバランサー（ALB） ― 複数台の前に立つ入口

2台にした。でも、利用者はどちらへ行けばいい？

では、フォトログのサーバーを2台にしてみます。第10章で作った AMI から、もう1台起動すれば、同じ中身の台ができます。

ところが、ここで困ったことが起きます。2台はそれぞれ別のパブリック IP（第9章）を持っています。利用者は、どちらの住所にアクセスすればいいのでしょうか。

どれも、「どの台が元気か」を利用者の側に判断させているのが問題です。利用者は、サーバーの事情を何も知りません。

必要なのは、利用者からは1つの住所に見えて、その裏で元気な台を選んで渡してくれる係です。この係をロードバランサー（負荷を分散する装置）と呼びます。

ロードバランサー：1つの入口で、後ろの台に振り分ける

ロードバランサーは、複数のサーバーの前に立つ入口です。利用者はロードバランサーだけにリクエストを送り、ロードバランサーが後ろの台を1つ選んで中継します。

たとえるなら、大きなお店の入口に立つ案内係です。お客さんはお店の住所だけを知っていればよく、中に入ると案内係が空いているレジへ案内してくれます。レジが1つ閉まっていても、案内係はそこへは案内しません。

AWS のロードバランサーのサービスは Elastic Load Balancing（ELB）と呼ばれ、中にいくつかの種類があります。Web サービスでいちばん使うのが ALB（Application Load Balancer）です。「Application」とは、Web の通信（HTTP＝ブラウザとサーバーの会話の決まり、その暗号化版の HTTPS）の中身まで読んで振り分けられる、という意味です。

ALB 自体も、AWS が裏で複数の機械で動かしています。ALB が1台の機械で、それが壊れたら終わり、ということはありません。

置き場所：ALB はパブリック、サーバーはプライベート

ALB を置くと、ネットワークの設計（第5〜8章）が一段きれいになります。

図では、上の段のパブリックサブネットに ALB が1つ、AZ 1a と 1c にまたがって置かれています。下の段のプライベートサブネットには、AZ ごとに1台ずつサーバーがあります。

この形には、よいことがたくさんあります。

これが、第2章で「なぜ複数の AZ を使うのか」と問いかけたことの、具体的な答えです。

なお、プライベートのサーバーが OS の更新をダウンロードするには、第7章の NAT ゲートウェイか VPC エンドポイントが要ります。中に入るのは、第9章の Session Manager です。

リクエストの流れ ①：ALB が1台目に渡す

利用者が「写真の一覧を見せて」とリクエストを送ったときの流れを、図の赤い小包で追います。

ALB は、既定ではラウンドロビン（順番に回す）で台を選びます。1件目は Web 1、2件目は Web 2、3件目は Web 1…という具合です。処理中の件数が少ない台を選ぶ方式に切り替えることもできます。

ここで大事な点が1つあります。サーバーから見ると、リクエストは ALB から届いたように見えることです。利用者と直接話しているわけではありません。だから、サーバーの扉（SG）は「ALB から」を許せばよく、利用者の住所を許す必要はありません（この後で見ます）。

リクエストの流れ ②：次のリクエストは2台目へ

次のリクエストが来ると、ALB は今度は Web 2 を選びます。図の小包が、右の台へ移りました。

台が2台なら、1台あたりの仕事はおよそ半分。4台なら4分の1です。混んできたら台を足せば、1台あたりの負担が下がります。台を足しても、利用者が使う住所（ALB の名前）は変わりません。

ここで、次のことに気づくでしょうか。

1人の利用者の続けての操作でも、毎回違う台が答えるかもしれないのです。利用者はそれを知りませんし、知る必要もありません。

逆に言えば、サービスを作る側は、どの台が答えても同じ結果になるようにしておかなければなりません。Web 1 に投稿した写真は、Web 2 からも見えなければいけませんし、Web 1 でログインした状態は、Web 2 でも続いていなければいけません。

これが、この後のフォトログで出てくる困りごとの正体です。第12章で「ステートレス」という考え方として整理します。

ALB を作る4つの部品

ALB は、図の番号の4つの部品を組み合わせて作ります。

ターゲットグループに入れる送り先（ターゲット）には、EC2 のインスタンスのほか、IP アドレスや、第22章の Lambda 関数も指定できます。

大事なのは、リスナーとターゲットのポートは別でよいことです。利用者は80番（HTTP の標準）に来ますが、ALB はそれを台の8080番（アプリが待っているポート）へ渡せます。利用者からは、アプリがどのポートで動いているかは見えません。

また、ヘルスチェックはターゲットグループの設定の一部です。グループごとに「どの URL で元気さを確かめるか」を決めます。次に、その仕組みを見ます。

ヘルスチェック：元気な台だけに渡す

ALB は、ターゲットグループの各台に、定期的に「元気？」とリクエストを送っています。これがヘルスチェックです。

図では、Web 2 が続けて返事をしなかったので「不健康」と判定され、ALB は Web 2 へリクエストを渡すのをやめました。赤い小包は Web 1 にだけ届いています。利用者から見ると、何事もなかったかのように使い続けられます。

不健康になった台は、捨てられるわけではありません。見回りは続いていて、直って5回続けて返事がよければ、自動で振り分けに戻ります。

逆に言うと、ALB は壊れた台を直したり、新しい台を足したりはしてくれません。1台が壊れたままだと、残りの台だけで全員を受け持つことになります。壊れた台を自動で入れ替えるのは、次の第12章の Auto Scaling の役目です。

ヘルスチェックは「何を確かめるか」を決める

既定のヘルスチェックはトップページ（/）に聞きますが、実際には確認用の URLを用意するのがおすすめです。たとえば /health に来たら、「アプリは動いています」と短く返すだけの入口を作ります。

難しいのは、どこまで確かめるかです。

最後の行は特に大事です。DB は全台で共有しているので、DB の不調を各台のヘルスチェックに入れると、全台が同時に外れてしまいます。台を入れ替えても DB は直らないので、意味がありません。

そこで、「この台自身が、リクエストに答えられる状態か」だけを見るのがよい落としどころです。DB などの共有部品の不調は、監視（第17章）で別に知らせます。

ちなみに、全部の台が不健康になった場合、ALB は「全台に配る」動きをします（フェイルオープン）。全部止めてしまうより、動くかもしれない台に渡したほうがまし、という考え方です。

パスで振り分ける：1つの入口に、何種類ものサーバー

ALB は HTTP の中身を読めるので、URL を見て行き先を変えることができます。これがルールです。

ルールには優先順位があり、上から順に確かめて、最初に当たったものが使われます。どれにも当たらなければ、リスナーの既定の行き先に回ります。

条件には、パスのほかにホスト名（api.photolog.example と www.photolog.example で分ける）、ヘッダー、クエリ文字列（URL の ? の後ろ）なども使えます。条件に当たったら、振り分ける代わりに「別の URL へ転送する」「決まった返事を返す」こともできます。

これのうれしい点は、1つの ALB で複数のサービスを受けられることです。API のサーバーだけ台数を増やす、管理画面は社内の人だけに絞る、といったことが、入口を分けずにできます。ALB は1つごとに時間の料金がかかるので、まとめられるならまとめたほうが安くなります。

フォトログも、画面を返す部分と、スマートフォンのアプリから呼ばれる API を、後でこの方法で分けることになります。

扉の設計：サーバーは「ALB からだけ」受け付ける

ALB を置いたら、第8章のセキュリティグループ（SG）を次の形にします。

ポイントは2行目です。サーバーの扉は、IP アドレスではなく、ALB の SG を指して許しています。第8章で見た「SG から SG を許す」形です。

こうしておくと、利用者は必ず ALB を通ることになります。後で ALB に HTTPS（第14章）や WAF（第27章、攻撃を止める盾）を付けたとき、それを迂回される心配がありません。

台を外すときは、話し中の人を待ってから

サーバーを更新するときなど、台をターゲットグループから外したい場面があります。このとき、いきなり外すと、その台で処理中のリクエストが途中で切れてしまいます。写真のアップロード中なら、失敗になります。

そこで ALB は、台の登録を解除すると、次のように動きます。

この待ち時間を登録解除の遅延（接続のドレイニングとも言います）と呼び、既定は300秒です。すぐ終わる処理しかないサービスなら、短くすると入れ替えが速くなります。

もう1つ、ALB の後ろのサーバーで知っておきたいことがあります。サーバーから見ると、リクエストの送り元は ALB です。本当の利用者の IP アドレスを知りたいとき（アクセスの記録や、不正な利用の調査など）は、ALB が付けてくれる `X-Forwarded-For` というヘッダー（リクエストに付いてくる追加の情報）を見ます。ログの設定で、これを記録するようにしておきます。

ALB と NLB：何を見て振り分けるかの違い

ELB には、ALB のほかに NLB（Network Load Balancer）があります。違いは、何を見て振り分けるかです。

TCP と UDP は、インターネットでデータを運ぶ基本の決まりです。HTTP は TCP の上に乗っている「会話の中身の決まり」なので、NLB は中身の会話を読まずに、接続をそのまま後ろへつなぎます。そのぶん速く、たくさんの接続をさばけます。

NLB を選ぶ主な理由は、固定の IP が必要なとき（取引先に「この IP からの通信だけ許可して」と言われた、など）や、HTTP ではない通信を扱うときです。

さらに、通信の中身を検査する専用の機械（ファイアウォールの製品など）の前に置く Gateway Load Balancer もありますが、ふつうの Web サービスでは使いません。

フォトログは Web のサービスなので、ALB を使います。迷ったら ALB、と覚えておけば、まず間違いありません。

作り方：ターゲットグループ → ALB → リスナー

コンソールでは、EC2 の画面の左の「ロードバランシング」から作ります。図の番号の順に進めます。

CLI で主要な部分を書くと、次のようになります。

aws elbv2 create-target-group --name photolog-web \
  --protocol HTTP --port 8080 --vpc-id vpc-0aaa \
  --health-check-path /health
aws elbv2 create-load-balancer --name photolog-alb \
  --subnets subnet-pub-1a subnet-pub-1c --security-groups sg-alb
aws elbv2 create-listener --load-balancer-arn <ALB の ARN> \
  --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=<グループの ARN>

ARN は、AWS の中のものを指す長い名前（Amazon Resource Name）です。作ったときの結果に出てきます。

ALB の IP アドレスは変わることがあるので、アクセスするときは必ず DNS 名を使います。第14章で、自分のドメイン（photolog.example.com）をこの ALB に向けます。

フォトログ v1：入口1つ・AZ ごとに1台

ここまでの内容で、フォトログは次の形になりました。

1台が止まっても、もう1台が答えます。AZ 1a 全体が止まっても、1c で動き続けます。

ところが、2台にした途端、利用者から2つの苦情が届きました。

どちらも、台の中に、その台だけが知っている情報を置いていることが原因です。前に見た「どの台が答えても同じ結果になる」が守られていません。

ALB には、同じ利用者を同じ台へ送り続けるスティッキーセッションという機能もあります。でもこれは一時しのぎです。その台が壊れたら、やはり写真もログインも消えます。本当の解決は、次の第12章で見る「台の中に大事なものを置かない」ことです。

お金：動いている時間と、処理した量

ALB の料金は、主に次のものにかかります。

LCU（Load Balancer Capacity Unit）は、ALB がどれだけ働いたかを測る単位です。「新しい接続の数」「同時につながっている数」「運んだデータの量」「ルールを確かめた回数」の4つを測り、そのうち最も多く使ったもので数えます。小さなサービスなら、LCU の料金はわずかです。

気をつけたいのは、作っただけで時間の料金がかかることです。練習で作った ALB を放っておくと、利用者が1人もいなくても毎月かかります。

安くするコツは、前に見たようにルールで1つの ALB にまとめることです。サービスごとに ALB を作ると、そのたびに時間の料金とパブリック IPv4 の料金が増えます。

具体的な単価は、公式の「Elastic Load Balancing の料金」ページで確認してください。

よくある落とし穴

ALB を置いたのに「つながらない」とき、原因の多くは次のどれかです。

502 は「後ろの台からおかしな返事が来た（または返事がなかった）」、504 は「後ろの台が時間内に答えなかった」という意味の番号です。どちらも、ALB 自体ではなく後ろの台との間に問題があるという合図です。

ALB の画面の「ターゲット」タブには、各台が不健康な理由（タイムアウト、返事の番号の違いなど）が表示されるので、まずそこを見ます。

片付け：入口から順に消す

ALB まわりは、部品どうしが参照し合っているので、消す順番があります。

aws elbv2 delete-load-balancer --load-balancer-arn <ALB の ARN>
aws elbv2 delete-target-group --target-group-arn <グループの ARN>

ALB の削除には、削除保護という設定もあります。本番の ALB には付けておくと、うっかり消すのを防げます。付いている場合は、先に外してから削除します。

片付けたら、翌日に Billing の画面で、Elastic Load Balancing の料金が増えていないことを確かめます。