このドキュメントは、Google Cloud の障害復旧（DR）について説明するシリーズのパート 2 です。このパートでは、DR 計画の構成要素として使用できるサービスと製品（Google Cloud プロダクトと、プラットフォームを横断して動作する製品の両方）について説明します。
シリーズは次のパートで構成されています。
- 障害復旧計画ガイド
- 障害復旧の構成要素（この記事）
- データの障害復旧シナリオ
- アプリケーションの障害復旧シナリオ
- 地域制限があるワークロードの障害復旧の設計
- 障害復旧のユースケース: 地域制限のあるデータ分析アプリケーション
- クラウド インフラストラクチャの停止に対する障害復旧の設計
はじめに
Google Cloud には障害復旧（DR）アーキテクチャの一部として使用できる幅広いプロダクトが用意されています。このセクションでは、Google Cloud DR 構成要素として最も一般的に使用されているプロダクトの DR 関連の機能について説明します。
これらのサービスの多くは、高可用性（HA）機能を備えています。HA は DR と完全に重複するわけではありませんが、HA の目標の多くは DR 計画の設計にも該当します。たとえば HA 機能を活用することで、稼働時間を最適化し、単一の VM の障害といった小規模な障害の影響を軽減できるアーキテクチャを設計できます。DR と HA の関係の詳細については、障害復旧計画ガイドをご覧ください。
以降のセクションで、こうした Google Cloud DR 構成要素の概要と、これらの構成要素が DR 目標の達成にどのように役立つかについて説明します。
コンピューティングとストレージ
Compute Engine |
|
Cloud Storage |
|
GKE |
|
Compute Engine
Compute Engine は仮想マシン（VM）インスタンスを提供する、Google Cloud の主力サービスです。Compute Engine インスタンスの構成、起動、モニタリングに加えて、DR 計画を実装するために、通常はさまざまな機能を使用します。
DR シナリオでは、削除保護フラグを設定すると、VM を誤って削除することを防止できます。これは特に、データベースなどのステートフルなサービスをホストする場合に便利です。低い RTO 値と RPO 値を達成するには、堅牢なシステムを設計するためのベスト プラクティスに従ってください。
アプリケーションがプリインストールされた状態でインスタンスを構成し、その構成をカスタム イメージとして保存できます。カスタム イメージには、達成したい RTO を反映させることが可能です。
インスタンス テンプレート
Compute Engine のインスタンス テンプレートを使用して VM の構成の詳細を保存すると、既存のインスタンス テンプレートからインスタンスを作成できます。テンプレートを使用すると、好みの方法で構成した必要な数のインスタンスを必要なときに起動して、DR ターゲット環境を立ち上げられます。インスタンス テンプレートはグローバルに複製されるため、インスタンスを Google Cloud 内の任意の場所に同じ構成で再作成できます。
インスタンス テンプレートはカスタム イメージを使用するか、既存の VM インスタンスに基づいて作成できます。
Computing Engine イメージの使用方法については、このドキュメント後半のイメージ構成とデプロイ速度のバランスをとるのセクションで詳しく説明します。
マネージド インスタンス グループ
マネージド インスタンス グループは、Cloud Load Balancing（このドキュメントの後半で説明）と連携して、ゾーン間でコピーされた同一構成のインスタンスのグループにトラフィックを分散させます。マネージド インスタンス グループでは、自動スケーリングや自動修復などの機能を使用できます。こうした機能により、インスタンスの削除や再作成を自動的に行うことができます。
予約
Compute Engine では、カスタムまたは事前定義のマシンタイプを使用して、特定のゾーンの VM インスタンスを予約できます。予約する VM インスタンスには、GPU またはローカル SSD を追加することもできます。DR 用のミッション クリティカルなワークロードの容量を確保するには、DR ターゲット ゾーンに予約を作成する必要があります。予約がない場合、復旧時間目標を満たすために必要なオンデマンド容量が得られない可能性があります。予約は、コールド、ウォーム、ホット DR のシナリオで役立ちます。これにより、低 RTO のニーズを満たせるように、フェイルオーバーに利用可能なリカバリ リソースを保持できます。事前にリソースをフル構成してデプロイする必要はありません。
永続ディスクとスナップショット
永続ディスクは長期的なネットワーク ストレージ デバイスであり、インスタンスからアクセスできます。永続ディスクはインスタンスから独立しているため、インスタンスを削除した後でも、永続ディスクを切断または移動してデータを保持することが可能です。
障害の発生時には、Compute Engine VM の増分バックアップまたはスナップショットを作成し、それをリージョン間でコピーして、永続ディスクを再作成できます。さらに永続ディスクのスナップショットを作成すると、ユーザーエラーによりデータが失われることを防止できます。スナップショットは増分なので、スナップショット ディスクが実行中のインスタンスにアタッチされている場合でも、わずか数分で作成できます。
永続ディスクには冗長性が組み込まれているため、機器の故障からデータを保護するとともに、データセンターのメンテナンス中でもデータの可用性を保証します。永続ディスクはリージョン リソースまたはゾーンリソースのいずれかです。リージョン永続ディスクでは同じリージョン内の 2 つのゾーン間で書き込みが複製されます。ゾーンが停止した場合、バックアップ VM インスタンスで、もう一方のゾーンのリージョン永続ディスクを強制接続できます。詳細については、リージョン永続ディスクを使用した高可用性オプションをご覧ください。
ライブ マイグレーション
ライブ マイグレーションでは、ホストシステムでソフトウェア / ハードウェアの更新などのイベントが発生しても、VM インスタンスの実行が継続されます。Compute Engine は VM の再起動を要求することなく、同じゾーンの別のホストに対して、実行中のインスタンスのライブ マイグレーションを行います。Google ではこれにより、インフラストラクチャの保護と信頼性を維持するために不可欠なメンテナンスを、VM の実行を中断せずに実施することが可能になっています。
仮想ディスク インポート ツール
仮想ディスク インポート ツールを使用すると、VMDK、VHD、RAW などのファイル形式をインポートして、新しい Compute Engine 仮想マシンを作成できます。このツールを使用すると、オンプレミスの仮想マシンと同じ構成の Compute Engine 仮想マシンを作成できます。この方法は、イメージにすでにインストールされているソフトウェアのソースバイナリから Compute Engine イメージを構成できない場合に適しています。
Cloud Storage
Cloud Storage は、バックアップ ファイルの保存に理想的なオブジェクト ストアです。次の図のような特定のユースケースに適した、さまざまなストレージ クラスが用意されています。
DR シナリオで重要となるのは、Nearline Storage、Coldline Storage、Archive Storage です。これらのストレージ クラスでは、Standard Storage に比べてストレージ コストを削減できます。ただし、これらのクラスに格納されているデータやメタデータには、最小保存期間の課金に加え、取得に関連する追加コストがかかります。Nearline はアクセスが最大でも月 1 回のバックアップ シナリオ用に設計されているため、費用を抑えながら定期的な DR ストレステストを実施するのに最適です。
Nearline、Coldline、Archive はいずれも低いアクセス頻度に合わせて最適化されており、料金モデルはこの点を念頭に置いて設計されています。そのため課金は最小保存期間に対して行われ、クラスの最小保存期間よりも早い時期には、これらのクラスのデータまたはメタデータの取得に対して追加料金が発生します。
Storage Transfer Service を使用すると、Amazon S3 または HTTP ベースのソースから Cloud Storage にデータをインポートできます。DR シナリオでは、次のようなことに Storage Transfer Service を利用できます。
- データを他のストレージ プロバイダから Cloud Storage バケットにバックアップする。
- デュアルリージョンまたはマルチリージョンのバケットからリージョン内のバケットにデータを移動して、バックアップの保存コストを削減する。
Filestore
Filestore インスタンスは、Compute Engine インスタンスまたは GKE クラスタで実行するアプリケーションで使用するフルマネージド NFS ファイル サーバーです。
Filestore インスタンスは特定のゾーン限定であり、ゾーン間でのレプリケーションに対応していません。Filestore インスタンスは、所属するゾーンが停止すると使用できなくなります。gsutil rsync コマンドを使用して、Filestore ボリュームを別のリージョンの Filestore インスタンスと同期して、データを定期的にバックアップすることをおすすめします。これを行うには、Compute Engine インスタンスまたは GKE クラスタ上で実行されるジョブをスケジュールする必要があります。
DR シナリオでは、復元プロセスが完了するのを待たずに、フェイルオーバー リージョンの Filestore に切り替えることで、アプリケーションの Filestore ボリュームへのアクセスを迅速に再開できます。この DR ソリューションの RTO 値は、スケジュールされたジョブの頻度に大きく依存します。
GKE
GKE は、コンテナ化されたアプリケーションをデプロイするための、マネージド型の本番環境です。GKE では HA システムをオーケストレートすることができ、次のような機能が用意されています。
- ノードの自動修復。ノードが長い期間（10 分前後）連続してヘルスチェックに失敗すると、GKE はそのノードの修復プロセスを開始します。
- livenessProbe。liveness プローブを指定すると、定期的に GKE に Pod が稼働中であることが通知されます。Pod がプローブに失敗した場合、プローブを再起動できます。
- 永続ボリューム。データベースはコンテナの存続期間が過ぎても存続し続けなければなりません。Compute Engine の永続ディスクにマッピングされる永続ボリュームの抽象化を使用することで、個々のコンテナとは無関係にストレージの可用性を維持できます。
- マルチゾーン クラスタとリージョン クラスタ。Kubernetes リソースは、リージョン内の複数のゾーンを横断して分散できます。
- マルチクラスタ Ingress を使用すると、異なるリージョンの複数の GKE クラスタ間で共有されたロード バランシング リソースを構成できます。
- Backup for GKE を使用すると、GKE クラスタのワークロードをバックアップおよび復元できます。
ネットワーキングとデータ転送
 Cloud Load Balancing |
|
Traffic Director |
|
Cloud DNS |
|
Cloud Interconnect |
|
Cloud Load Balancing
Cloud Load Balancing は、一連のインスタンスにユーザー リクエストを分散することで Compute Engine の高可用性を実現します。インスタンスが使用可能かどうかを判断するヘルスチェックを Cloud Load Balancing で構成すれば、障害が発生したインスタンスにトラフィックがルーティングされることを防止できます。
Cloud Load Balancing は、Compute Engine インスタンスの前に、グローバルにアクセス可能な単一の IP アドレスを配置します。アプリケーションでは異なるリージョン（ヨーロッパと米国など）でインスタンスを実行することができ、エンドユーザーは最も近いインスタンスに誘導されます。インターネットに公開されているサービスの負荷分散を実現できるだけでなく、プライベート負荷分散 IP アドレスの背後にあるサービスに対して内部負荷分散を構成することもできます。この IP アドレスには、Virtual Private Cloud（VPC）の内部にある VM インスタンスでのみアクセスできます。
Traffic Director
Traffic Director を使用すると、フルマネージドのサービス メッシュ用トラフィック コントロール プレーンをデプロイできます。Traffic Director は、Compute Engine と GKE で実行されているサービス プロキシの構成を管理します。高可用性を確保するには、サービスを複数のリージョンにデプロイします。Traffic Director はサービスのヘルスチェックをオフロードし、サービス プロキシのフェイルオーバー構成を開始します。これにより、トラフィックが正常なインスタンスにリダイレクトされます。
Traffic Director は高度なトラフィック制御のコンセプト、回路遮断、フォールト インジェクションもサポートしています。回路遮断を使用すると、特定のサービスに対するリクエスト数に制限を適用できます。リクエスト数がこの制限に達すると、リクエストはそのサービスに到達できなくなるため、サービスのさらなるパフォーマンス低下が防止されます。フォールト インジェクションを使用すると、Traffic Director でリクエストの一部を意図的に遅延または中断して、リクエストの遅延や中断に対するサービスの耐性をテストできます。
Cloud DNS
Cloud DNS は自動復旧プロセスの一環として、DNS エントリをプログラムで管理する方法を提供します。Cloud DNS は、Google のエニーキャスト ネームサーバーの世界的ネットワークを使用して、全世界のあらゆる場所からお客様の DNS ゾーンをサポートし、ユーザーに高い可用性と低レイテンシを提供します。
オンプレミスで DNS エントリを管理する場合、Google Cloud 内で VM を有効化し、Cloud DNS の 転送によってこれらのアドレスを解決できます。
Cloud Interconnect
Cloud Interconnect は、情報を他のソースから Google Cloud に移動する方法を提供します。このプロダクトについては、後述する Google Cloud との間でデータを転送するのセクションで説明します。
管理とモニタリング
| クラウド ステータス ダッシュボード |
|
Google Cloud Observability |
|
Cloud Status ダッシュボード
Cloud Status ダッシュボードには、Google Cloud サービスの現在の可用性が表示されます。ステータスはページ上で確認でき、サービスに関するニュースがあるたびに更新される RSS フィードも購読できます。
Cloud Monitoring
Cloud Monitoring は、Google Cloud、AWS、ホストされた稼働時間プローブ、アプリケーション インストゥルメンテーション、その他のさまざまなアプリケーション コンポーネントから、指標、イベント、メタデータを収集します。Slack や Pagerduty などのサードパーティ ツールに通知を送信するようにアラートを構成すると、適切なタイミングで管理者にアップデートを提供できます。DR で Cloud Monitoring を利用する他の方法として、Pub/Sub シンクを構成し、Cloud Functions を使用して、Cloud Monitoring アラートに対して自動プロセスをトリガーすることもできます。
クロスプラットフォームの DR 構成要素
複数のプラットフォームを横断してワークロードを実行する場合、運用上のオーバーヘッドを削減する一つの方法は、使用するすべてのプラットフォームで動作するツールを選ぶことです。このセクションでは、プラットフォームに依存せず、クロスプラットフォームの DR シナリオをサポートできるいくつかのツールとサービスについて説明します。
宣言型テンプレート ツール
宣言型テンプレート ツールを使用すると、プラットフォームをまたいだインフラストラクチャのデプロイを自動化できます。Terraform はよく使われている宣言型テンプレート ツールです。
構成管理ツール
大規模または複雑な DR インフラストラクチャの場合は、Chef や Ansible のようなプラットフォームに依存しないソフトウェア管理ツールをおすすめします。こうしたツールにより、コンピューティング ワークロードがどこにあっても再現可能な構成を適用できるようになります。
オブジェクト ストレージ
一般的な DR のパターンは、異なるクラウド プロバイダのオブジェクト ストアにオブジェクトのコピーを持つというものです。このためのクロスプラットフォーム ツールの 1 つに boto があります。これはオープンソースの Python ライブラリで、Amazon S3 と Cloud Storage の両方のインターフェースとなります。
オーケストレーター ツール
コンテナは DR 構成要素と見なすこともできます。コンテナはサービスをパッケージ化し、プラットフォーム間の整合性をもたらすための方法です。
コンテナを使用する場合、通常はオーケストレーターを利用します。Kubernetes は Google Cloud 内のコンテナを（GKE を使用して）管理するだけでなく、複数のプラットフォーム間でコンテナベースのワークロードをオーケストレートする手段を提供します。Google Cloud、AWS、および Microsoft Azure はすべて、マネージド バージョンの Kubernetes を提供しています。
異なるクラウド プラットフォームで動作している Kubernetes クラスタにトラフィックを分散するには、重み付きレコードをサポートしヘルスチェックを組み込んだ DNS サービスを利用できます。
また、イメージは必ずターゲット環境に pull できる必要があります。つまり、障害の発生時にはイメージ レジストリにアクセスできなければなりません。プラットフォームにも依存しない有効な選択肢は Artifact Registry です。
データ転送
データ転送はクロスプラットフォームの DR シナリオの重要な要素です。クロスプラットフォームの DR シナリオは必ず、DR データ転送シナリオで必要になる内容の現実的なモックアップを使用して、設計、実装、テストしてください。データ転送のシナリオについては、次のセクションで説明します。
DR のパターン
このセクションでは、前述した構成要素に基づく DR アーキテクチャの最も一般的なパターンをいくつか説明します。
Google Cloud との間でデータを転送する
DR 計画の 1 つの重要な側面は、Google Cloud との間でデータをどのくらい速く転送できるかということです。これは DR 計画が、オンプレミスから Google Cloud へ、または別のクラウド プロバイダから Google Cloud へのデータの移動に基づいている場合は極めて重要になります。このセクションでは、優れたスループットを保証できるネットワーキングおよび Google Cloud サービスについて説明します。
オンプレミスまたは別のクラウド環境にあるワークロードの復旧サイトとして Google Cloud を使用する場合は、次の重要事項を考慮する必要があります。
- Google Cloud にどのように接続するか
- 使用している環境と相互接続プロバイダとの間にどの程度の帯域幅があるか
- プロバイダから Google Cloud に直接提供される帯域幅はどうなっているか
- 他にどのようなデータがそのリンクを使用して転送されるか
公共のインターネット接続を使用してデータを転送する場合、ネットワークのスループットは ISP の容量とルーティングの制約を受けるため予測できません。ISP は制限付きの SLA を提供している場合もありますが、そうでない場合もあります。ただし、公共のインターネット接続は比較的低料金で利用できます。
Cloud Interconnect では、いくつかの選択肢の中から、Google と Google Cloud に接続する方法を選択できます。
- Cloud VPN を使用すると、Google Cloud VPC ネットワークとターゲット ネットワークの間に IPsec VPN トンネルを作成できます。2 つのネットワーク間のトラフィックは一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号されます。HA VPN を使用すると、SLA で可用性 99.99% が保証された高可用性 VPN 接続を作成できます。さらに、冗長 VPN を作成する場合に比べて簡単に設定できます。
- ダイレクト ピアリングを使用すると、Google のパブリック IP アドレスへのネットワーク ホップ数を最小限に抑えることができます。ダイレクト ピアリングを使用して、ユーザーのネットワークと Google のエッジ拠点（PoP）との間でインターネット トラフィックを送受信できます。
- Dedicated Interconnect は、オンプレミス ネットワークと Google のネットワークを物理的に直接接続します。大規模なデータ転送でも安定したスループットを確保できるだけでなく、SLA も含まれています。回線は 10 Gbps または 100 Gbps のいずれかで、Google のコロケーション施設のいずれかで終端します。帯域幅を増やすと、オンプレミスから Google Cloud へのデータ転送時間を短縮できます。次の表は、10 Gbps から 100 Gbps にアップグレードした場合の速度の向上を示しています。
- Partner Interconnect は Dedicated Interconnect と同様の機能を提供しますが、回線速度は 10 Gbps 未満です。サポートされているサービス プロバイダをご覧ください。
Google Cloud に転送する必要があるデータ量に基づいて使用する転送方法を選択するには、次の図を参考にできます。
転送時間計算ツールを使用して、移動するデータセットのサイズと転送可能な帯域幅を指定して、転送にかかるであろう時間を知ることができます。DR 計画の一環としてのデータ転送については、ビッグ データセットの転送をご覧ください。
イメージ構成とデプロイ速度のバランスをとる
新しいインスタンスをデプロイするためのマシンイメージを構成するときは、構成がデプロイの速度に及ぼす影響を考慮してください。イメージの事前構成量、イメージを維持するためのコスト、そしてデプロイ速度の間にはトレードオフがあります。たとえばマシンイメージの構成が最小限である場合、それを使用するインスタンスは、依存関係をダウンロードしてインストールする必要があるため、起動にかかる時間が長くなります。一方マシンイメージが高度に構成されていれば、それを使用するインスタンスはより早く起動しますが、イメージはより頻繁に更新する必要があります。すべての機能が動作するインスタンスの起動にかかる時間は、RTO に直接関係します。
ハイブリッド環境全体でマシンイメージの整合性を維持する
ハイブリッド ソリューション（オンプレミスからクラウドまたはクラウドからクラウド）を実装する場合は、本番環境全体で VM の整合性を維持する方法を見つける必要があります。
完全に構成されたイメージが必要な場合は、Packer などのソフトウェアの使用を検討してください。このソフトウェアを使えば、複数のプラットフォーム向けに同じマシンイメージを作成できます。ここでは同じスクリプトをプラットフォーム固有の構成ファイルとともに使用できます。Packer の場合は、構成ファイルをバージョン管理に格納して、本番環境にデプロイされたバージョンを追跡できます。
別の方法として、Chef、Puppet、Ansible、Saltstack などの構成管理ツールを利用してより細かくインスタンスを構成すると、必要に応じてベースイメージ、最小限の構成のイメージ、または完全な構成のイメージを作成できます。これらのツールを効果的に使用する方法については、Google Cloud で Chef を使用してゼロからデプロイするをご覧ください。
また、Amazon AMI、Virtualbox イメージ、RAW ディスク イメージなどの既存のイメージを手動で変換し、Compute Engine にインポートすることもできます。
階層型ストレージの実装
階層型ストレージ パターンは通常、バックアップに利用され、最新のバックアップがより高速なストレージに保存されて、古いバックアップはより低コストの低速ストレージにゆっくりと移行されます。Cloud Storage を使用したパターンの実装には、データがどこにあるかに応じて（Google Cloud またはオンプレミス）、2 種類の方法があります。どちらの場合も、さまざまなストレージ クラスのバケット間でオブジェクトを移行します。通常は Standard Storage からより低コストのストレージ クラスに移行することになります。
ソースデータがオンプレミスで生成される場合、実装は次の図のようになります。
または、オブジェクト ライフサイクル ルールを使用してバケット内のオブジェクトのストレージ クラスを変更し、オブジェクト クラス内の変更を自動化することもできます。
プライベート インスタンスに同じ IP アドレスを維持する
一般的なパターンは、VM のサービス提供インスタンスを 1 つ維持するというものです。VM を交換する必要がある場合、新しい VM は元の VM のように見えなければなりません。そのためクライアントが新しいインスタンスに接続するために使用する IP アドレスは、同じままにする必要があります。
最も単純な構成は、インスタンスを 1 つだけ保持するマネージド インスタンス グループを設定することです。このマネージド インスタンス グループは内部（プライベート）のロードバランサと統合されます。これにより、このインスタンスが元のイメージであるか置換されたものかにかかわらず、インスタンスの前に配置される IP アドレスには同じものが使用されることになります。
技術パートナー
Google には、Google Cloud を利用したバックアップと DR のユースケースをサポートする、堅牢なパートナー エコシステムがあります。具体的には、お客様はパートナー ソリューションを使用して、次のようなことを行っています。
- オンプレミスから Google Cloud にデータをバックアップする。この場合、大半のオンプレミス バックアップ プラットフォームのストレージ ターゲットとして Cloud Storage が統合されます。このアプローチを利用すると、テープやその他のストレージ アプライアンスを置き換えることができます。
- オンプレミスから Google Cloud への DR 計画を実装する。Google のパートナーのサポートを利用して、セカンダリ データセンターを排除し、Google Cloud を DR サイトとして使用できます。
- クラウドベースのワークロードに DR およびバックアップを実装する。
パートナー ソリューションの詳細については、Google Cloud ウェブサイトのパートナーのページをご覧ください。
次のステップ
- Google Cloud の地域とリージョンを読む。
この DR シリーズの他の記事を読む:
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。