はじめに
Docker、Kubernetes、Istioと来れば、次は『Chaos Engineering』（以下、カオスエンジニアリング）を語らずにはいられません。カオスエンジニアリングは、マイクロサービスやサービスメッシュなどのモダンなシステムアーキテクチャにおいて、これから主流になっていくであろう障害対策のひとつです。先人のわかりやすい言葉を借りながら、初めて耳にする方にもなるべくやさしく説明していきます。
※ 本記事は2年前の内容です。カオスエンジニアリングの現状をUPDATEする形で続編も投稿しましたので、よろしければこちらもご覧になってください。「カオスエンジニアリングと聞いてカオスになった人必見(続)」
カオスエンジニアリングを知る
カオスエンジニアリングとは？
カオスエンジニアリングとは、全世界に動画配信サービスを提供するNetflixが導入したことで注目されるようになった手法で、「本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にもちゃんと耐えられるようにしよう」という取り組みです。
まず、小規模の障害を意図的に発生させ、特定のサービスが一時的に使用できなくなったときにシステムがどう対応するかを把握します。このようなトラブル対処の知見を蓄積していき、サービスを大規模化したときの安定的な運用につなげます。みなさんは、オフィス火災の避難訓練は経験があると思いますが、まさに「ITの避難訓練」ようなイメージです。
Netflixは、2015年に、このカオスエンジニアリングで、実際にAWSの大規模障害を乗り切り、大きな話題となりました。（AWS大規模障害を乗り越えたNetflixが語る「障害発生ツールは変化に対応できる勇気を与えてくれる」）
現在、Netflixだけではなく、大規模な金融機関や製造業、ヘルスケア業界でも適用されているそうです。また、先日行われた『AWS re:Invent 2018』でも、CON310 - Breaking Containers: Chaos Engineering for Modern Applications on AWS が発表されており、世界的注目度が伺えます。
カオスエンジニアリング？なにがカオスなの？
カオスエンジニアリングの「カオス」は、日本語でよく訳される「混沌」という意味ではなく、「カオス理論・力学、あるいは複雑系」というニュアンスが正しいです。
分散システムは複雑で、小規模な障害や事象を加えるとカオス的な振るまいをする（＝何がどうなるかわからない）のでカオスと呼ばれるようになったみたいです。
※ カオスなのは「分散システムの振るまい」であり、意図的に起こされる障害はコントロールされたものです。
必要に迫られている背景は？（利点は？）
時代は、「集中システム（モノリシックサービス）」から「分散システム（マイクロサービス）」に、トレンドは移行しています。そして、このトレンドを反映した、Docker、Kubernetes、Istioなどのモダンなテクノロジーたちは、これまで良いとされてきた「ダウンしないサービス」を目指しているのではなく、万が一ダウンしても、即時に「自動回復可能なサービス」を目指して設計されています。このようなパラダイム・シフトに伴い、障害の質が変化しており、原因がどこにあるのかつきとめにくく、リカバリーの影響範囲がわかりづらくなるなどの弊害が生じています。
そこで登場するのが、障害を早期に見つけ被害を最小限に抑える取り組みであるカオスエンジニアリングです。対策が後になればなるほどコストと手間がかかります。早い段階で障害を見つけることで、被害やコストを最小限に抑えることが可能になります。
カオスエンジニアリングを深める
カオスエンジニアリングの5原則
続いて、カオスエンジニアリングにおける5つの原則をみていきましょう。『Principles of Chaos Engineering』によると、以下の5つの原則を定義しています。
1. 定常状態の振る舞いについて仮説を立てる：Hypothesize about steady state
システムの「定常状態」とはなにか、どのような値をどのような早さで「どうアウトプットするのか」に注目する。
2. 実世界の事象は多様である：Vary real-world events
カオスとして定義されるものはさまざまなので、潜在的影響や想定される発生頻度を考慮して、優先順位をつけて実験をする。
3. プロダクション環境で実験を実行する：Run experiments in production
「実験」といはいえ、実際にカオスエンジニアリングをおこなうのは本番環境である。より質の高いデータを手に入れるために、本番環境で実験をおこなう。
4. 実験を自動化して継続的に実行する：Automate experiments to run continuously
実験は継続的にしなければデータが集まらず、おこなう意味がない。自動化して継続的に実行する仕組みを作ることを目指す。
5. 爆発半径を最小化する：Minimize blast radius
本番環境で実験をおこなえば、想像以上の悪影響がおこる可能性がある。ユーザーに被害を受けさせないよう、緊急停止を可能にするなど被害を最小限に抑える工夫が必要である。いつでもトラブルへの対処ができるよう、実験は深夜ではなくオフィスに人がいる日中におこなう。
と、小難しい言葉が並んでいますが、「計画的に本番環境で実験しなさい」と唱えられています。
カオスエンジニアリングを実現する
このカオスエンジニアリングの5原則を実現するにあたり、カオスエンジニアリングツールが不可欠になります。現状、20以上のカオスエンジニアリングツールが存在しており、選定は難しい段階ですが、有名なものをいくつか紹介したいと思います。
Chaos Monkey
Netflixが公開している最も有名なカオスエンジニアリングツールです。クラウドインスタンスやKubernetes上のコンテナを落とすだけでなく、NW、DISK、CPUの負荷を高くしたりと様々な障害を注入できます。Spinnakerと言う「継続的デリバリ（CD）」ツールの導入が必須となっており、少々敷居が高いですが、様々な角度から大暴れできます。
pumba
Chaos Monkeyのような挙動をDockerのコンテナレベルで行うカオスエンジニアリングツールです。コンテナより下位レイヤーに障害を注入することは出来ないですが、非常に扱いやすく、カオスエンジニアリング対象のスコープが合えば十分に効果のあるものだと思います。
Gremlin
Gremlin: Chaos Engineering Tools to Break Things on Purpose
Failure as a Serviceと呼ばれる、システムに障害を注入するためのSaaSプラットフォームです。どうせ本番に組み込むなら、一つのサービスにしてしまえといった思想のもと生まれたものです。また、カオスエンジニアリングを導入するためにシステム構成を大きく変更することなく、インフラ、アプリケーションに障害を注入できます。冒頭でも書きました『AWS re:Invent 2018』で発表されたCON310 - Breaking Containers: Chaos Engineering for Modern Applications on AWSでも紹介されていたもので、注目株です。
カオスエンジニアリングとはいえ・・・
国内で普及しない理由
率直に「本番環境で障害をわざと起こすなんてとんでもない」と考えるエンジニアやサービスオーナーがほとんどだからだと予想していますが、そもそも、マイクロサービス（分散システム）自体を必要とする企業が、まだ多くないからかもしれません。
また、単純なモノリシックサービス（集中システム）であれば、無理にカオスエンジニアリングを適用することは不要で、従来の耐障害試験を、しっかり行えば良いと思います。また、カオスエンジニアリングは、自動復旧可能なシステムであることが前提なので、ダウンしないように開発されている従来ながらのシステムへの適用は、メリット以上に障壁が多いと思われます。
すなわち、カオスエンジニアリングは、どのようなシステムにも適用可能なものではないことに注意して、導入を検討してください。
まとめ
カオスエンジニアリングの取り組みは、決して容易なことではありません。本番環境で障害をエミュレートすることの本質を理解した上で、サービスオーナー各所への説得も必要となりますし、必然的に開発・構築コストも上がります。しかしながら、突然発生する障害対応のコストと手間をはじめ、サービスのダウンタイムは、機会損失につながったり、社会的信用をまで失う可能性まであるので、その代償と比べれば安いもののはずです。
特にIaaS利用者は、IaaSは落ちてしまうものとして設計すべきであり、こんな大掛かりなことが出来なくとも、自動復旧すること、部分的にでもサービス継続可能なこと、リージョン別のDRサイトを持つことをポイントに、しっかり耐障害設計するようにしましょう。
また、このカオスエンジニアリングは、国内でも着実に認知を広めています。例えば、クックパッド社は2018年8月に「Chaos Engineering やっていく宣言」を公表しました。マイクロサービス時代のトレンドも後押しして、今後は日本でもカオスエンジニアリングを導入する企業が増えていくことが予想されます。
これを機会に、システム担当者の方は、ぜひ導入を検討してみてください。「攻め」も「守り」も、かっちりと。
参考
Principles of Chaos Engineering
※ カオスエンジニアリングにおけるRFCのようなドキュメントです。
Chaos Engineering [Book]
※ オライリー社のカオスエンジニアリング書籍です。Freeで読めます。
GitHub - dastergon/awesome-chaos-engineering: A curated list of Chaos Engineering resources.
※ GitHub上で最新のカオスエンジニアリングについての情報が寄贈されています。
Chaos Engineeringの概要とPumba入門 - Qiita
※ Qiitaの中で最もよくまとまっています。おすすめ。
日本企業が「カオスエンジニアリングやっていく宣言」を出せた理由
※ クックパッド社の国内事例です。
カオスエンジニアリングとは？わざと障害を起こして復旧対処する、システムの”筋トレ” | Workship MAGAZINE(ワークシップマガジン)
※ わかりやすい解釈でカオスエンジニアリングを説明されています。