待機系を常時起動・同期しておき、主系故障時に即座に切り替える方式。
ホットスタンバイとは、待機系(=予備のサーバ)を常に起動しておき、データもリアルタイムに同期しておく二重化の方式です。主系(=普段サービスを提供するサーバ)が故障したら、その瞬間に待機系へ切り替えてサービスを続けます。
身近な例で考えると、運転中の電車に乗っている車掌の交代に似ています。次の車掌があらかじめ乗務してすぐ運転を代われる状態で待っていれば、急に何かあってもほぼ止まらずに走り続けられます。エンジンを切って車庫で待っている予備とは、すぐ動けるかどうかが大きく違います。
上のツールで▶ボタンを押すと、主系が処理しながら待機系へリアルタイム同期し、主系の故障とほぼ同時に待機系へ切り替わってサービスが続く流れを確認できます。
ホットスタンバイが速く切り替えられるのは、待機系が「いつでも代われる準備」を済ませているからです。切替に時間がかかる作業を、故障が起きる前に終わらせておくのがポイントです。
具体的には、次の準備があらかじめできています。
・起動済み:待機系のOSやアプリケーションは動いた状態で、電源投入や起動の待ち時間が不要
・データが最新:リアルタイム同期により主系とほぼ同じ最新データを持つので、データ復元が不要
・故障検知:主系の死活を監視しており、止まったらすぐ気づいて引き継ぎを始める
これらが揃っているため、故障を検知した瞬間に待機系が主系に昇格して処理を引き継げます。上のツールのSTEP4で、起動や復元の待ち時間なしに切り替わる様子を確認できます。
ホットスタンバイの切替時間は数秒〜ほぼ瞬時で、3つの待機方式の中でもっとも短くなります。一方で、待機系を常にフル稼働させ続けるため、コストはもっとも高くなります。
| 方式 | 待機系の状態 | 切替時間 | コスト |
|---|---|---|---|
| ホット | 常時起動+常時同期 | 最短(数秒〜瞬時) | 高い |
| ウォーム | 起動済み+定期同期 | 中間 | 中間 |
| コールド | 停止 | 最長 | 安い |
つまりホットスタンバイは、コストをかけてでも止められないシステムに向いています。たとえば銀行のオンラインシステムや、24時間動き続ける必要のあるサービスなどです。「お金をかけて、いつでも代われる予備を控えさせておく」── これが切替時間の短さの代償だと考えると分かりやすいです。
ホット・ウォーム・コールドの3方式が存在するのは、「速さ」と「コスト」のどちらを優先するかがシステムによって異なるからです。全システムをホットスタンバイにすれば理想ですが、費用が2倍近くかかります。
3方式の違いは、「待機系がどこまで準備を済ませているか」で決まります。
・ホット:起動済み + データを常時同期 → すぐ代われる、でも常にリソースを消費
・ウォーム:起動済み + データは定期的に同期 → 切替に数分かかるが常時同期コストは不要
・コールド:電源オフ → 起動から始めるので時間がかかる、でも電気代・ライセンス料が節約できる
たとえるなら、タクシーを常に待機させる(ホット)か、呼んだら5分で来る(ウォーム)か、自分で車を借りに行く(コールド)かの違いです。「止まったときの影響がどれだけ大きいか」に応じて方式を選ぶのが設計の基本です。
ホットスタンバイで「即座に切替できる」のは、待機系が主系と同じ最新のデータを持っているからです。もし同期していなければ、切替したとたんに「さっきの注文が消えた」「残高が戻った」といった問題が起きてしまいます。
なぜ「リアルタイム」でなければならないのか。それは、主系でデータが更新されるたびに待機系へ即座にコピーすることで、いつ故障しても「ほぼ差がない状態」を保てるからです。定期的にしか同期しないウォームスタンバイでは、最後の同期から故障するまでの間に更新されたデータが失われる可能性があります。
身近な例で考えると、作業中のファイルを毎回保存する(リアルタイム同期)か、1時間おきに自動保存(定期同期)するかの違いに似ています。電源が落ちたとき、毎回保存していれば直前の状態から再開できますが、自動保存が1時間前だと1時間分の作業が消えてしまいます。