目標復旧時間と目標復旧時点について説明する
高可用性とディザスター リカバリー (HADR) 計画には、可用性ソリューションの要である目標復旧時間と目標復旧時点を理解することがきわめて重要です。
目標復旧時間
目標復旧時間 (RTO) は、障害や問題が発生してからリソースをオンラインに戻す際に利用できる時間の上限です。 そのプロセスの所要時間が RTO を超えた場合、罰金が科せられる、作業を終えることができない、といった結果につながるおそれがあります。 RTO は、すべてのリソースを含むソリューション全体を対象に指定できるほか、SQL Server インスタンスやデータベースなど、個別のコンポーネントを対象に指定することもできます。
目標復旧時点
目標復旧時点 (RPO) は、どの時点までデータベースを復旧すべきかであり、企業が進んで受け入れることのできるデータ損失の最大量に相当します。 たとえば、SQL Server が置かれている IaaS VM で午前 10:00 に障害が発生し、SQL Server インスタンス内のデータベースには、15 分の RPO が設けられているとします。 インスタンスとそのデータベースを復旧させるために使用されている機能やテクノロジに関係なく、想定されるデータの損失は最大でも 15 分相当です。 つまり、データベースは午前 9:45 以降の時点まで復旧することができます。データの損失は最小限またはゼロで済み、前述の RPO が満たされることになります。 そこには、RPO が達成可能かどうかを決定する要因があると考えられます。
目標復旧時間と目標復旧時点を設定する
RTO と RPO は、ビジネス要件だけでなく、さまざまな技術的要因や、その他の要素、たとえば管理者 (DBA 以外も含む) のスキルや能力によっても左右されます。 企業はダウンタイムもデータの損失もゼロにしたいと考えるでしょうが、それはさまざまな理由から現実的でないか不可能です。 ソリューションの RTO と RPO は、関係するすべての当事者間の、開かれた率直な話し合いに基づいて決定されなければなりません。
RTO と RPO のどちらにとっても、きわめて重要なポイントの 1 つはダウンタイムのコストです。 その値が明らかとなり、ダウンまたは利用不可となることで企業が被る全体的な影響がわかれば、ソリューションが定義しやすくなります。 たとえば、1 時間あたり 10,000 ドルの損失が生じたり、何かが正しく処理されなかったことで行政機関から罰金が科せられたりする場合、それを基準にすれば RTO と RPO を決めやすくなります。 ダウンタイムの量、つまりコストが大きくなれば、それに比例してソリューションにかかる費用も大きくなると考えられます。 HADR ソリューションにコストがかかるとしても、問題が発生したときの影響が数時間や数日ではなく、結果的に数秒で済むのであれば元が取れます。
ビジネス以外の観点から言えば、RTO はアプリケーション アーキテクチャ全体について設定するだけでなく、コンポーネント (SQL Server など) レベルでも設定する必要があります。 障害から復旧する能力は、結局のところ、その最も弱い部分によって決まります。 たとえば、SQL Server とそのデータベースは 5 分後にオンラインに復旧できるものの、アプリケーション サーバーの復旧には 20 分かかるとした場合、全体的な RTO は 5 分ではなく 20 分となります。 SQL Server 環境の RTO が 5 分だとしても、それによって全体の復旧時間が変わることはありません。
RPO がとりわけ解決しようとするのはデータであり、HADR ソリューションの設計と管理のポリシー、管理の手順に RPO は直接関係します。 使用される機能は、設定された RTO と RPO の両方をサポートしている必要があります。 たとえば、トランザクション ログ バックアップが 30 分ごとにスケジュールされている場合、RPO を 15 分に設定しても、データベースは、利用可能な最後のトランザクション ログ バックアップの時点までしか復旧できません。最悪のケースでも 30 分前ということになります。 このタイミングは、他に問題がないこと、またバックアップが事前にテストされて良好であるとわかっていることが前提です。 環境内のデータベースごとに生成されたバックアップをすべてテストするのは困難ですが、バックアップは、ファイル システム上のファイルに過ぎません。 少なくとも定期的に復元を実行しないと、それらが良好である保証は得られません。 バックアップの過程でチェックを実行すれば、信頼度を多少高めることはできます。
RTO と RPO は、Always On 可用性グループ (AG)、Always On フェールオーバー クラスター インスタンス (FCI) など、実際に使用されている機能によっても左右されます。 それらの機能の構成によっては、IaaS または PaaS ソリューションが自動的に別の場所にフェールオーバーされる場合もあり、そうなるとダウンタイムはもっと長くなります。 RTO と RPO を設定することにより、許容される時間とデータの損失を把握しながら、要件に対応した技術的なソリューションを設計することができます。 非現実的であると判明した場合は、RTO と RPO を適宜調整する必要があります。 たとえば、必要な RTO が 2 時間であるにもかかわらず、バックアップ処理で、復元に使用される宛先サーバーへのコピーに 3 時間かかるようでは、既に RTO の達成に失敗しています。 RTO と RPO を決定する際は、こうした要因を考慮に入れる必要があります。
RTO と RPO は、HA と DR の両方について設定する必要があります。 HA は、より局所的で、比較的簡単に復旧できる事象と考えられます。 Azure リージョン内のレプリカ間で AG が自動的にフェールオーバーされるのは、高可用性の一例です。 所要時間は数秒程度であり、フェールオーバー後、その時点でアプリケーションから接続できる状態を確保する必要があります。 SQL Server のダウンタイムは最小限と考えられます。 ソリューションまたはシステムのクリティカルな特性によっては、ローカルの RTO または RPO の基準が分単位になる場合もあります。
DR は、まったく新しいデータセンターを導入することに似ています。 この作業には多数の要素が関係し、SQL Server は 1 つのコンポーネントに過ぎません。 すべてをオンラインに戻すには、数時間またはそれ以上かかることもあります。 RTO と RPO が別々に存在しているのも、それが理由です。 HA と DR に使用される多くのテクノロジと機能が同じであったとしても、時間と労力の度合いが同じであるとは限りません。
すべての RTO と RPO は正式に文書化し、定期的に、または必要に応じて見直す必要があります。 文書化したら、アーキテクチャに使用できるテクノロジや機能を検討することができます。