カオスエンジニアリングの過去と今(後編)

はじめに

このエントリではカオスエンジニアリングの歴史から、その目的が本番環境におけるテストから本番環境前に行うテストへ変わりつつあるのではないかということを説明する。

前編では、

• カオスエンジニアリングとは実験であること
• カオスエンジニアリングを提唱したNetflixはAWSの障害を乗り切ったという成功体験を元に本番環境での試験を重要視していること(推測を含む)
• カオスエンジニアリングの周知に伴い、色々なツールが開発されたが、現在も生き残っているプロダクトは少ないこと
  などを説明した。

それでは後編に続く。

📘【note】
この記事はKubernetes2 Advent Calendar 2020の19日目です。
昨日は@hhiroshellさんのアルパカでもわかる安全なPodの終了 - 実験編でした。

Kubernetesにより、有名になったアーキテクチャデザイン

2014年、GoogleはKubernetesをオープンソースとして公開する。コンテナランタイムをフル活用し、冗長性と回復性を備えたKubernetesは、分散システムを支えるプラットフォームとして瞬く間に有名になった。

そして、Kubernetesがプラットフォームとして活用されるにつれて、とあるコンテナのアーキテクチャデザインが有名になる。Sidecar Pattern だ。

Kubernetes誕生以前、Sidecar Patternは今とは違い、一つのアプリケーションに閉じた世界にあった。

「Design It!」10章 Visualize Design Decisionsより引用

アプリケーション開発者なら、MVCパターンって言葉をどこかで必ず耳にしたことがあるだろう。アプリケーションを設計する際に、Model, View, Controllerといったように処理内容と責務に応じて領域をレイヤーに分けて、各レイヤー間の関係性を明確にすることで技術負債を生みにくくするための設計手法だ。

元々、Sidecar Patternは、MVCパターンなどのレイヤーに限らず共通して使われるユーティリティツール、エラーハンドラー、通信プロトコル、データベースアクセスメカニズムなどを説明する際に説明するときによく使われる言葉だった^[1]。

Kubernetes誕生以降、有名になったコンテナのアーキテクチャデザインとしてのSidecar Patternも本質は同じである。

サイドカー パターンより引用

システムをマイクロサービスとして分割したときに、監視、ログ記録、構成、ネットワーク サービスなど各サービスで共通して使われるモジュールを独立させて配置させることで、マイクロサービスの本体のプログラミング言語、動作環境に寄らずに共通したモジュールとして設計できることが主眼だからだ。

Kubernetesの普及の中で、Sidecar Patternを活用し、最もその名を有名にすることに成功したプロダクトが2016年にLyftがOSSとして公開したEnvoy Proxyである。

What is Service Mesh? — An Introduction to Envoy Proxy より引用

Envoyは、各サービスのプロキシサーバーとして機能することで、各サービス間の通信を制御する役割を果たす。マイクロサービスにおいてサービスは独立しているのでプログラミング言語レベルでバラバラな状況にあるが、通信制御に関しては一貫したサービスで行うことが可能になったわけだ。それにより、通信障害発生時の円滑な処理やネットワークポリシーの適用によるセキュリティ担保といったことが可能になった。

サービスメッシュの誕生だ。

Kubernetesとサービスメッシュによるモチベーションの自然解決

Kubernetesとその上に構築されたサービスメッシュ。二つの登場により、プラットフォームはアプリケーションインスタンスとネットワーク、二つの観点からResilience(回復性)を得たことになる。分散コンピューティングの落とし穴のチェック項目が半分以上埋まったわけだ。

これらを採用した環境下では、かつてNetflixが開発したOSS...カオスエンジニアリングやマイクロサービスのためのソフトウェアは、ほぼ過去になったといってよい。そして、カオスエンジニアリングの実験範囲も自ずと限られたものになった。ハードルが上がったといっていいだろう。プラットフォーム自体の回復力を超えて障害を起こさなければ試験にならないからだ。

本番環境での試験、時に失敗した実験は起こさなくてもいい障害を引き起こす。前編でも紹介した本番環境でのテスト: 難しい側面ではCloudflareがダークローンチにより本番環境で試していた開発中モジュールが全体に与えてしまった障害事例を例に挙げているが、寝た子を起こすなのマインドが時にリスク管理を上回るのは仕方がないことだろう。SREとErrorBudget(エラーを厳密に測定することである程度のエラーを"予算"として許容する考え)の浸透下でも変わることのないマインドだ。

しかし、そもそもカオスエンジニアリングが本番環境での試験でこだわっていた点が解決されていたとしたらどうだろうか。前編ではっきり書かなかったが、2010年ごろ、カオスエンジニアリングを始めたNetflixのモチベーションは次のところがある。

🤔 本番環境と開発環境(ステージング環境)での環境差異はどうしても生じてしまう(だから本番環境...)

📘【answer】
Netflixがカオスエンジニアリングを始めた2010年前後のEC2中心だった環境とは違い、IaCツールの発達により、Kubernetes環境下で同じマニフェストファイルを使うことで簡単に同じ環境を再現することが可能になった。ステージング環境で確認できれば、本番環境で何も壊すことなく品質を担保できるのでは？

🤔 本番環境でのトラフィックを開発環境で再現することは難しい(だから本番環境...)

📘【answer】
サービスメッシュはサービス間の通信制御とともに、外部からのリクエスト制御も担う。流入するトラフィックのコントロール(トラフィックスプリッティングやミラーリング)が従来技術より容易になった。本番環境でのトラフィックを開発環境で無理なく再現できるのでは？

これらのアイディアを元に、CI/CD手法としてまとめたのがプログレッシブデリバリーという考え方だ。

GKE + Istio + FlaggerによるProgressive Deliveryに詳しい説明がある。DevOpsの素案がflickrのセッションで発表されて以来、1日に何度もビルドとデプロイを繰り返しながらサービスを拡充していく速度感(Agility)と、それに伴う品質の低下をいかに抑えて担保した信頼性(Reliabilty)は常に相反する考え方だ。そこに対する回答の一つとして本番環境にデプロイするより前、いわゆる左シフトでも本番環境相当の環境を準備して、本番環境と同じサービスレベルに基づいて試験し、品質をチェックしていこうというわけだ。

このプログレッシブデリバリーのスキーマに、カオスエンジニアリングで行う障害を試験項目として追加しようというのが、前編の冒頭で説明したPart-1: Evaluating Resiliency with Keptn and LitmusChaosのざっくりとした概要である。

一方で、カオスエンジニアリングに関して下記の側面は、"絶滅"を乗り越えて、形を変えて今後も生き続けると考えてよいだろう。

🤔 本番環境でプラットフォームでのResilienceを超えるような障害が生じたときは最終的に人手が必要になる。本番環境での試験は、運用者を鍛えるための契機になるはずだ

📘【answer】
本番環境での試験を繰り返すのはコストが高い。避難訓練のようにイベント開催日を決めて運用者に対応方法をトレーニングさせたほうが、コスト面、学習効率が上がるはず。

同種の避難訓練イベントは、AWSではGame Days、GoogleではDirTと呼ばれている。いずれもプラットフォームが持つResilienceでは対処しきれないビジネスクリティカルなトラブルに対して、運用者の対処能力を向上させることが目的だ。

現在のカオスエンジニアリングツールと今後の動向

ChaosMonkeyなどのツールをカオスエンジニアリングにおける第一世代とするなら、これから紹介するツールはKubernetes環境を前提とした第二世代のツールと言える。

• Chaos Mesh
  • 分散型データベースTiDBを開発しているPingCAP社がデータベースの試験用に開発。
  • 名前の通り、サービスメッシュのSide Carアーキテクチャデザインのようにカオス状態を引き起こすモジュールをアプリケーションPodのサブコンテナに配置することでカオスエンジニアリングを実現する
• Litmus
  • Mayadata社が開始した後、CNCFサンドボックスプロジェクトとなった。
  • Cloud NativeなChaos Engineering Frameworkを謳っており、カオスエンジニアリングの"実験"としての側面を強調したウェブサイトがカワイイ
  • カオスエンジニアリングが経緯的に本番環境での試験が強調されてきた中にあって、Spinnakerプラグインの提供などCI/CD、つまり本番環境に出す前の開発時を意識した設計になっていると思う
    • どのようなことができるのか更に知りたい場合、Litmus 101 - Chaos Engineering Frameworkという@iaoiuiさんのわかりやすい解説記事を参照するとよい

ツールではなくManaged Serviceも出てきている。

• Gremlin
  • Netflixのカオスエンジニアリングチームの中の人がスピンアウトして作った企業
  • ManagedでChaos Engineeringと言えばまずここが思い浮かぶ
• Verica
  • 同じくNetflixの中の人がスピンアウトとして作った企業
  • 創業者はChaos Engineering の共著者
    • ここから本を無償で手に入れることができる
    • ↑ オライリー・ジャパンさんから日本語に翻訳された本が出版されました(2022/6/18追記)
  • Litmusと同じでCI/CDにおけるカオスエンジニアリングを用いた検証を重要視している

まとめ

本番環境で試験することを前提に進められてきたカオスエンジニアリングは、クラウドネイティブ前提の環境とKubernetesの躍進によって、本番環境に出す前に試験するように姿が変わってきている。

この背景を探るために、Netflixの技術史からカオスエンジニアリングを実施したモチベーションを紐解き、現在のCloud-Native前提な環境において Run expreriments in production. が形骸化しつつある現実を見つめ直して、現在のツールからトレンドを追った。

所感

この発表の下地は自社の勉強会で二年以上前に発表したものだが、自分自身のモチベーションは正直あの頃に比べれば下がっている。なぜなら、カオスエンジニアリングの実施はまずDevOpsが自然と回せるようになった先にあるからだ。そこができてないのにカオスエンジニアリングに手を出せるはずもない。

DevOpsの文脈で、CI/CDのようなリリースパイプラインの自動化は試してみた系情報も多いが^[2]、下記に関する情報は圧倒的に足りておらず、自分としてももっと取り組まないといけない領域だと思っている。DXに対する批判より、生産性を上げるために現場での知見が欲しいところだ。

• 今まで手動でテストを行っていたレガシー業務アプリケーションに自動テストを入れて品質を担保する仕組み
• 修正後のアプリケーションに対する効果測定をObservabilityから拾って次の開発につなげる仕組み
  • 例えば、レイテンシーというありふれたメトリクス一つとっても、それを元にアーキテクチャデザインを設計し直すどころか、正しく計測するという時点で躓きかねない現実がある。レイテンシーを計算する技術の話というLINEさんの記事が深い知見を与えていて好き。リスペクト記事を以前書いた。

ただ、現実としてはまだまだハードルは高いとわかっていても、カオスエンジニアリングが持つセレンディピティとしての魅力は否定できない。自分の知らなかったことへの気づきが次のより良いものへ繋がるのではないか。どこかでそう思っている。

脚注

1. 2017年出版のDesign It!、2012年出版のSoftware Architecture in Practice, Third Edition等。肥大化するユーティリティクラスはアプリケーション開発者にとっては常に悩みの種であり、レイヤーをぶっ壊すという点でわりとあんまりよくないニュアンスで自分は使っていた。

2. 開発者ってどうして皆CI/CDツール大好きなのだろうか？ 自分自身、純粋なCIツールだけで、Jenkins、CircleCI、AzureDevOps、Tekton&OpenShift Pipelines、GitHub Actions、GitLab CI/CDはパイプラインを組んだことがある(GitOpsまで領域を広げるとさらに数サービス加わる)