コールドスタンバイ

🐾 猫で例えると？

普段は名前を呼ぶとすぐに可愛くお返事をしてくれる茶トラですが、深く眠っているわけではないものの、魂が抜けた抜け殻のようにぼーっとしている時は、写真のように目は開いていても反応が全くありません。しかし、決して壊れた（システムダウンした）わけではなく、大好きな「おやつ」の袋の音が鳴れば即座に覚醒（起動）して駆けつけてきます。この「一見起きているようでシステム（意識）は立ち上がっておらず、特定のトリガーで稼働できる」状態が、コールドスタンバイのイメージにぴったりです。

💻 IT現場における「コールドスタンバイ」とは？

企業がシステムを運用する際、サーバーが1台しかないと、そのサーバーが壊れた瞬間にサービスが完全に停止してしまいます。これを防ぐために、同じ構成の予備サーバーを用意しておくことを「冗長化（じょうちょうか）」と呼びます。その予備サーバーをどのような状態で待機させておくかで、呼び方が変わります。

予備機を常にメイン機と同じ状態（電源オンでデータも常時同期）にしておく「ホットスタンバイ」は、障害時に一瞬で切り替わるためダウンタイムがほぼありません。しかし、サーバーを2台同時にフル稼働させるため、コスト（電気代やライセンス料）が2倍かかります。一方、普段は予備機の電源を落としたり、OSを落としたりしておく「コールドスタンバイ」は、切り替えに時間がかかり数十分〜数時間のサービス停止（ダウンタイム）が発生しますが、待機中のコストを最小限に抑えることができます。予算と「どこまでの停止時間を許容できるか」のバランスで選択されます。

⚠️ コールドスタンバイの仕組みと注意点

コールドスタンバイにおける最大の注意点は、「いざという時に本当に動くのか」という点です。長期間立ち上げていなかった予備サーバーを、障害発生のパニックの中でいざ起動した結果、OSやアプリのアップデートが適用されておらずエラーで立ち上がらなかった、という笑えないトラブルは現場でよく起こります。

クラウド環境におけるスタンバイ構成のイメージ

AWSなどのクラウド環境では、物理的な予備サーバーをずっと眠らせておかなくても、設定ファイル（IaC）だけを用意しておき、障害時にコマンド一発で新しいサーバーを立ち上げる「ウォームスタンバイ（コールドに近い）」構成がよく取られます。

# 障害発生時の復旧手順のイメージ
# 1. メインシステムに障害が発生したことを検知する
# 2. 保管しておいたバックアップデータと設定ファイルを用意する
# 3. 予備システム（コールドスタンバイ）の電源を入れ、OSやアプリを立ち上げる
# 4. 最新のデータをリストア（復元）する
# 5. アクセス先（DNSなど）を予備システムに切り替える

# ※抜け殻状態から完全に意識を立ち上げるまでに時間がかかるため、ダウンタイムの許容が必要です。

このように、切り替えには「OS・アプリの起動」「データの復元」という段階を踏むため、ホットスタンバイに比べるとどうしても数分〜数十分のタイムラグが発生します。

🛠️ コールドスタンバイを賢く使うためのポイント

現場でコールドスタンバイを運用する際の重要なポイントです。

• 定期的な起動テスト（避難訓練）： 最低でも半年に1回は、意図的にメインシステムを止めてコールドスタンバイ側を起動し、マニュアル通りに切り替えられるかをテストする「DR（ディザスタリカバリ）訓練」が必須です。
• データ同期の設計： 予備機のシステムが立ち上がっていない間も、メイン機に書き込まれたデータ（ログやユーザーデータなど）は、外部のストレージ（S3など）に安全にバックアップし続けておく必要があります。
• クラウドへの移行検討： 現代では、物理サーバーのコールドスタンバイを維持するよりも、クラウド環境のオートスケーリング機能を利用して、障害時に自動で新しいインスタンスを立ち上げる方が、コストも安く復旧も早いケースが増えています。

アメショの姿が見えないと寂しそうに鳴き続ける依存関係の強い茶トラですが、システムの世界でも、メイン機がダウンした時には予備機（茶トラ）が確実に抜け殻状態から目を覚まして処理を引き継げるよう、日頃からの準備とテストを怠らないようにしたいですね。