The Doppler Quarterly (日本語) 夏 2018 | Page 64

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