Google Cloud で SAP システムの障害復旧を行うための 3 つのパス

※この投稿は米国時間 2020 年 7 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

障害復旧（DR）は、ビジネス継続戦略において後手に回りがちです。複雑なシステムを持ち、何テラバイトもの機密データを扱う企業でさえも、時代遅れでテストもされていない DR 計画を使用していたり、あるいはまったく DR 計画を立てていなかったりします。効果的な DR 計画では、重要なビジネス機能を支える技術システムに焦点が当てられます。この計画には、どのような種類の障害が発生した後でも、重要な技術インフラストラクチャとシステムを復旧し、継続するための一連のポリシーと手順が含まれます。基本的に、効果的な DR 計画では、技術システムはプライマリ サイトから DR サイトに移行します。

DR 計画を作成する際に企業が直面する最大の課題の一つは、自社で管理しているオンプレミス ハードウェアとクラウド ソリューションのいずれを使用するかという課題です。複雑なモノリシック アプリケーションを使用する企業や組織にとっては、障害復旧のために既存のオンプレミス ソリューションを拡張するのは比較的容易であることは魅力的です。クラウド DR ソリューションを使用する場合は、どうしてもリファクタリングとモダナイゼーションが必要になります。ただし、オンプレミス ハードウェアには非常に高いリスクが付随します。手間のかかるメンテナンス、インフラストラクチャの硬直化、サービス停止の可能性、ネットワークの制限、高いレイテンシ、データの保管と取得の問題です。この 2 つの戦略のどちらを使用するか決めかねている SAP のお客様は、いくつかの重要な要素を検討する必要があります。

自社の障害復旧戦略にとって重要なものは何か

すべての障害復旧に使用できる、万能なアプローチはありません。戦略は、構造、機能、目的に応じて、アプリケーションごとに異なります。最も成功が見込めるのは、技術ネットワーク全体と企業の最終目標が考慮された DR 計画です。

自社のビジネスにとって最適な戦略、アーキテクチャ、ツールセットを見つけるには、まず、目標復旧時間（RTO）を定義します。これは、ビジネスをオフラインにしておくことができる時間です。また、目標復旧時点（RPO）も定義します。これは、許容できるデータ損失量の限界値で、この値を超えると、財務上の損失によるコンプライアンスの問題となります。RTO と RPO の目標値が小さいほど、アプリケーションの費用は高くなります。

すべての組織は、その状況や目標にかかわらず、システムがオフラインの間に発生するビジネス上の費用と、データの損失と再作成に対する費用を判断し、考慮する必要もあります。

3 種類のアプリケーションと DR の 3 つのパス

使用されるアプリケーションとデータベースに応じて、データと該当するアプリケーション構成をプライマリ サイトから DR サイトにレプリケーションするには複数の方法があります。

パス 1: RTO は数日以内 / RPO は機能によって異なる

このシナリオは、ミッション クリティカルではないビジネス アプリケーションと非本番環境用です。目標復旧時間は数時間から数日、目標復旧時点は 1 日未満です。障害が発生すると、Google Cloud で実行されている SAP システムは、永続ディスクのスナップショット、Cloud Storage バケットに保存されているバックアップのどちらか一方、またはその両方から復旧されます。データベース サーバーとアプリケーション サーバーの新しい VM を Compute Engine マシンイメージ（ベータ版）から作成することもできます。さらに、SAP HANA Backint agent for Google Cloud（ベータ版）がデータベースのバックアップに使用されている場合は、Cloud Storage バケットから直接 SAP HANA データベースを復旧できます。SAP システムのデータベース サーバーとアプリケーション サーバーのバックアップ頻度によって、RPO が決まります。このパスの主な利点の一つは、障害の発生後に新しい VM が作成されるため、障害が発生する時点まで、通常運用時にシステムをスタンバイ モード（ホットまたはコールド）にしておいても費用が発生しないことです。また、Actifio、Commvault、Dell EMC などのサードパーティ製のマネージド バックアップ ソリューションを使用することもできます。

パス 2: RTO は 1 日未満 / RPO は数分以内

このパスは、妥当な復旧計画があり、一時的にビジネスをそのアプリケーションなしで運営できる場合に有効です。障害が発生した場合、SAP アプリケーション サーバーは永続ディスクのスナップショットまたは Google マシンイメージから復旧されます（これは、前のパスと同じです）。データベース サーバーの復旧は、SAP システムの基盤となるデータベースの種類（SAP HANA またはその他のデータベース）に応じてアプローチが異なります。SAP HANA データベースには、ほぼリアルタイムのレプリケーションを行うための非同期レプリケーション機能が備わっています。その他のデータベースでは、バックアップからのレプリケーションつまり復旧の機能や、レプリケーションされた最新ログの再生機能に基づいて、復旧アプローチが異なります。最後にログがレプリケーションされた時点までは、任意の時点にデータベースを復旧できるため、ユーザーエラーからシステムを保護できます。

Google Cloud では、永続ディスクのスナップショットと Compute Engine マシンイメージに、データの地理的な冗長性を確保するためのマルチリージョン ストレージ ロケーションを設定できます。Cloud Storage バケットには、単一リージョンのパフォーマンスと地理的な冗長性を兼ね備えた、デュアルリージョン ストレージ ロケーションのオプションも用意されています。このアプローチで考慮すべき重要な点は、短い RTO と少ない RPO のメリットです。これには、（データまたはログのレプリケーションのために）データベース サーバーを DR サイトで運用するための費用が伴います。さらに、目標 RTO 内にアプリケーション サーバーを起動するために、DR リージョンにおいて容量がひっ迫する可能性があるというリスクもあります。このリスクは、障害発生時に本番環境システムの復旧のために容量を再利用できる DR リージョンで、容量（追加費用を払って）を予約するか、品質保証システムやテストシステムといった非本番環境システムを運用することで緩和できます。

パス 3: RTO は数分以内 / RPO は可能な限りゼロに近い

この最後の戦略は、ビジネス クリティカルなアプリケーションに最適です。このパスでは、障害復旧サイトでリソースが完全に保存されていることが保証されます。DR リージョンの SAP システムは常にオンで、ソースシステムと同じサイズになるように構成されているため、アプリケーションを迅速に復旧できます。RTO / RPO の値を最小に抑えると、DR リージョンでサーバーを常時稼働する費用が伴いますが、継続利用割引といったオプションが用意された Google Cloud の革新的な料金体系を利用すれば、費用効率の良い DR 戦略を策定できます。

DR のどのパスを選んだとしても、Google Cloud のプレミアム ネットワーキングが、業界最高のネットワーク パフォーマンス、ソフトウェア定義ネットワーキング、グローバル バーチャル プライベート ネットワーク、最高水準のセキュリティを提供いたします。シンプルでありながら、堅牢で信頼性の高い DR アーキテクチャを構築しましょう。

DR 戦略を計画する際のその他の考慮事項

DR 設計の方向性を決める RPO と RTO を定義したら、より大きな事業継続計画の一環として、キャパシティ プランニングと自動化について検討します。まず、開発システムのコピーを立ち上げられるだけの十分な容量があることを確認します。十分な容量があれば、開発方法と、緊急の SAP の変更を本番環境システムに転送する方法を制御できます。

通常、DR 計画の開始は手動のタスクですが、エラーのない復旧を迅速に行うために、復旧と起動は自動化する必要があります。Google Cloud では、インフラストラクチャはコードと見なされています。Google では、プロビジョニング、構成、デプロイといった繰り返しのタスクは自動化すべきだと考えています。すべての Google Cloud のお客様は、Infrastructure as Code（IaC）機能を利用できます。この機能では、ランドスケープを繰り返しビルド、開始、停止できます（システムを稼働状態に戻すには、これら 3 つのステップが必要です）。

SAP インストール環境用に、Google Cloud では特定の Deployment Manager / terraform スクリプトも提供しています。これは、インフラストラクチャの作成時間を短縮するだけでなく、HSR と Pacemaker を使用する SAP HANA クラスタ設定などの一般的な SAP システム構成を自動化します（すべての構成のリストはこちらをご覧ください）。これらのスクリプトは、前述した最初の復旧パスにおけるシステムの起動などの、特定のデプロイ ユースケースに合わせて拡張またはカスタマイズできます。Google Cloud には、Cloud Scheduler などの追加の自動化ツールも用意されています。これは、Cloud Functions と Cloud Pub/Sub と組み合わせて、バックアップの自動化や DR 戦略のテストに使用できます。

DR 計画の策定を先送りにしない

ほとんどの企業は、想定外の事態に備えた計画には早急に取り掛からなければならないということを、経験を通して学びます。まず取り掛かるのは DR 計画の策定ですが、これだけでは不十分です。計画全体は、計画、設計、テスト、反復または更新を含む、フェイルオーバーからフェイルバックまでの復旧プロセスすべてを網羅したものである必要があります。自社のビジネスの目標を念頭に置いて、適切なサービスを適切な費用で提供できるようなソリューションを作成します。計画を実行に移したら、事業継続性と DR 戦略にとって定期的なテストと更新が不可欠であることを忘れないでください。最後に、可能な限りいつでも、どこでも自動化を行います。Cloud Scheduler、Cloud Functions、Deployment Manager などの機能がなければ、自動化は骨の折れる作業です。これらの機能を Google Cloud では手軽に利用できるので、最小限の労力で、いつでもエラーなしで実行できるように DR 計画を準備できます。

Google Cloud 上の SAP システムとアプリケーション用に最適な障害復旧戦略を作成する方法について詳しくは、ホワイトペーパー Google Cloud 上の SAP: 障害復旧戦略をダウンロードするか、SAP のお客様向けの Google Cloud 障害復旧戦略とソリューションに関する動画をご覧ください。

 -Google Cloud SAP 戦略およびアーキテクチャ担当パートナー技術リーダー Ramesh Suraparaju