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

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

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

定義

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

• 障害とは、環境のオペレーションに必要な 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 以降のバージョンでサポートされています。

• スナップショットを作成するには、Airflow データベースのデータが 20 GB 未満である必要があります。

• スナップショットを作成するには、環境のバケット内の /dags、/plugins、/data フォルダ内のオブジェクトの合計数が 100,000 未満にする必要があります。

• XCom メカニズムを使用してファイルを転送する場合は、Airflow のガイドラインに従って使用するようにしてください。XCom を使用して大きなファイルや大量のファイルを転送すると、Airflow データベースのパフォーマンスに影響し、スナップショットの読み込みや環境のアップグレード時に障害が発生する可能性があります。大量のデータを転送するには、Cloud Storage などの代替手段の使用を検討してください。

準備の概要

どちらの 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 のメンテナンスを設定する

データベースのクリーンアップを設定して、Airflow データベースを小さくしてサイズの上限内に保ちます。これにより、スナップショットの保存と読み込みのプロセスが高速化されます。スナップショットを作成するには、Airflow データベースのデータが 20 GB 未満である必要があります。

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

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

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

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

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

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. リソースの種類に、[Cloud Composer 環境] を選択します。
   3. 指標カテゴリに、[環境] を選択します。
   4. 指標に [Snapshot creation count] を選択します。
   5. [適用] を選択します。
6. [フィルタを追加] をクリックし、プルダウン メニューを使用して次のフィルタを追加します。

   Filter	コンパレータ	値
   [リソースのラベル] > [environment_name]	=	スケジュールされたスナップショットをモニタリングする環境の名前。
   [Monitor label] > [result]	=	SUCCEEDED

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

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

   • ローリング ウィンドウ関数に [デルタ] を選択します。
8. [次へ] をクリックします。
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 は、環境が配置されているリージョン ID のリストに置き換えます
• 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. 必要に応じて、フェイルオーバー環境を削除します。

次のステップ

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