コールドスタンバイ

🐾 猫で例えると？

目を開けたままぼんやりする茶トラを、「必要になってから活動を始める予備の担当」に見立てます。ただし、コールドスタンバイはおやつの音に瞬時に反応する状態ではありません。起こす、準備する、仕事を引き継ぐという時間を見込む必要があります。

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

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

稼働中の予備系へ切り替える構成に比べ、停止している予備系は起動や復元の時間が必要です。一方、待機中の費用を抑えられる場合があります。切替時間や費用が必ず一定、あるいはホット構成なら費用が正確に2倍になるわけではなく、データ同期やライセンス、機器構成で変わります。

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

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

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

クラウドで設定やバックアップから障害時に作り直す方式は、バックアップ＆リストア型などとして設計されます。AWSのウォームスタンバイは、縮小したシステムを稼働させておく方式です。「設定ファイルだけがある状態」をウォームスタンバイと呼ぶと、復旧手順を取り違えるので注意しましょう。

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

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

復旧に許せる時間をRTO、失ってよいデータの範囲を時間で表した目標をRPOといいます。起動だけでなく、データ復元、接続先の変更、動作確認を含めて実測し、目標内に収まるかを確認します。

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

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

• 復旧訓練を行う： 更新頻度や業務への影響に応じて、隔離した環境で手順とバックアップを検証します。毎回本番を意図的に停止することや、一律に半年ごとという間隔が必須なわけではありません。
• データ同期の設計： 予備機のシステムが立ち上がっていない間も、メイン機に書き込まれたデータ（ログやユーザーデータなど）は、外部のストレージ（S3など）に安全にバックアップし続けておく必要があります。
• クラウドへの移行検討： 現代では、物理サーバーのコールドスタンバイを維持するよりも、クラウド環境のオートスケーリング機能を利用して、障害時に自動で新しいインスタンスを立ち上げる方が、コストも安く復旧も早いケースが増えています。

予備機が用意されていても、必要なときに起動・復元できるとは限りません。メイン機の停止を検知し、予備機を準備して処理を引き継ぐまでを試し、許容する復旧時間に収まるかを確認します。