このドキュメントでは、継続的インテグレーションと継続的デリバリー（CI/CD）のコンテキストで、障害復旧（DR）と事業継続計画について説明します。また、包括的な事業継続計画（BCP）を策定する際に、依存関係を特定して軽減する方法についてもガイダンスを提供します。このドキュメントには、使用するツールやプロセスに関係なく、BCP に適用できるベスト プラクティスが記載されています。このドキュメントは、ソフトウェア配信と運用サイクル、CI/CD、DR の基本を理解していることを前提としています。
CI/CD パイプラインは、ビジネス クリティカルなアプリケーションの構築とデプロイを担当します。したがって、アプリケーション インフラストラクチャと同様に、CI/CD プロセスでは DR と事業継続の計画が必要です。CI/CD の DR とビジネス継続性を考えるときは、ソフトウェア デリバリーと運用サイクルの各フェーズを理解し、それらが包括的なプロセスとしてどのように連携するかを理解することが重要です。
次の図は、ソフトウェア開発と運用のサイクルの簡略化されたビューです。このサイクルには、次の 3 つのフェーズがあります。
- 開発内部ループ: コード、試行、commit
- 継続的インテグレーション: ビルド、テスト、セキュリティ
- 継続的デリバリー: 昇格、ロールアウト、ロールバック、指標
この図は、Google Kubernetes Engine（GKE）、Cloud Run、Google Distributed Cloud が、ソフトウェア開発と運用サイクルのデプロイ ターゲットとして使用できることも示しています。
ソフトウェア開発と運用のサイクルの全体を通して、業務上重要なアプリケーションを運用および維持するチームの能力に対する障害の影響を考慮する必要があります。これにより、CI/CD ツールチェーン内のツールの目標復旧時間（RTO）と目標復旧時点（RPO）を決定できます。
さらに、ほとんどの組織には、さまざまなアプリケーションとインフラストラクチャ セットに対応する多くの異なる CI/CD パイプラインがあり、各パイプラインには DR と事業継続計画に固有の要件があります。パイプラインに選択する復元戦略は、ツールの RTO と RPO によって異なります。たとえば、一部のパイプラインは他のパイプラインよりも重要度が高く、RTO と RPO の要件が低くなります。BCP でビジネス クリティカルなパイプラインを特定することが重要です。また、復元手順のテストと実行に関するベスト プラクティスを実装する際にも、これらのパイプラインに重点を置く必要があります。
各 CI/CD プロセスとそのツールチェーンは異なるため、このガイドの目的は、CI/CD プロセスの単一障害点を特定し、包括的な BCP を策定することです。以降のセクションでは、次のことを行います。
- CI/CD プロセスに影響する DR イベントから復旧するために必要なことを理解する。
- CI/CD プロセスのツールの RTO と RPO を決定します。
- CI/CD プロセスの障害モードと依存関係を理解する。
- ツールチェーン内のツールに適した復旧戦略を選択します。
- CI/CD プロセスの DR 復旧計画を実装するための一般的なベスト プラクティスを理解する。
ビジネス継続性プロセスを理解する
BCP を構築することは、中断や緊急事態が発生した場合に組織が業務を継続できるようにするために重要です。これにより、組織は CI/CD プロセスの通常のオペレーション状態に迅速に戻すことができます。
以降のセクションでは、効果的な BCP の作成に関連する手順を含む、大まかな段階について説明します。これらのステップの多くはプログラム管理と DR に広く適用されますが、特定のステップは CI/CD プロセスの事業継続計画に関連しています。CI/CD の事業継続計画に特に関連する手順は、次のセクションでハイライト表示されています。また、このドキュメントの残りの部分のガイダンスの基礎も形成しています。
開始と計画
この初期段階では、技術チームとビジネス チームの両方が協力して、事業継続計画プロセスとその継続的なメンテナンスの基盤を確立します。このステージの主なステップは次のとおりです。
- リーダーシップの賛同: 上級管理者が BCP の開発をサポートし、推進していることを確認します。計画の監督を担当する専任チームまたは個人を割り当てます。
- リソースの割り当て: BCP の策定と実装に必要な予算、人員、リソースを割り当てます。
- 範囲と目標: BCP の範囲とその目標を定義します。どのビジネス プロセスが重要で、計画で対処する必要があるかを判断します。
- リスク評価: 自然災害、サイバーセキュリティ侵害、サプライチェーンの中断など、ビジネスを中断する可能性のあるリスクと脅威を特定します。
- 影響分析: これらのリスク評価の結果が、ビジネス運営、財務、評判、顧客満足度に及ぼす潜在的な影響を評価します。
ビジネス インパクト分析
この段階では、ビジネスチームと技術チームが、お客様と組織へのサービス停止の影響を分析し、重要なビジネス機能の復旧に優先順位を付けます。これらのビジネス機能は、ビルド プロセスとデプロイ プロセスのさまざまなフェーズで、さまざまなツールによって実行されます。
ビジネスへの影響分析は、CI/CD のビジネス継続性計画プロセスの重要な段階です。特に、重要なビジネス機能とツールの依存関係を特定する手順が重要です。また、CI/CD プロセスの BCP を開発するための基本的な構成要素として、CI/CD ツールチェーン（その依存関係や DevOps ライフサイクル内での機能など）を理解することが重要です。
ビジネスへの影響の分析段階の主な手順は次のとおりです。
- 重要な機能: 復元のために優先順位を付ける必要がある主要なビジネス機能とプロセスを決定します。たとえば、アプリケーションのデプロイが単体テストの実行よりも重要であると判断した場合は、アプリケーションのデプロイ プロセスとツールの復元を優先します。
- 依存関係: 重要な機能の復元に影響する可能性のある内部および外部の依存関係を特定します。依存関係は、ツールチェーンを通じて CI/CD プロセスの継続的な運用を確保するために特に重要です。
- RTO と RPO: 重要な機能ごとに、許容できるダウンタイムとデータ損失の上限を定義します。これらの RTO と RPO の目標は、継続的な運用におけるビジネス機能の重要性に関連しており、ビジネス機能が円滑に機能するために必要な特定のツールが含まれます。
戦略の策定
この段階では、技術チームが、オペレーションとデータの復元、ベンダーや関係者とのコミュニケーションなど、重要なビジネス機能の復旧戦略を策定します。戦略の開発は、CI/CD プロセスの事業継続計画の重要な部分でもあります。特に、重要な機能の概要的な復旧戦略を選択するステップは重要です。
戦略開発段階の主なステップは次のとおりです。
- 復旧戦略: 重要な機能を復元するための戦略を策定します。これらの戦略には、代替の場所、リモートワーク、バックアップ システムが含まれる場合があります。これらの戦略は、各重要な機能の RTO と RPO の目標に関連付けられています。
- ベンダーとサプライヤーの関係: 主要なベンダーとサプライヤーとのコミュニケーションと調整計画を策定し、中断中にサプライ チェーンを維持します。
- データと IT の復旧: データのバックアップ、IT システムの復旧、サイバーセキュリティ対策の計画を作成します。
- コミュニケーション計画: サービス停止中と停止後に、社内外の関係者向けに明確なコミュニケーション計画を策定します。
計画の策定
この段階の主なステップは、BCP を文書化することです。技術チームは、重要な機能ごとにツール、プロセス、復元戦略、根拠、手順を文書化します。計画の策定には、中断中に従業員が従うべき手順書の作成も含まれます。実装と継続的なメンテナンス中に、プランに変更を加える必要が生じることがあります。この場合、プランは生きたドキュメントとして扱う必要があります。
実装
このステージでは、技術チームが作成した BCP を使用して、組織の計画を実装します。実装には、従業員のトレーニングと BCP の初期テストが含まれます。実装には、中断が発生した場合に通常の運用を回復するために計画を使用することも含まれます。主な実装手順は次のとおりです。
- 初期テストとトレーニング: BPC を文書化したら、シミュレーションと演習でテストしてギャップを特定し、有効性を高めます。サービス停止中の役割と責任について従業員にトレーニングします。
- 有効化: サービス中断が発生した場合は、事前定義されたトリガーと手順に従って BCP を開始します。
- コミュニケーション: 状況と復旧作業について関係者に情報を提供します。
メンテナンスと確認
このステージは、1 回だけ発生する定義済みのプロセスではありません。代わりに、CI/CD 運用の通常の一部となる継続的な取り組みを表します。中断が発生した場合に関連性と実行可能性を維持できるように、組織内の BCP を定期的に確認、テスト、更新することが重要です。メンテナンスと確認の主なステップは次のとおりです。
- 定期的な更新: BCP が最新かつ有効な状態を保つように、定期的に確認して更新します。人員、技術、ビジネス プロセスに変更があるたびに更新します。
- 教訓: 中断やテストのたびに、デブリーフィングを実施して教訓と改善点を特定します。
- 規制遵守: BCP を業界の規制と標準に準拠させます。
- 社員への周知: BCP とその実行における社員の役割について、継続的に社員に教育します。
CI/CD のビジネス継続プロセスを構築する
このセクションでは、CI/CD オペレーションの復元に特化した BCP を作成する際の具体的なガイドラインについて説明します。CI/CD のビジネス継続性を計画するプロセスは、CI/CD ツールチェーンと、それがソフトウェア デリバリーと運用のライフサイクルにどのように関連しているかを十分に理解することから始まります。この理解を基盤として、組織が中断から CI/CD オペレーションを復元する方法を計画できます。
CI/CD プロセスの堅牢なビジネス継続性プロセスを構築するには、次の主な手順を行う必要があります。
- ツールチェーンについて
- データと依存関係を特定する
- RTO と RPO の目標を決定する
- ビジネスの継続性に関する大まかな戦略を選択する
- BCP を文書化し、ベスト プラクティスを実装する
- 障害のシナリオをテストし、計画を維持する
以降のセクションでは、これらの各ステップについて詳しく説明します。
ツールチェーンを理解する
CI/CD ツールチェーンは、さまざまな個別のツールで構成されており、ツールの組み合わせは無限に存在します。ただし、CI/CD のツールチェーンとその依存関係を理解することは、CI/CD の事業継続計画の鍵となります。CI/CD プロセスのコア ミッションは、エンドユーザーが使用できるように本番環境システムにコードを配信することです。このプロセスでは、さまざまなシステムとデータソースが使用されます。これらのデータソースと依存関係を把握することは、BCP の策定に不可欠です。DR 戦略の作成を開始するには、まず CI/CD プロセスに関連するさまざまなツールを理解する必要があります。
このドキュメントでは、独自のツールチェーンを評価して BCP を開発する方法について説明するために、GKE で実行されるエンタープライズ Java アプリケーションの例を使用します。次の図は、ツールチェーン内のデータとシステムの最初のレイヤを示しています。この最初のレイヤは直接管理でき、次のものがあります。
- アプリケーションのソース
- CI/CD プラットフォームのツール（Cloud Build や Cloud Deploy など）
- さまざまなツールの基本的な相互接続
図に示すように、サンプル アプリケーションの主なフローは次のとおりです。
- 開発内部ループのコード開発イベントが Cloud Build をトリガーします。
- Cloud Build は、ソース管理リポジトリからアプリケーションのソースコードを pull します。
- Cloud Build は、Artifact Registry の Java リポジトリのサードパーティ JAR ファイルなど、ビルド構成ファイルで指定されている必要な依存関係を特定します。Cloud Build は、これらの依存関係をソースの場所から pull します。
- Cloud Build はビルドを実行し、静的分析や単体テストなどの必要な検証を行います。
- ビルドが成功すると、Cloud Build はコンテナ イメージを作成し、Artifact Registry のコンテナ リポジトリに push します。
- Cloud Deploy パイプラインがトリガーされ、パイプラインはリポジトリからコンテナ イメージを pull して、GKE 環境にデプロイします。
CI/CD プロセスで使用されるツールを把握するには、このドキュメントの例に似た、CI/CD プロセスとそのプロセスで使用されるツールを示す図を作成することをおすすめします。次に、この図を使用して、プロセスのフェーズ、ツールの目的、ツール自体、ツールの障害の影響を受けるチームなど、CI/CD ツールチェーンに関する重要な情報をキャプチャする表を作成できます。次の表に、ツールチェーン内のツールのマッピングを示します。また、CI/CD プロセスの特定のフェーズで使用されるツールも示します。この表は、ツールチェーンとその動作を総合的に把握するのに役立ちます。
次の表に、前述のエンタープライズ アプリケーションの例を図の各ツールにマッピングします。ツールチェーン マッピングの例をより完全なものにするため、これらの表には、セキュリティ ツールやテストツールなど、図に記載されていない他のツールも含まれています。
最初の表は、CI/CD プロセスの CI フェーズで使用されるツールを示しています。
| 継続的インテグレーション | 送信元 | 使用するツール | 主なユーザー | 用途 |
|---|---|---|---|---|
| フェーズ: ソース管理 |
|
|
|
|
| フェーズ: ビルド |
|
デベロッパー |
|
|
| フェーズ: テスト |
|
デベロッパー |
一貫性のあるオンデマンド プラットフォームで単体テストと統合テストを実行します。 |
|
| フェーズ: セキュリティ |
|
|
コードをスキャンしてセキュリティ上の問題がないか確認します。 |
2 つ目の表では、CI/CD プロセスの CD フェーズで使用されるツールに焦点を当てています。
| 継続的デプロイ | 送信元 | 使用するツール | 主なユーザー | 用途 |
|---|---|---|---|---|
| フェーズ: デプロイ | デプロイ構成ファイル |
|
デプロイを自動化し、安全で一貫性のあるプラットフォームでトラフィックを昇格、承認、管理します。 |
|
| フェーズ: テスト |
|
|
デベロッパー |
品質とユーザビリティを確認するために、統合とパフォーマンスをテストします。 |
| フェーズ: ロギング |
|
|
オブザーバビリティとトラブルシューティングのためにログを保持します。 |
|
| フェーズ: モニタリング | 構成ファイルのモニタリング（以下を含む）:
|
|
|
BCP の作業を進め、CI/CD ツールチェーンに対する理解が深まってきたら、図とマッピング表を更新できます。
データと依存関係を特定する
ベース インベントリと CI/CD ツールチェーンのマップを作成したら、次はメタデータまたは構成の依存関係をキャプチャします。BCP を実装する際は、CI/CD ツールチェーン内の依存関係を明確に理解することが重要です。依存関係は通常、内部（第 1 階層）依存関係と外部（第 2 階層または第 3 階層）依存関係の 2 つのカテゴリのいずれかに分類されます。
内部依存関係
内部依存関係は、ツールチェーンで使用され、直接制御できるシステムです。内部依存関係もチームによって選択されます。これらのシステムには、CI ツール、鍵管理ストア、ソース管理システムが含まれます。これらのシステムは、ツールチェーン自体の次のレイヤにあると考えることができます。
たとえば、次の図は、内部依存関係が toolchain 内にどのように適合するかを示しています。この図は、サンプル Java アプリケーションの最初のレイヤのツールチェーン図を拡張したもので、ツールチェーンの内部依存関係（アプリケーション認証情報、deploy.yaml ファイル、cloudbuild.yaml ファイル）も示しています。
この図は、サンプルの Java アプリケーションで正常に動作するには、Cloud Build、Cloud Deploy、GKE などのツールが、cloudbuild.yaml、deploy.yaml、アプリケーション認証情報などの toolchain 以外の依存関係にアクセスする必要があることを示しています。独自の CI/CD ツールチェーンを分析する際は、ツールを単独で実行できるかどうか、または別のリソースを呼び出す必要があるかどうかを評価します。
サンプル Java アプリケーションの内部依存関係について考えてみましょう。認証情報は Secret Manager に保存されます。これはツールチェーンの一部ではありませんが、デプロイ時にアプリケーションを起動するには認証情報が必要です。したがって、アプリケーション認証情報は GKE の依存関係として含まれます。また、deploy.yaml ファイルと cloudbuild.yaml ファイルは、アプリケーション コードとともにソース コントロールに保存されている場合でも、そのアプリケーションの CI/CD パイプラインを定義するため、依存関係として含めることも重要です。
サンプル Java アプリケーションの BCP では、deploy.yaml ファイルと cloudbuild.yaml ファイルに対するこれらの依存関係を考慮する必要があります。これは、復元プロセス中にツールが配置された後に CI/CD パイプラインを再作成するためです。また、これらの依存関係が侵害されると、ツール自体がまだ動作していても、パイプラインの全体的な機能に影響します。
外部依存関係
外部依存関係とは、ツールチェーンが動作するために依存する外部システムであり、直接制御することはできません。外部依存関係は、選択したツールとプログラミング フレームワークから生じます。外部依存関係は、内部依存関係の下位レイヤにあると考えることができます。外部依存関係の例としては、npm リポジトリや Maven リポジトリ、モニタリング サービスなどがあります。
外部依存関係は管理の範囲外ですが、BCP に組み込むことができます。次の図は、内部の依存関係に加えて外部の依存関係（Maven Central の Java ライブラリと Docker Hub の Docker イメージ）を含めて、サンプル Java アプリケーションを更新しています。Java ライブラリは Artifact Registry で使用され、Docker イメージは Cloud Build で使用されます。
この図は、外部依存関係が CI/CD プロセスにとって重要であることを示しています。Cloud Build と GKE の両方が、2 つの外部サービス（Maven と Docker）に依存して正常に機能します。独自のツールチェーンを評価する場合は、ツールがアクセスする必要がある外部依存関係と、依存関係の停止を処理する手順の両方を文書化します。
サンプルの Java アプリケーションでは、Java ライブラリと Docker イメージを直接制御することはできませんが、それらのイメージとその復元手順を BCP に含めることができます。たとえば、Maven の Java ライブラリについて考えてみましょう。ライブラリは外部ソースに保存されますが、Java ライブラリをローカル Maven リポジトリまたは Artifact Registry に定期的にダウンロードして更新するプロセスを設定できます。これにより、復元プロセスでサードパーティ ソースの可用性に依存する必要がなくなります。
また、外部依存関係には複数のレイヤがある可能性があることも重要です。たとえば、内部依存関係で使用されるシステムは、第 2 階層の依存関係と見なすことができます。これらの第 2 階層の依存関係には、第 3 階層の依存関係と考えられる独自の依存関係がある場合があります。中断中にオペレーションを復旧するには、BCP で第 2 次および第 3 次の外部依存関係の両方を文書化して考慮する必要があります。
RTO と RPO の目標を決める
ツールチェーンと依存関係を理解したら、ツールの RTO と RPO の目標を定義します。CI/CD プロセスのツールはそれぞれ異なるアクションを実行し、ビジネスに異なる影響を与える可能性があります。そのため、ビジネス機能の RTO と RPO の目標の優先度を、ビジネスへの影響に合わせて設定することが重要です。たとえば、CI ステージで新しいバージョンのアプリケーションをビルドする方が、CD ステージでアプリケーションをデプロイするよりも影響が少ない場合があります。したがって、デプロイ ツールの RTO と RPO の目標は、他の機能よりも長くなる可能性があります。
次の 4 つの四分割チャートは、CI/CD ツールチェーンの各コンポーネントの RTO と RPO の目標を決定する方法の一般的な例です。このチャートには、IaC パイプラインやテストデータソースなどのツールがマッピングされています。これらのツールは、Java アプリケーションの前の図では説明されていませんが、より完全な例を提供するためにここに示します。
このグラフは、デベロッパーとオペレーションへの影響レベルに基づく四分割を示しています。グラフでは、コンポーネントは次のように配置されます。
- デベロッパーへの影響は中程度、運用への影響は低い: テスト用データソース
- デベロッパーへの影響が中程度、運用への影響が中程度: Cloud Key Management Service、Cloud KMS
- デベロッパーへの影響は中程度、運用への影響は大きい: デプロイ パイプライン
- デベロッパーへの影響が大きく、運用への影響が低い: デベロッパー内部ループ
- デベロッパーへの影響が大きい、オペレーションへの影響が中程度: CI パイプライン、Infrastructure as Code（IaC）パイプライン
- デベロッパーへの影響とオペレーションへの影響が高い: ソース コントロール管理（SCM）、Artifact Registry
ソース コントロール管理や Artifact Registry などのコンポーネントは、デベロッパーと運用への影響が大きく、ビジネスに最も大きな影響を与えます。これらのコンポーネントには、RTO と RPO の目標を最も低く設定する必要があります。他の四分割領域のコンポーネントは優先度が低く、RTO と RPO の目標値が高くなります。一般に、ツールチェーン コンポーネントの RTO と RPO の目標は、そのコンポーネントのサービス復元にかかる時間と比較して許容できるデータまたは構成の損失の量に応じて設定する必要があります。
たとえば、グラフの Artifact Registry と IaC パイプラインの異なるロケーションについて考えてみましょう。これらの 2 つのツールを比較すると、Artifact Registry の停止は IaC パイプラインの停止よりもビジネス運用に大きな影響を与えることがわかります。Artifact Registry の停止は、アプリケーションのデプロイや自動スケーリングに大きな影響を与えるため、他のツールと比較して RTO と RPO の目標値が低いことになります。一方、グラフは、IaC パイプラインの停止が他のツールよりもビジネス運用に与える影響が小さいことを示しています。停止中に他の方法でインフラストラクチャをデプロイまたは更新できるため、IaC パイプラインの RTO と RPO の目標は高くなります。
事業継続のための大まかな戦略を選択する
本番環境アプリケーションのビジネス継続性プロセスでは、多くの場合、3 つの一般的な DR 戦略のいずれかを使用します。ただし、CI/CD では、ビジネス継続性のための 2 つの大まかな戦略（アクティブ/パッシブまたはバックアップ/復元）から選択できます。選択する戦略は、要件と予算によって異なります。各戦略には複雑さとコストのトレードオフがあり、CI/CD プロセスにはさまざまな考慮事項があります。以降のセクションでは、各戦略とそのトレードオフについて詳しく説明します。
また、サービスが中断される事態が発生すると、CI/CD 実装よりも大きな影響を受ける可能性があります。また、ネットワーク、コンピューティング、ストレージなど、必要なすべてのインフラストラクチャも検討する必要があります。これらのビルディング ブロックの DR 計画を作成し、効果を確認するために定期的にテストする必要があります。
アクティブ / パッシブ
アクティブ/パッシブ（またはウォーム スタンバイ）戦略では、アプリケーションとパッシブ CI/CD パイプラインはミラーリングされます。ただし、パッシブ パイプラインは実際にはお客様のワークロードやビルドやデプロイを処理していないため、スケールダウンされた状態になっています。この戦略は、少量のダウンタイムを許容できるビジネス クリティカルなアプリケーションに最適です。
次の図は、このドキュメントで使用する Java アプリケーションのアクティブ/パッシブ構成を示しています。パッシブ パイプラインは、別のリージョンのアプリケーション ツールチェーンを完全に複製します。
この例では、region1 がアクティブな CI/CD パイプラインをホストし、region2 にパッシブなパイプラインがあります。コードは、GitHub や GitLab などの外部 Git サービス プロバイダでホストされます。リポジトリ イベント（pull リクエストからのマージなど）により、region1 の CI/CD パイプラインがトリガーされ、マルチリージョン本番環境にビルド、テスト、デプロイされます。
プロダクトのリージョン停止など、region1 パイプラインの重大な問題が発生すると、デプロイやビルドが失敗する可能性があります。問題から迅速に復旧するには、Git リポジトリのトリガーを更新して region2 パイプラインに切り替えます。これにより、このパイプラインがアクティブになります。region1 で問題が解決したら、region1 のパイプラインをパッシブのままにできます。
アクティブ/パッシブ戦略のメリットは次のとおりです。
- ダウンタイムが短い: パッシブ パイプラインはデプロイされていますがスケールダウンされているため、ダウンタイムはパイプラインのスケールアップに必要な時間に制限されます。
- データ損失に対する構成可能な許容度: この戦略では、構成とアーティファクトを定期的に同期する必要があります。ただし、量は要件に基づいて構成できるため、複雑さを軽減できます。
この戦略のデメリットは次のとおりです。
- 費用: インフラストラクチャが重複するため、この戦略では CI/CD インフラストラクチャの全体的な費用が増加します。
バックアップ / 復元
バックアップ/復元戦略では、インシデント復旧時に必要な場合にのみフェイルオーバー パイプラインを作成します。この戦略は、優先度の低いユースケースに最も適しています。次の図は、サンプル Java アプリケーションのバックアップと復元の構成を示しています。バックアップ構成では、アプリケーションの CI/CD パイプラインの一部のみが別のリージョンに複製されます。
前の例と同様に、region1 はアクティブな CI/CD パイプラインをホストします。region2 には、パッシブ パイプラインではなく、Maven パッケージやコンテナ イメージなど、必要なリージョン データのバックアップのみがあります。ソース リポジトリを region1 でホストする場合は、DR ロケーションにもデータを同期する必要があります。
同様に、リージョン プロダクトの停止など、region1 パイプラインで重大な問題が発生した場合は、region2 で CI/CD 実装を復元できます。インフラストラクチャ コードがインフラストラクチャ コード リポジトリに保存されている場合は、リポジトリから自動化スクリプトを実行し、region2 で CI/CD パイプラインを再ビルドできます。
停止が大規模なイベントである場合、クラウド リソースを他のお客様と競合する可能性があります。この状況を軽減する方法の一つとして、DR ロケーションに複数のオプションを用意することが挙げられます。たとえば、region1 パイプラインが us-east1 にある場合、フェイルオーバー リージョンは us-east4、us-central1、us-west1 のいずれかになります。
バックアップと復元の戦略の利点は次のとおりです。
- 費用: この戦略では、DR シナリオでのみバックアップ パイプラインをデプロイするため、費用が最も低くなります。
この戦略のデメリットは次のとおりです。
- ダウンタイム: この戦略では、フェイルオーバー パイプラインは必要に応じて作成するため、実装に時間がかかります。事前構築されたパイプラインを使用する代わりに、インシデント復旧中にサービスを作成して構成する必要があります。アーティファクトのビルド時間と外部依存関係の取得時間も大幅に長くなる可能性があります。
BCP を文書化し、ベスト プラクティスを実装する
CI/CD ツールチェーンをマッピングし、その依存関係を特定し、重要な機能の RTO と RPO の目標を決定したら、次は、関連するすべての情報を書面による BCP に記録します。BCP を作成するときに、各重要な機能を復元するための戦略、プロセス、手順を文書化します。このドキュメント化プロセスには、中断中に特定の役割の社員が従う手順を記述することが含まれます。
BCP を定義したら、ベスト プラクティスを使用して CI/CD ツールチェーンをデプロイまたは更新し、RTO と RPO の目標を達成します。CI/CD ツールチェーンは大きく異なる場合がありますが、ツールチェーンに関係なく、ベスト プラクティスの 2 つの重要なパターンが共通しています。それは、依存関係の包括的な理解と自動化の実装です。
依存関係に関しては、ほとんどの BCP は管理対象のシステムに直接対処します。ただし、第 2 次または第 3 次の外部依存関係も同様に影響を受ける可能性があるため、これらの重要な依存関係にもベスト プラクティスと冗長性対策を実装することが重要です。サンプル アプリケーションの外部 Java ライブラリは、第 3 次の依存関係の例です。これらのライブラリのローカル リポジトリまたはバックアップがない場合は、ライブラリを pull する外部ソースが切断されていると、アプリケーションをビルドできないことがあります。
自動化に関しては、ベスト プラクティスの実装を全体的な クラウド IaC 戦略に組み込む必要があります。IaC ソリューションでは、Terraform などのツールを使用して、CI/CD 実装に必要なリソースを自動的にプロビジョニングし、プロセスを構成する必要があります。IaC 手法は、CI/CD パイプラインの日常的な機能に組み込まれているため、非常に効果的な復旧手順です。また、IaC は、ソース管理での構成ファイルの保存を促進します。これにより、バックアップのベスト プラクティスの導入が促進されます。
BCP と依存関係と自動化のベスト プラクティスに従ってツールチェーンを実装した後、CI/CD プロセスと復元戦略が変更される場合があります。BCP のレビューとベスト プラクティスの実装に伴う復旧戦略、プロセス、手順の変更は必ず記録してください。
障害シナリオをテストして計画を維持する
BCP を定期的に確認、テスト、更新することが重要です。BCP と復旧手順をテストすることで、計画が引き続き有効であり、文書化された RPO と RTO の目標が許容されることを確認します。ただし、最も重要なのは、定期的なテスト、更新、メンテナンスにより、BCP の実行が通常の運用の一部になることです。 Google Cloudを使用すると、最小限の費用で復旧シナリオをテストできます。テストに役立つよう、以下を行うことをおすすめします。
- IaC ツールでインフラストラクチャのプロビジョニングを自動化する: Terraform などのツールを使用して、CI/CD インフラストラクチャのプロビジョニングを自動化できます。
- Cloud Logging と Cloud Monitoring によるテストのモニタリングとデバッグ: Google Cloud Observability には、API 呼び出しでアクセスできるロギングとモニタリング ツールが用意されています。これにより、指標に反応して復旧シナリオのデプロイを自動化できます。テストを設計する際は、適切なモニタリング機能とアラート機能を用意して、状況に応じた復旧アクションがトリガーされるようにしてください。
- BCP でテストを実施する: たとえば、DR 環境で権限とユーザーのアクセス権が本番環境と同様に機能するかどうかをテストできます。DR 環境で統合テストと機能テストを実施できます。 Google Cloud への通常のアクセスパスが機能しないテストを実施することもできます。
Google では、DiRT（障害復旧テスト）と呼ばれるプロセスで BCP を定期的にテストしています。このテストは、影響と自動化を確認して、考慮されていないリスクを明らかにするのに役立ちます。実装が必要な自動化と BCP の変更は、DiRT の重要な出力です。
ベスト プラクティス
このセクションでは、RTO と RPO の目標を達成するために実装できるベスト プラクティスについて説明します。これらのベスト プラクティスは、特定のツールではなく、CI/CD の DR に広く適用されます。実装に関係なく、高可用性、RTO、RPO が要件を満たしていることを確認するために、BCP を定期的にテストする必要があります。インシデントや障害が発生した場合は、事後分析を行い、プロセスを分析して改善する必要があります。
高可用性
ツールごとに、高可用性のベスト プラクティスを実装する必要があります。高可用性のベスト プラクティスに従うと、CI/CD プロセスが障害に対してより耐障害性を持つため、CI/CD プロセスがよりプロアクティブなスタンスになります。これらの事前対応型の戦略は、復元とバックアップの両方に対して、より事後対応型の制御と手順とともに使用する必要があります。
高可用性を実現するためのベスト プラクティスをいくつかご紹介します。ただし、詳細なベスト プラクティスについては、CI/CD の各ツールの詳細なドキュメントをご覧ください。
- マネージド サービス: マネージド サービスを使用すると、運用上の責任が Google Cloudに移行されます。
- 自動スケーリング: 可能な場合は自動スケーリングを使用します。自動スケーリングの重要な点は、ワーカー インスタンスが動的に作成されるため、障害が発生したノードの復元が自動的に行われることです。
- グローバル デプロイとマルチリージョン デプロイ: 可能であれば、リージョン デプロイではなく、グローバル デプロイとマルチリージョン デプロイを使用します。たとえば、マルチリージョン ストレージ用に Artifact Registry を構成できます。
- 依存関係: ツールのすべての依存関係を把握し、それらの依存関係が高可用性であることを確認します。たとえば、Artifact Registry にすべてのサードパーティ ライブラリをキャッシュに保存できます。
バックアップ手順
CI/CD にDR を実装する場合、一部のツールとプロセスはバックアップ/復元戦略に適しています。包括的なバックアップ戦略は、効果的な事後対応管理への第一歩です。バックアップを使用すると、不正な行為者や障害が発生した場合に、中断を最小限に抑えて CI/CD パイプラインを復元できます。
まず、次の 3 つのベスト プラクティスを実装する必要があります。ただし、バックアップの詳細なベスト プラクティスについては、CI/CD プロセスの各ツールのドキュメントをご覧ください。
- ソース管理: 構成ファイルと、自動化スクリプトやポリシーなど、コード化されたものをソース管理に保存します。例:
cloudbuild.yaml、Kubernetes YAML ファイル。 - 冗長性: パスワード、証明書、API キーなどのシークレットへのアクセスに関して単一障害点がないようにします。避けるべき方法の例としては、パスワードを 1 人のみが知っていることや、特定のリージョンの 1 台のサーバーにのみ API キーを保存することなどがあります。
- バックアップ: バックアップの完全性と正確性を頻繁に検証します。Backup for GKE などのマネージド サービスを使用すると、検証プロセスを簡素化できます。
復旧手順
DR では、バックアップ プロセスを補完する復元手順も必要です。障害シナリオに迅速に対応できるかどうかは、完全なバックアップと組み合わせた復元手順によって決まります。
依存関係の管理
CI/CD パイプラインには多くの依存関係があり、これが障害の原因となることもあります。依存関係の完全なリストは、このドキュメントのデータと依存関係を特定するで説明されているように特定する必要があります。ただし、依存関係の最も一般的な 2 つのソースは次のとおりです。
- アプリケーション アーティファクト: パッケージ、ライブラリ、イメージなど
- 外部システム: チケット発行システムや通知システムなど
依存関係のリスクを軽減する方法の一つは、ベンダーリングのプラクティスを採用することです。アプリケーション パッケージまたはイメージのベンダー化は、それらのコピーを作成して限定公開リポジトリに保存するプロセスです。ベンダーリングにより、これらのパッケージやイメージの外部ソースへの依存関係が解消され、ソフトウェアのサプライ チェーンにマルウェアが挿入されるのを防ぐこともできます。
アプリケーション パッケージまたはイメージをベンダー化すると、次のようなメリットがあります。
- セキュリティ: ベンダーリングにより、アプリケーション パッケージやイメージの外部ソースへの依存関係が解消されるため、マルウェア挿入攻撃を防ぐことができます。
- 制御: 独自のパッケージまたはイメージをベンダー化することで、組織はこれらのパッケージとイメージのソースをより細かく制御できます。
- コンプライアンス: ベンダーリングは、サイバーセキュリティ成熟度モデル認定などの業界規制への準拠を支援します。
チームがアプリケーション パッケージまたはイメージをベンダーに委託する場合は、次の主な手順に沿って対応します。
- ベンダーに提供する必要のあるアプリケーション パッケージまたはイメージを特定します。
- ベンダー提供のパッケージまたはイメージを保存するプライベート リポジトリを作成します。
- 元のソースからパッケージまたはイメージをダウンロードし、プライベート リポジトリに保存します。
- パッケージまたはイメージの完全性を確認します。
- 必要に応じて、ベンダー提供のパッケージまたはイメージを更新します。
CI/CD パイプラインでは、スキャンの実行、チケットのロギング、通知の送信などのアクションを実行するために、外部システムを呼び出すことがよくあります。ほとんどの場合、これらのサードパーティ システムには、実装する独自の DR 戦略があります。ただし、適切な DR 計画がない場合があります。そのような場合は、BCP に明記する必要があります。次に、可用性の理由でパイプラインのこれらのステージをスキップできるかどうか、または CI/CD パイプラインのダウンタイムが発生しても問題ないかどうかを判断する必要があります。
モニタリングと通知
CI/CD はアプリケーションの本番環境システムと同じであるため、CI/CD ツールのモニタリングと通知手法も実装する必要があります。ベスト プラクティスとして、ダッシュボードとアラート通知を実装することをおすすめします。Cloud Monitoring の GitHub サンプル リポジトリには、ダッシュボードとアラート ポリシーの例が多数あります。
サービスレベル指標（SLI）やサービスレベル目標（SLO）など、追加のモニタリング レベルを実装することもできます。これらのモニタリング レベルは、CI/CD パイプラインの全体的な健全性とパフォーマンスを追跡するのに役立ちます。たとえば、ビルド ステージとデプロイ ステージのレイテンシを追跡するように SLO を実装できます。これらの SLO は、チームが希望するレートと頻度でアプリケーションを構築してリリースするのに役立ちます。
緊急アクセス手順
災害発生時には、オペレーション チームが標準手順以外の対応をとったり、システムやツールに緊急アクセスしたりすることが必要になる場合があります。このような緊急対応は、緊急手順と呼ばれることもあります。まず、次の 3 つのベスト プラクティスを実装する必要があります。
- 明確なエスカレーション計画と手順を用意する。明確な計画があると、オペレーション チームは緊急アクセス手順を使用する必要があるタイミングを把握できます。
- 構成やシークレットなどの重要な情報に複数のユーザーがアクセスできるようにします。
- 緊急アクセス手順が使用された日時と使用者をトラッキングできるように、自動監査方法を開発します。
次のステップ
- このドキュメントで使用されている Google Cloud プロダクトの詳細を確認する。
- 障害復旧計画ガイドをご覧ください。
- チュートリアルを完了して、他の Google Cloud 機能を試す。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Ben Good | ソリューション アーキテクト
- Xiang Shen | ソリューション アーキテクト
その他の寄稿者:
- Marco Ferrari | クラウド ソリューション アーキテクト
- Anuradha Bajpai | ソリューション アーキテクト
- Rodd Zurcher | ソリューション アーキテクト