実験！カオスエンジニアリング / How to Chaos Engineering

OCHaCafe Season5 #5の資料です．
デモのソースコード等はこちらをご参照ください．

Transcript

1. 実験！カオスエンジニアリング Oracle Cloud Hangout Cafe – Season 5 #5 Shuhei Kawamura Cloud Solution Engineer Solutions Architect, Oracle Corporation Japan May 11, 2022
2. 自己紹介 Copyright © 2022, Oracle and/or its affiliates 2 川村 修平（Shuhei Kawamura） • 日本オラクル株式会社 • ソリューション・アーキテクト本部 • 担当領域 • Cloud Native, App Dev • Data Platform (Spark周り) • AI Services • (趣味で) 認証・認可関連(FIDO, OAuth, OpenID Connect, etc.) • 趣味 • サウナ、料理、音楽、スノーボード @shukawam Twitter/GitHub/Qiita
3. Agenda 1. カオスエンジニアリングとは？ 2. Kubernetes上で稼働するアプリケーションに対するカオスエンジニアリング 3. カオスエンジニアリングをサポートするツール 4. まとめ 3 Copyright © 2022, Oracle and/or its affiliates
4. Copyright © 2022, Oracle and/or its affiliates 4 カオスエンジニアリングとは？
5. • カオスエンジニアリングは、本番環境のコンポーネントを“ランダム”に壊し、信頼性を高める手法である • カオスエンジニアリングは、分散システム(マイクロサービス)にのみ適用されるソフトウェアテスト手法である これらが誤解やカオスエンジニアリングの一部の側面であることを説明していきます カオスエンジニアリング…？ Copyright © 2022, Oracle and/or its affiliates 5
6. https://principlesofchaos.org/ • これはなに？ • カオスエンジニアリングのコアになる考えを記したもの • 発足当時に比べると、ツールや事例などは充実し たが基本的には、Principles of Chaos Engineering に則ったものばかり • 構成 • 序文 • カオスエンジニアリングを行うモチベーション • カオスエンジニアリングの定義 • 検証におけるカオス • 検証プロセス（=カオス実験）の手順 • 詳細な原則 • 検証プロセスの“理想的な”応用方法 Principles of Chaos Engineering Copyright © 2022, Oracle and/or its affiliates 6
7. 参考: モノリシックなアプリケーションに対するカオスエンジニアリング Copyright © 2022, Oracle and/or its affiliates 7 https://speakerdeck.com/chaosconf/think-big-chaos-testing-a-monolith
8. • カオスエンジニアリング • 対象システムの振る舞いを学習するために適切に制御された実験を行い、その結果を観察することで新しい気づ きを得ようとするアプローチのこと • UnknownをKnownに変えるためのアプローチ カオスエンジニアリング Copyright © 2022, Oracle and/or its affiliates 8 Known Knowns 問題を理解し、対処法も分かっている状況 Known Unknows 問題を理解しているが、対処法が分からない状況 Unknown Knowns 問題を理解していないが、対処法は分かる状況 Unknown Unknowns 問題を理解していないし、対処法も分からない状況 カオスエンジニアリングの目的 参考: いつもニコニコあなたの隣に這い寄るカオスエンジニアリング！
9. • 実験とテストは異なる • 物理、化学の実験 vs. 中間、期末テスト • 実験 • 構築された仮説や、既存の理論が実際に当てはまるかどうかを確認することや、既存の理論からは予測が困難な 対象について、さまざまな条件の下で様々な測定を行うこと。 知識を得るための手法の一つ。 by wikipedia • テスト • 被験者または試料の能力や性質を測定するために行う行為のこと。 by wikipedia 実験とテスト Copyright © 2022, Oracle and/or its affiliates 9 LitmusChaos 実験をモチーフにしたものも…
10. • システムの運用に自信をつけたい • 特定の事象が発生しても、エンドユーザーには影響がないことが確認できた • 突然中身の良く分からないレガシーシステムの運用担当者になってしまった • 今まで意識することもできなかった問題を発見したい • 発生することが分かれば、対処は（今までに比べれば）簡単になるし、具体的に調査もしやすい • 多少の犠牲を払って、早期に問題を発見するのか？後で大きな問題として発覚するのか？ カオスエンジニアリングを行うモチベーション Copyright © 2022, Oracle and/or its affiliates 10
11. 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 11 定常状態を 定義する 仮説を立てる 現実世界の イベントを反映す る変数を導入する 仮説を検証する 成功！ 失敗！ Fix
12. 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 12 定常状態を 定義する 仮説を立てる 現実世界の イベントを反映す る変数を導入する 仮説を検証する 成功！ 失敗！ Fix
13. 1. 定常状態を定義する 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 13 計画を立てる 可観測性を確保する 定常状態を定義する • どのようなデータを取得する必 要があるのか計画をたてる • ビジネス／サービスの発展に影 響がある要因 • 安定稼働に影響がある要因 • 実験はシンプルであればあるほ ど良い • システムの内部属性ではなく、 測定可能な出力に焦点を当て る • 定常状態を表す指標となる データをシステムから確保可能 な状態にしておく • システム全体のスループット • CPU/メモリの使用率 • etc. • はじめはできるだけシンプル、か つ簡単に取得できるものが望ま しい • 事象が予想範囲内/外である ことを理解できるようにするため に、正常な状態（=定常状 態）を定義する • 1 リクエストの平均応答時間は、 100ms 以内である • “app=hoge” とラベルの付いた すべての Pod が安定稼働して いる • etc.
14. Observabilityの基本 ～ Cloud Native における Observability を実現する典型的なツールの解説まで 是非、ご一読を！ 参考: Observability 再入門 Copyright © 2022, Oracle and/or its affiliates 14 https://speakerdeck.com/oracle4engineer/oracle-cloud-hangout-cafe-observabilityzai-ru-men
15. 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 15 定常状態を 定義する 仮説を立てる 現実世界の イベントを反映す る変数を導入する 仮説を検証する 成功！ 失敗！ Fix
16. 2. 仮説をたてる • 実際に収集した信頼できるデータや過去の経験をもとに直観的に判断できる仮説を立てる • 定常状態における 1 リクエストの平均応答時間は、50ms なので、AP-DB サーバ間に 1s の遅延を追加しても平均応答時 間は、2.5s を超えないだろう • 今まで安定稼働しているので、app=hoge のラベルが付いた Pod の 50% がダウンしても業務は続行可能だろう • etc. • 仮説を立てる際に役に立つイベントの例 • 外部のイベント（地震、洪水、火災、停電、etc.） • ハードウェアの障害 • リソース不足 • 人為的なエラー • トラフィックの遅延／増加 • etc. 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 16
17. 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 17 定常状態を 定義する 仮説を立てる 現実世界の イベントを反映す る変数を導入する 仮説を検証する 成功！ 失敗！ Fix
18. 3. 現実世界のイベントを反映する変数を導入する • 仮説に基づき、実験を行うための変数をシステムに導入する • 変数の導入ポイントや方法は様々 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 18 Cloudベンダーから提供されているSDK/CLI カオスエンジニアリング用のツールを使う kubectl + 簡単なスクリプト Envoy カオスエンジニアリング用のツールを使う tc, stress-ng, etc. カオスエンジニアリング用のツールを使う コンテナ環境にtc, stress-ng, etc.を持ち込む seccomp カオスエンジニアリング用のツールを使う コードでイベントを直接表現する 言語に備わっている機能を使う (javaagent, etc.) ライブラリとして提供されているものを使う (Chaos Monkey for Spring Boot, etc.) カオスエンジニアリング用のツールを使う
19. Layer Pros Cons Application • イベントの表現がコードレベルで柔軟にできる • 特別なツールの準備や事前の学習コストが 不要 • （複雑な依存関係を持つ）大規模なアプ リケーションには不向き Infrastructure (Container/K8s /VM/Platform) • エコシステムが充実している（監視ツールと の連携のしやすさ、etc.） • 影響範囲が（コードで表現するよりも）限 定しやすい • ツールの習熟やセットアップには時間がかかる Application vs. Infrastructure Copyright © 2022, Oracle and/or its affiliates 19 答えはないので、何を優先するか？を考慮し適材適所で選択する
20. 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 20 定常状態を 定義する 仮説を立てる 現実世界の イベントを反映す る変数を導入する 仮説を検証する 成功！ 失敗！ Fix
21. 4. 仮説を検証する • 実験を実行した結果を観測し、仮説を検証する • 仮説が正しかった場合 • そのシナリオに対する自信をつけることができた • 他のシナリオでも検証してみる • 仮説が誤っていた場合 • 問題が起きることを知ることができた • 問題を改善するために具体的な調査を行う • 実験の条件を変えることでより詳細な情報を得る 検証プロセス（=カオス実験）の手順 Copyright © 2022, Oracle and/or its affiliates 21
22. • 検証は自動化する • 手作業による検証は、手間や時間がかかるため長続きしない • 再現性が得やすくなる • 影響範囲（Blast Radius）を局所化する • 実験が失敗した際に、大惨事にならないように • アプローチの例 • まずは、本番環境ではなく検証環境で試してみる • トラフィックの小さいサブネットで実験を行い、段階的に実験を拡張する • ユーザーへの影響が少ない時間帯を選択して実験を実施してみる • etc. • 本番環境で検証を実行する • 本番環境以外で行う実験は、結局のところ何かが不完全（データ、スケール、環境構成、etc.） 詳細な原則 Copyright © 2022, Oracle and/or its affiliates 22
23. カオス実験の 4 つのプロセス 1. 定常状態を定義する • k6* の実行結果に含まれる平均応答時間を採 用 • 定常状態では、数 100ms オーダー 2. 仮説を立てる • WordPress, MySQL 間の通信に 1s の遅延を 仕込んでも平均応答時間は、 3s を超えない • 応答時間が 3s を超えるとユーザーの離脱率が大幅 に上がるので、仮の目標値 3. 現実世界のイベントを反映する変数を導入する • Toxiproxy** を用いて、1s の遅延を追加してみ る 4. 仮説を検証する *: OSSの負荷テストツール **: Shopifyが公開しているTCPレイヤーのシンプルなプロキシサーバー Demo: 初めてのカオスエンジニアリング Copyright © 2022, Oracle and/or its affiliates 23 Load Balancer OKE User 1秒の遅延を仕込む Toxiproxy toxiproxy-cli -h $TOXIPROXY_URL toxic add ¥ --type latency ¥ --attribute latency=1000 ¥ --upstream ochacafe Listen: [::]:3306 Upstream: 127.0.0.1:3316
24. • カオスエンジニアリング • 対象システムの振る舞いを学習するために適切に制御された実験を行い、その結果を観察することで新しい気づ きを得ようとするアプローチのこと • PRINCIPLES OF CHAOS ENGINEERING へ立ち返る • Observability が大切 • 定常状態の定義、実験後の状態観測のために必要 • 実験計画に基づき、意味のあるものを取得する • 実験は極力シンプルになるように心がける ここまでのまとめ Copyright © 2022, Oracle and/or its affiliates 24
25. Copyright © 2022, Oracle and/or its affiliates 25 Kubernetes上で稼働するアプリケーションに 対するカオスエンジニアリング w/ Chaos Mesh
26. • 検証は自動化する • 手作業による検証は、手間や時間がかかるため長続きしない • 再現性が得やすくなる • 影響範囲（Blast Radius）を局所化する • 実験が失敗した際に、大惨事にならないように • アプローチの例 • まずは、本番環境ではなく検証環境で試してみる • トラフィックの小さいサブネットで実験を行い、段階的に実験を拡張する • ユーザーへの影響が少ない時間帯を選択して実験を実施してみる • etc. • 本番環境で検証を実行する • 本番環境以外で行う実験は、結局のところ不完全（データ、スケール、環境構成、etc.） （再掲）詳細な原則 Copyright © 2022, Oracle and/or its affiliates 26 CIの一環として組み込む Chaos Meshのスケジュール実行機能 Chaos Meshのワークフロー実行機能 CIの一環として組み込む Chaos Meshのセキュリティ機能
27. Open Source Cloud-Native Chaos Engineering platform • Cloud Nativeな環境（Kubernetes）用に設計されたカオスエンジニアリングプラットフォーム • https://chaos-mesh.org/ • 最新版は、v2.2.0 (※2022/05 現在) • Kubernertes v1.15 ~ 1.22 がサポート対象 • ユーザーフレンドリーな UI を提供 • 実験の作成や進行状況のモニター機能 • 専用の CLI: chaosctl • 安全に実験を行うための機能をサポート • Kubernetes の RBAC 機能を用いた権限制御（Manager/Viewer） • 実験の対象範囲を制御する namespace でのフィルタリング • Schema Type, CRD, Event Handler(Custom Controller) を追加する事で独自の実験タイプが作成可能 Chaos Mesh Copyright © 2022, Oracle and/or its affiliates 27 kubectl annotate ns $NAMESPACE chaos-mesh.org/inject=enabled
28. Chaos Meshのアーキテクチャ Copyright © 2022, Oracle and/or its affiliates 28 kubectl apply client.Apply() Web UI (Chaos Dashboard) 参考: https://chaos-mesh.org/docs/#architecture-overview K8s API Server Chaos Controller Manager Chaos Daemon Container Runtime kubelet create/delete event List/Kill Pod Get PID User C1 C2 C3 C4 Inject chaos Chaos Daemon Container Runtime kubelet C1 C2 C3 C4 PodChaos Physical MachineChaos Network Chaos JVMChaos Cgroup Namespace IPset Iptables TC stress-ng ptrace fuse StressChaos KernelChaos … CRD(Custom Resource Definitions) Manage lifecycle
29. Chaos Dashboard Chaos Meshのコンポーネント Copyright © 2022, Oracle and/or its affiliates 29 • ユーザーが実験を操作したり、観察するための Web UI を提供 • （オプション）Kubernetes の RBAC 機能を用いた 権限制御機能 • ServiceAccount • (Cluster)Role • (Cluster)RoleBinding のManifestが生成される
30. Chaos Controller Manager Chaos Meshのコンポーネント Copyright © 2022, Oracle and/or its affiliates 30 • Chaos Mesh の中核をなす論理コンポーネント • カオス実験(CRD)のスケジューリングと管理を行う • 複数のコントローラーの集合 • Workflow Controller • Scheduler Controller • Controllers of various fault types
31. Chaos Daemon Chaos Meshのコンポーネント Copyright © 2022, Oracle and/or its affiliates 31 • 実験のメインの実行コンポーネント • Kubernetes の DaemonSet として動作する • デフォルトで”Privileged”権限を持つ（無効化可 能） • ターゲット Pod の Namespace にハッキングするこ とで、ネットワークデバイスやファイルシステム、カーネ ルに干渉し障害を発生させる $ kubectl get nodes NAME STATUS ROLES AGE VERSION 10.0.10.129 Ready node 4h17m v1.22.5 10.0.10.35 Ready node 4h59m v1.22.5 10.0.10.72 Ready node 5h11m v1.22.5 $ kubectl -n chaos-testing get daemonsets.app chaos-daemon NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE chaos-daemon 3 3 3 3 3 <none> 6d8h $ kubectl -n chaos-testing get po -o wide | grep -i chaos-daemon chaos-daemon-45pdc 1/1 Running 0 5h3m 10.244.3.131 10.0.10.35 <none> <none> chaos-daemon-d25kp 1/1 Running 0 5h15m 10.244.3.11 10.0.10.72 <none> <none> chaos-daemon-lsfwp 1/1 Running 0 4h21m 10.244.4.3 10.0.10.129 <none> <none>
32. 豊富な種類の障害をCRD(Custom Resource Definitions)として提供 fault types description PodChaos Podの障害をシミュレート（failure, kill, container kill） NetworkChaos Pod間のNetworkの障害をシミュレート（partition, loss, delay, duplicate, corrupt, bandwidth） DNSChaos DNS障害をシミュレート（error, random） HTTPChaos HTTP通信の障害をシミュレート（abort, delay, replace, patch） StressChaos CPU, RAMの競合をシミュレート IOChaos I/O障害をシミュレート（latency, fault, modify） TimeChaos システム時間を変更し、summer timeやその他時間に関連するイベントへの適応をシミュレート KernelChaos カーネル障害をシミュレート（メモリ割り当ての例外、etc.） JVMChaos JVMの障害をシミュレート（exception, gc, latency, stress, etc.） AWSChaos AWSの障害をシミュレート（EC2 stop/restart, detach volume） GCPChaos GCPの障害をシミュレート（GCE stop/restart, disk loss） AzureChaos Azureの障害をシミュレート（VM stop/restart, disk detach） Fault Injection Copyright © 2022, Oracle and/or its affiliates 32 NEW!!
33. 一番シンプルな実行 Manifest例 Copyright © 2022, Oracle and/or its affiliates 33 kind: PodChaos # fault types(PodChaos, NetworkChaos, IOChaos, etc.) apiVersion: chaos-mesh.org/v1alpha1 metadata: namespace: ochacafe name: pod-kill spec: selector: # 実験対象の絞り込み namespaces: - ochacafe labelSelectors: app: wordpress mode: one # 実行モード(one/all/fixed/fixed-percent/random-max-percent) action: pod-kill # action gracePeriod: 0 ※Web UI(Chaos Dashboard)からでも同様のことが可能です
34. スケジューリング実行 Manifest例 Copyright © 2022, Oracle and/or its affiliates 34 ※Web UI(Chaos Dashboard)からでも同様のことが可能です kind: Schedule # Schedule実行 apiVersion: chaos-mesh.org/v1alpha1 metadata: namespace: ochacafe name: pod-kill-scheduled spec: schedule: 30 18 * * * # cron concurrencyPolicy: Forbid # 実験の同時実行許可(Allow/Forbid) historyLimit: 1 # 履歴の保持件数 type: PodChaos # fault types(PodChaos, NetworkChaos, IOChaos, etc.) podChaos: selector: # 実験対象のPodを絞り込み namespaces: - ochacafe labelSelectors: app: wordpress mode: one action: pod-kill gracePeriod: 0
35. Chaos Meshでは、カオス実験のワークフローを作成するために、以下の機能を持つ ワークフロー実行 Copyright © 2022, Oracle and/or its affiliates 35 features description 直列(Serial)実行 複数の実験、タスクを順番に実行する 並列(Parallel)実行 複数の実験、タスクを並列に実行する（複雑な条件のシミュレートに有効） Custom Task 任意のコンテナイメージを用いて独自定義の処理を実行する。実行結果による条件分岐も可能 Suspend 待ち時間を発生させる Status Check ステータスの確認を行うタスク（HTTPのリクエストを発行し、ステータスコードを確認する） Task Task HTTP Request Incoming Webhook e.g. 定常状態の測定、イベントの注入、実験後の状態の測定を行い、完了後の通知を自動的に行うワークフロー NetworkChaos NEW!!
36. apiVersion: chaos-mesh.org/v1alpha1 kind: Workflow # ワークフロー実行 metadata: namespace: ochacafe name: chaos-workflow spec: entry: chaos-workflow # ワークフローの EntryPoint 定義 templates: - name: chaos-workflow # ワークフロー定義 templateType: Serial # Serial 実行 deadline: 10m children: # 上から順番に実行される - pod-kill - network-latency # ...続く (1) ワークフロー実行 Manifest例 Copyright © 2022, Oracle and/or its affiliates 36 ※Web UI(Chaos Dashboard)からでも同様のことが可能です
37. ワークフロー実行 Manifest例 Copyright © 2022, Oracle and/or its affiliates 37 # ...続き (1) - name: pod-kill templateType: PodChaos deadline: 5m podChaos: selector: namespaces: - ochacafe labelSelectors: app: wordpress mode: one action: pod-kill gracePeriod: 0 # ...続く (2) # ...続き (2) - name: network-latency templateType: NetworkChaos deadline: 5m networkChaos: selector: namespaces: - ochacafe labelSelectors: app: wordpress tier: mysql mode: all action: delay delay: latency: 2s correlation: '0' jitter: 0ms direction: to ※Web UI(Chaos Dashboard)からでも同様のことが可能です
38. Schema Type, CRD, Event Handler(Custom Contoroller)を追加し、Chaos Mesh のカスタムイメージをビルドする https://chaos-mesh.org/docs/add-new-chaos-experiment-type/ Kubernetes Operator の基本的な説明から作り方まで一通り網羅されています！ 参考: 独自の実験タイプを作る Copyright © 2022, Oracle and/or its affiliates 38 https://speakerdeck.com/oracle4engineer/kubernetes-operator-introduction
39. CI (Continuous Integration) の一環として組み込むための GitHub Action をマーケットプレイスで公開 Chaos Mesh Integrations – GitHub Actions Copyright © 2022, Oracle and/or its affiliates 39 ソースコード修正 ビルド テスト デプロイ テスト #1 Chaos Mesh Test … helm/kind-action*等で作成した K8s環境に対して、カオス実験を実行 *: GitHub Actions用のKubernetes in Docker CI CD
40. • https://github.com/chaos-mesh/chaos-mesh-action/pull/11 が受け入れられるまでは、 metadata.annotations: Too longというエラーが発生するため、実行に失敗する • 暫定対処 • chaos-mesh/chaos-mesh-action をForkして、main.shに以下の修正を加えたものを使用する • 修正前: kubectl apply -f ./manifests/crd.yaml • 修正後: kubectl create -f ./manifest/crd.yaml or kubectl apply --server-side -f ./manifest/crd.yaml GitHub Integrationの注意（2022/05現在） Copyright © 2022, Oracle and/or its affiliates 40
41. • Grafana の Data Source 用のプラグインが提供されている • モニタリングツールの結果と併せて、Grafana のダッシュボード上で参照したい時などに便利 • (2022/05現在) Grafana Labs – Plugins で公開されているプラグインは最新版と互換性がないのでご注意を Chaos Mesh Integrations – Grafana Dashboard Copyright © 2022, Oracle and/or its affiliates 41
42. • 実験のデバッグログや主要コンポーネントのログを表示するためのクライアントツール • 新しい実験タイプを作成するときのデバッガーとして活用 • リカバリー機能（chaosctl recover）を用いた、特定の障害からの復旧も可能となる予定（現在は、未実装） Chaos Mesh Integrations – chaosctl Copyright © 2022, Oracle and/or its affiliates 42 $ chaosctl help Interacting with chaos mesh # show debug info chaosctl debug networkchaos # show logs of all chaos-mesh components chaosctl logs # forcedly recover chaos from pods chaosctl recover networkchaos pod1 -n test Usage: chaosctl [command] Available Commands: completion Generate completion script debug Print the debug information for certain chaos forward Forward ctrl api port to local help Help about any command logs Print logs of controller-manager, chaos-daemon and chaos-dashboard physical-machine Helper for generating TLS certs and creating resources for physical machines recover Recover certain chaos from certain pods Flags: -h, --help help for chaosctl -N, --manager-namespace string the namespace chaos-controller-manager in (default "chaos-testing") -s, --manager-svc string the service to chaos-controller-manager (default "chaos-mesh-controller-manager") Use "chaosctl [command] --help" for more information about a command.
43. https://github.com/chaos-mesh/chaos-mesh/blob/master/ROADMAP.md • Support injecting faults into native components of Kubernetes. • More comprehensive status inspection mechanism and reports. • Improve observability via events logs and metrics. • Improve authentication system, and support using GCP/AWS account to log in chaos dashboard. • Add GRPC Chaos. Support injecting faults into GRPC connections. • A new component to force recovery chaos experiments, and avoid experiments going out of control. • Build a hub for users sharing their own chaos workflow and chaos types. • Support doing chaos experiments on multiple Kubernetes clusters. • Provide a plugin approach to extend complex chaos types, such as RabbitMQChaos, RedisChaos... • Continue to enrich fault types. 参考: Roadmap Copyright © 2022, Oracle and/or its affiliates 43
44. カオス実験の4つのプロセス 1. 定常状態を定義する • kubectl get podsの結果、Podが2つStatus: runningな状態で存在する 2. 仮説を立てる • app: wordpressのラベルが付いたPodをランダム に1つ削除しても自動的に復旧する 3. 現実世界のイベントを反映する変数を導入する • Chaos Mesh(PodChaos)を用いて、ランダムに Podを1つkillする 4. 仮説を検証する • どうなるでしょう？ Demo: CI(Continuous Integration)にカオスエンジニアリングを組み込む Copyright © 2022, Oracle and/or its affiliates 44 User ランダムにPodを 一つ落とす git push hook Chaos Daemon Inject PodChaos
45. カオス実験の4つのプロセス 1. 定常状態を定義する • k6*の実行結果に含まれる応答時間を採用 2. 仮説を立てる • WordPress, MySQL間の通信に1sの遅延を仕 込んでも平均応答時間は、3sを超えない 3. 現実世界のイベントを反映する変数を導入する • Chaos Mesh(NetworkChaos)を用いて、1sの 遅延を追加してみる 4. 仮説を検証する • 仮説に反する（大幅に応答時間が伸びる）こと が確認できた *: OSSの負荷テストツール Demo: 初めてのカオスエンジニアリング w/ Chaos Mesh – Workflow and etc. Copyright © 2022, Oracle and/or its affiliates 45 Load Balancer OKE User Chaos Daemon Inject NetworkChaos 1秒の遅延を仕込む
46. 該当ページを表示させるのに、複数回（20~40回）のクエリーが直列で発行されているため、AP – DB 間に仕込んだ1s の遅延は、1s * 20~40回 = 20~40s の遅延として観測される 参考: 極端な遅延が発生した理由 Copyright © 2022, Oracle and/or its affiliates 46 AP-DB間に 1sの遅延追加後
47. Copyright © 2022, Oracle and/or its affiliates 47 カオスエンジニアリングをサポートするツール
48. Chaos Engineering Tools Copyright © 2022, Oracle and/or its affiliates 48 この他にも多くのツールが存在します https://github.com/dastergon/awesome-chaos-engineering#notable-tools
49. Gremlin Failure as a Service. Pumba Chaos testing and network emulation for Docker containers (and clusters). ここで紹介するツール Copyright © 2022, Oracle and/or its affiliates 49
50. https://www.gremlin.com/ • Gremlin Inc. が開発 • Failure as a Service のコンセプトで作成された SaaS プラットフォーム • インスタンスにエージェントを仕込む形で様々な障害をシミュレートする • プリセット済みのカオス実験のシナリオや簡易的な実験レポート機能を提供 Gremlin Copyright © 2022, Oracle and/or its affiliates 50 ※2022/05現在、Kubernetes 1.22+には未対応
51. Helm repo を追加 namespace 作成 変数設定（Gremlin の管理コンソールから確認） インストール 参考: OKEへのインストール手順 Copyright © 2022, Oracle and/or its affiliates 51 helm repo add gremlin https://helm.gremlin.com kubectl create namespace gremlin GREMLIN_TEAM_ID=<team-id> GREMLIN_CLUSTER_ID=<cluster-id> GREMLIN_TEAM_SECRET=<team-secret> helm install gremlin gremlin/gremlin ¥ --namespace gremlin ¥ --set gremlin.secret.managed=true ¥ --set gremlin.secret.type=secret ¥ --set gremlin.collect.processes=false ¥ --set gremlin.hostPID=true ¥ --set gremlin.secret.teamID=$GREMLIN_TEAM_ID ¥ --set gremlin.secret.clusterID=$GREMLIN_CLUSTER_ID ¥ --set gremlin.secret.teamSecret=$GREMLIN_TEAM_SECRET ¥ --set gremlin.container.driver=crio-runc
52. Category Attacks Description Resource CPU CPUの負荷をシミュレート Disk ハードディスクへのファイルを書き込みの負荷をシミュレート IO I/Oデバイスに対する負荷をシミュレート Memory メモリへの負荷をシミュレート State Process Killer 指定されたプロセスを強制終了する。アプリケーションや依存関係のクラッシュをシミュレートす るために使用 Shutdown ホストOSのシャットダウンを実行 Time Travel システム時間を変更し、summer timeやその他時間に関連するイベントへの適応をシミュ レート Network Blackhole 条件に一致するすべてのネットワークトラフィックをドロップする DNS DNSサーバーへのアクセスをブロックする Latency 条件に一致するすべてのインバウンドのトラフィックに対して、レイテンシーを注入する Packet Loss 条件に一致するすべてのトラフィックに対して、パケットロスを発生させる CategoryとAttacks Copyright © 2022, Oracle and/or its affiliates 52
53. カオス実験のための Web UI Copyright © 2022, Oracle and/or its affiliates 53 実験の影響範囲（Blast Radius）が一目で分かるUI 簡易的なレポート機能
54. https://github.com/alexei-led/pumba • Docker (Swarm)専用のカオスエンジニアリングツール • Pumba のバイナリをインストールして使う • コンテナアプリケーションのクラッシュ、ネットワーク障害のエミュレーション、コンテナリソース(CPU, RAM, IO, etc.)のストレ ステスト等の実施を支援するツール Pumba Copyright © 2022, Oracle and/or its affiliates 54
55. https://github.com/alexei-led/pumba pumba --help Copyright © 2022, Oracle and/or its affiliates 55 pumba --help NAME: Pumba - Pumba is a resilience testing tool, that helps applications tolerate random Docker container failures: process, network and performance. USAGE: pumba [global options] command [command options] containers (name, list of names, or RE2 regex if prefixed with "re2:") VERSION: 0.9.0 - 2e7ab7b (master) 2021-11-21T10:12:49+0200 AUTHOR: Alexei Ledenev <alexei.led@gmail.com> COMMANDS: kill kill specified containers exec exec specified containers restart restart specified containers stop stop containers pause pause all processes rm remove containers stress stress test a specified containers netem emulate the properties of wide area networks help, h Shows a list of commands or help for one command GLOBAL OPTIONS: --host value, -H value daemon socket to connect to (default: "unix:///var/run/docker.sock") [$DOCKER_HOST] --tls use TLS; implied by --tlsverify --tlsverify use TLS and verify the remote [$DOCKER_TLS_VERIFY] --tlscacert value trust certs signed only by this CA (default: "/etc/ssl/docker/ca.pem") --tlscert value client certificate for TLS authentication (default: "/etc/ssl/docker/cert.pem") --tlskey value client key for TLS authentication (default: "/etc/ssl/docker/key.pem") --log-level value, -l value set log level (debug, info, warning(*), error, fatal, panic) (default: "warning") [$LOG_LEVEL] --json, -j produce log in JSON format: Logstash and Splunk friendly [$LOG_JSON] --slackhook value web hook url; send Pumba log events to Slack --slackchannel value Slack channel (default #pumba) (default: "#pumba") --interval value, -i value recurrent interval for chaos command; use with optional unit suffix: 'ms/s/m/h' (default: 0s) --label value filter containers by labels, e.g '--label key=value' (multiple labels supported) --random, -r randomly select single matching container from list of target containers --dry-run dry run does not create chaos, only logs planned chaos commands [$DRY-RUN] --skip-error skip chaos command error and retry to execute the command on next interval tick --help, -h show help --version, -v print the version
56. コンテナを kill する コンテナのリソースに負荷をかける ネットワークに遅延を追加する 使い方の一例 Copyright © 2022, Oracle and/or its affiliates 56 pumba kill re2:alpine pumba stress --duration 10s --stress-image alexeiled/stress-ng:latest-ubuntu --stressors="--cpu 4 --timeout 60s" re2:alpine pumba netem --tc-image "gaiadocker/iproute2" --duration 20s delay --time 1000 re2:alpine
57. Gremlin Pumba Chaos Mesh 提供形態 SaaS バイナリ Kubernetes CRD 使いやすさ ◎ プリセット済みのカオス実験のシナリオ の多さ、直感的なUI ◦ 直感的なCLI ◦ 直感的なUI 対象 Cloud Platform, VM, Kubernetes, Container Container(Docker) Cloud Platform, VM, Kubernetes, Container, Application 実験の作成方法 Web UI CLI Web UI, kubectl apply 影響範囲の絞り込みやすさ ◎ Web UI △ コンテナ名（正規表現で絞り込み） ◎ Web UI, namespace, RBAC スケジュール実行の有無 ◦ × 要他ツール（cron等） ◦ ワークフローの有無 ◦ ステータスチェックの仕組み有 × ◎ ステータスチェック、任意のコンテナイ メージの実行が可能 その他 Free Plan 有 CI(GitHub Actions)へ組み込み可 まとめ Copyright © 2022, Oracle and/or its affiliates 57
58. Gamified Chaos Engineering Tool for Kubernetes おまけ: KubeInvadersとkubedoom Copyright © 2022, Oracle and/or its affiliates 58 kubedoom • FPSの始祖ともいえるDOOMをモチーフに敵(Pod)を 倒すと実際の環境でもkillされる KubeInvaders • スペースインベーダーをモチーフに敵(Pod, Worker Node)を倒すと実際の環境でもkillされる https://github.com/lucky-sideburn/KubeInvaders https://github.com/storax/kubedoom
59. Copyright © 2022, Oracle and/or its affiliates 59 まとめ
60. • カオスエンジニアリング • 対象システムの振る舞いを学習するために適切に制御された実験を行い、その結果を観察することで新しい気づ きを得ようとするアプローチのこと • PRINCIPLES OF CHAOS ENGINEERING へ立ち返る • 小さな範囲からでもまずはやってみることが大切！ • Kubernetes上で稼働するアプリケーションであれば、 • 実験の自動化 → CIの一環に組み込む、ツールのスケジューリング機能を使う、etc. • 影響範囲の局所化 → (Chaos Meshであれば) namespace, RBACの活用 • Chaos Mesh • Open Source Cloud-Native Chaos Engineering platform • シンプルで使いやすいUIと豊富な実験タイプを提供 まとめ Copyright © 2022, Oracle and/or its affiliates 60
61. Special Thanks! • Principles of chaos engineering • 日本語: https://principlesofchaos.org/ja/ • 英語: https://principlesofchaos.org/ • O’Reilly Chaos Engineering • https://learning.oreilly.com/library/view/chaos-engineering/9781617297755/ • Chaos Mesh • https://github.com/chaos-mesh/chaos-mesh/ 61 Copyright © 2022, Oracle and/or its affiliates
62. Special Thanks! • Chaos Engineering Whitepaper v0.1 • https://github.com/chaoseng/wg-chaoseng/blob/master/WHITEPAPER.md • github/awesome-chaos-engineering • https://github.com/dastergon/awesome-chaos-engineering • Chaos Engineeringという考え方 / A concept of Chaos Engineering • https://speakerdeck.com/mahito/a-concept-of-chaos-engineering • OCHaCafe Season4 #6 – Observability 再入門 • https://speakerdeck.com/oracle4engineer/oracle-cloud-hangout-cafe-observabilityzai-ru-men • OCHaCafe Season5 #1 – Kubernetes Operator 超入門 • https://speakerdeck.com/oracle4engineer/kubernetes-operator-introduction 62 Copyright © 2022, Oracle and/or its affiliates
63. 参考 • oracle-japan/ochacafe-chaos-engineering • https://github.com/oracle-japan/ochacafe-chaos-engineering 63 Copyright © 2022, Oracle and/or its affiliates
64. Copyright © 2022, Oracle and/or its affiliates 64 Thank you