カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応

カオスエンジニアリング（Chaos Engineering）とは、稼働中のサービスにあえて擬似的な障害を発生させることで、システムの耐障害性を検証する手法です。動画配信サービスを提供するNetflix社が2011年ごろから実践し、ソフトウェアや情報を積極的に公開したことで世界中から注目されるようになりました。

国内ではまだ導入事例も少ないなか、料理のレシピ投稿・検索サービスを提供するクックパッド株式会社では2年前からこの手法に取り組み、カオスエンジニアリングのさまざまな事例やノウハウを蓄積しています。

Chaos Engineering やっていく宣言 - クックパッド開発者ブログ

今回は、クックパッドの技術部・SR（Site Reliability）グループの小杉山拓弥さんとDX（Developer Productivity）グループの鈴木康平さんに、カオスエンジニアリング導入の理由や、この手法を成功につなげる知見について伺いました。

• まずは仮説を立てる
• ステージング環境におけるFault Injectionによる検証
• プロダクション環境での検証が必要になる理由
• 効果的な負荷試験のためツール構成を選択する
• 成熟したサービスだからこそカオスエンジニアリングが有効

※新型コロナウィルス感染拡大防止の観点から、インタビューはリモートで行いました。

まずは仮説を立てる

── クックパッドは、なぜカオスエンジニアリングを導入したのでしょうか？

鈴木　前提としてクックパッドでは、これまでモノリシックだったサービスのマイクロサービス化を進めてきました（記事末の関連記事も参照）。サービス分割のプロジェクトは順調だったものの、マイクロサービス化に伴ってサービス全体の可用性が落ちている実感がありました。

なぜなら、サービス間の通信回数が増えるに伴って、通信が失敗するおそれのある箇所も増加してしまうからです。

この課題を解決するため、技術部を中心に「カオスエンジニアリングが有効ではないか？」という話が持ち上がりました。そこで小杉山を主担当として、カオスエンジニアリングを推進することにしたのです。

── カオスエンジニアリングの導入を決めたといっても、まだ実践の参考にできる情報も限られていたのではないでしょうか。

小杉山　私たちが調査をはじめたのは、Netflix社がオープンソースソフトウェアとして公開したChaos Monkeyなどのツールが注目を集めていたころで、カオスエンジニアリングといえば「インスタンスやネットワークを落としてテストをする」というキャッチーな面ばかりがフォーカスされることもよくありました。

しかし、そうした表面的なテスト技法を学ぶよりも、カオスエンジニアリングにおいては「どのような思想に基づいて検証を行うのか」という理念を知ることの方が、より重要です。カオスエンジニアリングの原則を提唱した「Principles of Chaos Engineering」などは非常に役に立ちました。

他にも参考資料としては、Netflixの知見が解説された論文「Chaos Engineering paper」[PDF]や、技術ブログの記事「The Netflix Simian Army」、それから当時はまだ出版されていませんでしたが、現在であればオライリー社の書籍『Chaos Engineering』はとても参考になると思います。

例えばそういった資料には、カオスエンジニアリングにおいて仮説を立てることの重要性が記載されています。そうした情報を学べたことはとても有益でした。

── 「仮説を立てる」というのは、例えばどのようなことですか？

小杉山　冒頭で鈴木が話したように、当社においては「サービス間通信が増えることで、可用性が落ちているのではないか？」という懸念がありました。このケースにおいて仮説を立てる作業とは、通信でエラーが発生したときに「各サービスはどのようなふるまいをすべきなのか？」を考えることです。

複数のサービスが相互に通信をしているときに、いずれかのサービスがエラーになった場合、サイトの閲覧そのものができなくなるべきなのか？ または、表示項目が少し欠けた状態でサイトは表示されるべきなのか？ そういった仮説を立てた上で、検証を行います。

検証の結果、仮説が誤っていることが判明したならば、どのようにシステムを修正すれば適切な挙動になるのかを検討していきます。逆に、仮説を立てられない状態ならば、カオスエンジニアリングを導入するにはまだ時期尚早であるとも言えます。

ステージング環境におけるFault Injectionによる検証

── 実際にどういった検証から手を付けていったのかを教えてください。

小杉山　カオスエンジニアリングの手法のひとつに、Fault Injection（障害注入）があります。当社はマイクロサービス化の推進に伴ってサービスメッシュ基盤を整備していますが、そのデータプレーンとして用いているEnvoyにはFault Injectionの仕組みが備わっているので、まずこれを活用しました。

Fault Injection — envoy documentation

このテストをネットワークに対して行い、想定する挙動と実態が合っているかを調べることにしました。クックパッドでは、ステージング環境もプロダクション環境も同じようなサービスメッシュ基盤を用いていますから、ユーザーに影響が出ないよう、ステージング環境で個別のサービスの検証を進めていきました。

── 検証によってどのような問題が分かったのでしょうか？

小杉山　例えばあるサービスでは、レシピ情報のAPI呼び出し結果をキャッシュしている機構に問題がありました。API呼び出しが一度失敗してしまった場合、APIの復旧後にも失敗した結果のキャッシュをひたすら返し続けていたのです。

実はこれには理由がありました。レシピ情報のAPIに障害が発生しているときに、呼び出し元がリトライをくり返すとサービスの負荷が高くなり、障害がさらに拡大するおそれがあります。つまり、延焼させない防壁のような役割を果たしていました。ところが、障害発生時のリトライ制御はサービスメッシュのレイヤーで実現できますから、アプリケーションの外でハンドリングした方がメンテナンス性に優れます。

このように不具合もいくつか発見でき修正もしましたが、全体としては自分たちが予想していたより遥かに適切なエラーハンドリングが、各サービスで行われていました。

── ネットワークに関する処理をアプリケーションレイヤーから分離できるのは、マイクロサービスや分散システムでサービスメッシュを用いる利点のひとつですね。

鈴木　そうですね。当社ではかつてExpeditorというgemを開発して、サービス間通信におけるリトライやフォールバックなどをアプリケーションレイヤーで実現しようと試みていた時期がありました。

ですが、gemはRuby言語専用のパッケージ管理システムです。マイクロサービス化が進み採用される言語・フレームワークが多様化するにつれて、Rubyでしか使えないことがネックになっていきました。

また、アプリケーションレイヤーでリトライやフォールバックなどを実現すると、各種の設定についてコンフィグファイルやプログラムの実装を読まなければ分からないという欠点も生じます。そうした課題を解決する上で、サービスメッシュの導入は非常に意義のあるものでした。

クックパッド株式会社 技術部 DX（Developer Productivity）グループ 鈴木康平さん

プロダクション環境での検証が必要になる理由