【Azure】 Azure でカオスエンジニアリングする💥

1.はじめに

はい、アベンドカレンダー5日目、12日目、19日目担当です。気づいたら一週間たっていた…何を言ってるのかわから

今回はAzureで11月に利用ができるようになった、__Azure Chaos Studio__についてです。
Azure Chaos Studioでは、Azure上のリソース対して__カオスエンジニアリング__を行うことができます。

__カオスエンジニアリング__と聞くと、このようなイメージを持つのは私だけですかね…たぶん私だけですね。

2.この記事の概要

• カオスエンジニアリングの理解
• Azure Chaos Studioとは
• 起こせる障害や規模

カオスエンジニアリングとは

じゃあまずカオスエンジニアリングって何なのか、っていう話をしましょう。
カオスエンジニアリングというのは、__「本番稼働中のサービスにツールにより疑似障害を発生させ、対障害性を高める」__手法です。

正常稼働しているサービスに対して人為的に障害を発生させるので、人によっては「なんでそんなことするの！？」と驚天動地を飛び越え怒り出す方もいらっしゃるかと思いますが、ごもっともです。
カオスエンジニアリングは本番環境で実施するので、大変なリスクが伴います。しかも、__繰り返し、定期的に何度も実行すること__が前提です。
しかしながら、こういったことを本番環境で行うことに大きな意味があります。ステージング環境で発生しないけど、本番環境だけで発生した障害、というのはあるあるですよね。(嫌な記憶を誘発してしまったら大変申し訳ございません。)
本来であればそういったことはあってはなりませんが、、、、
ステージング環境をより本番環境に近づけることも大切ですが、実際のユーザーが使っている状況をステージング環境で作り出すのも現実的に難しいです。
耐障害性を高めるために、本番環境で実験するからこそ意味があるのです。

また近年KubernetesやDookerを利用した分散システム構成が取られるようになり、システム障害の本質も変わりました。
これらのシステムでは、__障害を0にするのではなく、自動的に復旧すること__を目的としています。
自動的に復旧するということは、逆に言えば__何が問題でどう対策すればよいのか__が見えにくくなっているということです。
そういったことが見えなくなってくると、いざ障害が発生した際に、何をどう確認したらよいのか、そもそも障害が発生しないようにするためにするにはどうしたらよいのか、という視点が抜け落ちていきます。カオスエンジニアリングを行うことで、これらの視点を可視化し、対策を行い、本質的な障害に耐えられるようにします。

通常、カオスエンジニアリングを進める際は、以下のようなことを検討します。

1.システムが「正しく」動作している状態を定義し、共通認識とする
2.仮説を立て、対策を検討する
3.実験を計画する
4.実験する
5.結果をレポートとしてまとめる

これらの取り組みはGoogleやMicrosoft等、様々な組織で行われています。
またカオスエンジニアリングを行うツールも増えてきており、__始祖的なツールである「Chaos Monkey」、SaaSで利用できる「Gremlin」__というものが有名です。
AWSやAzureでも独自にカオスエンジニアリングをクラウド上で利用できるツールを提供しています。
というわけで、今回はAzure Chaos Studioをご紹介するわけです。

Azure Chaos Studio

2021/11にMicrosoftから発表された、Azure上でカオスエンジニアリングを利用できるツールです。
(というわけで、まだプレビュー版です)

Azure Chaos Studioで起こせる障害は、2種類あります。

• サービスダイレクト障害
  • AKSなどに対して、インストールやインストルメンテーションなしでAzureリソースに対して直接実行される障害
• エージェントベース障害
  • 仮想マシン内でエージェントを経由して実行されるエージェントベースの障害

次に、それぞれの障害の詳細についてみていきましょう。

Azure Chaos Studioで利用できる障害(2021/12時点)

Azure Chaos Studioで利用できる障害は、以下のリンクに記載があります。
Chaos Studio の障害およびアクション ライブラリ

• virtualMachines

  • 物理メモリ負荷
  • CPU 負荷
  • 仮想メモリ負荷
  • ディスク I/O 負荷 (Windows)
  • ディスク I/O 負荷 (Linux)
  • 任意の stress-ng ストレス
  • Windows サービスを停止する
  • 時刻の変更
  • プロセスを強制終了する
  • DNS エラー
  • ネットワーク待ち時間を増やす
  • ネットワーク切断
  • ファイアウォール規則を使用したネットワーク切断
  • 仮想マシンのシャットダウン

• VirtualMachineScaleSet

  • 物理メモリ負荷
  • CPU 負荷
  • 仮想メモリ負荷
  • ディスク I/O 負荷 (Windows)
  • ディスク I/O 負荷 (Linux)
  • 任意の stress-ng ストレス
  • Windows サービスを停止する
  • 時刻の変更
  • プロセスを強制終了する
  • DNS エラー
  • ネットワーク待ち時間を増やす
  • ネットワーク切断
  • ファイアウォール規則を使用したネットワーク切断
  • 仮想マシン スケール セット インスタンスのシャットダウン

• CosmosDB

  • Cosmos DB のフェールオーバー

• AzureKubernetesServiceChaosMesh

  • AKS Chaos Mesh のネットワーク障害
  • AKS Chaos Mesh のポッド障害
  • AKS Chaos Mesh のストレス障害
  • AKS Chaos Mesh の IO 障害
  • AKS Chaos Mesh の時刻の障害
  • AKS Chaos Mesh のカーネル障害
  • AKS Chaos Mesh の HTTP 障害
  • AKS Chaos Mesh の DNS 障害

• NetworkSecurityGroup

  • ネットワーク セキュリティ グループ (誤ったルールをあえて適用してみる）

• AzureCacheForRedis

  • Azure Cache for Redis の再起動

まぁ__なんかまだまだって感じは否めません__ね。利用できるサービス障害が少ないし…
VMに対しての障害は豊富に準備されているので、CPUアクセス負荷が増大した場合に正しくスケーリングされるか、その場合にアプリケーションに問題が発生しないかなどを簡単に試すことができるのはとてもよいと思います。

また個人的には、AKSを利用している環境下で、基盤の実験として様々な負荷をかけることができるのがうれしいです。

6．終わりに

今回は、Azure上でカオスエンジニアリングを行えるツールということで、AzureChaosStudioで起こせる障害を中心に書いてみました。
実際には日本の企業でカオスエンジニアリングを採用している会社は少ないと思います。
それは分散システムとしてアプリケーションが構成されていない、そもそも本番環境で障害をあえて起こすなんてありえない、といったところがあると思います。

ただ、カオスエンジニアリングで得られる運用的な知見は大きいです。
必要であれば、検討を進めてみるのがよいと思います。では。