動機
カオスだった平成最後の日に。
日本では未だ、マイクロサービス化が海外と比べて対応が遅いと言われていて、Chaos Engineeringが採用されるのも遅い傾向があります。
SREとして新卒入社したので、自分の知識の枠を広げるためにChaos Engineeringについて猛勉強をして、ChaosKubeができる機能を試してみたので記事にしました。
アジェンダ
この記事のアジェンダは以下の通りです。
Chaos Engineering
オライリーで無料で読むことができるので、以下の本を推薦します。
実際に取り組む前に、Chaos Engineeringがどのようなもので、なぜ必要かを解説しようと思います。
Chaos Engineeringとは
Chaos Engineeringとは、もともとはNetflix社が論文にて提案したものです。具体的には以下のように定義されています。
Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
私の拙い英語翻訳で明文化すると、以下の通りです。
Chaos Engineeringとは、本番環境の分散システムが過酷な状況でも耐えられるとの確信を得るために、実験するという訓練のこと
分散システムといえば、マイクロサービスが身近なところかなと思います。分散システムについて、またはマイクロサービスについて知識がなければ、以下の本を読むことをおすすめします。
分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計
- 作者: Brendan Burns,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/04/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
Chaos Engineeringは強力な実践方法で、分散システムにおけるシステムの不確実性を洗いだして、フォールトトレラントシステムを検証することに取り組んでいます。
概念は大まかに理解できたといえど、何をしたらいいのか分かりません。以下の方法で検証をしていきます。
- 正常な状態を定義する
- この正常な状態が通常時と障害エミュレート時の両方で継続することを仮定する
- サーバクラッシュ、ディスク異常、ネットワークエラーなどの現実世界で起こりえる障害をエミュレートする
- 1で定義した値を通常時と障害エミュレート時で比較し検証していく
そして、結果として一番のゴールである顧客体験を損なわない分散システムが完了するのです。DevOpsには非常に重要な概念です。
Chaos Engineeringのツール
Chaos Monkeyなどはよく知られていますが、他にもたくさんの種類があります。
レイテンシを膨大に発生させたり、サーバーを落としたり、いろいろな不確実性の形があります。
なぜやらないといけないの？
マイクロサービスは、モノリシックな巨大サービスから小さなサービスへ移行し、よりベロシティ、スケーラビリティ、効率の良さなどを求めた結果、システムは複雑になり、組織間の連携も難化しました。
何よりもマイクロサービス固有の問題として、高度で安定したインフラが求められます。「どのくらい確信をもって複雑なシステムをプロダクション環境で持てるの？」という疑問が出てきます。
信頼と可用性を保証するために、サービス自体のアーキテクチャの標準化と個々のマイクロサービスが満たさなければならない要件が必要になります。システムが暴れる or 止まる前に対策をできていなければなりません。
まさに「プロダクションレディ」という概念です。詳しくは以下の本で、詳しく解説されています。
プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化
- 作者: Susan J. Fowler,佐藤直生,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/09/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
「プロダクションレディにするには？」という問いに対して、満たさない要件を詰めていき、炙り出していくプロセスを行うと、高い信頼性と高可用性を保証できるようになると思います。
それはChaos Engineeringをしてしまおうということです。もし耐えられないなら、要件を満たすように構築すればいいのです。
また、本来ならここで、このセクションは終わっていましたが、最近モニタリングに関する書籍が出たので少し触れます。
- 作者: Mike Julian,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
「監視をできているか」という問題もChaos Engineeringで解決できます。監視といえど、ただ可視化してアラートするだけでなく、そのあとの対応が何よりも重要となります。
実際にインシデントを起こして、その状態をキャプチャして、そして次のアクションを起こせるようなシステムこそが監視でしょう。
5つの原則
Chaos Engineeringとは、5つの法則があります。出典は以下のサイトです。
実験自体を設計していると、以下の法則が非常に役に立ちます。
その5つの原則とは、以下の通りです。
1. 定常状態の振る舞いについて仮設を立てる
システムの内部の話ではなくて、正しく動作するかにフォーカスを当てます。
それはシステム全体のスループット、エラーレート、待ち時間パーセンタイル、CPU使用率などはすべて、定常状態の挙動を表すメトリックとして使用することができます。
ビジネスKPIに合っていたら、なおさら良いです。
検証中のシステムの行動パターンに焦点を当てることで、カオスはシステムがどのように動くかを検証するのではなく、機能するかどうかを検証します。
カナリア分析をするのもいいでしょう。
定義した定常状態の振る舞いに対するメトリクスをモニタリングをして、システムが機能するかを確認せよ！
2. 実世界のイベントを多様化する
カオスは、現実世界のエベントを反映するようなものでなければなりません。優先度の高いイベンtのは潜在的なインパクトがあるか、頻繁に起こるものです。
例えば
- ハードウェア的なバグ
- ネットワークのレイテンシ
- リソースの枯渇
など挙げたらキリがないほど起こりうるものはあります。
定常状態を壊しうるイベントは、すべてChaos Engineeringの実験対象です。
3. プロダクション環境で実験をすること
環境によって当然環境が異なり、時間によっても変化をするため、実際のアプリケーションで導入する必要がある。
4. 継続的に実験するために自動化をする
手動でChaos Engineeringを進めるには、労力が伴い、いずれやらなくなります。それはテストなども同様の理由です。継続的に進めるには、自動化が必須になると思います。
5. 影響範囲を最小化せよ
プロダクション環境で実際にユーザーがサービスを利用できなくなるまでサービスが落ちてしまったら、ビジネス的にも問題があります。
そのため、仮に不確実性に耐えられなくてもサービスに最小限の問題しか与えられないようにします。
実験のデザイン
1. 仮説を選ぶ
どの仮説を検証するのかを選ばなければなりません。最近Redisのタイムアウトがあったなら、システムがタイムアウトにたえられるか検証したいでしょう。
2. 実験のスコープを選ぶ
スコープを決めないといけませんが、ここでは２つの法則があります。先程の「プロダクション環境で実験をすること」と「影響範囲を最小化せよ」というものです。
プロダクション環境に近ければ近いほど得られるものが多いはずです。最初はスコープの小さい箇所から取り組むべきです。
3. 検証したいものにマッチするメトリクスを特定せよ
メトリクスがある場合は、どのくらい許容できるかを定義しなければ実験をやっても分かるものは少なくなります。
4. 組織に通知をする
プロダクション環境で実験をしているときは、組織のメンバーが慌てないように、何をしているのかを通知したほうがよいです。
実際に実験をしてみて、どれくらいのチームが結果に興味を持っているのか、または逆に、不安を抱えているのかを知ったほうがよく、いずれは組織の自信になります。
5. 実験を実行する
ここでやっとカオスな実験を遂行するときが来ました。
大事なのは、いざというときに実験を停止させることのできることです。特にシステムだけでなくて、サードパーティがいたりすると損害を与えてしまうかも知れません。
6. 結果を分析せよ
収集した結果で仮説が正しいかをチェックします。
実世界のイベントに対して耐障害性のシステムでありましたか？ほかに予想外の挙動がなかったですか？
とにかく、学び続けることが大事です。
7. スコープを増加する
最初は小さなスコープから、そして少しずつスコープを大きくしていきます。
8. 自動化する
これらの一連の流れは、自動化を進めて、より円滑なChaos Engineeringになるように心がけるべきです。
Chaos Engineering Toolで簡単にクラスタを壊してみる
1. モニタリングしながら、Chaoskubeを使う
今回は簡単にChaos EngineeringをすることができるChaoskubeを導入して実験を行ってきます。Githubリポジトリは以下の通りです。
Cloud Native Computing Foundationのこちらの部分に該当します。
Kube-ops-viewを使って、Podを監視しようと思います。知らない方は、以前まとめたのでご利用ください。
ChaoskubeはNamespace関係なく、Podをランダムに落とします。セルフヒーリングがあるKubernetesはどのようになるのでしょうか？
例えばMaster Nodeにあるkube-apiserver, kube-controller-manager と kube-schedulerが落ちれば、どのようになるでしょうか。
想像するだけでは分からないので実際に使ってみます。
現在のContainerの状況はこちらの通りです。
特に、Podを落とすinterval`フィールド以外はいじる機会はあまりないと思います。HelmでDeploymentをDeployします。
helm install stable/chaoskube --set interval="1m" --set dryRun=false --name chaoskube
ログを見てみると、以下の通りです。
... chaoskube-67f9d548cf-w9vv2 chaoskube time="2019-04-19T11:10:39Z" level=info msg="terminating pod" name=kube-dns-7df4cb66cb-jsznx namespace=kube-system chaoskube-67f9d548cf-w9vv2 chaoskube time="2019-04-19T11:11:39Z" level=info msg="terminating pod" name=kube-dns-7df4cb66cb-7b5m7 namespace=kube-system chaoskube-67f9d548cf-w9vv2 chaoskube time="2019-04-19T11:12:40Z" level=info msg="terminating pod" name=prometheus-to-sd-8qxnv namespace=kube-system chaoskube-67f9d548cf-w9vv2 chaoskube time="2019-04-19T11:13:39Z" level=info msg="terminating pod" name=tiller-deploy-54fc6d9ccc-vgwzl namespace=kube-system chaoskube-67f9d548cf-w9vv2 chaoskube time="2019-04-19T11:14:39Z" level=info msg="terminating pod" name=heapster-v1.6.0-beta.1-6879d79477-76sth namespace=kub ...
Podがコントロールされていた通りTerminationされています。
TerminationはKillとは違い、グレースフルシャットダウンをするようになります。実際にはKubectlによってdeleteしなければ、このようなことは起きないため、比較的、ゆるいものです。Issueにも上がっている話題です。
gracePeriodはデフォルトでは30秒になっており、プロダクション環境ではまずグレースフルシャットダウンはあり得ません。
クラスタ自体は壊れませんが、遊ぶにはちょうどいいでしょう。
またカオスエンジニアリングをするならば、実際のトラフィックやプロダクション環境にどのような影響があるかを実験しなければならず、この記事では「カオスエンジニアリングの理解とツールで遊んでみた」だけです。
まとめ
今回はChaos Engineeringの体系的な理解と、KubernetesクラスタにChaosKubeを載せてみて、実際にPodをTerminateさせている様子が分かりました。
やっと入り口に立ったレベルなので、もっとSREとして成長できるように猛頑張りしていきたいです。次の記事では、Chaos Engineeringの実践を行ってみようと思います。
最後まで、ありがとうございました！