環境のスナップショットを使用した障害復旧

Cloud Composer 1 | Cloud Composer 2

このページでは、障害復旧に環境スナップショットを使用する方法について説明します。

定義

このガイドでは、次の定義を使用します。

• 障害とは、環境のオペレーションに必要な Cloud Composer やその他のコンポーネントが利用できないイベントのことです。このイベントには、異なるリージョンと Cloud Composer 環境へのフェイルオーバーが必要です。障害の原因は自然である可能性があります。また、Google Cloud リージョンのダウンタイムと独自のインフラストラクチャの停止の両方などの人為的なものである可能性もあります。
• Cloud Composer のコンテキストでの障害復旧（DR）は、障害発生後に環境のオペレーションを復元するプロセスです。プロセスには、（おそらく別のリージョンに）環境を再作成することが伴います。障害復旧の詳細については、障害復旧計画ガイドをご覧ください。
• プライマリ環境は、DR 機能を有効にする Cloud Composer 環境です。
• フェイルオーバー環境は、プライマリ環境からアクティビティを引き継ぐように指定された Cloud Composer 環境です。
• ウォーム DR のシナリオは障害復旧のバリエーションであり、障害が発生する前に作成するスタンバイ フェイルオーバー環境を使用します。
• コールド DR のシナリオは障害復旧のバリエーションであり、障害が発生した後にフェイルオーバー環境を作成します。
• クロスリージョン DR は、プライマリとフェイルオーバーの環境が異なるリージョンにある、ウォームまたはコールドの障害復旧のバリエーションです。

障害復旧手順について

障害復旧手順によって、障害のためにプライマリ環境が動作しなくなる（破損または別の原因でアクセスできなくなる）場合に問題を解決します。

この手順は、障害に対処するためにプライマリ環境が適切に修正されないことを前提としています。代わりに、並行して 2 つ目の（フェイルオーバー）環境を作成します。この環境は、プライマリ環境の代わりに動作します。後の段階で、プライマリ環境に戻るか、フェイルオーバー環境を使い続けるかを選択できます。

手順はフェイルオーバー環境を使用するため、プライマリ環境から切り替える際に、変更が適用されます。プライマリとフェイルオーバーの環境の間の変更は次のとおりです（リストは包括的なものではありません）。

• ウェブサーバーの URL は異なるものになります。これにより、Airflow UI と Airflow REST API エンドポイントのアドレスが変更されます。

• 環境のバケット URL は異なるものになります。

• ネットワークとアクセス許可の構成に調整が必要となる場合があります。

ウォーム DR シナリオを使用する場合、ウェブサーバー、環境のバケット アドレス、ネットワーク構成の値を事前に把握します。

始める前に

• Cloud Composer では、2.0.32 以降のバージョンのスケジュールされたスナップショットをサポートしています。環境のスナップショットは 2.0.9 以降のバージョンでサポートされています。

準備の概要

どちらの DR シナリオにも、次のような準備手順が含まれています。

1. フェイルオーバー環境を作成する。

   • ウォーム DR シナリオでは、この環境の可用性を維持します。
   • コールド DR のシナリオでは、障害復旧手順をテストするためだけにこの環境を作成します。準備が完了したら、この環境を削除し、障害発生後にそれを再作成します。

2. スナップショット用のバケットを作成する。

   • バケットは DR リージョンで利用可能である必要があります。 クロスリージョン DR の場合、スナップショット バケットはマルチリージョンであるか、プライマリ環境とは異なるリージョンに配置されている必要があります。

   • DAG がリージョン リソースにアクセスできることを確認します。

3. DB のメンテナンスを設定する。

4. スケジュールされたスナップショットを設定する。

5. 障害復旧手順をテストする。

障害復旧の概要

障害発生後:

1. （コールド DR のみ）フェイルオーバー環境を作成する。
2. 可能であれば、プライマリ環境で DAG の実行を停止します。
3. スナップショット バケットからフェイルオーバー環境にスナップショットを読み込みます。
4. 必要に応じて、フェイルオーバー環境の構成を調整します。
5. プライマリ環境の対応方法を決定します。

準備手順

以下に概説する手順を実行して、環境の障害復旧を設定します。

フェイルオーバー環境を作成する

フェイルオーバー環境として機能する環境を作成します。

次のガイドラインに従ってください。

• プライマリとフェイルオーバーの環境では、Cloud Composer と Airflow の同じバージョンを使用する必要があります。

  注意: 互換性に関連する追加の変更が必要になる場合があるため、Cloud Composer または Airflow の新しいバージョンへのフェイルオーバーは実行しないでください。

• ウォーム DR のシナリオでは、両方の環境を同期して、更新、アップグレードするようにしてください。たとえば、プライマリ環境を新しい Cloud Composer バージョンにアップグレードするか、PyPI パッケージをインストールすると、フェイルオーバー環境にもこれらの変更が必要になります。

• フェイルオーバー環境は、プライマリ環境とは異なるリージョンに作成することをおすすめします。その結果、リージョン全体の可用性に影響する障害など、より広い範囲の障害シナリオに対応できます。

• Terraform を使用してプライマリとフェイルオーバーの環境を作成し、両方に一貫した構成を持たせることをおすすめします。プライマリとフェイルオーバーの両方の環境の Terraform 定義が同期されるようにしてください。

• フェイルオーバー環境の構成（環境のサイズ、スケジューラの数、IAM 権限など）は、プライマリ環境の構成に適合することをおすすめします。両方の環境の IAM 権限により、ユーザーとスナップショットに対する適切なアクセス権が付与されている必要があります。

リソースの可用性を確認する

DAG は外部リソースで動作し、それらのリソースへのアクセスは、環境の構成（環境のサービス アカウント、ネットワーク構成、プロジェクトに付与されている権限など）によって異なる場合があります。これらのリソースがフェイルオーバー環境で使用可能であることを確認します。

環境が、Airflow に保存されている接続を通じて、一部の外部リソースとやり取りする場合があります。プライマリ環境と比較して、フェイルオーバー環境でこれらのリソースを調整する必要があるかどうかを確認します。

スナップショット用のストレージ バケットを作成する

環境のスナップショット用の新しいストレージ バケットを作成します。保持ポリシーとライフサイクルの構成はバケットレベルで適用されるため、障害復旧に環境バケットを使用しないでください。

このストレージ バケットに IAM 権限、保持ポリシー、ライフサイクル構成が、誤って削除または不正アクセスされないように設定されていることを確認します。スナップショット用のバケットの構成の詳細については、スケジュールされたスナップショットの構成をご覧ください。

次のことが可能です。

• 異なるリージョンにバケットを作成します。
• マルチリージョン バケットを作成します。

注意: プライマリ環境と同じリージョンにバケットを作成する場合、リージョン全体の可用性に影響する障害などの一部の障害シナリオは対応できません。

DB メンテナンスを設定する

データベース メンテナンス DAG を実行して、Airflow メタデータ データベースを小さく保ちます。そうすることで、スナップショットの保存と読み込みを迅速化できます。Airflow メタデータ データベースのスナップショットをサポートする データは 20 GB 未満である必要があります。

スケジュールされたスナップショットを設定する

プライマリ環境のスケジュール設定されたスナップショットを設定します。

スナップショットは正常な環境でのみ作成できるため、障害が発生する前にスナップショットを保存する必要があります。

スナップショットの仕組みの詳細については、環境のスナップショットの保存と読み込みをご覧ください。保存されたスナップショットのある場所については、ドキュメントの環境スナップショットの保存セクションをご覧ください。

注: 割り当て上限により、単一の環境で 1 日あたり最大 52 件のスナップショット オペレーションを保存できます。スケジュール設定されたスナップショットを定期的に取得する場合は、スナップショットの間隔を 30 分以上にする必要があります。

（省略可）スケジュール設定されたスナップショット操作のモニタリングを設定する

少なくとも 12 時間に 1 回の頻度でスケジュール設定されるスナップショットについては、Cloud Monitoring を使用して、スナップショットが自動的に作成されない場合にアラートを受け取ることができます。

頻度の低いスケジュールの場合は、Google Cloud CLI を使用してスナップショット オペレーションの結果を確認します。スナップショット オペレーションの保存を確認するをご覧ください。

1. Google Cloud コンソールで、[Monitoring] ページに移動します。

   [Monitoring] に移動

2. [Monitoring] のナビゲーション ペインで、[ アラート] を選択します。
3. 通知チャンネルを作成せずに通知を受け取る場合は、[EDIT NOTIFICATION CHANNELS] をクリックして、通知チャンネルを追加します。チャンネルを追加したら、[アラート] ページに戻ります。
4. [アラート] ページで、[CREATE POLICY] をクリックします。
5. 指標を選択するには、[指標の選択] メニューを開き、次の操作を行います。
   1. メニューを関連するエントリに限定するには、フィルタバーに「Composer Snapshot」と入力します。結果が表示されない場合は、[Show only active resources & metrics] をオフにします。
   2. [Resource type] で [Cloud Composer Environment] を選択します。
   3. [指標のカテゴリ] で [Environment] を選択します。
   4. [Metric] で [Snapshot created count] を選択します。
   5. [適用] を選択します。
6. [フィルタを追加] をクリックし、プルダウン メニューを使用して次のフィルタを追加します。

   Filter	コンパレータ	値
   リソースラベル > 環境名	=	スケジュール設定されたスナップショットをモニタリングする環境名。
   ラベルのモニタリング > 結果	=	SUCCEEDED

7. [データの変換] セクションで、次の属性を設定します。
   • [ローリング ウィンドウ] で、このアラートのモニタリング ウィンドウを選択します。この値は、次のステップでしきい値の構成に影響します。

     スケジュールされたスナップショット モニタリングの推奨値: 1 日

   • [ローリング ウィンドウ関数] で [デルタ] を選択します。
8. [Next（次へ）] をクリックします。
9. [Configure alert trigger] ページの設定によって、アラートがトリガーされるタイミングが決まります。次のテーブルの設定を使用して、このページに入力します。
   

   フィールド	値
   Condition type	Threshold
   Alert trigger	Any time series violates
   Threshold position	Below threshold
   Threshold value	アラートの [ローリング ウィンドウ] として構成された時間内に保存されることが予想される、スケジュール設定されたスナップショットの数。 次の式を使用してこの値を計算します。 (rolling window in hours / schedule frequency in hours) - 1 注: 数式で 1 時間を導出すると、さまざまなスナップショット完了時間を考慮することができます。これにより、モニタリング チェック中に最新のスナップショットが実行されている場合、誤検出が発生するのを防ぐことができます。 例: 推奨の1 日のローリング ウィンドウを使用し、スケジュール頻度が 2 時間に 1 回の場合、この値を11 に設定します（計算に従って: 24 / 2 - 1 = 11）。 スケジュールが正しく実行されていれば、24 時間以内に 11 個以上のスナップショットが保存されます。 完了していない場合、スナップショット オペレーションが正常に完了せず、Cloud Monitoring がこのアラートをトリガーします。
   Condition name	条件のカスタム名。

10. [Next（次へ）] をクリックします。
11. （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャンネルを選択し、[OK] をクリックします。
12. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
13. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
14. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
15. [Create Policy] をクリックします。

詳細については、アラート ポリシーをご覧ください。

障害復旧手順をテストする

障害復旧手順を設定したら、その後は必ず定期的にテストしてください。これにより、実際の障害復旧プロセスに影響を与える可能性のある潜在的な問題に対処できます。

コールド DR のシナリオでは、障害復旧手順のテストが完了した後にフェイルオーバー環境を削除できます。

スナップショットの保存操作を確認する

Google Cloud CLI を使用して、スナップショットの保存オペレーションのリストを取得し、スナップショットが障害復旧シナリオに対応できる状態かどうかを確認できます。

この方法は、スナップショットの保存頻度が少なくとも 12 時間に 1 回よりも少ない場合に便利です。スナップショットが頻繁に保存されたことを確認する場合は、Cloud Monitoring アラートを構成することをおすすめします。スケジュールされたスナップショット オペレーションのモニタリングを設定するをご覧ください。

gcloud

特定の環境のスナップショット オペレーションをすべて一覧表示します。コマンドの完全なリファレンスについては、gcloud composer operations list をご覧ください。

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

次のように置き換えます。

• LOCATIONS は、環境が配置されているリージョン識別子のリストで置き換えます
• PROJECT_ID は、環境が配置されているプロジェクトの ID に置き換えます。
• ENVIRONMENT_ID は、スナップショット オペレーションを確認する環境の ID に置き換えます。

例:

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

障害発生後

障害が発生した後に、以下に概説する手順を実行して、プライマリ環境を復元します。

（コールド DR のみ）フェイルオーバー環境を作成する

フェイルオーバー環境を作成するの手順に従います。

プライマリ環境における DAG の実行を停止する

可能であれば、プライマリ環境で DAG の実行を停止します。

• プライマリ環境にまだアクセスできる場合は、すべての DAG を一時停止します。
• プライマリ環境のバケットにアクセスできる場合は、すべての DAG を環境のバケットから、またはプライマリ環境のバケット内の /dags 以外のフォルダに移動します。

スナップショットをフェイルオーバー環境に読み込む

プライマリ環境からフェイルオーバー環境にスナップショットを読み込みます。

スナップショットがフェイルオーバー環境に読み込まれると、スナップショットの作成後にプライマリ環境によって何も実行されなかったかのように、タスクがスケジュール設定され、実行されます。ただし、それらのタスクの一部は、プライマリ環境によってすでに実行されている場合があります。フェイルオーバー環境には、スナップショットを作成してから障害が発生する前にどのタスクが実行されたを認識する手段はありません。その結果、一部のタスクは（プライマリとフェイルオーバーの両方の環境で）2 回実行される可能性があります。すべてのタスクがべき等であること、およびスケジュール設定されたスナップショットを 2 時間ごとに作成することをおすすめします。

（必要に応じて）フェイルオーバー環境の構成を調整する

場合によっては、プライマリ環境のスナップショットを読み込んだ後、フェイルオーバー環境の構成を変更する必要があることがあります。

たとえば、コールド DR のシナリオでは、フェイルオーバー環境で異なる Airflow 環境変数のセットを使用する必要がある場合があります。別の例として、ウォーム DR のシナリオでは、Airflow UI でユーザーに権限を付与して、フェイルオーバー環境にアクセスできるようにする必要がある場合があります。

これらの変更を手動で実行するか、gcloud composer environment update コマンドを実行してフェイルオーバー環境の構成を変更するコマンドでシェル スクリプトを準備します。

プライマリ環境の対応方法を決定する

プライマリ環境に接続できないが、まだ稼働している、または正常に稼働していない場合は、なんらかの障害が発生することがあります。たとえば、インフラストラクチャの障害により、ネットワークを通じてプライマリ環境にアクセスできない。別の例として、環境がなんらかのエラーが発生している、または容量が削減された状態で運用されているが、一部の DAG がまだ実行されている。

元の環境がまだ実行されていると、その後、新しい環境が代わりに作成されたとしても、DAG を通じてアクセスされる Cloud Composer またはその他のサービスに直接関連する費用が発生する場合があります。この環境では、一部の DAG をまだ実行でき、その結果、一部のオペレーションは、まだ実行されているプライマリ環境と、スナップショットの読み込み後のフェイルオーバー環境で 2 回実行される場合があります。

プライマリ環境が存在するが、正常に稼働しない場合

すべての関連データが復元された場合、プライマリ環境を削除できます。たとえば、ネットワーク構成や、/dags フォルダと /plugins フォルダの外部にある環境のバケットの内容など、環境スナップショットに含まれていないデータを復元したいとします。

プライマリ環境が再びアクセス可能で正常な状態になった場合

プライマリ環境が一時的にのみアクセス不能で、再びアクセス可能で正常な状態になった場合は、次の方法を選択できます。

• フェイルオーバー環境を使用し続けます。
• プライマリ環境に戻ります。

フェイルオーバー環境を使用し続けるには:

1. プライマリ環境がまだ DAG を実行している場合は、できるだけ早く それらを一時停止します。
2. すべての関連データが復元されていることを確認してから、プライマリ環境を削除します。
3. フェイルオーバー 環境の DR 準備手順（スケジュール設定されたスナップショットの設定など）を繰り返します。

プライマリ環境に戻るには:

1. フェイルオーバー環境内のすべての DAG を一時停止します。
2. フェイルオーバー環境ですべての DAG 実行が完了するまで待つか、それらを停止します。
3. フェイルオーバー環境のスナップショットを保存します。
4. このスナップショットをプライマリ環境に読み込みます。
5. プライマリ環境で DAG の一時停止を解除します。
6. 必要に応じて、フェイルオーバー環境を削除します。

次のステップ

• スケジュールされたスナップショットを構成する
• 環境を作成する