The Doppler Quarterly (日本語) 夏 2018 | Page 64
以下のオプションがあります。
• コールド復元、動作している代替フェイルオーバーリソースがない設定です。これには、
アプリケーションとデータ環境の完全な再構築が必要です ( 可能であれば自動化で実
行 )。フェイルオーバーリソースが動作中ではないため、この設計は最も費用が低くなり
ますが、障害後の実行には最も時間がかかります。
• パイロットライトシステム、最小限の重複したシステムが準備されています。障害まで必
要最小限のサービスのみが立ち上がり、動作します。このアプローチは、コールド復元よ
りもコストがかかりますが、より迅速に復元します。
• ウォームスタンバイシステム、完全に動作している環境を引き継ぐ準備ができています。
ただし、リソースの規模が縮小され、必要な場合にのみ本番環境の最大容量に拡張さ
れます。前の 2 つのオプションよりも費用がかかりますが、最小限のサービスレベルを
迅速にリストアできます。
• ホットスタンバイシステム、いつでも、プライマリシステムを引き継ぐ準備が整っており、
リソースが完全に重複した環境です。これは最も費用がかかるシステムで、設計が複雑
なシステムですが、可能な限り最短の RTO を達成できます。
高可用性
実際にはこれはバックアップ用語ではありませんが、コンセプトはディザスタリカバリと大きく
重複するところがあります。突きつめれば、高可用性とは非常に小さい RTO ( 通常、分 / 秒
単位で測定 ) およびゼロに近い RPO ( つまり運用データがいつでも、障害中でも最新状態
である ) をサポートするビジネスソリューションを設計し、維持することです。ホットスタンバ
イ設計と高可用性実装の境界線ははっきりしていません。ともに RTO と RPO をゼロに近づ
ける必要があるからです。一般に、高可用性ソリューションには、稼働中での冗長なデータ同
期、さらには長期バックアップおよびアーカイブ向けの異なる実装があります。結果として、こ
れらの実装は非常に費用がかかる可能性があります。
62 | THE DOPPLER | 2018 年夏号