chaoskube動機カオスだった平成最後の日に。Engineeringが採用されるのも遅い傾向があります。Engineeringについて猛勉強をして、ChaosKubeができる機能を試してみたので記事にしました。アジェンダこの記事のアジェンダは以下の通りです。Engineeringオライリーで無料で読むことができるので、以下の本を推薦します。Engineeringがどのようなもので、なぜ必要かを解説しようと思います。Engineeringとは、もともとはNetflix社が論文にて提案したものです。具体的には以下のように定義されています。production.私の拙い英語翻訳で明文化すると、以下の通りです。Engineeringとは、本番環境の分散システムが過酷な状況でも耐えられるとの確信を得るために、実験するという訓練のこと分散システムといえば、マイクロサービスが身近なところかなと思います。分散システムについて、またはマイクロサービスについて知識がなければ、以下の本を読むことをおすすめします。Engineeringは強力な実践方法で、分散システムにおけるシステムの不確実性を洗いだして、フォールトトレラントシステムを検証することに取り組んでいます。概念は大まかに理解できたといえど、何をしたらいいのか分かりません。以下の方法で検証をしていきます。正常な状態を定義するこの正常な状態が通常時と障害エミュレート時の両方で継続することを仮定するサーバクラッシュ、ディスク異常、ネットワークエラーなどの現実世界で起こりえる障害をエミュレートする1で定義した値を通常時と障害エミュレート時で比較し検証していくそして、結果として一番のゴールである顧客体験を損なわない分散システムが完了するのです。DevOpsには非常に重要な概念です。Monkeyなどはよく知られていますが、他にもたくさんの種類があります。medium.comレイテンシを膨大に発生させたり、サーバーを落としたり、いろいろな不確実性の形があります。やらないといけないの?マイクロサービスは、モノリシックな巨大サービスから小さなサービスへ移行し、よりベロシティ、スケーラビリティ、効率の良さなどを求めた結果、システムは複雑になり、組織間の連携も難化しました。何よりもマイクロサービス固有の問題として、高度で安定したインフラが求められます。「どのくらい確信をもって複雑なシステムをプロダクション環境で持てるの?」という疑問が出てきます。信頼と可用性を保証するために、サービス自体のアーキテクチャの標準化と個々のマイクロサービスが満たさなければならない要件が必要になります。止まる前に対策をできていなければなりません。「プロダクションレディ」という概念です。詳しくは以下の本で、詳しく解説されています。単行本(ソフトカバー)この商品を含むブログを見る「プロダクションレディにするには?」という問いに対して、満たさない要件を詰めていき、炙り出していくプロセスを行うと、高い信頼性と高可用性を保証できるようになると思います。Engineeringをしてしまおうということです。耐えられないなら、要件を満たすように構築すればいいのです。本来ならここで、このセクションは終わっていましたが、最近モニタリングに関する書籍が出たので少し触れます。Engineeringで解決できます。監視といえど、ただ可視化してアラートするだけでなく、そのあとの対応が何よりも重要となります。実際にインシデントを起こして、その状態をキャプチャして、そして次のアクションを起こせるようなシステムこそが監視でしょう。Engineeringとは、5つの法則があります。出典は以下のサイトです。実験自体を設計していると、以下の法則が非常に役に立ちます。principlesofchaos.orgその5つの原則とは、以下の通りです。定常状態の振る舞いについて仮設を立てるシステムの内部の話ではなくて、正しく動作するかにフォーカスを当てます。それはシステム全体のスループット、エラーレート、待ち時間パーセンタイル、CPU使用率などはすべて、定常状態の挙動を表すメトリックとして使用することができます。ビジネスKPIに合っていたら、なおさら良いです。検証中のシステムの行動パターンに焦点を当てることで、カオスはシステムがどのように動くかを検証するのではなく、機能するかどうかを検証します。カナリア分析をするのもいいでしょう。実世界のイベントを多様化するカオスは、現実世界のエベントを反映するようなものでなければなりません。優先度の高いイベンtのは潜在的なインパクトがあるか、頻繁に起こるものです。ハードウェア的なバグネットワークのレイテンシリソースの枯渇など挙げたらキリがないほど起こりうるものはあります。Engineeringの実験対象です。プロダクション環境で実験をすること環境によって当然環境が異なり、時間によっても変化をするため、実際のアプリケーションで導入する必要がある。Engineeringを進めるには、労力が伴い、いずれやらなくなります。それはテストなども同様の理由です。継続的に進めるには、自動化が必須になると思います。影響範囲を最小化せよプロダクション環境で実際にユーザーがサービスを利用できなくなるまでサービスが落ちてしまったら、ビジネス的にも問題があります。そのため、仮に不確実性に耐えられなくてもサービスに最小限の問題しか与えられないようにします。仮説を選ぶどの仮説を検証するのかを選ばなければなりません。最近Redisのタイムアウトがあったなら、システムがタイムアウトにたえられるか検証したいでしょう。実験のスコープを選ぶスコープを決めないといけませんが、ここでは2つの法則があります。先程の「プロダクション環境で実験をすること」と「影響範囲を最小化せよ」というものです。プロダクション環境に近ければ近いほど得られるものが多いはずです。最初はスコープの小さい箇所から取り組むべきです。検証したいものにマッチするメトリクスを特定せよメトリクスがある場合は、どのくらい許容できるかを定義しなければ実験をやっても分かるものは少なくなります。組織に通知をするプロダクション環境で実験をしているときは、組織のメンバーが慌てないように、何をしているのかを通知したほうがよいです。実際に実験をしてみて、どれくらいのチームが結果に興味を持っているのか、または逆に、不安を抱えているのかを知ったほうがよく、いずれは組織の自信になります。実験を実行するここでやっとカオスな実験を遂行するときが来ました。大事なのは、いざというときに実験を停止させることのできることです。システムだけでなくて、サードパーティがいたりすると損害を与えてしまうかも知れません。結果を分析せよ収集した結果で仮説が正しいかをチェックします。実世界のイベントに対して耐障害性のシステムでありましたか?ほかに予想外の挙動がなかったですか?とにかく、学び続けることが大事です。スコープを増加する最初は小さなスコープから、そして少しずつスコープを大きくしていきます。Engineeringになるように心がけるべきです。EngineeringをすることができるChaoskubeを導入して実験を行ってきます。Githubリポジトリは以下の通りです。Foundationのこちらの部分に該当します。Kube-ops-viewを使って、Podを監視しようと思います。知らない方は、以前まとめたのでご利用ください。www.1915keke.comChaoskubeはNamespace関係なく、Podをランダムに落とします。kube-schedulerが落ちれば、どのようになるでしょうか。想像するだけでは分からないので実際に使ってみます。現在のContainerの状況はこちらの通りです。全NamespaceのPod特に、Podを落とすinterval`フィールド以外はいじる機会はあまりないと思います。HelmでDeploymentをDeployします。chaoskubeログを見てみると、以下の通りです。namespace=kub...Podがコントロールされていた通りTerminationされています。TerminationはKillとは違い、グレースフルシャットダウンをするようになります。実際にはKubectlによってdeleteしなければ、このようなことは起きないため、比較的、ゆるいものです。Issueにも上がっている話題です。github.comgracePeriodはデフォルトでは30秒になっており、プロダクション環境ではまずグレースフルシャットダウンはあり得ません。クラスタ自体は壊れませんが、遊ぶにはちょうどいいでしょう。カオスエンジニアリングをするならば、実際のトラフィックやプロダクション環境にどのような影響があるかを実験しなければならず、この記事では「カオスエンジニアリングの理解とツールで遊んでみた」だけです。Engineeringの体系的な理解と、KubernetesクラスタにChaosKubeを載せてみて、実際にPodをTerminateさせている様子が分かりました。入り口に立ったレベルなので、もっとSREとして成長できるように猛頑張りしていきたいです。Engineeringの実践を行ってみようと思います。20:30Tweet関連記事2018-12-23Concourseで継続的デリバリー。»プロフィール学生エンジニア。忘れてしまうので備忘録です。flaskでServerlessにホストするTelepresence概論スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。