このブログを改善してくれたgenbokuさんに感謝しました。

Chaos Meshはカオスエンジニアリングのためのテストツールです。

コンテナ化されたアプリケーションに対してカオスなテストを行うことができます。

そして、クラウドネイティブに準じたオープンソースなツールキットです。

基礎知識

カオステストが必要な理由

カオスはプロダクション環境で頻繁に発生します、マシン障害、ネットワーク障害など。それらの障害=故障に対応するために、多くの試行錯誤を行って来ました。その結果生まれたのがカオステストです。

単体テストはソースコードのモジュールごとの安定性を保障するために行います。同様にカオステストは 故障時の障害対応を安定して行えることを保証するために 行います。

マーフィーの法則によれば、「失敗する余地があるなら、失敗します」。

システムがより複雑でより規模が大きくなるほど、潜在的なバグも多くなります。プロダクション運用環境と同じサイズの開発環境であったとしてもバグを見逃すことはまだあるでしょう。しかし、コストを節約するために、通常の開発環境は(プロダクション運用環境よりも)小さいです。バグはさらに見つけにくくなります。

例えばハードドライブが損傷する確率は1時間あたり0.0001％であると仮定しましょう。100台のハードドライブのクラスターが10,000時間実行してようやく1台のハードディスクが破損する可能性がでてきます。しかし、開発環境ではその可能性は非常に低いことはいうまでもありません。

カオステストはこの障害状況をシミュレートすることです。

クラウドネイティブな理由

クラウドネイティブに至った理由

カオスの実装方法はたくさんあります。時間のカオスをシミュレートするためにシステム時間を調整したり、ネットワークのカオスをシミュレートするためにiptablesを使用したファイアウォールのセットアップを行ったり…その中で自分の経験からクラウドネイティブを選んだ理由を説明します。

PingCAPでは、非常に早い段階でカオステストを開始しました。

最初は、SSH経由でマシンにカオスを設定していました。

sshで構成されたカオス

あの時、僕はTiDB用のカオステストツールを作成しました。

tidb-ansible を使用してTiDBをデプロイし、データベースに接続するロードプログラムを実行しながら、さらに同時にカオス操作を実行するツールです。

大事な問題は、このテストフレームワークにもバグがあることでした。例えば、tidb-ansibleを使用したTiDBのデプロイに失敗したり、iptablesのルール削除に失敗するなど（そしてそれは次のテストの環境汚染を引き起こします）。

他にも様々な問題がありました：

  • リソース使用率が低い
  • 問題が発生した場合、プログラムの実行状態を記述するために、次のテストは停止する必要がありました
  • ログ収集を行う必要がありました
  • 複数のクラスターを同時にテストできましたが、新しいクラスタを追加するたびに、テスト環境を手動で構成する必要がありました
  • …

さらに上記の問題に共通する事項として、このテストスイートを使用するためには、多くの場合、手動による介入が必要でした。

クラウドネイティブのアドバンテージ

  • Kubernetesはリソースを適切に管理し、テストに標準環境を提供します
  • TiDB Operatorは、TiDBクラスタを管理できます
  • Chaos Mesh、TiDB Operatorなどのユニットに分割できます

クラウドネイティブの欠陥

  • ある一部の障害のシミュレートできません。例えば、電源切断など。

Chaos Meshを試す

カオスエンジニアリングによるテストがなぜ必要か。

そしてChaos Meshがどうしてクラウドネイティブな作りをしているのか。

わかったところで公式ドキュメント：https://github.com/pingcap/chaos-mesh#deploy-chaos-meshにしたがって、実際にKubernetesでChaos Meshを動かしてみましょう。

Helm使用して、Chaos Mesh展開

Helmチャートを取得する

1
2
git clone https://github.com/pingcap/chaos-mesh.git
cd chaos-mesh/

カスタムリソースをインストールする

1
2
3
4
5
6
kubectl apply -f manifests/
# CRD を確認する
kubectl get crd podchaos.pingcap.com
kubectl get crd networkchaos.pingcap.com
kubectl get crd iochaos.pingcap.com
kubectl get crd timechaos.pingcap.com

通常、コンテナランタイムはDocker。もし他のコンテナランタイムを使用している場合はドキュメントを参照してください。

1
2
3
4
5
6
7
8
# 名前空間を作成する
kubectl create ns chaos-testing
# helm 2.X
helm install helm/chaos-mesh --name=chaos-mesh --namespace=chaos-testing
# helm 3.X
helm install chaos-mesh helm/chaos-mesh --namespace=chaos-testing
# Chaos Mesh pods を確認する
kubectl get pods --namespace chaos-testing -l app.kubernetes.io/instance=chaos-mesh

テストしてみましょう

テスト対象のアプリケーションコンテナを実行します。

1
2
kubectl create ns hello-chaos
kubectl -n hello-chaos create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

カオスを設定します。

例：https://github.com/pingcap/chaos-mesh/blob/master/examples/pod-kill-example.yaml

hello-chaosネームスペースのapp=kubernetes-bootcampというラベルがついたpodを1分ごとにランダムに一つ終了させます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: pingcap.com/v1alpha1
kind: PodChaos
metadata:
  name: hello-pod-kill
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - hello-chaos
    labelSelectors:
      "app": "kubernetes-bootcamp"
  scheduler:
    cron: "@every 1m"

pod killを適用して、動作しているか確認します。

1
2
3
4
# pod kill を適用する
kubectl apply -f hello-pod-kill.yaml
# pod 再起動を確認する
watch -n 1 kubectl -n hello-chaos get pods

今後の仕事

現在のChaos Meshにはいくつかの欠陥があります。

  • カオスの追加は面倒です
  • カオスイベントを視覚化できません

作業効率を向上し、より良い体験を得るために、Chaos Meshはこれからも将来的に改善し続けます。