AI を使用してカオステストを強化

数十から数百ものマイクロサービスを大規模に使用して複雑なシステムを実行するという要求が大幅に増加しています。エンドユーザーは使用しているサービスに常時アクセスできることを期待しているため、ダウンタイムはたとえ数分であっても問題となります。プロアクティブなカオスエンジニアは、プロダクション環境でダウンタイムが発生する前にボトルネックを特定し、サービスを強化することで、ユーザーの期待に応えられるよう支援します。エンドユーザーからの信頼の失墜を防ぐという点で、カオスエンジニアリングは極めて重要です。

回復力のある Kubernetes プラットフォームに対する需要に対処し、ユーザーエクスペリエンスを向上させるために、Red Hat はオープンソース・コミュニティおよびエンドユーザーと協力して、Krkn などのオープンソースツールやカオスエンジニアリング・フレームワークを構築および維持しています。Krkn の機能についてより詳しくお知りになりたい方は、カオステスト実行から得られた知見と調査結果に関する追加のリソースをご覧ください。

多数の製品に Krkn を導入するコミュニティやお客様が増え、私たちは次のような課題に直面していました。これらに対しては、人工知能 (AI) が有用であることがわかっています。

• 製品への新機能や修正の追加にあわせ、テストケースを追加および更新する
• 複数の製品のカオステスト対象範囲を追加して維持する (厳密な追跡を含む)
• 中断につながる可能性が高いと思われるものだけでなく、何百ものテストケースを実行する

Red Hat Chaos Engineering チームと IBM Research チームは、テストカバレッジの改善と自動化のために、Krkn への AI の統合を共同で進めています。これは、異なるアーキテクチャ、ノードスケール、トラフィックパターンを実行する複数の製品に対するカオステストの取り組みを拡張するのに役立ちます。

Krkn での AI 統合のユースケース

さまざまな製品や構成のカオステストへの Krkn の導入が増えるにつれ、十分な対象範囲を確保するためのテストケースは複雑になっています。たとえば、多数のデプロイメントを持つアプリケーションスタックがあり、ユーザーのリクエストに対応するためには Pod が連携する必要があるとします。これに対してカオステストを行うには、アーキテクチャを理解し、サービスの性質 (1 つのマイクロサービスから他のサービスへの依存のパターンや、リソース集約性、CPU、メモリー、IOPS、ネットワーク、トラフィックパターンなど) に応じてテストケースを設計する必要があります。

このすべてをカバーするには何百ものテストケースを反復実行する必要があるため、膨大な作業時間と、場合によってはクラウドのコストが必要になります。そこまでしたとしても、テストから漏れていたエッジのケースを見つけたり、アプリケーションスタックの進化 (機能の追加、アーキテクチャの変更など) にテストケースを適応させたりするために、継続的な監視が必要となります。複数の Pod に対して実行する場合、シナリオの組み合わせを予測するのは難しく、それによりサービスレベル目標 (SLO) の未達やパフォーマンスの低下が発生し、最終的にサービスに影響が及ぶ可能性があります。

同じことを多数の製品やアプリケーションに対して行うことを想像してみてください。これを Krkn への Chaos AI 統合で解決できます。これは、能力の向上と複雑な問題の解決に AI がどのように適応し、支援できるかを示す典型的な例です。

目標は、デプロイされた Chaos AI と Krkn のフレームワークが、サービスに影響を与えるシナリオを自動的に検出して実行し、強化機械学習を使用して製品スタックの変更に適応できるようにすることです。

Krkn

Krkn は、クラウド、Kubernetes、および OpenShift API を対象とするカオスエンジンで、障害状態を注入して、対象コンポーネントの復旧、クラスタの全体的な正常性、およびパフォーマンス SLO を追跡します。

Chaos-recommender

chaos-recommender は、サービスへのポインターを指定されると、Prometheus を使用して各 Pod のプロファイリングを行ってそれらがネットワーク集約型であるか、また CPU、メモリー、I/O に関連しているかを把握し、中断を引き起こす可能性が最も高いシナリオを Krkn に提示します。

Krkn Telemetry

Krkn Telemetry を有効にすると、スケール (ノード数、Pod 数、ルート数など)、アーキテクチャ (AMD、ARM、X86_64)、ネットワークプラグイン (SDN、OVN) などといった環境の情報に加えて、メトリクス、アラート、カオスパラメーター、テストの合格/不合格、ログを取得して保存します。このデータは、AI/ML モデルのトレーニングに使用され、どのコンポーネントに頻繁に障害が発生しているのかを把握することで、それらに対してより多くのテストを行えるようになります。

Chaos AI のワークフロー

これは、Krkn のシナリオと SLO を入力として受け取り、chaos-recommender と Krkn-telemetry のサポートを受けて、テストを必要とするコンポーネントに重みを付け、アプリケーションスタックに対してさまざまな組み合わせのシナリオを実行するエンドツーエンドのフレームワークです。

Etcd と ApiServer のワークフロー例を次に示します。

ステップ 1

ユーザーは、Etcd と ApiServer の Namespace をターゲットとして提供し、SLO を指定します。AI はこれをチェックし、未達に報酬を与えます。以下に例を示します。

• Namespace 入力は openshift-etcd と openshift-apiserver
• API サーバーのレイテンシーは 99% が 1 秒未満
• SLO は Etcd のリーダー選出が 0 未満

ステップ 2

Chaos-AI が chaos-recommender をトリガーします。chaos-recommender は Etcd と ApiServer の Namespace をプロファイリングし、prometheus のリソース使用量メトリクスに基づいて中断の可能性が高いカオスシナリオを特定します。

ステップ 3

強化学習を使用して、Chaos-AI モデルに対するトレーニングが行われます。Etcd コンポーネントおよび ApiServer コンポーネントの Krkn-telemetry データを収集し、頻繁に障害が発生している Pod とコンテナを特定します。

ステップ 4

Chaos-AI がステップ 2 とステップ 3 に基づいて重み付けを行い、Krkn シナリオを実行します。強化学習は、SLO を満たさなかった場合にフレームワークが報酬を与えるシステムに基づいて行われます。この例では、API のレイテンシーが 1 秒を超えたとき、および Etcd がリーダー選出を通過したときに報酬が発生します。

中断の可能性が低い他の領域も実行しますが、反復は少なくなります。たとえば、新しいコンポーネントまたは組み合わせで頻繁にエラーが発生しているのが見つかったとします。このことは Krkn-telemetry に記録され、モデルにフィードバックされて次回の反復で考慮されます。

ステップ 5

ユーザーが対処できるよう、エラーが出力されます。

これは継続的なプロセスであり、製品の進化に合わせて適応し、テストから漏れたエッジケースが存在する可能性がある場合に、人間による介入なしに改善できる領域を特定します。

ユースケース

このフレームワークを使用すると、製品リリース CI でテストケースを手動で識別して追加するのではなく、テストケースを自動的に識別して実行し、さらにはターゲットとするコンポーネントだけでなく、新しく導入されたコンポーネントも自動的に調整できます。

さらに、Red Hat OpenShift だけでなく、Red Hat OpenShift Service on AWS や Red Hat OpenShift AI などのポートフォリオ全体で、テスト範囲を簡単に追加、スケーリング、拡張することができます。

次のステップ

Krkn と Chaos AI の統合は、テストの対象範囲の改善に役立ちます。テスト可能な製品とアプリケーションスタックの数を増やすことで、製品と環境への信頼性を高め、ユーザーが迅速にスケーリングできるようにします。

今後のブログ記事で統合の結果や発見について報告していきますのでご期待ください。ご紹介したように、Krkn、chaos-recommender、Krkn-telemetry などのいくつかの機能はすでにオープンソース化されており、環境のテストと強化に利用できます。現在は、Chaos AI + Krkn フレームワーク全体のオープンソース化に向けて積極的に取り組んでいます。

フィードバックやコントリビューションは大歓迎です。コードは GitHub で公開されています。独自のユースケースに関するご相談やコラボレーションもお受けします。