- スタンバイ機がプライマリと同じ処理を常時並行実行しており障害発生時に数秒以内・ほぼダウンタイムゼロで切り替えられる高可用性の冗長構成のこと
- コールドスタンバイ（電源OFF待機）・ウォームスタンバイ（起動済み待機）より切り替えが速い最上位の冗長構成でFTサーバーに近いダウンタイムゼロを実現するが常時2系統を稼働させるため最もコストが高い
- 証券取引システム・オンラインバンキング・ECサイトの決済サーバーなど「1分の停止も許容できない」ミッションクリティカルなシステムで採用される構成だ
【深掘り】これだけ知ってればOK！
ホットスタンバイのデータ同期方式を理解しよう。同期レプリケーション：プライマリへの書き込みが完了する前にスタンバイへの複製も完了を確認する。データの整合性は完全だが書き込み性能が低下する。非同期レプリケーション：プライマリへの書き込みが完了してからスタンバイに複製する。書き込み性能は高いが障害時に少量のデータ損失（RPO>0）が発生する可能性がある。
クラウドでのホットスタンバイ実装例：Amazon Aurora Multi-AZ（複数のDBインスタンスが同時に読み書き可能）・Kubernetes（Deployment）（同じPodを複数レプリカで常時稼働させてPodの障害を自動的に回復）・AWS Global Accelerator（地理的に分散したエンドポイントに自動フェイルオーバー）。
スタンバイ構成の3種類のコスト・切り替え時間のトレードオフ：コールドスタンバイ（コスト最小・切り替え数分〜十数分）→ウォームスタンバイ（コスト中程度・切り替え数十秒〜数分）→ホットスタンバイ（コスト最大・切り替え数秒以内）。システムの停止許容時間（RTO）と予算に応じた選択が重要だ。
よくある誤解
ホットスタンバイとウォームスタンバイは同じだと思っている
ウォームスタンバイはスタンバイ機が起動済みで待機しているが実際の処理は実行していない。ホットスタンバイはスタンバイ機がプライマリと同じ処理を常時並行実行している。この違いが切り替え時間（ウォームは数分・ホットは数秒以内）の大きな差になる。
ホットスタンバイは最も可用性が高いからどんなシステムにも採用すべきだと思っている
ホットスタンバイは常時2系統を稼働させるため最もコストが高い。全てのシステムに採用すると不必要なコストがかかる。システムの停止許容時間（RTO）と重要性に応じてコールドスタンバイ・ウォームスタンバイ・ホットスタンバイを使い分けることが重要だ。
会話での使われ方
決済システムにホットスタンバイを設定しました。プライマリが落ちても5秒以内にスタンバイに切り替わりユーザーへの影響を最小化できます。
インフラエンジニアが決済システムのホットスタンバイ構成を説明している場面。
データの同期をアクティブ-アクティブにするかホットスタンバイにするか迷っています。トラフィックが片方に集中する場合はアクティブ-アクティブの方がリソース効率が良いですね。
アーキテクトが高可用性構成の選択肢を検討している場面。
ホットスタンバイのRTO目標は5秒以内です。DR訓練で実際に測定したら3.2秒で切り替わっていたので目標達成です。
SREエンジニアがホットスタンバイのRTO達成を確認している場面。
【まとめ】3つのポイント
- プライマリと同じ処理を常時並行実行して障害時に数秒以内に切り替わる最高可用性構成：コールドスタンバイ（数分〜十数分）・ウォームスタンバイ（数分）と比べて切り替えが最速のホットスタンバイは停止が絶対に許されないミッションクリティカルなシステムに適している
- 同期レプリケーションで整合性重視・非同期レプリケーションで性能重視の使い分けが重要：ホットスタンバイのデータ同期方式はRPO（目標復旧ポイント）の要件とシステムの書き込み性能のトレードオフで設計する
- コスト最大のホットスタンバイはRTOが厳格なシステムだけに絞って採用する：常時2系統を稼働させるホットスタンバイは最もコストが高いためシステムの停止許容時間（RTO）と重要性に応じてコールドスタンバイ・ウォームスタンバイと使い分けることがインフラコストの最適化につながる
よくある質問
-
Qホットスタンバイとコールドスタンバイ・ウォームスタンバイの切り替え時間の違いは？
-
A
コールドスタンバイは数分〜十数分・ウォームスタンバイは数十秒〜数分・ホットスタンバイは数秒以内が目安です。ただし環境によって異なります。
-
Qクラウドでホットスタンバイを実装するには何を使えばいいですか？
-
A
Amazon Aurora Multi-AZ・Kubernetes Deploymentのreplicas設定・AWS Global Acceleratorなどが代表的なクラウドネイティブなホットスタンバイ実装方法です。
-
QRTO・RPOとは何ですか？
-
A
RTO（Recovery Time Objective）は障害発生から復旧するまでの目標時間です。RPO（Recovery Point Objective）は障害発生時に許容できる最大のデータ損失量（時間）です。
-
QホットスタンバイとFTサーバーはどちらを選べばいいですか？
-
A
ミリ秒単位のダウンタイムゼロが必要な最重要システムはFTサーバーが向きます。数秒以内の切り替えが許容できるシステムはホットスタンバイで十分です。FTサーバーの方がコストは大幅に高いです。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| サーバー | サーバーを押さえると本記事の理解がさらに深まります。ネットワークを通じて情報やサービスを提供する側のコンピューターのこと。レストランで料理を運んでくれる給仕係（server）をイメージするとわかりやすいよ |
| コールドスタンバイ | コールドスタンバイを押さえると本記事の理解がさらに深まります。平常時はスタンバイ機の電源を切った状態（コールド＝冷たい状態）で待機させておき、プライマリが障害を起こしたときに起動してサービスを引き継ぐ高可用性構成のこと |
| FTサーバ | FTサーバは関連分野でよく登場する重要キーワードです。Fault Tolerant（耐障害性）の略で、CPUやメモリ・I/Oなどの主要コンポーネントを全て二重化して1箇所が故障してもサービスを無停止で継続できる高可用性サーバーのこと |
| 可用性 | 可用性は関連分野でよく登場する重要キーワードです。必要なときにシステムを使える状態を維持し続ける能力のこと。英語でAvailabilityといい、情報セキュリティの三大要素（CIA）の一つに数えられる |
| データ | 本記事のテーマと実務上セットで使われることが多い用語です。コンピュータが処理する数値や文字、画像といった事実や資料そのもの、それがデータだ |
【出典】参考URL
https://aws.amazon.com/jp/rds/aurora/ ：Amazon Auroraの高可用性の説明
https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ ：KubernetesのDeploymentドキュメント
https://e-words.jp/w/%E3%83%9B%E3%83%83%E3%83%88%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%90%E3%82%A4.html ：IT用語辞典「ホットスタンバイ」
コメント