2023年6月6日
信頼性
Jenkinsによるカオスエンジニアリング
Jenkinsパイプラインは、パイプラインにカオス試験を追加することで、レジリエンスの検証を行うことができます。CDパイプラインにカオス試験を追加すると、開 発者の生産性の向上、運用上の負債の削減、レジリエンスの問題の早期発見など、大きなメリットがあります。
Harness Chaos EngineeringまたはHarness CEは、DevOpsやSDLCの全ての段階での回復力を検証するためのカオス試験の概念化、設計、開発、実行、分析に必要なエンドツーエンドのツールを提供します。Jenkinsなどの他のCI/CDツールでは、これらのカオス試験をパイプラインに簡単に追加できます。このブログでは、Harness Chaos EngineeringとJenkinsパイプラインの統合方法について説明します。
CDパイプラインでカオス試験を実行するメリット
組織がCDパイプラインでカオス試験を実行する理由は次の通りです。
CD ROI対レジリエンスの未知数性
企業は、開発者の労力を軽減しながらより高い俊敏性を実現するために、CDパイプラインテクノロジーに投資してきました。このROIは、潜在的な信頼性の低下と相殺されているのでしょうか？偶然に任せるのではなく、想定されるカオスシナリオに対して出荷するコードのレジリエンスを検証するだけで、CDへの投資の最大限のROIを達成できます。
開発者の効率を向上する
開発者は、設計やアーキテクチャーの変更に常に対応していますか？パイプラインでの機能テストが成功しても、設計、アーキテクチャー、または依存関係の変更の検証が成功することは保証されません。そして、全ての開発者がこれらの変更を深く理解しているわけではありません。うまく書かれたカオス試験は、パイプラインを壊すときに、これらの分野のギャップを開発者にすぐに知らせることができます。開発者は、より高いコストで生産するよりも、パイプラインの中で、最も早い段階でデザインギャップや実装ギャップに対処しています。
レジリエンス負債を削減する
技術的な負債と同じように、本番サービスにも積み重なるレジリエンス負債があります。アラートとインシデントは本番環境に登録され、最終的には解決済みキューまたは監視対象キューに入れられます。これらのアラートやインシデントにより、ホットフィックス／ホットコードパッチや構成変更が発生する場合があります。多くの場合、開発者はメモリーの増設、CPU の追加、ノードの追加などの回避策を追加するだけになってしまいます。どちらの場合も、製品チームはフィードバックを受けて、カオステストによる関連する検証テストをパイプラインに追加することで対応ができます。パイプラインのデプロイが承認される前に、関連するカオス試験を追加するよう、ポリシーを設定したり強制したりできます。例えば、コンポーネントの誤動作（OR）ネットワーク損失（OR）ネットワークの遅さ（OR）外部APIが期待通りに応答しない（OR）高負荷などによる全てのインシデントやアラートは、そのインシデントやアラートから60日以内にパイプラインシミュレーションで対応するカオス試験を検証しなければならないというポリシーを設定できます。これにより、蓄積されつつあるレジリエンス負債をチェックする 規律がもたらされることになるのです。開発者とQAチームは、新しい機能をどんどん本番に投入するのではなく、本番のコードで修正する必要があるものに集中せざるを得なくなるのです。
CD Pipelinesのカオス試験のユースケース
CD Pipelinesは、新しいコード変更をデプロイするときに実行されます。機能テストと統合テストは、最近の変更が期待される機能を壊していないか、新しい機能が期待通りに動作しているかを確認するために実行されます。パイプラインの実行は、新しいコードの機能の検証に加えて、以下のレジリエンスシナリオを検証する機会を提供します。
CD pipelinesにおけるカオスエンジニアリングのユースケース
デプロイを既存のレ ジリエンス条件と照らし合わせて検証する
パイプラインのレジリエンスカバレッジは常に低い数値から始まりますが、それらをうまく自動化したときに初めてカバレッジを高めることができます。パイプラインを通じてデプロイされる全ての変更は、既に知られているレジリエンス条件に対してテストされます。これは、レジリエンススコアがターゲット環境において安定していることを確認するためです。
新たに追加されたレジリエンス条件に対してデプロイを検証する
デプロイされるコード変更は１つの側面ですが、パイプラインに追加された新しいレジリエンステストやカオス試験は、パイプラインの実行の重要性を増加させます。これは、レジリエンスカバレッジを高めることです。レジリエンスカバレッジの増加がレジリエンススコアの低下を意味する場合、まだ本番環境の停止を引き起こしていないが、今すぐ検討する価値がある潜在的な弱点が見つかったことになります。これには、開発者が失敗したカオス試験を調査し、パイプラインを止めるか、今は無視して、復旧シナリオの文書化、SREへのメモ、設定変更の提案など、並行して行動を起こすことを決めることも含まれます。
ターゲットデプロイが動作するプラットフォームの変更
Kubernetesバージョンなどの基盤となるプラットフォームが変更されると、パイプラインで行われるテストに大きな注目が集まります。レジリエンススコアが低下することがありますが、これはアップグレードされたプラットフォームで新たな潜在的弱点が見つかったことを示しています。
本番環境のインシデントやアラートに対してデプロイを検証する
このユースケースでは、SRE/Opsチームとパイプラインビルダーの間で調整を行い、最近見つかったインシデントまたはアラートに関連するレジリエンステストを追加する必要があります。各インシデントやアラートは、データベースにまだ追加されていない場合、新しいカオス試験につながる可能性があります。
構成の変更に対するデプロイを検証する
新しい変更がソフトウェア内またはターゲットインフラ内の構成変更に関するものである場合、レジリエンステストによって潜在的な弱点に関する新たな知識がもたらされる可能性があります。これは、ターゲット環境が上位または下位の構成によって変更されたために、以前に合格したレジリエンステストが失敗し始めるという別のシナリオです。
JenkinsのCI/CDパイプラインにカオス試験を導入するためのステップバイステップガイド
開発者はカオスプロジェクトでカオス試験を作成します。その後、カオス試験はステップとしてパイプラインに取り込まれます。カオスステップの各実行結果は、期待されるレジリエンススコアを満たすか、満たさないかのいずれかであり、その時点でパイプラインステージの設定された失敗戦略を呼び出すことができます。
Harness CEカオス試験をJenkins CI/CDパイプラインに追加する
ステップ１：
カオス試験を作成して実行し、最後まで実行されることを確認します。関連するプローブは、レジリエンススコアに関する偽陽性または偽陰性のシナリオを回避するために追加されます。
Harness CEでカオス試験を作成する
ステップ２：
カオス試験を開始するAPIコマンドを準備する
Harness CEでは、試験を実行したり起動したりするためのAPIが用意されています。APIでは、ユーザーが多くのパラメーターを追加する必要があり、ユーザーは実行のためにそれをフォーマットする必要があります。Harnessでは、このAPIを用意するために、使いやすいCLIを用意しています。このCLIツールはhce-api-linuxと呼ばれています。Linux用はここからダウンロードできます。
ここでは、hce-api-linux CLIの使用例として、カオス試験のカオス起動スクリプトを作成した例を示します。
#!/bin/bash
set -e
curl -sL https://storage.googleapis.com/hce-api/hce-api-linux-amd64 -o hce-api-saas
chmod +x hce-api-saas
output=$(./hce-api-saas generate --api launch-experiment --account-id=${ACCOUNT_ID} \
--project-id ${PROJECT_ID} --workflow-id ${WORKFLOW_ID} \
--api-key ${API_KEY} --file-name hce-api.sh | jq -r '.data.runChaosExperiment.notifyID')
echo ${output}上記のサンプルスクリプトから分かるように、APIを正常に生成するには、いくつかのパラメーターを指定する必要があります。これらのパラメータは次の通りです。
API_KEY：HarnessのユーザーのAPIキー。ユーザーのAPIキーの管理方法の詳細については、こちらのドキュメントを参照してください。
WORKFLOW_ID：特定のアカウントのプロジェクト内のカオス試験の一意のID。Harness CEモジュールのChaos試験テーブルからコピーできます。
ACCOUNT_ID：Account IDタブにあるHarnessのアカウントID。
PROJECT_ID:カオス試験が作成されるカオスモジュール内のプロジェクトのID。これは、プロジェクトがリストされているときにプロジェクトの名前の下に表示されます。
ステップ３:
カオス試験の実行結果、別名Resilience Scoreを取得するAPIコマンドを準備します。
同じCLIコマンドを使用して、異なるコマンドパラメーターを渡すことで、カオス試験実行の最新の結果を取得できます。取得される結果は、最新のレジリエンススコアに他なりません。このスコアは、パイプラインの次のステージ／ステップに移動するか、ロールバックなどの失敗戦略を呼び出すなど、適切なアクションを実行するために使用されます。
以下は、カオス試験の実行結果を取得する例です。
#!/bin/bash
set -e
curl -sL https://storage.googleapis.com/hce-api/hce-api-linux-amd64 -o hce-api-saas
chmod +x hce-api-saas
resiliencyScore=$(./hce-api-saas generate --api validate-resilience-score --account-id=${ACCOUNT_ID} \
--project-id ${PROJECT_ID} --notifyID=$1 \
--api-key ${API_KEY} --file-name hce-api.sh)
echo "${resiliencyScore}"ステップ４：Jenkinsのスクリプトで用意されたAPIコマンドを使い、カオス試験を実行する
前のステップの２つのコマンドは、与えられたカオス試験を実行し、その与えられたカオス試験の実行結果を取得するのに役立ちます。これらのAPIコマンドをJenkinsパイプラインスクリプトのchaos-stepまたはchaos-stageに注入してください。以下に例を示します。
stage('Launch Chaos Experiment') {
steps {
sh '''
sh scripts/launch-chaos.sh > n_id.txt
'''
script {
env.notify_id = sh(returnStdout: true, script: 'cat n_id.txt').trim()
}
}
}
stage('Monitor Chaos Experiment') {
steps {
sh '''
sh scripts/monitor-chaos.sh ${notify_id}
'''
}
}
stage('Verify Resilience Score') {
steps {
sh '''
sh scripts/verify-rr.sh ${notify_id} > r_s.txt
'''
script {
env.resilience_score = sh(returnStdout: true, script: 'cat r_s.txt').trim()
}
}
}
stage('Take Rollback Decision') {
steps {
sh '''
echo ${resilience_score}
sh scripts/rollback-deploy.sh ${resilience_score}
'''
}
}まとめ
パイプラインにカオス試験を導入すると、ビジネスクリティカルなサービスの信頼性に大きなメリットがもたらされ、開発者の生産性が向上し、未知の要素を処理できないリスクが大幅に軽減されます。JenkinsとHarness CEを併用すれば、パイプラインの展開段階にレジリエンステストをシームレスに導入できます。
Harness Chaos Engineeringを始めましょう
Harness Chaos Engineeringは、カオスエンジニアリングのContinuous ResilienceTMアプローチを展開するために必要な上記の構成要素で構築されています。これには、すぐに使える多くの障害、セキュリティーガバナンス、カオスハブ、CDパイプラインやFeature Flagsと統合する機能などが付属しています。
Harness Chaos Engineering 無料プラン
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳 したものです。無断複製を禁じます。原文はこちらです。