CodeZine(コードジン)

特集ページ一覧

Chaos Toolkitでカオスエンジニアリングを体験しよう~Azure上のVMにカオス挿入

クラウドネイティブ時代の実践カオスエンジニアリング 第2回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

Azure Virtual Machineへのカオス挿入方法

3. サブスクリプションIDの確認

 AzureのサブスクリプションIDを確認します。確認方法の例は以下の通りです。

Azure Portalでの確認方法

 Azure Portalにサインインし、[すべてのサービス]から[サブスクリプション]を選択します。

 すると、サブスクリプション名とサブスクリプションIDが確認できます。

Azure PowerShellでの確認方法

 以下のコマンドを実行することでサブスクリプションIDが確認可能です。

# Azureにサインイン
Connect-AzAccount

# サブスクリプションIDの一覧を表示
Get-AzSubscription

 確認したサブスクリプションIDは、以下のように後述の実験ファイルに記述します。

{
  "configuration": {
    "azure_subscription_id": "<your-azure-subscription-id>"
  }
}

4. 実験ファイルの作成

 実験ファイルをJSON形式で作成します。ここでは、Virtual Machineをランダムに停止させる実験ファイルのサンプルを以下に示します。

実験ファイルの要素

 実験ファイルに記述する主要な要素は以下の通りです。

  • configuration:アクションに渡すランタイム値を記述します。以下サンプルではサブスクリプションIDを記述しています。
  • secrets:アクションに渡す機密情報を記述します。以下サンプルではサービスプリンシパルの情報を記述しています。
  • method:適用するアクションのシーケンスを記述します。以下サンプルではVirtual Machineをランダムに停止させる「stop_machines」のアクションを記述しています。

実験ファイルのサンプル(Stop_Machines.json)

{
    "version": "1.0.0",
    "title": "...",
    "description": "...",
    "tags": ["azure", "VM"],
    "configuration": {
      "azure_subscription_id": "xxx"
    },
    "secrets": {
      "azure": {  
        "client_id": "xxx",
        "client_secret": "xxx",
        "tenant_id": "xxx"
      }
    },
    "method": [
        {
          "name": "stop-machines",
          "type": "action",
          "provider": {
            "type": "python",
            "module": "chaosazure.machine.actions",
            "func": "stop_machines",
            "secrets": ["azure"],
            "config": ["azure_subscription_id"]
          }
        }
    ]
  }

 また、method内に引数(arguments)を記述することで実験対象のリソースを指定することも可能です。

指定したリソースグループ内のすべてのVirtual Machineをランダムに停止する場合

"method": [
    {
      "name": "stop-machines",
      "type": "action",
      "provider": {
        "type": "python",
        "module": "chaosazure.machine.actions",
        "func": "stop_machines",
        "arguments": {
			"filter": "where resourceGroup=='<your-resource-group-name>'"
		},
        "secrets": ["azure"],
        "config": ["azure_subscription_id"]
      }
    }
]

指定したリソースグループの内、2つのVirtual Machineをランダムに停止する場合

"method": [
    {
      "name": "stop-machines",
      "type": "action",
      "provider": {
        "type": "python",
        "module": "chaosazure.machine.actions",
        "func": "stop_machines",
        "arguments": {
			"filter": "where resourceGroup=='<your-resource-group-name>' | sample 2"
		},
        "secrets": ["azure"],
        "config": ["azure_subscription_id"]
      }
    }
]

指定したリソースグループの内、指定のVirtual Machineを停止する場合

"method": [
    {
      "name": "stop-machines",
      "type": "action",
      "provider": {
        "type": "python",
        "module": "chaosazure.machine.actions",
        "func": "stop_machines",
        "arguments": {
			"filter": "where resourceGroup=='<your-resource-group-name>' and name=='<your-virtual-machine-name>'"
		},
        "secrets": ["azure"],
        "config": ["azure_subscription_id"]
      }
    }
]

 その他、実験ファイルの記述方法は、Chaos ToolkitのAzure拡張機能に関するリファレンスを参照いただければと思います。

5. 実験ファイルの実行

 作成した実験ファイルを実行するには、以下のようにchaos runコマンドを使用します。

(chaostk) $ chaos run Stop_Machines.json

 コマンド実行後、指定したサブスクリプション内に存在するVirtual Machineがランダムに停止することが確認できるかと思います。Azure Portalより、Virtual Machineのアクティビティログを確認すれば、Virtual Machineが停止した時刻も確認できます。

図3:Virtual Machineの停止が記録されたアクティビティログ
図3:Virtual Machineの停止が記録されたアクティビティログ

まとめ

 今回は、カオスエンジニアリングツールであるChaos Toolkitのインストール方法やAzure Virtual Machineへのカオス挿入方法を紹介しました。今回紹介したシナリオでは、比較的シンプルな障害を題材としておりますが、実験ファイルに記述を加えることでより複雑な障害を再現することが可能となります。今回の実験ファイルには「method」のみを記述しましたが、実際にカオスエンジニアリングを実施する際は、「steady-state-hypothesis」や「rollbacks」を定義することでシナリオが完成します。これらの使い方は、次回以降で説明します。

 エンタープライズの分野においては、多様化するエンドユーザのニーズに対応するため、システムの構成も複雑になってきています。オンプレミス時代では、Web3層で構成されるシステムが大半を占め、障害パターンも比較的シンプルに定義でき、障害テストで問題なければ比較的安定したシステム運用をすることができました。昨今のクラウド時代では、サーバを増やすことに対するハードルが下がったことも相まって、運用システムの追加開発を進める中でサーバが増加し、Virtual Machine同士が複雑に通信し合うシステム構成となってしまうことがあります。このような複雑化したシステムにおいては、障害時の復旧対応は困難を極めます。

 具体的な例として、以下の図のシステムを題材に説明します。図で示すWebアプリケーションのシステムは、WebサーバのバックエンドにサービスA、B、Cで構成されています。また、サービスAとサービスBがAPI連携しており、さらにサービスBとサービスCがAPI連携しているとします。データセンター障害により、図中の"×"印のサーバがランダムに停止する障害が発生したとします。その際、Webアプリケーションにどのような影響が発生するのか、また正常な状態にシステムを復旧させるために、どのような優先度で対応すべきなのか、といったことを迅速に判断し対応しなくてはならない場面に直面したとします。この判断は、熟練の運用者でない限り、非常に困難な課題であると言えます。

図4:複雑化したシステムにおける障害の例
図4:複雑化したシステムにおける障害の例

 複雑なシステムでは、障害のパターンを網羅したテストを実施することは大変な労力と時間を要します。日頃の運用訓練や障害テストの際、今回紹介したようなカオスエンジニアリングツールを活用することで、障害を想定した事前準備や耐障害性を高めるためのシステムのアップデートを推進していく活動に貢献すると考えています。

次回予告

 次回は、クラウドならではの構成であるAzure仮想マシンスケールセット(VMSS)を構成したシステムに対するカオス挿入について説明します。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:クラウドネイティブ時代の実践カオスエンジニアリング

著者プロフィール

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5