Continuous Verificationの重要性

Continuous Verificationは、デプロイを検証するデプロイパイプラインのクリティカルなステップです。ここではそのContinuous Verificationの重要性について説明しましょう。

デプロイを担当するエンジニアにとって本質的な問いに、「このデプロイはいつ終わる？」というものがあります。この問いを掘り下げると、まず「何をデプロイしているの？」という反応が続きます。Kubernetesの世界では、レディネスプローブが完了したときとして線を引く人もいるかもしれません。アプリケーション中心の視点では、トランザクションの最初のセットが成功したとき、またはトランザクションの境界を越えたときかもしれません。特定のアーキテクチャー的な考え方では、次のデプロイが開始されたらこのデプロイは終了、となります。

どのケースでも、何らかの検証を行う必要がある、という全てのアプローチを結び付ける共通のスレッドが存在します。新しく更新されたエンドポイントにアクセスして変更が反映されたことを検証するエンジニアから、オブザーバビリティースタックに問い合わせるSREまで、判断を下すには検証が必要なのです。

デプロイがうまく行ったとしても・・・・

現代のソフトウェアデリバリーチームでは、進めるか否かの決定はより複雑なものになっています。これは、通常は絶対的な失敗が存在しないためです。デプロイの開始に失敗したなど、絶対的な障害が発生した場合、行動喚起は非常に迅速に行われます。ロールバックはほぼ即座に行われます。ただし、厳密に検査される現代のソフトウェアデリバリーと、細分化が進んだマイクロサービスの台頭により、開始したばかりのアプリケーションのデプロイは、最初は本番環境でうまくいくでしょう。大きな出来事が起こらないため、「根本原因はない」ということになるのです。

サイト信頼性エンジニアリング（SRE）とは、針が干し草の山に置かれてしまう前に見つけるようなものです。無数のオブザーバビリティー、監視、ロギングツールを綿密に調べて、障害の傾向を探すのは簡単なプロセスではありません。データ分析を要する全てのデプロイに専用のSREを用意すると、コストがかかってしまいます。これが、Harnessが皆さんに代わってこの分析を行うContinuous Verification（CV）を作った理由です。

Continuous Verificationとは

Continuous VerificationはHarnessのデプロイ検証ツールです。無料または有料のHarness Continuous Deliveryサブスクリプションの一部に含まれるContinuous Verficationは、オブザーバビリティー、監視、ロギングのツールとプラットフォームを使用してデプロイを検証します。

検証ステップをHarnessパイプラインに追加することで、Prometheus、Datadog、Splunk、AppDynamics、さらにはカスタムのヘルスソースをクエリーして、Harnessがユーザーに代わって判断を下せるようになります。より包括的なリストはCVドキュメントをお読みください。

Prometheusメトリクスを分析するContinuous Verification

Continuous VerificationはHarnessパイプラインに統合されています。Harnessがユーザーに代わって自動アクションを実行したり、手動介入などのHarnessパイプラインによってサポートされる失敗戦略を実行するようにできます。

ログデータを分析するContinuous Verification

Continuous Verificationは、デプロイ戦略と連携して機能します。例えばカナリアデプロイを実行する場合、CVは続行前にカナリアフェーズを分析できます。

デプロイ戦略に合わせたContinuous Verification

パイプラインでContinuous Verificationを有効にすることは、デプロイでレジリエンシー目標を達成するための重要なステップです。

Continuous Verificationはなぜ重要なのか

エンジニアリングあるあるの「品質は全員の責任」と「遅さは新たなダウン」を組み合わせると、「信頼性は全員の責任」ということになります。CDパイプラインは複数の分野にわたる専門知識の集大成です。全てのデプロイをSREに手動で検証してもらっていてはスケールできませんが、検証における最も困難なタスクを支援するシステムがあれば、スケール可能になります。Continuous Verificationがあれば、SREの専門知識をデリバリーパイプラインに一貫して体系的に適用できます。

変化は本質的にリスクをもたらし、信頼性にとってリスクとなる可能性があります。信頼性がわずかに低下しただけでも、評判の低下や収益の損失を引き起こす可能性が出てきます。イノベーションには変化が必要ですが、イノベーションと信頼性のバランスは多くのエンジニアが直面するパラドックスです。Continuous Verificationを使うと、体系的なベリフィケーションとバリデーションのレイヤーを追加することで、何が正常であるか、または正常であったかをベースライン化する機能により、変更を推進できます。

パイプラインにベリフィケーションとバリデーションを入れることは大切です。デリバリーパイプラインにHarnessを使用していない場合でも、Spinnaker／Kayenta、Argo Rollouts Analysisなどを活用するといいでしょう。HarnessのContinuous Verificationは、どのデプロイ戦略を採用する場合でも、使いやすさと柔軟性を考慮して設計されています。まずはCVをお試しください。

Harness Continuous Verificationを始めましょう

Harness Continuous Verificationを開始するには、Prometheusを使ったKubernetesデプロイの検証を説明したHarness Developer Hubのチュートリアルをお読みください。「信頼性は全員の責任」なので、Harnessパイプラインに検証ステップを追加することは賢明であり、Harness CDサブスクリプションの一部として含まれています（お問い合わせはこちら）。さあ、チュートリアルを参照して、信頼性への取り組みを進めましょう。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。