このドキュメントでは、継続的インテグレーションと継続的デリバリー（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 階層）の依存関係のいずれかに分類されます。
内部依存関係
内部依存関係は、ツールチェーンで使用され、直接制御できるシステムです。内部依存関係もチームによって選択されます。これらのシステムには、CI ツール、鍵管理ストア、ソース管理システムなどが含まれます。これらのシステムは、ツールチェーン自体の次のレイヤにあると考えることができます。
たとえば、次の図は、内部依存関係がツールチェーン内にどのように適合するかを示しています。この図は、Java サンプル アプリケーションの最初のレイヤのツールチェーン図を拡張したもので、ツールチェーンの内部依存関係（アプリケーション認証情報、deploy.yaml ファイル、cloudbuild.yaml ファイル）も示しています。
この図は、Java サンプル アプリケーションで正常に動作するために、Cloud Build、Cloud Deploy、GKE などのツールが cloudbuild.yaml、deploy.yaml、アプリケーション認証情報などのツールチェーン以外の依存関係にアクセスする必要があることを示しています。独自の 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 を定期的にテストしています。このテストは、Google が影響と自動化を確認し、想定外のリスクを明らかにするのに役立ちます。実装が必要な自動化と 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 | ソリューション アーキテクト