オートスケーリング

🐾 猫で例えると？

ソファーに並ぶ2匹は、もふもふの受付係のよう。もし「猫吸いしたい！」という要求が増えると自動でもう1匹が参加し、落ち着くと1匹が休憩へ戻る仕組みなら、オートスケーリングのイメージになります。2匹が並ぶことよりも、あらかじめ決めた条件で担当の数が自動的に増減するところがポイントです。

💻 IT現場における「オートスケーリング」とは？

オートスケーリングは、特にAWSやGCPといったクラウド環境で非常に重要となる機能です。Webサービスを運営していると、テレビで紹介されたり、SNSでバズったり、あるいは特定の日時にキャンペーンを行ったりすることで、突発的にアクセスが集中することがあります。このような時に手動でサーバーを追加していては到底間に合わず、システムダウンに繋がってしまいます。

そこで、CPU使用率やメモリ使用率、ネットワークのトラフィックなどを常に監視（モニタリング）し、「CPU使用率が70%を超えたら自動でサーバーを1台増やす（スケールアウト）」といったルールを設定しておきます。逆に、夜間などアクセスが減った際には「CPU使用率が30%を下回ったら自動でサーバーを減らす（スケールイン）」ように設定することで、不要なサーバー費用を抑え、コストパフォーマンスを最大化することができます。

⚠️ オートスケーリングの仕組みと注意点

増設には起動や準備の時間がかかり、その長さは構成によって異なります。急激な増加には追いつかないこともあるため、予測できるイベントには、指定日時に容量を変えるスケジュールスケーリングなどを組み合わせます。手動増設と予約による自動増設は区別します。

AWS Auto Scalingの設定イメージ

次はAWSの考え方を単純化した設定メモです。グループの台数設定と、CPUを対象にしたターゲット追跡ポリシーは別の設定であり、このままAPIへ送信するJSONではありません。

Auto Scalingグループ
  最小台数：1
  最大台数：5
ターゲット追跡ポリシー
  指標：平均CPU使用率
  目標：70%（説明用。適切な値は負荷試験で確認）

上限は増設できる範囲を決めますが、安定稼働や費用総額の保証ではありません。最大台数でも追いつかない場合や、DBがボトルネックの場合があります。台数上限への到達と、利用者が感じる遅延を両方監視します。

🛠️ オートスケーリングを賢く使うためのポイント

現場でオートスケーリングを導入する際は、ただ設定するだけでなく、システムの特性に合わせたチューニングが求められます。適切に設定しないと、意図しないタイミングで増減を繰り返してしまったり、コストが跳ね上がったりする危険性があります。

• 上限（MaxSize）を必ず設定する： 攻撃やプログラムの不具合で負荷が上がり続けた際、サーバーが無限に増えて莫大なクラウド請求（クラウド破産）が来るのを防ぐ。
• ウォームアップと縮小を調整する：方式ごとに、準備中の容量をどう扱うか、縮小をいつ許すかが異なります。すべての方式で一律に数分停止する設定ではなく、採用したポリシーの動作を確認します。
• ステートレスな設計にする： サーバーがいつ消えても大丈夫なように、ユーザーのセッション情報などを個別のサーバー内に保存せず、外部のデータベースやキャッシュサーバーに逃がす（ステートレス化）必要がある。

いつもの2匹体制を「負荷に応じて仲間が増減する仕組み」に置き換えると、オートスケーリングの違いが分かります。設定後は、増えたサーバーが処理を始めるまでの時間と、減らすときの影響を確認しましょう。最大台数でも間に合わない場合は、DBなど別の詰まりも調べます。