オートスケーリングの仕組み ― サーバーが自動で増減する技術

たとえばセールの日にECサイトへアクセスが殺到したとするよね。普段の10倍のサーバーを常に用意しておくと、平日はほとんど遊んでいてお金がもったいない。かといって少なすぎるとサイトが落ちる。オートスケーリングは、アクセス量に合わせてサーバーを自動で増やしたり減らしたりしてくれる仕組みなんだよ。

そうそう。コスト効率と信頼性を両立できるのが最大のメリットだね。ちなみにスケーリングには大きく2種類あって、スケールアップ（垂直スケーリング）とスケールアウト（水平スケーリング）があるんだ。

スケールアップは1台のサーバーをもっと高性能なものに交換すること。CPUやメモリを増やすイメージだね。スケールアウトは同じスペックのサーバーを台数ごと増やすこと。オートスケーリングで主に使われるのはスケールアウトの方で、台数を増減させるから柔軟性が高いんだよ。

基本的な流れは3ステップ。まずメトリクスを監視する。CPU使用率やリクエスト数、キューの滞留数なんかだね。次にあらかじめ設定したルールと照らし合わせて『閾値を超えたか？』を判定する。超えていたら新しいインスタンスを起動して、ロードバランサーに追加する。逆に負荷が下がったらインスタンスを減らすんだよ。

うん。リクエスト数やレスポンスタイム、メッセージキューの深さ、さらにはアプリ固有のカスタムメトリクスも使えるよ。たとえば動画配信サービスなら同時視聴者数をメトリクスにすることもあるんだ。何を基準にスケールさせるかはサービスの特性次第だね。

AWSではAuto Scaling Groups（ASG）が中心だよ。起動テンプレートでインスタンスの設定を決めて、最小・最大・希望台数を指定する。スケーリングポリシーには3種類あって、ターゲット追跡（CPU使用率を50%に保つ等）、ステップスケーリング（閾値ごとに追加台数を変える）、スケジュールスケーリング（毎朝9時に台数を増やす等）が使えるんだよ。

KubernetesにはHPA（Horizontal Pod Autoscaler）があるよ。metrics-serverがPodのCPUやメモリ使用率を収集して、設定した目標値に近づくようにPod数を自動調整するんだ。さらにPrometheusと連携すれば、リクエスト数やカスタムメトリクスでもスケールできる。コンテナだから起動が速くて、スケールアウトの反応が早いのが強みだね。

いい質問だね。それはフラッピング（スラッシング）と呼ばれる問題で、実際に起きやすいんだ。たとえばCPU使用率が閾値を行ったり来たりすると、増やす→減らす→また増やす…と無駄な動きをしてしまう。それを防ぐために『クールダウン期間』や『安定化ウィンドウ』を設定して、スケール後しばらくは次の判定を待つようにするんだよ。

あるよ。最近は予測スケーリングといって、過去のトラフィックパターンを機械学習で分析して、ピークが来る前にあらかじめスケールアウトしておく手法が使われているんだ。AWSのPredictive Scalingが代表例だね。さらにサーバーレスの世界ではKnativeやKEDAを使ってスケール・トゥ・ゼロ、つまりリクエストがないときはインスタンスをゼロにして、来たら起動するということもできるんだよ。

鋭いね。現場でよくある落とし穴は、アプリ層だけスケールアウトしてもデータベースがボトルネックになるケース。サーバーが10台に増えたのにDBの接続数上限に引っかかって結局エラーになる、なんてことがある。コネクションプーリングやリードレプリカの準備も合わせて考える必要があるんだ。それから大量のインスタンスが同時に起動してDBに一斉接続するコネクションストームも厄介な問題だね。オートスケーリングは魔法じゃなくて、システム全体を見て設計する必要があるよ。