DevOpsのデプロイであたふたしない鉄則

クラウド時代が到来するまでは、システムは垂直統合型であり、開発手法はウォーターフォール型が一般的でした。コードの作成は、他とは切り離された管理が行き届く環境で行われていました。コードはあらかじめ定義した動作環境にデプロイされ、本番稼働開始後はオペレーションチームがその影響範囲を追跡できました。多くの制約がある一方で、新たなコードの影響を容易に把握でき、想定通りに動作しない場合にどこに不良があり、どう対処したらよいかすぐに特定することができました。

発達を続けるクラウド環境やDevOpsが一般的になった現在、コードのデプロイ先は、過去のような「モノリス（一体）」型システムへではなく、ある特定のマイクロサービスとなります。デプロイ先のマイクロサービスは、オートスケール型の、数十あるいは数百ものコンテナやホストの集合体にデプロイされ、やはり数十もの上位サービスに影響するかもしれません。こうした開発手法は、機能性、パフォーマンス、運用コストを改善しますが、より複雑に絡み合っていることも事実で、ミスを招く全般的なリスクは高まります。

この流動的な環境に対応するため、新世代のデプロイ戦略が生まれました。イノベーションが急速に進む中で、最新ソフトウェアに支えられた多くの企業にとって、新たなデプロイ戦略は、今や「あったらいい」ものではなく、「なくてはならない」ものとなりつつあるのです。ソフトウェアエンジニアリングチームが、確信を持ってこの新たな世界に足を踏み入れ、リスクを抑制しつつメリットを享受するにはどうすべきなのでしょうか。

スピードとスケールを可能にする新世代デプロイ戦略

新しいデプロイ戦略群はそれぞれ異なる特徴を持っていますが、分散し、動的に変化し、相互に連携するクラウド上のソフトウェア開発に適用するという点は同じであり、時間をかけながらアプリケーションを継続的に改善していくことが可能です。

主な新世代のデプロイ戦略には次のようなものがあります。

●段階的なデプロイメント：例えば最初は少数のコンテナにだけデプロイする等、コードのデプロイ範囲を徐々に広げ、全体にデプロイする前に不良が発生しないかを検証する手法

• 

  deployment-tracking-dashboard」

●カナリアデプロイ：コードを「炭鉱のカナリア」として特定のインスタンスにデプロイすることで、同じようなインスタンスを増やした場合に不良が起きないか検証していく手法

●ブルー／グリーンデプロイ：既存のコードをバックグラウンドで稼働させつつ新しいコードを同時にデプロイし、問題が発生した場合に備え既存のコードをバックアップとして確保しておく手法

• 

  deployment-tracking（ブルー／グリーンデプロイ」

●Ａ／Ｂデプロイ：2種類の新しいデプロイを同時に稼働させ、それぞれのパフォーマンスを比較する手法

いずれの戦略も、新たなデプロイを分析し、必要であればロールバックすることができるため、新しいアプリケーションや機能をより迅速にデプロイすることができます。対象を絞ったインフラへ短時間にデプロイできるため、想定外の問題による影響を最低限に抑え、問題を特定、解決し、すみやかに再デプロイして、コードを改善していくことができます。

単純そうですが、言うは易く行うは難しです。複数のチーム、場合によっては技術者一人一人が様々なサービスを並行してデプロイできるため、すべてを追跡することが難しくなります。

では、実際にどのように活用されるのか、例を見ていきます。

ブルー／グリーンデプロイの活用例

ブルー／グリーンデプロイにより、アプリケーションのクリティカルなアップデートを行うと仮定します。既存のコードを中断なく稼働させつつ、新しいコードを分離したコンテナにデプロイし、その後トラフィックを新コードに移行していきます。担当のDevOpsまたはSRE（site reliability engineering）チームが状況をモニタリングし、さまざまな条件下でのコードのパフォーマンスをテストして、必要であればバックアップしていた既存コードに戻します。新コードのパフォーマンス、エラー、機能性を完全に検証できた段階で、既存コードを廃止するか今後のデプロイのために切り離します。

過去のデプロイ戦略では、単独のデプロイに対し一定期間内のデータを参照するだけでよかったのですが、上述のブルー／グリーンデプロイでは追跡がより複雑になります。複雑な状況に対応するためには、モニタリングを強化し、稼働しているあらゆるデプロイのあらゆる関連データを収集、整理し、リアルタイムおよび事後の検証を行う必要があります。

複数バージョンのデプロイからデータを収集し分析するところから始める

データの収集、整理、可視化のためにモニタリングツール導入と検証プロセス整備をすでにほとんどのチームで行っているでしょう。新世代デプロイ戦略の可視性を高めるためには、各デプロイにタグを付け比較できるようにする必要があり、また、デプロイは一つ残らずモニタリングする必要があります。複数のデプロイやさまざまなバージョンのコード間のトラブルシュートを行うためには、完全な可視化と簡単な切り替えが必要となります。

収集するデータの細かさも重要な視点です。根本原因を特定するためには対象データの幅広さとともに深さも必要です。そうすれば、各エンドポイントやリクエストから数値指標、ログ、トレースを収集でき、特定の問題に焦点を当て、より多様な環境や稼働中の複数のデプロイを背景とした確認ができるようになります。

細かい粒度のデータを収集し、すべてのデプロイをモニタリングする体制を導入することで、どれほど多数のデプロイを行っていても、細かいトラブルシューティングや修正を行うことが可能となります。

新世代デプロイ戦略におけるモニタリング体制の整備

あらゆるデプロイから広く豊富なデータを取得することは、はじめの一歩にすぎません。新世代のデプロイ戦略をうまく実行するためには、そのデータをトラブルシューティングに活用できるかが重要です。

第一に、デプロイによるパフォーマンス管理の最大の指標となる収集データとして、一連の「ゴールデンシグナル」を特定する必要があります。リクエスト、レイテンシー、エラーレートが最も一般的ですが、インフラの数値指標やアプリケーショントレースから得られるコードレベルのパフォーマンスの変化も重要です。

次に、同時に稼働する複数のデプロイ「バージョン」を運用、追跡できるよう、モニタリング手法を調整する必要があります。特定のイベントを一定の時間内だけ対象にするものではなく、様々なデプロイに関し継続的にモニタリングするアプローチでなければなりません。

さらに、新規デプロイまたはデプロイの並行稼働に起因するトラブルシューティングに備えて、オブザーバビリティ（可観測性）のあるすべてのスタックからの情報に容易にアクセスできるようにし、すべてのマイクロサービスバージョン間の相違点を特定することが必要です。こうすることで、ログ、トレース、コードプロファイルを臨機応変に比較、照合し、問題を修正することができます。

最後に、オペレーションチームが最重要な問題について通知を受け取り、状況をリアルタイムに可視化できるよう、事前に定義したアラートやダッシュボードによる堅固な枠組みが欠かせません。

デプロイを確実なものにするために

コードデプロイは、過去のように影響が限定的な単独のイベントではなくなり、デプロイの影響をモニタリングするプロセスと切り離せなくなっています。ご紹介してきた新しいデプロイ戦略の活用を確実に進めるためには、すべてのサービスバージョンにおけるゴールデンシグナルの迅速な比較を可能にし、問題発生時に十分な量の検証データを利用できるようにするモニタリング手法を確立しなければなりません。新機能のより迅速な提供、エラーの回避、顧客満足の維持など、最新のコードをデプロイするメリットを保証するには、モニタリングの体制を整備することが不可欠なのです。