MatsushitaTweetKubeConで実施されたカオスエンジニアリングのセッションを紹介。Americaは、バーチャルカンファレンスとして開催された。この記事では、カオスエンジニアリングに関するセッションを紹介する。カオスエンジニアリングは、2004年頃からAWSにおいて意図的にシステムに障害を起こす手法で、システムの信頼性を高める実験をしていたというのが始まりだという。元AWSのエンジニアが動画配信サービスのNetflixに移ってAWS上に構築したシステムの冗長性、信頼性を高めるためにHystrix/ChaosMonkeyを開発したのは2010年頃のことだ。その後2016年に、Netflixでカオスエンジニアリングを開発していたチームがスピンアウトして創業したのが、カオスエンジニアリングのトップベンダー、Gremlinだ。Gremlinはすでに多くのユースケースを持ってビジネスを進めている。Groupにおいてさまざまな議論が行われている。Chaosを紹介したい。カオスエンジニアリングの概要については、2018年にシアトルで開催されたKubeCon+CloudNativeConで行われた、カオスエンジニアリングのセッションに関する記事を参照して欲しい。Seattleでも耳目を集めたカオスエンジニアリング今回のセッションは、MayaDataとIntuitの共同で行われた。MayaDataはKubernetesネイティブなステートフルストレージをサービスとして提供するベンチャーで、OpenEBSというオープンソースのKubernetesネイティブなストレージの主な開発元として、活発にコミュニティ活動を行っている。一方のIntuitは、かつてQuicken、TourboTaxというPC用会計パッケージソフトベンダーとして知られていたが、現在はSaaSのサービスモデルに移行を果たしており、オープンソースコミュニティではArgoCDの主な開発元としても知られている企業だ。Chaosのコントリビューターとして開発に携わっている。Chaosを解説したブログ記事から引用したものだ。Chaosのキーパーソンと言える。Chaos自体を理解するには、MayaDataのブログ記事に使われているこの図版が最適だろう。Chaosで作った事例を紹介するというのが今回のセッションとなる。Nagal氏が担当する形式となった。ChaosがKubernetesに最適化されている背景として、クラウドネイティブなシステムで稼働するアプリケーションの多くの部分が他のオープンソースソフトウェアに依存していることを指摘し、「依存しているソフトウェアの信頼性が開発したアプリケーションの信頼性に相関している」ために、そのプラットフォーム自体の信頼性を高める必要があることを解説した。Kubernetesがクラウドネイティブなシステムのデファクトスタンダードなのであれば、仮想マシンなどを対象とせずに、Kubernetesに特化したカオスエンジニアリングがあるべきというのがMukkara氏の主張だろう。Chaosの構造は至ってシンプルだ。このスライドでは障害を注入するフローとそれを実装するモジュールが簡単に解説されている。Chaosのフローと実行されるモジュールフローチャートによると、安定している状態を確認した上で障害を注入する。その後、元に戻ればOK、戻らなければ原因を特定するというシンプルなものだ。Resourceの略である。Definitionを最大限に活用しているというのがKubernetesネイティブという意味だろう。Chaosのワークフローが主にArgoCDの仕組みを使っていることが示されている。Git上の構成情報をベースに運用を行うGitOpsを採用していることも解説された。障害パターンを実行するためのワークフローとして、手続き型言語などを使わずにArgoCDを使うという発想だ。Operatorが実行、その結果をPrometheusが収集して分析を行うという概要が解説された。ChaosHubの紹介ChaosHubはユーザーやベンダーが再利用可能な障害パターンを格納するハブとして機能するもので、MayaDataが開発するOpenEBS用のHelmチャートも多く存在しているようだ。現状ではKubernetesやKafkaなどのソフトウェアに対応する約40種類のパターンが存在している。MayaDataのエンジニアがメンテナーとして記載されているが、ベンダー主導でユーザーコミュニティの経験が集約されているというわけではないようだ。内容についても、MayaDataによる検証があったとしても品質の保証がされているわけではないことを考えると、コミュニティの知見が集まるハブとして機能するようになるには、まだ時間がかかりそうである。Chaosというコンセプトだろう。これはニーズに従って、SDKを使って障害パターンを自作できる機能だ。SDKを使ってカオスエンジニアリングの障害パターンを作成し、それを起動するコンテナイメージを組み合わせることで、独自のパターンを適用することができる。Portalが紹介された。PortalのGUIこのGUIでわかることは、ターゲットとなるノードを選択、すでに定義されたワークフローを選択して実行し、最後に検証するという流れに従って実行すれば、一通りのカオスエンジニアリングの障害パターンを検証できることだ。ChaosがKubernetesに特化したカオスエンジニアリングツールとして、プラットフォームの弱点を発見できることを解説して、次のIntuitのエンジニアにバトンタッチした。Chaosの特徴として、コードそのものがKubernetes上で稼働するためにKubernetesに慣れたエンジニアであれば新しい仕組みを覚える必要がないことが挙げられる。その半面、土台となるKubernetesそのもの、例えば分散キーバリューストアであるetcdを破壊するなどの障害パターンを実験することはできない点に留意しよう。Frameworkのように、サードパーティやユーザーがコードを提供する段階にまで達していないことも要注意ポイントだろう。今後利用が拡がり、MayaDataやIntuit以外からも知見が集まることに期待したい。この著者の記事一覧フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。運用監視イベント第7回ベンダーニュートラルな可視化ツールOpenTelemetryの最新情報を紹介2021/3/29可視化のためのプロジェクトOpenTelemetryの最新情報を、KubeConのセッションなどから解説する。2020において、オープンスースに貢献する意味を元Facebookのコンサルタントが解説したセッションを紹介する。Labsのエンジニアが紹介した。Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。ITがお届けするポッドキャストです。