勝手にAWS教室 3時間目：Auto Scaling・ELB
情報が古い場合があります。間違っている箇所がありましたらご教授いただけると幸いです。
Webサービスを運営していると避けて通れないのが 「急にアクセスが増えてサイトが落ちた」 という問題です。
テレビで紹介された飲食店に翌日行列ができるように、Webサイトもバズったりセールが始まったりすると一気にアクセスが集中します。
「サーバー増やせばいいんでしょ？」と思った方、その通りです。でも手動でやるのは大変ですし、夜中にアクセスが急増したら誰が対応するのでしょう。
そこで登場するのがAuto ScalingとELB（Elastic Load Balancing） です。
この2つはセットで使われることが多いので、まとめて覚えてしまいましょう。
先にまとめ
- Auto Scaling：忙しさに応じてサーバーを自動で増やしたり減らしたりする仕組み
- ELB：複数のサーバーにお客さんを均等に案内する受付係
- 組み合わせ：ELB＋Auto Scalingで「落ちないサイト」を作れる
1. Auto Scaling ＝ 飲食店のシフト自動調整
そもそもなぜ必要？
EC2の回で学んだとおり、サーバーは「クラウド上のコンピューター」です。
1台のサーバーで処理できるリクエスト数には限界があります。お店に例えると、店員1人で対応できるお客さんの数には限りがありますよね。
じゃあ最初から100台用意しておけばいいのでは？と思うかもしれませんが、サーバーは動いている間お金がかかります。
お客さんが1人しかいないのに店員を100人待機させておくのはもったいないですよね。
そこでAuto Scalingです。「忙しくなったら自動で増員、暇になったら自動で帰宅させる」 という夢のようなシフト管理をしてくれます。
仕組み
Auto Scalingは、サーバーの負荷（どれくらい頑張っているか）を監視して、EC2インスタンスを自動で増やしたり減らしたりする機能です。
飲食店でいうと、昼のピーク時間にアルバイトを追加で呼び出して、お客さんが減ってきたら「あがっていいよ」と帰宅させる店長のようなものです。しかもこの店長、24時間365日働いてくれます。
3つの設定値
Auto Scalingには「最低何人は置いておく」「普段は何人」「最大何人まで増やしていい」という3つの数字を設定します。
| 設定 | 意味 | 飲食店で例えると |
|---|---|---|
| 最小数（Min） | 常に維持する最低台数 | 「最低1人はシフトに入れておいて」 |
| 希望数（Desired） | 通常時の台数 | 「普段は2人でまわしてね」 |
| 最大数（Max） | 増やせる上限 | 「忙しくても10人までだよ（人件費的に）」 |
最大数を設定しておかないと、サーバーが無限に増えてしまい請求額がとんでもないことになる可能性があります。上限の設定は大事です（切実）。
いつ増やす？いつ減らす？
「忙しくなったら増やす」と言いましたが、具体的にどうやって「忙しい」と判断するのでしょう。主に3つの方法があります。
- CloudWatchアラーム — AWSの監視サービスと連携して「CPUの使用率が70%を超えたらサーバー追加！」のように設定できます。体温計が37.5度を超えたらアラートを出すようなイメージです。
- スケジュール — 「毎朝9時に3台に増やして、夜22時に1台に減らす」のように時間指定で設定。営業時間に合わせてシフトを組むのと同じです。
- 予測スケーリング — 過去のアクセスパターンをAIが学習して「明日のこの時間は混みそうだな」と先回りして増やしてくれます。
2. ELB ＝ 銀行の受付係
そもそもなぜ必要？
Auto Scalingでサーバーを増やせるようになりました。めでたしめでたし...ではありません。
サーバーが3台あっても、お客さん全員が1台目のサーバーにだけ殺到したら意味がないですよね。銀行の窓口が3つ開いているのに、全員が1番窓口に並んでいたらおかしいですよね。
ここで必要になるのが ELB（Elastic Load Balancer） です。
複数のサーバーにリクエスト（お客さん）を均等に振り分けてくれるサービスで、いわば銀行の「次の方どうぞ」と案内してくれる受付係です。
受付係がいなかったら、お客さんは空いている窓口がどこかわからず、偏りが生まれます。ELBがいることで、どのサーバーにも均等にリクエストが届くようになります。
ELBの種類
ELBには3つの種類があります。「え、また3つ覚えるの？」と思うかもしれませんが、最初はALBだけ覚えておけば大丈夫です。
| 種類 | 一言で言うと | 使いどころ |
|---|---|---|
| ALB（Application Load Balancer） | 一番よく使う万能型 | 普通のWebサイトやAPI。URLのパス（/apiと/imagesなど）で振り分け先を変えられる |
| NLB（Network Load Balancer） | とにかく速い特化型 | ゲームサーバーなど超高速な通信が必要なとき |
| GLB（Gateway Load Balancer） | セキュリティ向け | 通信をセキュリティ機器に通してからサーバーに届けたいとき |
ALBは「この人は/apiにアクセスしてきたからAチームのサーバーに案内して、この人は/imagesだからBチームね」のように、URLの中身を見て振り分け先を変えられます。賢い受付係ですね。
ヘルスチェック ＝ 窓口の稼働確認
ELBはただ振り分けるだけではありません。定期的にサーバーが正常に動いているか確認（ヘルスチェック） しています。
もしサーバーが異常だと判断したら、そのサーバーにはリクエストを送らなくなります。
銀行の受付係が「2番窓口、担当者が体調不良でダウンしてます」と気づいたら、お客さんを2番には案内しませんよね。それと同じです。
これのおかげで、サーバーが1台壊れてもユーザーは気づかずにサービスを使い続けられます。地味ですがとても重要な機能です。
3. Auto Scaling ＋ ELB ＝ 最強コンビ
この2つが組み合わさるとどうなるか。こうなります。
嬉しいポイントは、全部自動で連携するということです。
- アクセスが増える → Auto Scalingがサーバーを追加 → ELBが自動的に新しいサーバーにもリクエストを振り分け開始
- アクセスが減る → Auto Scalingがサーバーを削除 → ELBが自動的にそのサーバーへの振り分けを停止
手動で「サーバー増やしたからELBの設定も変えて...」なんてことをしなくていいんです。
深夜にアクセスが急増しても、寝ている間に勝手に対応してくれます。エンジニアの睡眠を守ってくれるありがたいコンビですね。
まとめ
| 概念 | 比喩 | 一言ポイント |
|---|---|---|
| Auto Scaling | シフト自動調整 | 負荷に応じてEC2を自動増減 |
| ELB | 銀行の受付係 | 複数サーバーへリクエストを均等振り分け |
| ALB | 賢い受付係 | URLのパスやヘッダーで振り分け先を変える |
| NLB | 超高速受付 | ゲームなど超高速通信向け |
| ヘルスチェック | 窓口の稼働確認 | 異常なサーバーへの振り分けを自動停止 |
| 最小数 / 希望数 / 最大数 | シフトの最低人数 / 通常人数 / 上限人数 | Auto Scalingの基本設定 |
最後に
Auto ScalingとELBは、EC2を本番環境で使う上でほぼ必ずセットで登場するサービスです。
「サーバーを自動で増減する仕組み」と「リクエストを均等に振り分ける仕組み」、この2つが揃って初めて「落ちにくいサービス」が作れます。
とりあえずAuto ScalingとELBについて聞かれたら「飲食店のシフト管理と銀行の受付係のことですね！」と言ってみてください。これで伝わる人がいればそれはきっと元教員をしていたエンジニアです。
現在までに投稿してきた「勝手にAWS教室」はこちらにまとめてあります。
興味がある方はご覧ください。