可用性の期待、要件、またはコミットメントがあるエンタープライズ システムでは、明確に定義され、実行可能で、十分にテストされたバックアップおよび障害復旧 (Disaster Recovery、DR) の方法が不可欠です。 バックアップ戦略または障害復旧の方法を設計するには、まず組織のシステムの範囲と依存関係を理解する必要があります。それから、復旧の目標を慎重に設定し、使用可能な IT リソースを理解して、バックアップや復元のトリガーから、スタッフの支援やユーザーへの影響の対応の可否など、復旧プロセス全体を検討する必要があります。
バックアップの重要性や役割は、主にそのシステムがビジネスでどれだけ重要か、どのようなワークフローをサポートするのか、および保存されるデータのカテゴリに関連します。 開発サーバーや、小規模なチームで使用されるシステムなど、一部のシステムでは、バックアップ戦略の必要はありません。一方で、他のシステムでは、主にプロセスをテストし、それを運用システムへ適用するうえでの有効性を確認するために、バックアップや DR の方法を使用します。
このトピックでは、バックアップと障害復旧のプロセスの概要について、ArcGIS ソフトウェア コンポーネントへの影響や、さまざまな ArcGIS アプリケーションのバックアップまたは障害復旧の方法をサポートするため利用可能なオプションについても解説します。
システム、データの一部、またはハードウェア コンポーネントをバックアップするプロセスは、IT システムにとって常に重要でした。 従来、バックアップは一般的にストレージ レベルで実装されていましたが、クラウド サービスの普及により、クラウド上にホストされたデータや SaaS システムのバックアップの必要性をはじめとして、バックアップをデータ レベルで保存するための新たな保存先やプロバイダーなど、バックアップに関するいくつかの新しい選択肢が登場しました。
バックアップの検討では、次のような点を慎重に定義します。
さらに、バックアップからシステムを復元するために使用される方法や、それがユーザーに与える影響も重要です。
従来は、最も重要なビジネス システムやデータのみが確実にバックアップされていたため、バックアップの範囲は最も重要なシステム、サーバー、またはデータベースが中心でした。 ストレージのコストが以前に比べて大幅に低下した現在、バックアップの範囲は劇的に拡大しており、1 つのアプリケーション コンポーネントやデータ タイプを選択的にバックアップするのではなく、システム全体を対象としたバックアップに移行する傾向にあります。
バックアップの作成に使用される方法は、バイナリー データベース ダンプや仮想マシン イメージなど、アプリケーション固有のバックアップ形式から、アプリケーションの状態と、データやアプリケーションのコード自体を組み合わせる、構成のバックアップや、複合バックアップまで、多岐にわたります。 バックアップの作成方法は、バックアップの作成に必要な時間、バックアップの実行頻度、およびバックアップの復元方法に大きな影響を及ぼします。 また、バックアップの作成方法や、実行中のシステムの状態をどれだけ適切に記録できるかも、バックアップの方式によって異なります。 ArcGIS システムで考慮すべきバックアップは、主に 3 つのタイプに分けられます。
システムのバックアップの頻度と、バックアップの開始時刻は、どちらも重要な考慮事項です。 バックアップをあまり頻繁に行うと、過剰なコストを要したり、システムの中断が増加したりする可能性があります。一方でバックアップの頻度が低すぎると、システムが停止したとき、最後のバックアップ以後に許容できないデータ損失が発生する可能性があります。 ほとんどのバックアップは、ある程度ユーザーの操作を妨げないように設計されていますが、バックアップのタイミングは、バックアップに取得されるデータとワークフローに影響を与える可能性があります。 バックアップは一般に、システムの「時間外」 (存在するなら) に行われ、それによって前日のデータと情報のほとんどを取得できます。労働日の作業時間内にバックアップを行うと、業務時間中は作業が進行中であるため、長いプロセスや大きなデータセットの一部しか取得できないことがあります。
バックアップ プロセスが存在する理由は、たとえばシステムの状態を復元するためなど、明白に思えるかもしれませんが、バックアップはそれ以外にも各種の微妙なユース ケースで使用されます。 一部のバックアップはシステムのアップグレードに関連付けられているため、アップグレードに問題が発見された場合は、システムを既知の状態に戻すことができます。 同じ考慮事項から、サーバーの撤去や新しいコンポーネントの追加など、システムの破壊的な変更に関連するバックアップ プロセスも実施されます。 一部のバックアップは、最悪のシナリオのみを想定して作成されており、障害が発生したとき、その障害から復旧するために使用できます。 他のバックアップは、環境の状態のスナップショットを作成し、新しい下位環境の複製を作成したり、下位環境から本番環境へコンテンツを昇格させたりするために利用される場合もあります。
障害復旧 (DR) は、多くの場合にバックアップおよび復元のプロセスと密接に関連しているトピックですが、同義語ではありません。 具体的に DR とは、「障害の後で復旧のために何をするか」、復旧に必要なプロセス、および組織固有のコンテキストで「障害」と「復旧」の両方が何を意味するかの定義を指します。 障害とは通常、ハードウェア、環境、またはユーザー構成の問題によって引き起こされる IT システムの重大な停止のことで、システムの稼働時間、可用性、または機能が大幅に低下します。
DR プロセスを確立するための最初のステップの 1 つは、障害復旧プロセスを必要とする「障害」とは何かを定義することです。 この定義を慎重に行うことは重要です。あまりにも敏感な定義 (たとえば、プライマリー システムでの 1 回のリクエスト失敗など) にすると、DR フェイル オーバー アクションが頻発する可能性があります。一方で、障害が 4 時間以上続くまで待つような緩すぎる定義にすると、ユーザーへの大規模な影響を招くおそれがあります。 結局のところ、システムが復旧やフェイルオーバーを開始するためのアクションを実行できるように「何を障害とするのか」を定義するには、自動と人手の両方による意思決定が関与し、可用性、重要性、稼働時間などの概念を組織で定義する必要があります。 DR を「開始する条件」の一般的な例には、データセンターにアクセスできなくなる、ストレージの障害、VM ハイパーバイザーの障害、DNS の停止やネットワーク接続の問題、さらにはデータ破損やシステムへのランサムウェア攻撃などがあります。
DR プロセスのもう 1 つの重要な定義は、組織の RPO (Recovery Point Objective、目標復旧時点) と RTO (Recovery Time Objective、目標復旧時間) です。 RPO は、_障害シナリオで失われるデータの量_に相当し、作成されるバックアップの種類と、データまたは構成がバックアップされる頻度を指します。 RPO が 4 時間の場合、DR レベルの停止が発生したときに最大で 4 時間分のデータや作業が失われ、組織は DR プロセスでその 4 時間分のデータや入力を失う可能性を許容することを意味します。 RPO を小さくすることは当然のように思えるかもしれませんが、ほとんどのシステムではバックアップが複雑で、ユーザーの作業が中断される可能性があるため、RPO を低く設定しすぎると、リソース、ストレージ、またはユーザーへの影響が許容範囲を超える可能性があります。
RTO は、_システムが復旧するまでの時間_を意味し、バックアップを DR システムに復元したり、新しいシステムを最初から作成したり、障害から回復するためのリソースを自動的にデプロイしたりするのに必要な時間を指します。 フェイルオーバー システムまたはそのコンポーネントの一部がすでに存在しており、DNS やネットワークを変更するだけで、そのシステムに切り替えられることもあるため、RTO が RPO よりも短いことは珍しくありません。 現実的な RPO と RTO を定義して達成することは、DR 戦略を構築するための重要な部分で、この戦略の実装によるコストやワークフローへの影響について、利害関係者の同意を得ることが重要です。
障害シナリオに対応する一般的な方法の 1 つは、プライマリー システムが問題を検出または特定した場合に、トラフィックを引き受けるためのフェイルオーバー システムにトラフィックを切り替えることです。 この方法には、コストとワークフローに影響を与えるいくつかの重要な要件があります。
DR の別の方法は、バックアップを使用してシステムを再構築することです。この方法では RTO が長くなる可能性がありますが、フェイルオーバー システムを常に維持する必要がなくなるため、継続的なコストが削減されます。 この方法では、VM のバックアップまたはアプリケーションレベルのバックアップを作成してから、Infrastructure-as-Code およびソフトウェア デプロイメントの自動化によって自動的にシステムを再構築するか、経験を積んだチームが手動でシステムを再構築します。バックアップを復元し、トラフィックがシステムに戻してから、ユーザーはシステム内のワークロードを再開できます。
DR プロセスには、ArcGIS で構築されたエンタープライズ システムに固有のものではない、より広範な影響や方法も考えられます。 たとえば、データセンター全体で、VM レプリケーションを使用して一連の VM を別のデータセンターに維持する DR 戦略があり、ストレージまたはハイパーバイザー コンポーネントの停止が識別されると、すべてのユーザーがセカンダリー データ センターへのアクセスに切り替える場合もあります。
DR プロセスでは、復旧後に何が起こるかも考慮する必要があります。 プライマリー システムまたはデータ センターがあり、DR イベントによってセカンダリー システムへのフェイルオーバーが発生した場合、停止が解決された後にトラフィックをプライマリー システムに戻すのを標準的な方法にするべきか。 それとも、スタンバイ システムが新たにプライマリー システムとなり、元のシステムは次の DR 状況に備えてスタンバイとして設定されるのでしょうか。 どちらのシナリオにも長所があり、インシデントが解決された後に何が起こるかを定義することは、DR の戦略と方法を完成させる上で重要な部分です。
ArcGIS システムでは、バックアップ プロセスを開始するためのいくつかの方法が、ArcGIS ソフトウェアに組み込まれています。 単一コンポーネント バックアップは、1 つのアプリケーションのコンテンツと状態のみをバックアップする方法で、Portal for ArcGIS、ArcGIS Server、ArcGIS Data Store などの ArcGIS Enterprise コンポーネントで使用できます。 これらのコンポーネント固有のバックアップは、DR を主目的とするものではなく、バックアップと復元をその場で行うことを意図したものです。DR の目的には、WebGISDR ツールをおすすめします。 各コンポーネントには、次のような異なるバックアップ方法があります。
いくつかの ArcGIS Server ロールは一般にステートレスで、関連するすべての構成がポータル アイテムとして格納され、通常はバックアップする必要はありません。 これには、Notebook Server、Business Analyst Enterprise Server (GeoEnrichment Server)、および Raster Analytics Server が含まれます。 これらの各コンポーネントは、コンテンツが ArcGIS Enterprise に格納されるため、通常は特定のデプロイメントを復元する代わりに、空白のコンピューターや、インストールされたイメージから再作成できます。 これ以外の考慮が必要なのは、Python ベースのワークフローまたは他のプロセスを有効にするため、カスタム コードまたはサード パーティのライブラリがシステムにデプロイされているシナリオのみです。
ArcGIS Enterprise には、コンポーネント固有のバックアップ機能に加えて、Web GIS Disaster Recovery ツール (略して WebGISDR) と呼ばれるマルチコンポーネント バックアップ ツールもあり、複数の異なる ArcGIS Enterprise コンポーネントの状態を同時にバックアップできます。
WebGISDR ツールの詳細については、ArcGIS Enterprise のドキュメントで詳しく説明されていますが、このツールは、バックアップの速度やプロセスの柔軟性よりも、アプリケーションの集合的な一貫性と状態を優先することに注意してください。 つまり、このツールは実際には、リクエストが実行された時点のシステムの状態を正確に取得しようと試みます。 バックアップの実行中にさらにコンテンツやデータが公開された場合、それらはどのバックアップ ファイルにも保存されず、フェイルオーバー システムに復元できません。 この優先順位は、RTO よりも RPO を重視し、システムを迅速に復元することよりもシステムの機能的な完全性を優先するのと同義です (システムの復元速度を優先すると、構成ミスや不良データにつながる可能性があります)。
ArcGIS アプリケーション固有のバックアップ以外にも、組織で推奨または優先されるさまざまな方法があり、それらは特定のコンポーネントやインフラストラクチャー プロバイダーに固有の場合があります。 これらの方法は、ArcGIS のバックアップまたは障害復旧のプロセスに適している場合もありますが、これらの使用によりシステムの動作に支障をきたす可能性があるため、慎重に評価して検討する必要があります。
たとえば、VM スナップショットはシステムをバックアップする一般的な方法ですが、スナップショットの方法にコンピューターの突然の再起動が含まれる場合は複雑な問題が引き起こされることがあります。また、データの状態のみが取得され、処理中の操作や構成が取得されない、あるいは一部しか取得されない可能性があり、その結果、復元または復旧が行われたときに予期しない状態や破損した状態が生じるおそれがあります。
VM ベースのバックアップ戦略では、停止を防ぐため 2 つのデータ ソース間で VM リソースを移動することがあります。 これらのシナリオでは、ArcGIS Server ホストと ArcGIS Pro ホストが、元のデータ センターにリクエストを送信せず、独自のデータ センター内のデータベースにアクセスしていることを確認してください。そうでないとレイテンシーが発生し、ユーザー エクスペリエンスに悪影響を及ぼします。
Microsoft Azure Site Recovery などのクラウドベースのバックアップ ツールや DR ツールは、サイトの復旧操作の際に DNS 解決、データベース コネクション、システムへのクライアント接続がすべて維持されるように慎重に計画されている場合、ArcGIS Enterprise システムと互換性を持たせることができます。 これらのバックアップ方法は、比較的低い仮想マシン レベルのアクセスで動作するため、アプリケーションの整合性は保証されません。 つまり、復旧システムは多くの場合、正常に復元および運用されますが、たとえば公開プロセスが進行中であったり、バックアップ中にフィーチャ サービスが編集される場合などには、アプリケーション レベルの不整合が発生する可能性があります。 このような事態に備える方法として、オフピーク時に VM スナップショットを作成するなどの対策もありますが、一般的には、こうした外部ツールを用いた手法には「計画、テスト、そして影響の慎重な検討」というガイダンスが適用されます。
ArcGIS が連携するリレーショナル データベース (エンタープライズ ジオデータベースまたはクエリ レイヤーのソースとして) を構築するデータベース プロバイダーは、独自のデータベース固有のバックアップ オプションを提供しています。通常は、データベースの内容と構成をファイルベースのバックアップとして作成し、必要に応じて新しいシステムやデプロイメントに復元できます。
ArcGIS Online は、SaaS 製品およびシステムとして、バックアップと復旧の観点から異なる取り組みが必要です。 システムの安定性の一環として、Esri はハードウェアおよびシステムレベルの停止に対するバックアップおよびリカバリの要件をユーザーの入力なしで処理します。ArcGIS Online のサービス レベル アグリーメントにはこのコミットメントが反映されています。 ArcGIS Online は現在、ユーザーが組織全体のバックアップまたは内容のバックアップを作成する方法を提供していないため、組織は次のようなさまざまなパターンを使用して、ArcGIS Online の内容や構成について独自の追加バックアップを行う戦略を定義する必要があります。
Esri パートナーは、ArcGIS Marketplace でレビューまたは購入できるバックアップ ソリューションも作成していることに留意してください。
ArcGIS Online では最近、削除したコンテンツを 14 日間 (デフォルトで) 保存してから完全に削除する「ごみ箱」機能が導入されました。 ごみ箱のコンテンツは、簡単なワークフローで以前のステータスと場所に復元できます。 これにより、他のコンテンツと相互に関連しているが、他のコンテンツに依存している、または他のコンテンツから依存されていると明確に特定されていないコンテンツの削除を防ぐことができます。
基本的なホスト フィーチャ サービス データの場合、変更の追跡の機能を使用して、編集が行われたときに以前の行の内容を保存します。 変更の抽出の操作により、このような以前のバージョンにアクセスできます。