Azure Chaos Studioを使ってみた

こんにちは。 AZPowerの森です。 

今日はAzure Chaos Studioというサービスをご紹介したいと思います。

サービスをご紹介する前に、まず、カオスエンジニアリング というキーワードをお聞きになったことはあるでしょうか?

カオスエンジニアリングとは擬似的な障害を発生させることで本番環境の耐障害性などの確認・検証などを行うことをこのようなキーワードで呼んでいます。
こちらはNETFLIX社が2015年に自社の分散システムに導入されたことで注目されました。

もともと、よく利用されていた「モノリシック」なサービスでは「いかにダウンせず運用できるか?」ということが良いこととされてきましたが、近年話題になっているサービス指向アーキテクチャ、そしてマイクロサービスで用いられるさまざまな技術では「自動回復可能なアーキテクチャ」として設計されていることが多くなります。

サービスを構成するための技術の変化に伴い、発生する障害の質も変化し、リカバリー範囲の特定なども非常に難しいケースも増えています。

このような障害を早期に発見するため、カオスエンジニアリングを早期から回帰的に実施し、被害を最小限に抑えることを目的とした取り組みです。

カオスエンジニアリングの原則

それでは、具体的にカオスエンジニアリングとはどのように取り組んでいけばよいのでしょうか。

カオスエンジニアリングを実施するにあたって参考になる記事が「Principles of Chaos」というサイトに公開されています。

こちらの内容を抜粋すると以下の5つの原則に沿って実施することが望ましいとされています。

  • 定常状態における振る舞いの仮説を立てる
  • 実世界は多様である
  • プロダクション環境で実験を実行する
  • 実験を自動化して継続的に実行する
  • 影響範囲を局所化する

これらをもう少し具体的に説明します。

定常状態における振る舞いの仮説を立てる

まず、カオスエンジニアリングでは、内的品質ではなく外的品質に特化した検証方法です。

つまり、システム内部の細かな動作やパラメータを操作・検証するようなことは行わず、外部から計測可能なシステムの出力に焦点を当てて定常状態を定義します。
具体的には、スループットやエラーレート、待ち時間のパーセンタイルといった外部から計測可能なテレメトリなどを指標にし、定常状態を定義します。

また、カオスエンジニアリングでは「システムがどのように動くか」は検証せず、「機能するかどうか」を検証することを目的にします。

実世界は多様である

非常に抽象的な原則ではありますが、これは何を指しているかというと、発生する障害やイベントは多様であることを指しています。
つまり、1つの原因だけで発生する障害だけではないケースもあり得るということです。
カオスエンジニアリングは、このような個別の障害やイベントを「カオス変数」として定義し、このカオス変数を組み合わせてシステムに注入することで実験を行います。

プロダクション環境で実験を実行する

実験とは言っても、テスト環境で実施するだけでは本番が正常動作することの検証になりません。
実際のカオスエンジニアリングは本番環境で実施することが望ましいとされています。

実験を自動化して継続的に実行する

実験は手作業で行うような方法では、何度も行うことができません。
何度も行うことができなければ、対障害性能の早期発見にはつながりません。
そのため、実験は自動化し、回帰的に実施することが価値のあることとされています。

影響範囲を局所化する

前述の原則では「プロダクション環境で実験を実行する」とは言ったものの、必要のない顧客の不満を呼び起こすことになりかねないことであることは、容易に想定できます。
そこで、利用者に不利益をもたらさないよう、被害を最小化する工夫は必要になります。
たとえば、AzureではInfrastracture as a Code(IaC)などを用いて本番相当の環境を準備し、実験を行うことで本番と類似の結果を得られる場合もあります。
また、トラブル対応がすぐ行えるよう、夜間や休日ではなく日中に実施することも重要です。

Azure Chaos Studio

このようなカオスエンジニアリングを行うためのツールとして公開されたサービスが「Azure Chaos Studio」です。
サービスは現在プレビューであるため、デフォルトではリソースプロバイダーの登録が行われていません。
お試しになる場合、サブスクリプションの[設定]⇒[リソース プロバイダー]でMicrosoft.Chaosを登録してください。

リソースプロバイダーの登録

登録が完了するとChaos Studioを検索して見つけることができるようになります。

Chaos Studioの検索

利用方法

ターゲット(対象)のオンボーディング

まず、最初に実験対象となるリソースを指定します。

リソースは以下の2種類の方法で指定できます。

  • サービス直接ターゲット
  • エージェントベースターゲット

ターゲットのオンボーディング

サービス直接ターゲット

障害を直接適用する場合に用いる方法です。
Azure上に構築済みのリソースを指定し、そのリソースに対して外部から障害を適用します。
リソースに障害を適用する場合は、併せてリソースに対して障害を発生させることができるよう対象リソースのアクセス制御(AIM)から権限を付与しておくことも必要になります。

エージェントベースターゲット

こちらエージェントを使用して障害を適用する場合に用いる方法です。
障害を発生させようとする仮想マシンや仮想マシンスケールセットなどに事前にエージェントをインストールしておき、Chaos Studioと接続し障害を適用します。

カオス実験 (Chaos Experiment)を作成

実行する障害と対象を「実験デザイナー」を使用して構成します。

実験の作成

実験デザイナーでは、まず障害の対象を選択します。

対象はAzure内のリソースを指定します。指定したら「次へ」をクリックします。

実験の作成

実験デザイナー

実験デザイナーは実験のロジックをデザインする画面になります。

ロジックは複数の「ステップ」と「セレクター」で構成します。

「セレクター」は前画面で選択されたリソースが指定されていますので、このリソースに対してこの画面で定義した「ステップ」を順次実行します。

実験デザイナー

義したそれぞれの「ステップ」には、1つ以上の「ブランチ」で構成されています。
「ブランチ」は「ステップ」の中で同時に実行されます。
「ブランチ」の中には実際実行する障害やイベントを「アクション」として定義します。

StepとBranch

アクション

「アクション」とはカオス実験のアクティビティの最小単位になります。
「アクション」には「障害」と「時間の遅延」があります。
「障害」はリソースに影響を与えるためのアクションを指し、「時間の遅延」は単に次のアクションやステップの実行まで待機することを表します。

つまり、この「アクション」を複数組み合わせて定義することで障害を表すことになります。

アクションは「名前」と「種類」といった2つのパラメーターで表現します。

「名前」は実際に実行されるアクションを表すURN形式のパラメーターです。
「種類」はアクションの実行方法を指し、「連続」「不連続」のいずれかです。
* 「連続」:停止せず実行されるアクション
* 「不連続」:1回だけ発生するアクション

「アクション」で利用できる障害は「障害ライブラリ」として定義されています。

障害ライブラリ

最新の障害ライブラリは以下を参照してください。

Chaos Studio の障害およびアクション ライブラリ

サポートされているリソースの種類

Chaos Studioで障害を適用できるリソースは以下の図のようになっています。

Chaos Studio でサポートされているリソースの種類とロールの割り当て

こちらも最新は以下のリンクを参照してください。

Chaos Studio でサポートされているリソースの種類とロールの割り当て

現在はまだ、適用できるリソースの種類は多くありませんが、今後、さまざまなリソースの種類の拡充を期待したいサービスですね。

参考)Azure Chaos Studio のドキュメント