障害復旧の構成要素

この記事は、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
  • コンテナ化されたアプリケーションのデプロイとスケーリングのためのマネージド環境
  • ノードの自動修復
  • liveness プローブと readiness プローブ
  • 永続ボリューム
  • マルチゾーン クラスタとリージョン クラスタ
  • リージョン クラスタを管理するコマンドライン ツール

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 のシナリオで役立ちます。あらかじめインスタンスを完全に構成してデプロイしなくても、リカバリ リソースを予約してフェイルオーバーに利用可能な状態に維持できるからです。

永続ディスクとスナップショット

永続ディスクは長期的なネットワーク ストレージ デバイスであり、インスタンスからアクセスできます。永続ディスクはインスタンスから独立しているため、インスタンスを削除した後でも、永続ディスクを切断または移動してデータを保持することが可能です。

障害の発生時には、Compute Engine VM の増分バックアップまたはスナップショットを作成し、それをリージョン間でコピーして、永続ディスクを再作成できます。さらに永続ディスクのスナップショットを作成すると、ユーザーエラーによりデータが失われることを防止できます。スナップショットは増分なので、スナップショット ディスクが実行中のインスタンスに接続されている場合でも、わずか数分で作成できます。

永続ディスクには冗長性が組み込まれているため、機器の故障からデータを保護するとともに、データセンターのメンテナンス中でもデータの可用性を保証します。永続ディスクはリージョン リソースまたはゾーンリソースのいずれかです。リージョン永続ディスクでは同じリージョン内の 2 つのゾーン間で書き込みが複製されます。ゾーンが停止した場合、バックアップ VM インスタンスで、もう一方のゾーンのリージョン永続ディスクを強制接続できます。詳細については、リージョン永続ディスクを使用した高可用性オプションをご覧ください。

ライブ マイグレーション

ライブ マイグレーションでは、ホストシステムでソフトウェア / ハードウェアの更新などのイベントが発生しても、VM インスタンスの実行が継続されます。Compute Engine は VM の再起動を要求することなく、同じゾーンの別のホストに対して、実行中のインスタンスのライブ マイグレーションを行います。Google ではこれにより、インフラストラクチャの保護と信頼性を維持するために不可欠なメンテナンスを、VM の実行を中断せずに実施することが可能になっています。

仮想ディスク インポート ツール

仮想ディスク インポート ツールを使用すると、VMDK、VHD、RAW などのファイル形式をインポートして、新しい Compute Engine 仮想マシンを作成できます。このツールを使用すると、オンプレミスの仮想マシンと同じ構成の Compute Engine 仮想マシンを作成できます。この方法は、イメージにすでにインストールされているソフトウェアのソースバイナリから Compute Engine イメージを構成できない場合に適しています。

Cloud Storage

Cloud Storage は、バックアップ ファイルの保存に理想的なオブジェクト ストアです。次の図のような特定のユースケースに適した、さまざまなストレージ クラスが用意されています。

高頻度アクセス用の Standard Storage、低頻度アクセス用の Nearline と Coldline、最低頻度アクセス用の Archive を示す図

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 バケットにバックアップする。
  • データをマルチリージョンのバケットからリージョン内のバケットに移動して、バックアップの保存コストを削減する。

GKE

GKE は、コンテナ化されたアプリケーションをデプロイするための、マネージド型の本番環境です。GKE では HA システムをオーケストレートすることができ、次のような機能が用意されています。

  • ノードの自動修復。ノードが長い期間(10 分前後)連続してヘルスチェックに失敗すると、GKE はそのノードの修復プロセスを開始します。
  • liveness プローブ。liveness プローブを指定すると、定期的に GKE に Pod が稼働中であることが通知されます。Pod がプローブに失敗した場合、プローブを再起動できます。
  • 永続ボリューム。データベースはコンテナの存続期間が過ぎても存続し続けなければなりません。Compute Engine の永続ディスクにマッピングされる永続ボリュームの抽象化を使用することで、個々のコンテナとは無関係にストレージの可用性を維持できます。
  • マルチゾーン クラスタとリージョン クラスタ。Kubernetes リソースは、リージョン内の複数のゾーンに分散できます。
  • Kubemci。このツールを使用すると、グローバル ロードバランサを構成して、異なるリージョンの複数の GKE クラスタ間でトラフィックの負荷を分散できます。

ネットワーキングとデータ転送

Cloud Load Balancing
  • ヘルスチェック
  • 単一のエニーキャスト IP
  • クロスリージョン
  • Cloud CDN との統合
  • 自動スケーリングの統合
Traffic Director
  • Google が管理するグローバル L7 ILB
  • xDSv2 対応オープン サービス プロキシのコントロール プレーン
  • VM とコンテナをサポート
  • ヘルスチェック オフロード
  • 迅速な自動スケーリング
  • 高度なリクエスト ルーティングとリッチ トラフィック制御ポリシー
Cloud DNS
  • プログラムによる DNS 管理
  • アクセス制御
  • ゾーンに対応するエニーキャスト
Cloud Interconnect
  • Cloud VPN(IPsec VPN)
  • ダイレクト ピアリング

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 の DNS 転送によってこれらのアドレスを解決できます。

Cloud Interconnect

Cloud Interconnect は、情報を他のソースから Google Cloud に移動する方法を提供します。このプロダクトについては、後述する Google Cloud との間でデータを転送するのセクションで説明します。

管理とモニタリング

Cloud Status ダッシュボード
  • Google Cloud サービスのステータス
Google Cloud のオペレーション スイート
  • 稼働時間のモニタリング
  • アラート
  • Logging
  • Error Reporting
Deployment Manager
  • 再現性を備え一貫したデプロイ プロセス
  • 並行的なデプロイメント
  • テンプレート
  • Infrastructure as Code

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 アラートに対して自動プロセスをトリガーすることもできます。

Deployment Manager

Deployment Manager を使用すると、一連のテンプレートで Google Cloud 環境を定義できます。その後そのテンプレートを利用すれば、単一のコマンドを繰り返し使用して環境を作成できます。同様に、単一のコマンドで環境を破棄することもできます。これにより、Deployment Manager は、どのリージョンでも確実に作成できる DR リカバリ環境を定義する場合に理想的です。

クロスプラットフォームの DR 構成要素

複数のプラットフォームでワークロードを実行する場合、運用上のオーバーヘッドを削減する 1 つの方法は、使用するすべてのプラットフォームで動作するツールを選ぶことです。このセクションでは、プラットフォームに依存せず、クロスプラットフォームの DR シナリオをサポートできるいくつかのツールとサービスについて説明します。

宣言型テンプレート ツール

宣言型テンプレート ツールを使用すると、プラットフォーム間でインフラストラクチャを簡単にデプロイできます。前述のように、Google Cloud のみのデプロイでは、Deployment Manager を使用できます。クロスプラットフォームでのデプロイの場合は、Terraform が最も一般的な宣言型テンプレート ツールの 1 つになります。

構成管理ツール

大規模または複雑な DR インフラストラクチャの場合は、Chef や Ansible のようなプラットフォームに依存しないソフトウェア管理ツールをおすすめします。こうしたツールにより、コンピューティング ワークロードがどこにあっても再現可能な構成を適用できるようになります。この種のツールの使用例については、Ansible と Spinnaker のチュートリアルおよび Google Cloud で Chef を使用してゼロからデプロイするをご覧ください。

オブジェクト ストレージ

一般的な DR のパターンは、異なるクラウド プロバイダのオブジェクト ストアにオブジェクトのコピーを持つというものです。このためのクロスプラットフォーム ツールの 1 つに boto があります。これはオープンソースの Python ライブラリで、Amazon S3 と Cloud Storage の両方のインターフェースとなります。

オーケストレーター ツール

コンテナは DR 構成要素と見なすこともできます。コンテナはサービスをパッケージ化し、プラットフォーム間の整合性をもたらすための方法です。

コンテナを使用する場合、通常はオーケストレーターを利用します。Kubernetes は Google Cloud 内のコンテナを(GKE を使用して)管理するだけでなく、複数のプラットフォーム間でコンテナベースのワークロードをオーケストレートする手段を提供します。Google Cloud、AWS、および Microsoft Azure はすべて、マネージド バージョンの Kubernetes を提供しています。

異なるクラウド プラットフォームで動作している Kubernetes クラスタにトラフィックを分散するには、重み付きレコードをサポートしヘルスチェックを組み込んだ DNS サービスを利用できます。

また、イメージは必ずターゲット環境に pull できる必要があります。つまり、障害の発生時にはイメージ レジストリにアクセスできなければなりません。プラットフォームにも依存しない有効な選択肢は Container 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 にアップグレードした場合の速度の向上を示しています。10 Gbps と 100 Gbps でのデータ転送時間を比較するグラフ
  • Partner Interconnect は Dedicated Interconnect と同様の機能を提供しますが、回線速度は 10 Gbps 未満です。サポートされているサービス プロバイダをご覧ください。

Google Cloud に転送する必要があるデータ量に基づいて使用する転送方法を選択するには、次の図を参考にできます。

Y 軸にデータ量(0~100 TB 超)、X 軸にデータの場所のカテゴリ(「Google Cloud 内」、「接続性の良いオンプレミス」など)を示すグラフ。カテゴリごとに転送ソリューションが異なる

DR 計画の一環としてのデータ転送については、ビッグ データセットの転送をご覧ください。

イメージ構成とデプロイ速度のバランスをとる

新しいインスタンスをデプロイするためのマシンイメージを構成するときは、構成がデプロイの速度に及ぼす影響を考慮してください。イメージの事前構成量、イメージを維持するためのコスト、そしてデプロイ速度の間にはトレードオフがあります。たとえばマシンイメージの構成が最小限である場合、それを使用するインスタンスは、依存関係をダウンロードしてインストールする必要があるため、起動にかかる時間が長くなります。一方マシンイメージが高度に構成されていれば、それを使用するインスタンスはより早く起動しますが、イメージはより頻繁に更新する必要があります。すべての機能が動作するインスタンスの起動にかかる時間は、RTO に直接関係します。

イメージの起動時間に対してマッピングされた、バンドリングの 3 つのレベル(非バンドル化から完全バンドル化まで)を示す図(最もバンドル化されたものが最も高速で起動する)

ハイブリッド環境全体でマシンイメージの整合性を維持する

ハイブリッド ソリューション(オンプレミスからクラウドまたはクラウドからクラウド)を実装する場合は、本番環境全体で VM の整合性を維持する方法を見つける必要があります。

完全に構成されたイメージが必要な場合は、Packer などのソフトウェアの使用を検討してください。このソフトウェアを使えば、複数のプラットフォーム向けに同じマシンイメージを作成できます。ここでは同じスクリプトをプラットフォーム固有の構成ファイルとともに使用できます。Packer の場合は、構成ファイルをバージョン管理に格納して、本番環境にデプロイされたバージョンを追跡できます。Packer などのオープンソース ユーティリティを利用して、イメージを継続的に構築するための自動化されたパイプラインを作成する方法については、Jenkins、Packer、Kubernetes を使った自動的なイメージ構築をご覧ください。

別の方法として、Chef、Puppet、Ansible、Saltstack などの構成管理ツールを利用してより細かくインスタンスを構成すると、必要に応じてベースイメージ、最小限の構成のイメージ、または完全な構成のイメージを作成できます。これらのツールを効果的に使用する方法については、Ansible と Spinnaker のチュートリアルGoogle Cloud で Chef を使用してゼロからデプロイするをご覧ください。

また、Amazon AMI、Virtualbox イメージ、RAW ディスク イメージなどの既存のイメージを手動で変換し、Compute Engine にインポートすることもできます。

階層型ストレージの実装

階層型ストレージ パターンは通常、バックアップに利用され、最新のバックアップがより高速なストレージに保存されて、古いバックアップはより安価な低速ストレージにゆっくりと移行されます。Cloud Storage を使用したパターンの実装には、データがどこにあるかに応じて(Google Cloud またはオンプレミス)、2 種類の方法があります。どちらの場合も、さまざまなストレージ クラスのバケット間でオブジェクトを移行します。通常は標準ストレージからより低価格の Nearline ストレージ クラスに移行することになります。

永続ディスクから Standard Storage、さらに Nearline Storage へのデータ移行を示す図

ソースデータがオンプレミスで生成される場合、実装は次の図のようになります。

オンプレミスから Cloud Interconnect を経由した Cloud 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 ウェブサイトのパートナーのページをご覧ください。

次のステップ