日本企業が「カオスエンジニアリングやっていく宣言」を出せた理由：クックパッドに直撃（1/2 ページ）

クックパッドが2018年8月2日に公開したブログエントリ「Chaos Engineering やっていく宣言」に大きな反響があった。米国を中心に多くの企業で実践されているが、疑似的とはいえ本番環境に障害を起こさせるというカオスエンジニアリングを日本で実践するのは、まず不可能という向きが多かったからだ。なぜ、クックパッドでは実践することが可能になったのか。

[高橋睦美，＠IT]

　今、エンジニアの間で注目を集めているキーワードが「カオスエンジニアリング」だ。動画配信サービスを提供するNetflixが導入したことで着目されるようになった手法で、本番サービスであえて疑似的な不具合を引き起こし、システムがどのように振る舞うかを把握する。ひいては、マイクロサービスを採用した大規模システムの安定性、可用性向上につなげていくことを目的とした取り組みだ。

　カオスエンジニアリングについては、いちエンジニアとして「面白そう、やってみたい」という声が上がる一方で、「でも、さすがにうちの会社でやるのは無理だよね……」とつぶやく声も散見される。そんな中で「Chaos Engineering やっていく宣言」を公開したのが、日本最大級の料理レシピ投稿・検索サービスの「クックパッド」だ。

　なぜ今、クックパッドではカオスエンジニアリングを導入するのか。その狙いを、同社 技術部 部長 兼 エンジニア統括マネージャーの庄司嘉織（ヨシオリ）氏に尋ねた。

クックパッド 技術部 部長 兼 エンジニア統括マネージャー 庄司嘉織（ヨシオリ）氏

カオスエンジニアリングの目的は本番環境を壊すことではない

　国内では、カオスエンジニアリングに対しては「面白そうだけれど、うちじゃ無理」といった声が多い。しかしヨシオリ氏は「カオスエンジニアリングは、耐障害性の高さを担保するためにやるもの。むしろ、なぜやらないのか、可用性の高さが求められるシステムであればあるほど導入すべきものではないかと言いたいですね」と話す。

　Netflixがまとめた論文にも示されているが、カオスエンジニアリングのポイントは、システムにとっての「カオス」、つまりちょっとした異常を注入し、正常なサービスの提供に影響がないかどうかを確認することだ。このため「Failure Injection」といった名前で呼ばれることもあり、「その方が実情に近いのではないか」とヨシオリ氏は言う。

Chaos Monkeyのロゴ（「GitHub - Netflix/chaosmonkey: Chaos Monkey is a resiliency tool that helps applications tolerate random instance failures.」から引用）

　「Netflixがオープンソースソフトウェアとして公開した『Chaos Monkey』『Chaos Kong』といったツールをはじめ、カオスという名前のせいで誤解されがちですが、カオスエンジニアリングは本番環境を壊すことを目的としているわけではありません。あれはあくまでも手段であって、可用性の高いシステムを作るためにやっているんです。ただいたずらにシステムに混乱を引き起こすもの、という誤解に引きずられてしまうのはもったいない」（ヨシオリ氏）

　逆に、その本質さえ理解していれば、カオスエンジニアリングの導入はそう高いハードルではない。クックパッドの場合はさらに2つの条件が整っていたそうだ。

　一つは「CTO（最高技術責任者）がちゃんとCTOとして機能していたことです。カオスエンジニアリングは可用性を高めるためにやるものだと理解し、そのために技術投資を行う決断ができ、さらにそのことをちゃんと他の経営層に伝えられることが大きいですね」（ヨシオリ氏）。率直に意思決定プロセスを振り返ると、「そろそろカオスエンジニアリングをやらないとうまく回らなくなるから、入れるよ」「そうだね」といった感じで決まったそうだ。

　もう一つは、環境が整ったのが大きな要因だ。クックパッドはここ数年、マイクロサービス化に取り組んできた。マイクロサービス化を可能にするコンテナ技術に加え、それを適切に扱うコンテナオーケストレーションの技術も出そろい、いよいよカオスエンジニアリングを行える状態になってきたという。

　「特に、@eagletmtが作成したコンテナオーケストレーションツールを使ってアプリケーションをデプロイする『hako』によって各サービスの管理が一元化されたこと。@taiki45が中心となってサービス間通信を一元管理する『Envoy』を導入したこと。この2つの技術が整ったのは大きいですね。今まではサービス間通信って、どことどこが通信しているかはそれぞれのサービス間でしか分からなかったので、通信するクライアント側に手を入れないと障害のエミュレーションができませんでした。それがEnvoyによってクライアント側に手を入れずにエミュレートできるようになったので楽になりました」

クックパッドでのサービスメッシュの概要（「Service Mesh and Cookpad - クックパッド開発者ブログ」から引用）

　その上、「既にChaos Monkeyレベルのことはやっていたのも大きいですね」とヨシオリ氏は話す。「cookpad.com」の環境は、全てAmazon EC2 スポットインスタンスの上で動いている。1日当たり2〜3回はAWS側に勝手に落とされているわけだ。

　「もちろんスポットインスタンスは落ちる前に通知が来るとか細かい違いはありますが、Docker化によるアプリケーションのImmutable Infrastructure化なども含め、インスタンスが落とされる前提でシステムを考えることはすでに行っていました。そういった意味では、クックパッドだけではなく、カオスエンジニアリングにラストワンマイルな状態になっている企業も多いのではないでしょうか？」（ヨシオリ氏）

マイクロサービスとカオスエンジニアリング

　何か起きたときでもサービスが正常に動き続けることを担保するため、大きなくくりでいえば日本企業が重視する「品質」を担保するための手段としてのカオスエンジニアリング。Webサービス系に限らず、可用性を重視するシステムならば導入のメリットは大きいが、ヨシオリ氏は「そもそも、マイクロサービス自体を必要とする企業もそんなに多くないかもしれません。モノリシックなサービスで、数台のサーバを立てていればOKというシステムならば、カオスエンジニアリングは必要ないと思います」と話す。

　可用性よりもまずサービスそのものの成長を目指す段階にある企業にとってもまた、カオスエンジニアリングはまだ荷の重い作業だ。当たり前だが、「何だか面白そう」で導入するのではなく、今の自社のサービスにとって何が重要で、それを達成するために必要な手段は何かを考えることが第一となる。

　現時点で、クックパッドの本番環境で動作しているマイクロサービス群は70以上あるという。その全てが密に連携しているわけではないが、障害が起きたとき、どこで何が起きているか分からないし、その影響がどこまで波及するか予測するのが不可能になってきていた。実際、Aというサービスが参照するBというサービスがさらにチェックするCというサービスのレスポンスタイムが遅くなったことが原因で、スマホの画面に何も表示できなくなる……といった恐れが現実のものになってきたという。

　「個人的には3年くらい前からずっと、楽しそうだからカオスエンジニアリングをやりたいなと言っていましたが、マイクロサービス化がどんどん進んだ結果、本当にカオスエンジニアリングを導入しないとエラーが予測できなくなってきたんですね」とヨシオリ氏は振り返る。

　鶏が先か卵が先か、かもしれないが、マイクロサービス化が進んだからカオスエンジニアリング導入に踏み切れただけではなく、だからこそカオスエンジニアリングが必要になったともいえる。