KubeCon＋CloudNativeCon NA 2020 IntuitとMayaDataによるカオスエンジニアリングのセッション

KubeCon＋CloudNativeConにおけるカオスエンジニアリングのセッション

KubeCon＋CloudNativeCon 2020 North Americaは、バーチャルカンファレンスとして開催された。この記事では、カオスエンジニアリングに関するセッションを紹介する。カオスエンジニアリングは、2004年頃からAWSにおいて意図的にシステムに障害を起こす手法で、システムの信頼性を高める実験をしていたというのが始まりだという。

元AWSのエンジニアが動画配信サービスのNetflixに移ってAWS上に構築したシステムの冗長性、信頼性を高めるためにHystrix/ChaosMonkeyを開発したのは2010年頃のことだ。のちに、オープンソースとして公開したのが2012年のSimian Armyとなる。

その後2016年に、Netflixでカオスエンジニアリングを開発していたチームがスピンアウトして創業したのが、カオスエンジニアリングのトップベンダー、Gremlinだ。Gremlinはすでに多くのユースケースを持ってビジネスを進めている。

CNCFでも、カオスエンジニアリングのWorking Groupにおいてさまざまな議論が行われている。2020年11月現在、Chaos MeshとLitmus Chaosという2つのプロジェクトがCNCFのサンドボックスプロジェクトとしてホストされているが、このレポートではLitmus Chaosを紹介したい。

カオスエンジニアリングの概要については、2018年にシアトルで開催されたKubeCon＋CloudNativeConで行われた、カオスエンジニアリングのセッションに関する記事を参照して欲しい。

参考：KubeCon Seattleでも耳目を集めたカオスエンジニアリング

今回のセッションは、MayaDataとIntuitの共同で行われた。MayaDataはKubernetesネイティブなステートフルストレージをサービスとして提供するベンチャーで、OpenEBSというオープンソースのKubernetesネイティブなストレージの主な開発元として、活発にコミュニティ活動を行っている。

一方のIntuitは、かつてQuicken、TourboTaxというPC用会計パッケージソフトベンダーとして知られていたが、現在はSaaSのサービスモデルに移行を果たしており、オープンソースコミュニティではArgoCDの主な開発元としても知られている企業だ。MayaDataもIntuitもLitmus Chaosのコントリビューターとして開発に携わっている。

カオスエンジニアリングの4つのポイント

この図版は、CNCFの公式ブログにMayaDataのCOOであるUmasankar Mukkara氏が寄稿したLitmus Chaosを解説したブログ記事から引用したものだ。Mukkara氏はこのセッションのプレゼンターでもあり、Litmus Chaosのキーパーソンと言える。

CNCFのブログ：Cloud native chaos engineering ? Enhancing Kubernetes application resiliency

そしてLitmus Chaos自体を理解するには、MayaDataのブログ記事に使われているこの図版が最適だろう。

Litmus Chaosの概要。Kubernetesに最適化されていることがわかる

タイトルにあるように、カオスワークフローをArgoCDとLitmus Chaosで作った事例を紹介するというのが今回のセッションとなる。

KubeConのセッション：Constructing Chaos Workflows with Argo and LitmusChaos

セッションのトピック

このアジェンダの通り、Litmus ChaosについてはMayaDataのMukkara氏が、後半のArgoCDについてはIntuitのSumit Nagal氏が担当する形式となった。

Litmus Chaosの解説

Mukkara氏はLitmus ChaosがKubernetesに最適化されている背景として、クラウドネイティブなシステムで稼働するアプリケーションの多くの部分が他のオープンソースソフトウェアに依存していることを指摘し、「依存しているソフトウェアの信頼性が開発したアプリケーションの信頼性に相関している」ために、そのプラットフォーム自体の信頼性を高める必要があることを解説した。Kubernetesがクラウドネイティブなシステムのデファクトスタンダードなのであれば、仮想マシンなどを対象とせずに、Kubernetesに特化したカオスエンジニアリングがあるべきというのがMukkara氏の主張だろう。

Kubernetesに依存しているのであればKubernetesを意図的に壊すツールが必要

Litmus Chaosの構造は至ってシンプルだ。このスライドでは障害を注入するフローとそれを実装するモジュールが簡単に解説されている。

Litmus Chaosのフローと実行されるモジュール

フローチャートによると、安定している状態を確認した上で障害を注入する。その後、元に戻ればOK、戻らなければ原因を特定するというシンプルなものだ。前述の図において「CR」とついているLitmus Chaosのモジュールは、Custom Resourceの略である。つまり純然としたLitmus ChaosのモジュールはChaos OperatorとChaos Runnerであり、あとはKubernetesをカスタマイズするための仕組みであるCustom Resource Definitionを最大限に活用しているというのがKubernetesネイティブという意味だろう。

Litmus ChaosのワークフローがArgoCDを使っていることがわかる

このスライドでは、Litmus Chaosのワークフローが主にArgoCDの仕組みを使っていることが示されている。またGit上の構成情報をベースに運用を行うGitOpsを採用していることも解説された。障害パターンを実行するためのワークフローとして、手続き型言語などを使わずにArgoCDを使うという発想だ。

Litmus Chaosのアーキテクチャー

システムのアーキテクチャーを表したこの図を用いて、ポータルにさまざまな実験を行うためのHelmチャートがカタログとして格納され、それがchaos-workflow.yamlという構成ファイルに従ってCRDに実装され、Chaos Operatorが実行、その結果をPrometheusが収集して分析を行うという概要が解説された。

ChaosHubの紹介

ChaosHubはユーザーやベンダーが再利用可能な障害パターンを格納するハブとして機能するもので、MayaDataが開発するOpenEBS用のHelmチャートも多く存在しているようだ。現状ではKubernetesやKafkaなどのソフトウェアに対応する約40種類のパターンが存在している。MayaDataのエンジニアがメンテナーとして記載されているが、ベンダー主導でユーザーコミュニティの経験が集約されているというわけではないようだ。また内容についても、MayaDataによる検証があったとしても品質の保証がされているわけではないことを考えると、コミュニティの知見が集まるハブとして機能するようになるには、まだ時間がかかりそうである。

参考：ChaosHub - Chaos Experiments for Kubernetes

すでに22のKubernetesに関連する障害パターンが登録されている

特徴的なのは、Bring your own Chaosというコンセプトだろう。これはニーズに従って、SDKを使って障害パターンを自作できる機能だ。SDKを使ってカオスエンジニアリングの障害パターンを作成し、それを起動するコンテナイメージを組み合わせることで、独自のパターンを適用することができる。

Bring your own Chaosでカオスパターンを自作できるBYOC

Litmus Chaosを紹介したセッション前半の最後のトピックとして、Litmus Portalが紹介された。これはカオスエンジニアリングのワークフローを管理するWeb UIの機能だ。

Litmus ChaosのWebUI、Litmus Portal

Litmus PortalのGUI

このGUIでわかることは、ターゲットとなるノードを選択、すでに定義されたワークフローを選択して実行し、最後に検証するという流れに従って実行すれば、一通りのカオスエンジニアリングの障害パターンを検証できることだ。

Litmus Chaosのまとめ

前半のまとめとして、Litmus ChaosがKubernetesに特化したカオスエンジニアリングツールとして、プラットフォームの弱点を発見できることを解説して、次のIntuitのエンジニアにバトンタッチした。

Litmus Chaosの特徴として、コードそのものがKubernetes上で稼働するためにKubernetesに慣れたエンジニアであれば新しい仕組みを覚える必要がないことが挙げられる。その半面、土台となるKubernetesそのもの、例えば分散キーバリューストアであるetcdを破壊するなどの障害パターンを実験することはできない点に留意しよう。また障害パターンを集めるChaosHubが、Red HatのOperator Frameworkのように、サードパーティやユーザーがコードを提供する段階にまで達していないことも要注意ポイントだろう。今後利用が拡がり、MayaDataやIntuit以外からも知見が集まることに期待したい。