Google Cloud 上の OpenShift: アクティブ / パッシブとアクティブ / 非アクティブの設定の障害復旧戦略

このドキュメントでは、 Google Cloud 上の OpenShift デプロイのアクティブ / パッシブとアクティブ / 非アクティブの障害復旧を計画して実装し、障害発生時のダウンタイムを最小限に抑え、迅速な復旧を実現する方法について説明します。データのバックアップ、コードとしての構成の管理、シークレットの処理に関するベスト プラクティスを提供し、障害発生時にアプリケーションを迅速に復元できるようにします。

このドキュメントは、Google Cloudにデプロイされた OpenShift Container Platform 上のアプリケーションの可用性と復元性を維持するシステム管理者、クラウド アーキテクト、アプリケーション デベロッパーを対象としています。

このドキュメントは、障害が発生した場合にワークロードの高可用性を維持し、迅速に復元するためのアプリケーション レベルの戦略に焦点を当てたシリーズの一部です。OpenShift での障害復旧のベスト プラクティスを読んでいることを前提としています。このシリーズのドキュメントは次のとおりです。

• Google Cloud上の OpenShift の障害復旧
• OpenShift での高可用性のベスト プラクティス
• Google Cloud上の OpenShift: アクティブ / パッシブとアクティブ / 非アクティブの設定の障害復旧戦略（このページ）

障害復旧のアーキテクチャ

このセクションでは、アクティブ / パッシブとアクティブ / 非アクティブの障害復旧シナリオのアーキテクチャについて説明します。

使用するプロダクト

• Google Compute Engine
• Google Cloud グローバル外部 HTTPS ロードバランサ
• Google Cloud パススルー ネットワーク ロードバランサ
• Cloud DNS
• ネットワーク エンドポイント グループ
• Cloud Storage
• Cloud SQL
• Persistent Disk
• Cloud Storage
• Secret Manager
• Cloud Monitoring
• VPC ネットワーク

アクティブ / パッシブ デプロイ

次の図は、 Google Cloud上の OpenShift のアクティブ / パッシブ デプロイ シナリオを示しています。

上の図に示すように、障害復旧のアクティブ / パッシブ デプロイでは、プライマリ リージョンの OpenShift クラスタがすべての本番環境トラフィックを処理します。別のリージョンのセカンダリ クラスタは、プライマリに障害が発生した場合に引き継ぐ準備を維持しています。この設定により、セカンダリ クラスタが事前にプロビジョニングされ、ウォーム状態（必要なインフラストラクチャとアプリケーション コンポーネントが設定されているが、必要になるまでトラフィックをアクティブに処理しない状態）になるため、ダウンタイムを最小限に抑えることができます。アプリケーション データはパッシブ クラスタに複製され、データ損失が最小限に抑えられ、RPO に沿ったものになります。

リージョン クラスタの一つがプライマリ（アクティブ）サイトとして機能し、すべての本番環境トラフィックを処理します。別のリージョンにあるセカンダリ クラスタは、障害復旧のスタンバイです。セカンダリ クラスタはウォーム状態に保たれ、プライマリ クラスタで障害が発生した場合に、最小限の遅延で引き継げるように備えています。

アクティブ / パッシブの DR シナリオのコンポーネントの説明

このアーキテクチャは、次の構成になっています。

• プライマリ OpenShift クラスタ（アクティブ）: プライマリGoogle Cloud リージョンに配置され、本番環境のワークロードを実行し、通常の動作条件下ですべてのユーザー トラフィックをアクティブに提供します。
• セカンダリ OpenShift クラスタ（パッシブ）: 障害分離のために別のGoogle Cloud リージョンに配置され、ウォーム スタンバイ クラスタとして機能します。部分的に設定されて実行されており、プライマリ システムに障害が発生した場合に引き継げるように備えています。必要なインフラストラクチャ、OpenShift 構成、アプリケーション コンポーネントがデプロイされていますが、フェイルオーバー イベントがトリガーされるまで、本番環境のトラフィックは処理されません。
• Google Cloud リージョン: 障害復旧の基盤となる地理的に分離されたロケーション。リージョンを分離することで、1 つのリージョンに影響する大規模なイベントがスタンバイ クラスタに影響しないようにします。
• グローバル外部 HTTPS ロードバランサ: アプリケーション トラフィックの単一のグローバル エントリ ポイントとして機能します。通常、すべてのトラフィックをプライマリ（アクティブ）クラスタに転送するように構成されています。ヘルスチェックは、プライマリ クラスタの可用性をモニタリングします。
• データ レプリケーション メカニズム: プライマリ クラスタからセカンダリ クラスタに重要なアプリケーション データ（データベースや永続ボリュームの状態など）をコピーする継続的なプロセスまたはツール。この方法によりデータの整合性が確保され、フェイルオーバー時のデータ損失が最小限に抑えられ、RPO を満たすことができます。
• モニタリングとヘルスチェック: プライマリ クラスタとそのアプリケーションの健全性と可用性を継続的に評価するシステム（Cloud Monitoring、ロードバランサのヘルスチェック、内部クラスタ モニタリングなど）。これらのシステムは、障害を迅速に検出するために重要です。
• フェイルオーバー メカニズム: プライマリで回復不能な障害が検出されたときに、プライマリからセカンダリ クラスタにトラフィックをリダイレクトする事前定義されたプロセス（手動、半自動、完全自動）。このプロセスでは通常、グローバル ロードバランサのバックエンド構成を更新してセカンダリ クラスタをターゲットにし、新しいアクティブ サイトにします。
• VPC ネットワーク: データ レプリケーションと管理のためにリージョン間の必要な接続を作成する基盤となる Google Cloud ネットワーク インフラストラクチャ。

アクティブ / 非アクティブ デプロイ

アクティブ / 非アクティブの DR では、セカンダリ リージョンをスタンバイとして維持し、災害発生時にのみアクティブにします。データが継続的に複製されるアクティブ / パッシブ設定とは異なり、この戦略では、Cloud Storage に保存される定期的なバックアップに依存します。フェイルオーバー時にインフラストラクチャがプロビジョニングされ、データが復元されます。OpenShift API for Data Protection（OADP）と統合された Velero などのツールを使用して、定期的なバックアップを実行できます。この方法はコストを最小限に抑えることができるため、復旧に時間がかかっても許容できるアプリケーションに最適です。また、組織が拡張された目標復旧時間（RTO）と目標復旧時点（RPO）に沿って対応するうえでも役立ちます。

アクティブ / パッシブの障害復旧シナリオでは、データはスタンバイ リージョンに定期的にバックアップされますが、アクティブに複製されません。インフラストラクチャはフェイルオーバー プロセスの一部としてプロビジョニングされ、データは最新のバックアップから復元されます。Velero オープンソース プロジェクトに基づく OpenShift API for Data Protection（OADP）を使用して、定期的なバックアップを実行できます。これらのバックアップは、バージョニングが有効になっている Cloud Storage バケットに保存することをおすすめします。障害発生時には、OADP を使用してクラスタのコンテンツを復元できます。このアプローチでは、継続的なコストを最小限に抑えることができますが、アクティブ / パッシブと比較して RTO が長くなり、RPO が高くなる可能性があります。この設定は、目標復旧時間が長いアプリケーションに適しています。

次の図は、アクティブ / 非アクティブ デプロイとフェイルオーバー プロセスを示しています。

フェイルオーバー プロセスは次のとおりです。

1. DR イベントは、モニタリング対象サービスが使用不可になったときにトリガーされます。
2. パイプラインは、DR リージョンにインフラストラクチャを自動的にプロビジョニングします。
3. 新しい OpenShift クラスタがプロビジョニングされます。
4. アプリケーション データ、シークレット、オブジェクトは、OADP を介して最新のバックアップから復元されます。
5. Cloud DNS レコードが更新され、DR リージョンのリージョン ロードバランサを参照するようになります。

上の図に示すように、2 つの別々の OpenShift リージョン クラスタがデプロイされます。それぞれ異なる Google Cloud リージョン（us-central1 や europe-west1 など）にデプロイされます。各クラスタは、リージョン内で高可用性を実現し、冗長性を確保するために複数のゾーンを使用する必要があります。

アクティブ / 非アクティブの DR シナリオのコンポーネントの説明

このアーキテクチャは、次の構成になっています。

• プライマリ リージョン（リージョン A）: 本番環境のトラフィックを処理する完全に機能する OpenShift クラスタが含まれています。
• セカンダリ リージョン（リージョン B）: 最初は最小限のリソース（VPC とサブネット）が含まれています。フェイルオーバー中にインフラストラクチャ（Compute Engine インスタンスと OCP）がプロビジョニングされます。
• バックアップ ストレージ: Google Cloud Storage バケットには、定期的なバックアップ（アプリケーション オブジェクトの OADP または Velero、PV、データベースのバックアップ）が保存されます。バケットには、バージョニングとクロスリージョン レプリケーションを使用することをおすすめします。
• 構成管理: Git リポジトリには、Infrastructure as Code（IaC、Terraform など）と Kubernetes または OpenShift マニフェスト（GitOps 用）が保存されます。
• バックアップ ツール: Cloud Storage へのスケジュール バックアップを実行するようにプライマリ クラスタで構成された OADP（Velero）。
• オーケストレーション: スクリプトまたは自動化ツールは、フェイルオーバー中にインフラストラクチャのプロビジョニングと復元プロセスをトリガーします。

ユースケース

このセクションでは、アクティブ / パッシブ デプロイとアクティブ / 非アクティブ デプロイのさまざまなユースケースの例を示します。

アクティブ / パッシブ DR のユースケース

アクティブ / パッシブ DR は、次のユースケースにおすすめします。

• コールド復元で実現可能な RTO よりも短い RTO（数分から数時間など）を必要とするアプリケーション。コールド復元では、すぐにアクセスできないバックアップからデータが復元されます。
• 継続的なデータ レプリケーションが可能で、RPO を最小限に抑える必要があるシステム（数分から数秒など）。
• ダウンタイムの制限が厳しく、ウォーム スタンバイ クラスタの維持費用がダウンタイムによるビジネスへの影響によって正当化される、ビジネス クリティカルなアプリケーションを運用している規制対象業界。

アクティブ / 非アクティブ DR のユースケース

アクティブ / 非アクティブ DR は、次のユースケースにおすすめします。

• RTO が長くても許容されるアプリケーション（数分から数時間など）。
• 費用最適化が重要であり、スタンバイ クラスタの継続的な実行費用が過大になる環境。主な継続費用は、コンピューティング インスタンスの実行ではなく、オブジェクト ストレージに対するものです。
• 開発、テスト、重要度の低い本番環境のワークロード。
• 復元時間が重要ではないアーカイブ システムまたはバッチ処理システム。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。

アクティブ / パッシブ設計の考慮事項

このセクションでは、アクティブ / パッシブ DR シナリオの設計上の考慮事項について説明します。

アプリケーションの状態と構成の保護

OpenShift Container Platform は OADP を提供し、クラスタで実行されているアプリケーションに包括的な障害復旧保護を提供します。これを使用して、コンテナ化されたアプリケーションと仮想マシンの両方で使用される Kubernetes オブジェクトと OpenShift オブジェクト（Deployment、Service、ルート、PVC、ConfigMap、Secret、CRD など）をバックアップできます。ただし、OADP はクラスタの完全なバックアップと復元をサポートしていません。バックアップの構成とスケジュール設定の方法、復元オペレーションの方法については、Red Hat のドキュメントをご覧ください。

OADP は、アプリケーションで使用されるブロック ストレージと NFS ストアに依存する永続ボリュームのバックアップと復元プロセスを提供します。これらのプロセスを実行するには、Restic または Kopia ツールを使用してスナップショットを作成するか、ファイルレベルのバックアップを実行します。

OADP は、オブジェクト定義のバックアップ、構成の整合性の確保、必要に応じて特定のアプリケーションや名前空間の復元に役立ち、データ複製を補完します。

アクティブ / パッシブ構成で RPO と RTO をさらに短縮するには、プライマリ リージョンとセカンダリ リージョン間のデータ レプリケーションを構成することをおすすめします。

データ レプリケーションは、セカンダリ クラスタがシームレスに引き継ぐことができるようにするために重要です。次のセクションで説明するように、プライマリ クラスタからセカンダリ クラスタへのデータ レプリケーションの実装は、アプリケーションが使用するストレージ タイプによって異なります。

ブロック ストレージ（永続ボリューム）

Google Persistent Disk 非同期レプリケーションを使用して、プライマリ リージョンからセカンダリ リージョンにデータをコピーします。この方法では、プライマリ リージョンにプライマリ ディスクを作成し、セカンダリ リージョンにセカンダリ ディスクを作成して、それらの間でレプリケーションを設定します。整合性グループを使用すると、両方のディスクに共通の時点のレプリケーション データが含まれるようになり、DR に使用されます。詳細については、Persistent Disk の非同期レプリケーションを構成するをご覧ください。

PersistentVolume オブジェクト

OpenShift で、これらのディスクにリンクする PersistentVolume オブジェクトを両方のクラスタに作成し、アプリケーションが両方のクラスタで同じ Persistent Volume Claim（PVC）を使用していることを確認します。

アプリケーション レベルのレプリケーション

一部のアプリケーション（データベースやメッセージ キューなど）には、クラスタ間で構成できる組み込みのレプリケーション機能があります。Pub/Sub などのマネージド サービスを使用して、特定のタイプのアプリケーション データやイベントのレプリケーションを容易にすることもできます（データベースやメッセージ キューなど）。

データベースのバックアップ

アプリケーションはさまざまな種類のデータベース プロダクトに依存する可能性があります。このドキュメントでは、データベース バックアップの設計上の考慮事項を説明するために、PostgreSQL をデータベースの例として使用します。

クラスタ内データベース オペレータを使用したセルフホスト型バックアップ

CloudNative PostgreSQL Operator などのデータベース オペレータを使用すると、PostgreSQL クラスタのスケジュール設定されたバックアップと障害復旧を容易に行うことができます。CloudNative PostgreSQL Operator は、pg_basebackup などのツールとネイティブに統合され、ストリーミング レプリケーション バックアップをサポートします。耐久性と復元のために、Google Cloud Storage（Cloud Storage）などのクラウド ストレージ サービスにバックアップを保存できます。

プライマリ リージョンで停止が発生した場合でもデータを利用できるように、プライマリ リージョン クラスタとセカンダリ リージョン クラスタ間でストリーミング レプリケーションを設定できます。このストリーミング レプリケーションは、通常、リージョン内では同期的に行われ、リージョン間では非同期的に行われます。構成手順の詳細については、CloudNativePG のドキュメントをご覧ください。

障害が発生した場合は、バックアップを新しい PostgreSQL クラスタに復元して、ダウンタイムとデータ損失を最小限に抑えることができます。次に、CloudNative PostgreSQL オペレーターを使用してスケジュールされたバックアップを有効にする構成スニペットの例を示します。

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

マネージド サービス

Cloud SQL などのマネージド データベースには、バックアップとレプリケーションの機能が組み込まれています。プライマリ データベース インスタンスからセカンダリ リージョンのレプリカへの非同期レプリケーションを設定することをおすすめします。詳細については、Cloud SQL でのレプリケーションについてをご覧ください。OpenShift で、各クラスタの正しいデータベース接続文字列を指すようにシークレットまたは構成マップを構成します。

非同期レプリケーションでは RPO がゼロにならないため、最新のデータ書き込みが失われる可能性があります。データ損失を軽減するようにアプリケーションを設計する必要があります。別のレプリケーション方法の使用を検討してください。

Cloud SQL の自動バックアップを有効にすることもおすすめします。詳細については、オンデマンド バックアップと自動バックアップを作成して管理するをご覧ください。

フェイルオーバー プロセス

プライマリ クラスタで障害が発生した場合、Cloud DNS はヘルスチェックとフェイルオーバー ポリシーに基づいて、トラフィックをセカンダリ リージョン クラスタに自動的にリダイレクトします。

セカンダリ クラスタがリードレプリカからプライマリにプロモートされると、アクティブ サイトとして引き継ぎ、本番環境のトラフィックを処理します。このプロモーションは、データベースの書き込みを受け入れるために必要です。

Cloud SQL の DR を設定するには、Google Cloud SQL の障害復旧のドキュメントに記載されている手順に沿って操作します。非同期データベースまたはストレージ レプリケーションを使用すると、RPO がゼロ以外になり、アプリケーションが最新の書き込みの損失を許容できるようになります。別のレプリケーション方法の使用を検討してください。

シークレットの安全な管理

データベース パスワード、API キー、TLS 証明書などのシークレットは、DR の重要な要素です。これらのシークレットを新しいクラスタで安全かつ確実に復元できる必要があります。

シークレット管理の一般的なアプローチは次のとおりです。

• 外部シークレットを使用する: 外部シークレット オペレーターなどのツールを使用して、Google Secret Manager からシークレットを pull します。
• OADP Operator でシークレットをバックアップする: 外部ストアを使用しない場合は、シークレットがバックアップに含まれていることを確認します。
• 定期的なローテーション: シークレットを定期的にローテーションし、シークレット管理戦略が DR シナリオに対応していることを確認します。
• テスト: ステージング済みの環境でシークレットの復元をテストし、提供された認証情報ですべてのサービスを開始できることを確認します。
• 検証: DR クラスタに、外部ストアからシークレットを取得するために必要な IAM ロールまたは認証方法があることを検証します。

ネットワーキングとトラフィックの管理

Google Cloudのグローバル外部 HTTPS ロードバランサをプライマリの Ingress ポイントとして使用して、複数の OpenShift クラスタ（プライマリ クラスタとセカンダリ クラスタなど）間でトラフィックを分散します。このグローバル サービスは、近接性、健全性、可用性に基づいて、ユーザー リクエストを適切なバックエンド クラスタに転送します。

グローバル ロードバランサを OpenShift クラスタに接続するには、次のいずれかの方法を使用します。

• リージョン ロードバランサ（インターネット NEG）を使用する: 各 OpenShift クラスタの Ingress サービス（OCP ルーター）を公開するリージョン ロードバランサの外部 IP アドレスを指すようにGoogle Cloud インターネット ネットワーク エンドポイント グループ（NEG）を構成します。グローバル ロードバランサは、これらのリージョン ロードバランサの IP にトラフィックをルーティングします。このアプローチでは抽象化レイヤが提供されますが、追加のネットワークへのホップが発生します。
• Pod の直接ルーティング（Compute Engine_VM_IP_PORT NEGs）: OpenShift Ingress Controller のインテグレーションを構成して、Compute Engine_VM_IP_PORT タイプの Google Cloudネットワーク エンドポイント グループ（NEG）を使用します。このアプローチにより、グローバル ロードバランサは、内部 PodIP:TargetPort を使用して OpenShift Ingress Controller（ルーター）Pod を直接ターゲットにできます。この方法では、余分なホップと追加のノードプロキシをバイパスします。通常、レイテンシが短縮され、グローバル ロードバランサからのより直接的なヘルスチェックが可能になります。

どちらの構成でも、グローバル ロードバランサは異なるリージョンのクラスタ間でトラフィックの分散を効果的に管理できます。詳細については、外部バックエンドを使用してグローバル外部アプリケーション ロードバランサを設定するをご覧ください。

VPC

VPC の管理には、次のアプローチをおすすめします。

• 共有 VPC: 共有 VPC を使用して、プライマリ クラスタとセカンダリ クラスタの両方のネットワーク管理を一元化します。この方法を使用することで管理が簡素化され、リージョン間で一貫したネットワーク ポリシーを適用できます。
• グローバル動的ルーティング: VPC 内でグローバル動的ルーティングを有効にして、リージョン間でルートを自動的に伝播し、クラスタ間のシームレスな接続を確保します。
• カスタムモード VPC: カスタムモード VPC を使用し、クラスタが実行されるリージョンに特定のサブネットを作成します。これは、Compute Engine_VM_IP_PORT ルーティングなどのメソッドで必要な VPC ネイティブ Pod ネットワーキングで必要になることがよくあります。
• VPC ネットワーク ピアリング: リージョンとクラスタごとに個別の VPC ネットワークを使用する必要がある場合は、VPC ネットワーク ピアリングを使用してリージョンとクラスタを接続します。

サブネットと IP アドレス

各リージョンにリージョン サブネットを作成して、ネットワーク セグメンテーションを維持し、IP アドレスの競合を回避します。

ルーティングの問題を防ぐため、リージョン間で IP 範囲が重複しないようにします。

Red Hat Service Mesh を使用したクラスタ間トラフィック

OpenShift はサービス メッシュの連携をサポートしています。これにより、複数の OpenShift クラスタにデプロイされたサービス間の通信が可能になります。この関数は、フェイルオーバーやデータ レプリケーション中にサービスがクラスタ間で通信する必要がある DR シナリオで特に役立ちます。

プライマリ クラスタとセカンダリ クラスタ間のサービス メッシュ連携を設定する方法については、Red Hat のドキュメントをご覧ください。

アクティブ / 非アクティブの設計に関する考慮事項

このセクションでは、アクティブ / 非アクティブ DR ソリューションの設計上の考慮事項について説明します。

アプリケーション構成をコードとして管理する（GitOps）

GitOps アプローチを採用して、すべてのクラスタとアプリケーションの構成を Git リポジトリに保存することをおすすめします。このアプローチでは、別のクラスタで確実に実行されていることがわかっている状態への同期を有効にすることで、DR シナリオでの迅速な復元が可能になります。バックアップにより、ランタイム状態のスナップショットを確保できますが、障害発生後にアプリケーション ロジック、マニフェスト、インフラストラクチャ定義を迅速に再デプロイする信頼性の高い方法も必要です。

OpenShift GitOps Operator を使用する

Argo CD に基づく OpenShift GitOps Operator は、OpenShift 環境内で GitOps パターンを直接実装するための Red Hat がサポートする方法を提供します。クラスタの状態と選択した構成を継続的に調整し、Git リポジトリに保存するプロセスを自動化します。

OpenShift GitOps Operator のコントローラは、クラスタの状態がこのリポジトリで定義された構成と一致することを継続的に確認します。リソースがドリフトしている場合や欠落している場合は、自動的に調整されます。詳細については、Red Hat OpenShift GitOps についてをご覧ください。

DR シナリオの実行

障害が発生した場合は、次の操作を行います。

• 別のリージョンに新しい OpenShift クラスタを設定します。
• OpenShift GitOps Operator をインストールします。
• Git リポジトリを参照する同じアプリケーション マニフェストを適用します。

Operator は、クラスタの状態をリポジトリと一致するように同期し、コードで定義されたデプロイ、サービス、ルート、オペレーター、その他のリソースを迅速に再デプロイします。

DR 中に問題が発生しないように、次のことをおすすめします。

• Git リポジトリで厳格なブランチ戦略とタグ付け戦略を維持して、DR に適した安定した構成を特定できるようにします。
• DR クラスタにネットワーク接続があり、Git リポジトリにアクセスするための適切な権限があることを確認します。
• フェイルオーバー時の手動介入を回避するために、すべてのリソースタイプをコードとして含めます（インフラストラクチャ コンポーネント、アプリケーション ワークロード、構成など）。

ファイアウォール ルール

統合ファイアウォール ポリシーを定義し、両方のクラスタに一貫して適用して、トラフィック フローを制御し、セキュリティを強化します。

最小権限の原則に従います。つまり、インバウンド トラフィックとアウトバウンド トラフィックをアプリケーションの機能に必要なもののみに制限します。

デプロイ

このリファレンス アーキテクチャに基づくトポロジーをデプロイする方法については、Red Hat のドキュメントをご覧ください。

次のステップ

• プライマリ環境とセカンダリ環境の両方で、クラスタの健全性、レプリケーション ステータス、バックアップの成功、アプリケーションのパフォーマンスのモニタリングとアラートを実装する方法を確認する。
• OpenShift を Google Cloudにインストールする方法を学習する
• Google Cloudでの Red Hat ソリューションの詳細