DevOps 技術: デプロイの自動化

デプロイの自動化とは、ボタンを押すだけでソフトウェアをテストや本番環境にデプロイできるようにすることです。本番環境のリスクを軽減するには、自動化が不可欠です。また、変更後にチームが包括的なテストをできるだけ早く行えるようにして、ソフトウェアの品質について迅速なフィードバックが得られるようにすることも同様に欠かせません。

自動デプロイのプロセスには次のようなインプットがあります。

  • 継続的インテグレーション(CI)プロセスによって作成されたパッケージ。パッケージは本番環境を含むあらゆる環境にデプロイできます。
  • 環境の構成、パッケージのデプロイ、デプロイテスト(スモークテスト)を行うスクリプト。
  • 環境固有の構成情報

スクリプトと構成情報は、バージョン管理システムに保存することをおすすめします。デプロイ プロセスでは、アーティファクト リポジトリ(Container RegistryNexusArtifactory、CI ツールの組み込みリポジトリなど)からパッケージがダウンロードされます。

通常、スクリプトは、次のタスクを実行します。

  1. ターゲット環境を準備します。これは、必要なソフトウェアのインストールと構成を行うか、Google Cloud などのクラウド プロバイダにあらかじめ準備されているイメージから、仮想ホストを起動することによって行います。
  2. パッケージをデプロイします。
  3. データベースの移行スクリプトを実行するなど、デプロイに関連するタスクを実行します。
  4. 必要な構成を行います。
  5. デプロイテストを行い、必要な外部のサービスにアクセスでき、システムが機能していることを確認します。

デプロイ自動化の実装方法

デプロイの自動化を設計する際は、次のベスト プラクティスを採用することをおすすめします。

  • 本番環境を含めすべての環境に、同じデプロイ プロセスを使用します。この原則により、本番環境へのデプロイでそのプロセスを使用する前に、何回もデプロイ プロセスをテストできるようになります。
  • 必要な認証情報があれば、アーティファクトのバージョンにかかわらず、あらゆる環境にオンデマンドかつ完全に自動で、誰でもデプロイできるようにします。チケットを作成して、環境が準備されるのを待つ必要がある場合は、完全に自動化されたデプロイ プロセスとはいえません。
  • すべての環境で同じパッケージを使用します。この原則は、パッケージとは別に、環境固有の構成を持つことを意味します。これにより、本番環境にデプロイするパッケージが、テストしたパッケージと同じものになります。
  • バージョン コントロールに保存されている情報から環境の状態を再現できるようにします。この原則により、デプロイを繰り返し行えるようになり、障害復旧の際に本番環境が確実に復元できます。

自律的に使用できるデプロイ用のツールを持ち、そのツールを使用して、各環境における現行のビルドや、監査用にデプロイ プロセスの出力を記録するのが理想です。CI ツールの多くが、このような機能を備えています。

デプロイの自動化における主な注意点

デプロイ プロセスを自動化する際に発生する問題は、次のとおりです。

  • 既存のプロセスが複雑。
  • サービス間の依存。
  • 自動化を意識して設計されていないコンポーネント。
  • チーム間の協調が不十分。

複雑性

最初の注意点は、複雑性です。複雑で破綻しやすい手動のプロセスを自動化することにより、複雑で破綻しやすい自動化されたプロセスが作り出されます。まず、デプロイが容易になるように再設計する必要があります。これはデプロイ スクリプトを可能な限りシンプルに作り、複雑な部分は、アプリケーション コードやインフラストラクチャ プラットフォームで実現することを意味します。デプロイの失敗のパターンに目を配り、サービス、コンポーネント、インフラストラクチャ プラットフォーム、モニタリングをどのように改善するとその失敗を回避することができたかを考えます。App EngineCloud RunPivotal Cloud Foundry など、クラウド ネイティブの PaaS(Platform-as-a-Service)アプリケーションでは、1 つのコマンドでデプロイできることが多く、他にデプロイ用のスクリプトを必要としていません。デプロイのプロセスは、このような形にするのが理想です。

信頼性の高いデプロイ プロセスには、重要な特性が 2 つあります。まず、デプロイ プロセスの各ステップは、失敗したとき、必要に応じて何度繰り返しても同じ結果が得られるようにします(べき等性)。次に、各ステップは実行順序に依存しないようにします。これは、必要としている他のコンポーネントやサービスが存在しない場合に想定外のクラッシュが起きないようにすることを意味します。代わりに、依存するサービスが利用可能になるまで、縮退した形で動作するようにします。

新しいプロダクトやサービスに対しては、設計の初期段階からこれらの原則を、システム要件として取り扱うことをおすすめします。既存のシステムに自動化を組み込む場合は、これらの特性を実装するか、プロセスが不整合な状態を検出して安全に失敗するようなテレメトリーを組み込む必要があるかもしれません。

依存関係

2 番目の注意点は、多くのデプロイ プロセスが、オーケストレーションを必要としていることです。これは特に企業環境において顕著です。つまり、緊密に同期したデータベースの移行など、他のタスクを実行しながら、複数のサービスを一度に、決まった順序でデプロイする必要があります。このような状況に対応する、多くの企業向けデプロイ ワークフロー ツールがありますが、それらは基本的に構造的な問題に応急処置的な対処(さまざまなコンポーネントやサービスを緊密に結合させる)をするものです。時間が経つと、この緊密な結合に対処する必要が出てきます。目標は、オーケストレーションの必要をなくし、サービスを独立してデプロイできるようにすることです。

この方法には通常、それぞれのサービスが下位互換性を持つようにする慎重な設計が必要です。これにより、サービスのクライアントを決まった手順で更新する必要がなくなり、後で独立に更新できるようになります。これには、API バージョニングなどの手法を利用できます。また、依存するほかのサービスに接続できない場合でも、サービスが動作を続ける(おそらく機能のいくつかは利用できない)ようにすることも重要です。このような設計は、障害の連鎖を防止するため、分散システムに向いています。Michael Nygard 氏の著書『Release It! 本番用ソフトウェア製品の設計とデプロイのために』には、CircuitBreaker(回路ブレーカー)など、分散システムの設計に役立ついくつかのパターンが紹介されています。また、ParallelChange パターンを使用して、データベースの更新を依存するサービスから切り離すこともできます。

自動化向きでない設計

3 番目の注意点は、自動化向けに設計されていないコンポーネントです。コンソールへのロギングと、手動操作であちこちをクリックする必要があるデプロイ プロセスは、改善の対象になります。現在、Google Cloud などのほとんどのプラットフォームでは、ユーザーのデプロイ スクリプトから利用できる API を提供しています。それがない場合は、独自の方法でこのような手作業を避ける必要があります。おそらく、ツールの裏にある構成ファイルやデータベースを見つけて、直接それを変更するか、API のある他のツールで置き換える必要があります。

チーム間の協調が不十分

最後の注意点は、デベロッパーと IT 運用チームの調和がとれていないときに起こります。この問題には、いくつかの形態があります。たとえば、デベロッパーがある手法でデプロイし、IT 運用担当者は異なる手法を使うような場合です。また別の例を挙げると、複数の環境の構成が異なる場合、それが不整合とエラーの原因となり、IT 運用担当者が行う手動のデプロイ プロセスのリスクがかなり引き上げられます。デプロイの自動化プロセスは、デベロッパーと IT 運用担当者の共同作業で作られる必要があります。これにより、どちらのチームもデプロイの自動化を理解、維持し、進化させることができるようになります。

デプロイ自動化の改善方法

最初のステップは、デベロッパーと運用担当者のどちらからも共通に使用できる Google ドキュメントや wiki などのツールで、既存のデプロイ プロセスをドキュメント化することです。続いて、段階的に簡略化を進めながら、デプロイ プロセスを自動化します。この方法は通常、次のタスクで構成されます。

  • デプロイに適した方法でコードをパッケージ化する。
  • 事前構成された仮想マシンまたはコンテナを作成する。
  • ミドルウェアのデプロイと構成を自動化する。
  • 本番環境にパッケージやファイルをコピーする。
  • サーバー、アプリケーション、またはサービスを再起動する。
  • テンプレートから構成ファイルを生成する。
  • 自動化されたデプロイテストを実行して、システムが動作することと正常に構成されることを確認する。
  • テスト手順を実行する。
  • データベース移行のスクリプトを作成し、自動化する。

できる限り手動の手順をなくし、必要に応じてべき等性と命令の独立性を実装して、インフラストラクチャプラットフォームの機能を最大限に活用します。デプロイの自動化はできる限りシンプルにする必要があります。

デプロイ自動化の評価方法

デプロイ自動化の評価は単純です。

  • デプロイ プロセスの手動ステップ数を数えます。このステップ数は、意識して少なくするように努めます。手動のステップ数が増えると、デプロイ時間とエラーの発生が増加します。
  • デプロイ パイプラインの自動化のレベル(または割合)を評価します。このレベルは、継続的に増加させるように努めます。
  • デプロイ パイプライン中の遅延時間を求めます。遅延時間の短縮が進むにつれて、デプロイ パイプライン中のコードが停止する場所と理由がわかります。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...