Engineering』(以下、カオスエンジニアリング)を語らずにはいられません。カオスエンジニアリングは、マイクロサービスやサービスメッシュなどのモダンなシステムアーキテクチャにおいて、これから主流になっていくであろう障害対策のひとつです。先人のわかりやすい言葉を借りながら、初めて耳にする方にもなるべくやさしく説明していきます。カオスエンジニアリングを知るカオスエンジニアリングとは?カオスエンジニアリングとは、全世界に動画配信サービスを提供するNetflixが導入したことで注目されるようになった手法で、「本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にもちゃんと耐えられるようにしよう」という取り組みです。小規模の障害を意図的に発生させ、特定のサービスが一時的に使用できなくなったときにシステムがどう対応するかを把握します。このようなトラブル対処の知見を蓄積していき、サービスを大規模化したときの安定的な運用につなげます。みなさんは、オフィス火災の避難訓練は経験があると思いますが、まさに「ITの避難訓練」ようなイメージです。Netflixは、2015年に、このカオスエンジニアリングで、実際にAWSの大規模障害を乗り切り、大きな話題となりました。(AWS大規模障害を乗り越えたNetflixが語る「障害発生ツールは変化に対応できる勇気を与えてくれる」)現在、Netflixだけではなく、大規模な金融機関や製造業、ヘルスケア業界でも適用されているそうです。発表されており、世界的注目度が伺えます。カオスエンジニアリング?なにがカオスなの?カオスエンジニアリングの「カオス」は、日本語でよく訳される「混沌」という意味ではなく、「カオス理論・力学、あるいは複雑系」というニュアンスが正しいです。分散システムは複雑で、小規模な障害や事象を加えるとカオス的な振るまいをする(=何がどうなるかわからない)のでカオスと呼ばれるようになったみたいです。カオスなのは「分散システムの振るまい」であり、意図的に起こされる障害はコントロールされたものです。必要に迫られている背景は?(利点は?)時代は、「集中システム(モノリシックサービス)」から「分散システム(マイクロサービス)」に、トレンドは移行しています。このトレンドを反映した、Docker、Kubernetes、Istioなどのモダンなテクノロジーたちは、これまで良いとされてきた「ダウンしないサービス」を目指しているのではなく、万が一ダウンしても、即時に「自動回復可能なサービス」を目指して設計されています。このようなパラダイム・シフトに伴い、障害の質が変化しており、原因がどこにあるのかつきとめにくく、リカバリーの影響範囲がわかりづらくなるなどの弊害が生じています。そこで登場するのが、障害を早期に見つけ被害を最小限に抑える取り組みであるカオスエンジニアリングです。対策が後になればなるほどコストと手間がかかります。早い段階で障害を見つけることで、被害やコストを最小限に抑えることが可能になります。続いて、カオスエンジニアリングにおける5つの原則をみていきましょう。Engineering』によると、以下の5つの原則を定義しています。stateシステムの「定常状態」とはなにか、どのような値をどのような早さで「どうアウトプットするのか」に注目する。eventsカオスとして定義されるものはさまざまなので、潜在的影響や想定される発生頻度を考慮して、優先順位をつけて実験をする。production「実験」といはいえ、実際にカオスエンジニアリングをおこなうのは本番環境である。質の高いデータを手に入れるために、本番環境で実験をおこなう。continuously実験は継続的にしなければデータが集まらず、おこなう意味がない。自動化して継続的に実行する仕組みを作ることを目指す。radius本番環境で実験をおこなえば、想像以上の悪影響がおこる可能性がある。ユーザーに被害を受けさせないよう、緊急停止を可能にするなど被害を最小限に抑える工夫が必要である。いつでもトラブルへの対処ができるよう、実験は深夜ではなくオフィスに人がいる日中におこなう。小難しい言葉が並んでいますが、「計画的に本番環境で実験しなさい」と唱えられています。カオスエンジニアリングを実現するこのカオスエンジニアリングの5原則を実現するにあたり、カオスエンジニアリングツールが不可欠になります。現状、20以上のカオスエンジニアリングツールが存在しており、選定は難しい段階ですが、有名なものをいくつか紹介したいと思います。Netflix/chaosmonkeyNetflixが公開している最も有名なカオスエンジニアリングツールです。クラウドインスタンスやKubernetes上のコンテナを落とすだけでなく、NW、DISK、CPUの負荷を高くしたりと様々な障害を注入できます。Spinnakerと言う「継続的デリバリ(CD)」ツールの導入が必須となっており、少々敷居が高いですが、様々な角度から大暴れできます。Monkeyのような挙動をDockerのコンテナレベルで行うカオスエンジニアリングツールです。コンテナより下位レイヤーに障害を注入することは出来ないですが、非常に扱いやすく、カオスエンジニアリング対象のスコープが合えば十分に効果のあるものだと思います。Serviceと呼ばれる、システムに障害を注入するためのSaaSプラットフォームです。本番に組み込むなら、一つのサービスにしてしまえといった思想のもと生まれたものです。カオスエンジニアリングを導入するためにシステム構成を大きく変更することなく、インフラ、アプリケーションに障害を注入できます。AWSでも紹介されていたもので、注目株です。率直に「本番環境で障害をわざと起こすなんてとんでもない」と考えるエンジニアやサービスオーナーがほとんどだからだと予想していますが、そもそも、マイクロサービス(分散システム)自体を必要とする企業が、まだ多くないからかもしれません。単純なモノリシックサービス(集中システム)であれば、無理にカオスエンジニアリングを適用することは不要で、従来の耐障害試験を、しっかり行えば良いと思います。カオスエンジニアリングは、自動復旧可能なシステムであることが前提なので、ダウンしないように開発されている従来ながらのシステムへの適用は、メリット以上に障壁が多いと思われます。カオスエンジニアリングは、どのようなシステムにも適用可能なものではないことに注意して、導入を検討してください。まとめカオスエンジニアリングの取り組みは、決して容易なことではありません。本番環境で障害をエミュレートすることの本質を理解した上で、サービスオーナー各所への説得も必要となりますし、必然的に開発・構築コストも上がります。発生する障害対応のコストと手間をはじめ、サービスのダウンタイムは、機会損失につながったり、社会的信用をまで失う可能性まであるので、その代償と比べれば安いもののはずです。IaaS利用者は、IaaSは落ちてしまうものとして設計すべきであり、こんな大掛かりなことが出来なくとも、自動復旧すること、部分的にでもサービス継続可能なこと、リージョン別のDRサイトを持つことをポイントに、しっかり耐障害設計するようにしましょう。このカオスエンジニアリングは、国内でも着実に認知を広めています。やっていく宣言」を公表しました。マイクロサービス時代のトレンドも後押しして、今後は日本でもカオスエンジニアリングを導入する企業が増えていくことが予想されます。これを機会に、システム担当者の方は、ぜひ導入を検討してみてください。「攻め」も「守り」も、かっちりと。カオスエンジニアリングにおけるRFCのようなドキュメントです。オライリー社のカオスエンジニアリング書籍です。GitHub上で最新のカオスエンジニアリングについての情報が寄贈されています。Qiitaの中で最もよくまとまっています。クックパッド社の国内事例です。わかりやすい解釈でカオスエンジニアリングを説明されています。Naoki@naokiiiii歌って踊れるエンジニアを目指しています。基盤サービス」の4事業でお客様のビジネスや快適な社会、暮らしを支えています。※各記事の内容は個人の見解であり、所属する組織の公式見解ではありません。upLoginユーザーは見つかりませんでした。