ROBO Backup：リモートオフィスや支店の保護

ROBOバックアップの真の問題点

1つの支店を保護するのは簡単なことです。500の支店を保護することこそが、真の問題なのです。 ROBOバックアップに関するアドバイスの多くは、前者の問題には対処するものの、後者の問題を無視しています。1つの支店で機能するアーキテクチャは50店舗になると機能しなくなり、50店舗で機能するアーキテクチャは500店舗になると一から再構築する必要があります。

私は、数百店舗を展開するチェーン店において、各小売店舗にバックアップアプライアンスを導入する顧客の様子を見てきました。 導入から2年が経過した時点で、現場には400台のバックアップアプライアンスが設置されていますが、ファームウェアのバージョンは統一されておらず、各拠点にはIT担当者がおらず、トラブルシューティングができるたった1人の担当者のための四半期ごとの出張予算しか確保されていません。バックアップは技術的には実行されています。しかし、ほとんどの拠点ではバックアップのテストが一度も行われていません。実際の復旧が機能するかどうか、誰も確信を持っていません。 

この記事では、支店側にほとんど何も配置しないことでスケーラビリティを実現するアプローチについて解説します。支店は、支店としての本来の業務を継続します。バックアップは中央で実行されます。

ROBO拠点が本社よりも難しい理由

本社にはデータセンター、大容量の回線、そしてITチームがあります。 ROBO拠点にはこれらはいずれもありませんが、事業継続性の要件は同じです。4つの具体的な課題が常に浮上します。

第一に、WANの帯域幅です。一般的な支店の回線でのフルバックアップは、バックアップウィンドウをオーバーし、業務時間中に回線を飽和させてしまう可能性があります。 日常業務には十分な帯域幅でも、夜間のフルバックアップには不十分なことがほとんどです。

2つ目は、現地のITスタッフがいなことです。小売店にはバックアップ管理者がいません。支店で実行されるシステムは、自律的に稼働し、自律的に復旧し、誰かが現地へ出向く必要が一切あってはなりません。

3つ目は、規模の問題です。 1つの支店なら簡単です。しかし、同一のポリシーと同一のレポート体制を持つ500の支店を管理することが、真の課題となります。

そして、4つ目はSLAです。顧客や規制当局は、小売店舗の回線が10Mbpsであるかどうかなど気にしません。 POSデータが失われたり、システムがダウンしたりすれば、事業は停止してしまいます。ROBOバックアップは、本社レベルのインフラを必要とせずに、本社レベルの復旧を実現しなければなりません。

支店におけるダウンタイムの実際のコスト

ダウンタイムのコストは様々ですが、最低ラインでも高額です。 Statistaの調査によると、組織の24％が、重要サーバーのダウンタイムによる1時間あたりのコストを30万1,000ドルから40万ドルと報告しており、14％は1時間あたり500万ドルを超えると報告しています。 分散型のPOS（販売時点情報管理）システムや取引システムを導入している小売業や金融サービス業界では、支店が1時間オフラインになるごとに、その影響は倍増します。

支店での障害は通常、互いに独立しているため、コストはさらに膨れ上がります。 単一の支店での障害だけでは、企業の緊急対策本部が動員されることはありません。誰かが気づくまで、収益は静かに失われ続けます。中央のIT部門が関与する頃には、復旧作業はすでに数時間経過していることがよくあります。

コンプライアンス規制により、最低ラインはさらに引き上げられています。GDPRでは、適時の削除を含む顧客データの慎重な管理が求められています。HIPAAでは、医療データに関する過去のコンプライアンス証明が求められています。 支店で生成されたデータは、適切にバックアップされているかどうかにかかわらず、両方の規制の対象となります。

現代のROBO環境におけるデータ保護に実際に必要なもの

5つの要件があり、そのいずれかを満たさないアーキテクチャは、1年以内に問題を引き起こすことになります。

WAN効率の高い運用。 バックアップによって、営業時間中に支店の接続帯域が飽和状態になってはなりません。WAN経由でのフルバックアップは許容されません。

ローカルインフラをゼロに。支店に専用のバックアップサーバー、アプライアンス、または独自仕様のストレージを設置しません。現場の構成要素が少ないほど、システムの信頼性は高まります。

一元管理。 すべての支店を単一の管理画面で一元管理します。ポリシーは一度適用すれば、どこでも強制されます。レポートは本社に集約されます。

両端での復旧。支店のスタッフは、本社のIT部門に連絡することなく削除されたファイルを復旧できます。本社のIT部門は、必要に応じて本社から支店全体を復旧できます。

きめ細やかでテナントを意識した設計。 VM、アプリケーション、またはファイルレベルでの復旧が可能です。管理者レベルおよびテナントレベルのアクセス権限により、各支店は他の支店のデータを見ることなく、自身のデータを管理できます。

「レプリカからのバックアップ」の実際の仕組み

現代のROBOバックアップを実用的にするアーキテクチャの転換は、一見すると単純に見えます。 各支店でバックアップを実行する代わりに、通常のDR（災害復旧）運用の一環として支店のデータをデータセンターにレプリケートし、その後、データセンターでレプリカから実際のバックアップを実行します。

何が変化するか：バックアッププロセスにより、支店側のコンピューティングリソース、ストレージ、帯域幅が一切消費されません。支店は、レプリケーションのために変更されたデータを一度送信するだけです。 バックアップは、本社にすでに存在するデータに対して行われます。

その流れは単純明快です。支店は、ネイティブのレプリケーション機能を使用して、継続的に、またはポリシーに基づいてデータセンターへデータをレプリケートします。データセンターの HYCU は、支店からではなく、レプリケートされたコピーからバックアップを行います。 オプションのセカンダリバックアップコピーは、3-2-1準拠のため、データセンター内のNutanix以外のストレージに書き込まれます。 復旧はどちらの拠点でも実行可能です。

特にNutanixベースのROBOの場合、本社で1時間以内にプロビジョニングされ、すぐに稼働可能な状態で支社へ発送される1ノードまたは2ノードのクラスターと組み合わせて使用されます。Prismの管理プレーンもHYCUのポリシーも共通です。 ROBO専用の製品は存在しません。また、ESXiベースのROBOサイトもサポートしており、復旧時にはAHVとESXiの間でワークロードを移動させたり、AWSやGCP上のNutanix Clustersへ移行したりすることが可能です。

レプリケーションだけでは災害復旧にならない理由

チームはこれらを常に混同しています。 「すべての支店からデータセンターへレプリケーションを行っているため、万全です。」これは重大な誤りです。

レプリケーションは現在の状態のコピーに過ぎません。ソースがランサムウェア、アプリケーションのバグ、あるいは管理者の誤ったコマンドによって破損した場合、その破損もレプリケーションされてしまいます。 その結果、データセンターには破損したデータの完全なコピーが残り、元のデータは失われてしまいます。復旧の拠り所がなくなってしまいます。

真のROBOデータ保護には、「3-2-1のルール」に従う必要があります。つまり、データのコピーを少なくとも3つ用意し、2種類の異なるメディアに保存し、そのうち少なくとも1つはオフサイトに保管することです。 レプリケーションはそのコピーの一つに過ぎず、戦略そのものではありません。バックアップは、レプリケーションでは提供されない、特定の時点の復元可能なコピーを追加します。レプリケーションは迅速なフェイルオーバーを可能にします。 バックアップは、クリーンな復旧を可能にします。

ROBO環境では、本社よりもこの点が重要です。なぜなら、支店には多くの場合、単一のレプリケーション先しかなく、他の保護層がないからです。ある支店がランサムウェア攻撃を受けると、本社の誰かが気付く前にレプリカが破損してしまう可能性があります。保存期間を設定したレプリカからのバックアップにより、この問題は解決されます。 稼働中のレプリカが侵害された後でも、支店をクリーンな特定の時点の状態に復元することが可能です。

ROBOの復旧が実際にどのようなものか

3つのシナリオで、ROBO運用に必要なことのほとんどを網羅できます。 単一のファイルまたはフォルダ：従業員が誤って文書を削除してしまった場合。支店のスタッフが、最新のバックアップからファイル単位の復旧をセルフサービスで行います。単一のVMまたはアプリケーション：POS（販売時点情報管理）用VMが故障したり、アプリケーションが破損したりした場合。ワンクリック復旧により、支店のVMを復元するか、支店のハードウェアが交換される間、一時的に本社でVMを復旧させます。 火災、洪水、ランサムウェア、またはハードウェア障害による支店全体の障害。支店全体を、代替サイト、あるいは一時的な運用としてAWSまたはGCP上のNutanix Clustersに復旧させます。

これら3つのシナリオすべてにおいて、復旧は管理者またはテナントによって制御されます。支店のスタッフは、自身の担当範囲内のデータを復旧します。 他の支店の状況については把握できません。これは、複数の事業者がインフラを共有する小売業やフランチャイズ環境において重要な点です。

ROBOのデータ保護に関するよくある質問

すべての支店にバックアップインフラは必要ですか？

いいえ、それこそがポイントです。 「レプリカからのバックアップ」では、支店がデータセンターへレプリケーションを行い、実際のバックアップ処理は一元的に実行されます。支店にバックアップサーバーも、アプライアンスも、専用ストレージも不要です。支店は変更されたデータをレプリケーションのために一度送信するだけで、残りの処理は本社が行います。

ROBOの災害復旧にはレプリケーションだけで十分ですか？ 

いいえ。レプリケーションは現在の状態をコピーするものであり、フェイルオーバーには有用ですが、ソースが破損している場合は無意味です。なぜなら、破損した状態もそのままレプリケートされてしまうからです。ROBO環境では、迅速なフェイルオーバーのためのレプリケーションと、特定の時点でのクリーンな復旧を可能にする保持期間付きのバックアップの両方が必要です。「3-2-1のルール」は、本社と同様に支店にも適用されます。 

サイト全体の損失にはどのように対処するのでしょうか？

火災、洪水、または長期にわたるハードウェア障害などにより、支店が現地で復旧不能となった場合、ワークロードはAWSまたはGCP上のNutanix Clustersに復元されます。ポリシーも復旧モデルも同様です。 支店がオンラインに戻るまで、クラウドホスト型インフラストラクチャから運用を継続します。ワークロードは、設定を変更することなく、後で元の場所に戻されます。

接続状態が悪い支店についてはどうでしょうか？

WAN帯域を消費する処理はレプリケーションのみです。 5Mbpsの回線で運用されているお客様もいらっしゃいます。レプリケーションは利用可能な帯域幅に合わせて構成され、それ以外の処理はすべてデータセンターが担当します。支店の回線が本当に使用不能な場合、このアーキテクチャでは対応できませんが、テープを郵送する以外の選択肢でも同様です。 

10拠点以上を運用されている場合は、ぜひご相談ください

当社が置き換えているROBOアーキテクチャの多くは、各拠点にバックアップアプライアンスを設置し、20～500拠点で運用されています。 これらを「レプリカからのバックアップ」に置き換える場合、通常、ハードウェアの更新を回避できるだけで、初年度中に投資を回収できます。運用面の改善効果は通常、コスト削減効果よりも大きいですが、事前に定量化するのは困難です。ご自身の環境に当てはまると思われる場合は、担当のアカウントチームにご相談ください。