BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Litmus 2.0リリースでマルチテナンシー、カオスワークフロー、GitOps、可観測性を提供

Litmus 2.0リリースでマルチテナンシー、カオスワークフロー、GitOps、可観測性を提供

ブックマーク

原文(投稿日:2021/09/24)へのリンク

Litmusは、CNCFサンドボックスプログラムに参加する最初のカオスエンジニアリングプロジェクトだ。カオスエンジニアリングにプログラム可能な宣言型アプローチを適用している。先月、Litmus 2.0が一般向けとしてリリースされた。カオスエンジニアリングを簡素化することを目的としており、カオスセンター、カオスワークフロー、カオス用GitOps、マルチテナンシー、可観測性、プライベートカオスハブなどの新機能を追加している。

InfoQは、ChaosNativeのCEOであり、Litmusエンジニアリングプラットフォームの共同作成者および保守担当者のUmasankar Mukkara氏にインタビューした。

InfoQ:Litmusは、CNCFに参加した最初のカオスエンジニアリングプロジェクトでした。 CNCFサンドボックスプロジェクトになった後のLitmusの技術進化について教えてください。

Umasankar Mukkara:4年前、Litmusのオリジナルのアイデアは、クラウドネイティブな方法でカオスエンジニアリングを行う必要性から着想しました。最初に「カオスオペレータ」を構築しました。CRDを使ってKubernetesネイティブの方法でカオスのアイデアを管理できるようにするためです。ChaosExperimentカスタムリソースとしてカオス実験を構築し、オペレータはそれを実行して、ChaosResultと呼ばれる別のカスタムリソースに結果を保存します。これにより、カオス実験を中心にコミュニティを構築し、コミュニティユーザ向けの「Litmusカオスハブ」と呼ばれる公開ハブを作成しました。これは、サンドボックスプロジェクトとしてLitmusをCNCFに寄付したフェーズです。それをLitmus 1.0と呼んでいます。

カオスエンジニアリングは、SREチームと開発者が意図的に障害を設計し、システムのどこに問題があるかを観察するプロセスです。そこで、カオスセンターの概念をLitmusプロジェクトに導入し、それを中心として、チームや組織内におけるカオスの取り組み、あるいは信頼性の取り組みを調整しました。カオスセンターは、SREまたは開発者がLitmusワークフローとして複雑な実験を構築できる場所でもあります。Litmusワークフローは明確な結果をもたらす完全なカオスシナリオと考えることができます。システムが特定のシナリオに対して回復力があるかどうかは関係ありません。

コミュニティからの非常に重要な教訓の1つは、カオス実験に関する定常状態の仮説を定義または構築する必要があることでした。定常状態の仮説を宣言的な方法で詳細に定義し、調整するために、Litmusプローブを開発しました。組織内でカオスシナリオを構築し、カオスカルチャーを構築できるようになると、カオスエンジニアリングを完全に自動化するフェーズに到達します。ここでChaos GitOpsの登場です。Chaos GitOpsを使うと、Kubernetesデプロイメントまたはマイクロサービスに変更が適用された後にLitmusワークフローをトリガーできます。

可観測性は、運用を成功させるための鍵です。カオスエンジニアリングを導入するときは、そのコンテキストを既存の可観測性システムに取り入れることができるようにする必要があります。Prometheusカオスメトリックは、カオス実験のコンテキストをGrafanaまたは他の同様のダッシュボードに簡単に重ね合わせることができるように構築されています。

全体として、CNCFサンドボックスプロジェクトになった後のLitmusの技術的進化を要約するために、カオスセンター、ワークフロー、GitOps、Litmusプローブ、そして、カオス可観測性の導入部分を構築しました。

InfoQ:Litmus 2.0は、ユーザが複数の実験を一緒に実行できるようにするカオスワークフローを導入しています。これにより、以前のバージョンのツールキットと比較して、ユーザのカオスエンジニアリングの実施をどのようにシンプルにできますか。

Mukkara:カオス実験はレゴブロックのようなものです。Litmusワークフローはレゴのおもちゃのようなものです。それで全てが揃っており、エンドユーザにとって意味あるものとなります。Litmusワークフローを使うと、ユーザはチームメンバーが行った多くの作業を再利用し、チームメンバーを強化して新しいカオスシナリオを構築できます。

カオスセンターでは、カオスワークフローの再実行、ワークフローのクローン作成、カオステンプレートからの開始、及び、出荷できる状態になっているワークフローのインポートが可能です。これにより、ユーザは実際のカオスエンジニアリングの考え方を簡単に理解できます。白紙の状態から始めていないためです。

InfoQ:Litmus 2.0は、VM、ベアメタルサーバ、ディスク(AWS、GCP、Azure、VMWare)などのインフラストラクチャ(クラウド)リソースにカオスを注入することで、Kubernetesを超えて拡張します。これにより、ハイブリッドインフラストラクチャに使うときに、プロジェクトの開発と保守がより複雑になることはありますか。

Mukkara:Litmusプロジェクトのアーキテクチャにより、カオス実験を完全に独立させ、プラグアンドプレイで行うことができます。LitmusプラットフォームはKubernetesアプリケーションとして記述されており、カオス実験はKubernetesカスタムリソースにラップされています。ただし、実験自体は、Kubernetesリソースをターゲットにすることに限定する必要はありません。そのため、Litmusを、クラウドネイティブサービスとクラウドベースサービスが共存している実際の環境で使用できます。

カオスシナリオやLitmusワークフローは、完全なハイブリッドシナリオを対象としたカオス実験で定義できるようになりました。これにより、Litmusがより便利になり、実用的なカオスエンジニアリングができるようになります。近い将来、コミュニティによってさらに多くのカオス実験が提供されることを期待しています。

Litmus 2.0リリースの詳細については、リリースノートを参照してください。

 

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT