カオスエンジニアリングを組織にも適用。アンチフラジャイルなシステムを目指してユーザベースが発見した問題とは？

Netflixがシステム運用に取り入れている、カオスエンジニアリング（chaos engineering）という手法があります。例えば機能を冗長化したシステムでも、いざ障害が起きたときに別系統が想定どおり機能するか分からない。そこで実際に動いているシステムで意図的に障害を起こし、挙動を確認してシステムの改善につなげる考え方です。

株式会社ユーザベースでは、アンチフラジャイル（antifragile、反脆弱）なシステムを目指してカオスエンジニアリングを導入しています。システムだけでなく、エンジニア組織においてもカオスエンジニアリングを応用した改善プロセスに着手しています。キーパーソンがいなくなってもプロジェクトはうまく動き続けるか、実際に外れてもらって確認するのです。

このチャレンジングな取り組みについて、CTOの林尚之さんと、システムでも組織でもカオスエンジニアリングを体験したエンジニアの野口光太郎さんに話をうかがいました。

※ この記事は株式会社ユーザベースによるSponsoredContentです。

野口 光太郎（のぐち・こうたろう、@enk_enk、上記の写真左）

株式会社ユーザベース Product Division ソフトウェアエンジニア
大学で文学部卒業後、エンジニアとして独立系SIerに入社し、その後パッケージソフト企業へと転職。Javaでのデータ連携ミドルウェアの開発に従事。2019年7月にユーザベースに入社し、現在はProduct DivisionのエンジニアとしてFORCAS事業のプロダクト開発に従事。

林 尚之（はやし・たかゆき、@t_hyssh、同右）

株式会社ユーザベース B2B SaaS事業 執行役員 CTO
松山大学経済学部を卒業後、SIerを経て2009年に独立。エンタープライズ向けシステム開発等に従事した後、2013年からSPEEDAの開発にフリーランスとして参画。2017年1月に入社し、2018年1月より現職。2021年9月にはUB Datatechの代表取締役にも就任。

5分に1度、自動的に障害を注入する

── ユーザベースではカオスエンジニアリングを導入したとお聞きしました。まだ国内でカオスエンニアリングを実践している企業はそう多くないと思いますが、どのような経緯で始めたのでしょうか？

林　カオスエンジニアリングは、以前からすごくやりたいと思っていました。ただ、そのころ私が見ていたSPEEDAでいきなり試すには、システム的に大き過ぎます。前段階として小さなシステムでフィードバックサイクルを回して、知見をためたいと考えました。

そこへ去年（2020年）ちょうど、FORCAS Salesをリリースしました。作り始めでサイズ的にもまだ大きくなく、導入するのに適切なタイミングだろうということで、今年（2021年）4月からFORCAS Salesでカオスエンジニアリングを始めています。

── 野口さんはその開発チームにいたわけですよね。カオスエンジアリングを始めると聞いて、どういうお気持ちでした？

野口　そんな特別なことはなくて「ああいいな。ぜひやりましょう」という感じでした。カオスエンジアリングについては「Netflixがやっている」というぐらいのふわっとしたイメージでしたが、システム面はSREが主導してくれました。

林　SREでも、実践する中で「こういう感じでやっているけど、これでいいんだろうか」と疑問が出てきて、カオスエンジニアリングの本を読み直したり勉強していたようです。

そこで得られた知見は、社内でプロダクトチームが技術的な発表をするTech Forumにおいて、SREから3週に分けてトータルで2時間半ぐらいかけて共有してくれました。

── 対象はいまのところFORCAS Salesでしょうか？

林　はい。ほかのサービスまでは展開していませんが、できそうだとは思っています。まだFORCAS Salesでもステージング環境への導入で、本番環境にはこれから適用しようと取り組んでいます。そこでめどを立ててから、同じ規模のサービスに行きたいですね。

そのステージング環境はできるだけ本番環境と同等にして、社内からアクセスしてもらったり、負荷試験的なこともしています。ただ、まったく同じではないので、最終的には本番環境で大丈夫ということを確認したいですね。

── FORCAS Salesで、具体的にカオスエンジニアリングとしてどういうことを実行したか、野口さんが体験したことをお話しください。

野口　FORCAS Salesのシステムは、マイクロサービスアーキテクチャで、Kubernetesを使っています。1つのプロダクトが、ざっくり10ぐらいのサービスで構成されていて、それぞれが冗長化されて動いています。

そこで実施したことは2つあります。まず、冗長化されているうち1つを突然落とすとどうなるか。もう1つは、それぞれのサービスのレスポンスを遅くするとどうなるか。それぞれ、そのときBFF（Backend For Frontend）のAPIにリクエストをして確認しています。

── どれぐらいの頻度で実行しているのでしょうか？

野口　Litmusというツールを使って、現在は5分に1度、自動的に障害を注入しています。

最初は「これからやるよ」と宣言してから実行して、発見された問題を改善しました。それから高い頻度で継続的に実施するようにしたのが現在の状態です。

林　システムは修正を続けていると、どこかのタイミングで壊れることがあります。自分たちの考えている冗長化が正しく動き続けるかどうか、継続的にチェックしています。

定常状態からシステムを把握して問題を発見

── 初期の実施では、どういった問題が分かったのでしょうか。

野口　まず実施を準備してる段階で、それぞれのAPIに定常状態でどれぐらい時間がかかっているか分かったことが、思わぬ発見でした。

林　普通の状態が分かっていないと悪い状態も分からないので、取り組みの前に調べたところ「ここがダメじゃないか」という箇所がいくつか出てきて、もとからカオスだったんじゃないかという（笑）。壊れていたわけではないけど、想定より遅かった箇所もありました。

── 実施前に意外な問題が見つかったわけですね。実践した結果はどうだったでしょう？

野口　意外と「ちゃんと動いているね」という感じです。レスポンスを遅くしても、動作が遅くなることはあっても、ほとんど動いていました。ただ、一部には処理が詰まって返ってこなくなる箇所があって、修正しました。これは本番環境で起きてもいつの間にか直ってることがありますが、それが発見できました。

── カオスエンジニアリングのメリットは、やはりそういった問題の発見でしょうか？

林　それも1つあります。また、障害が起きたときに想定通り動くことを認識する、あるいは想定通り動かなかったり、対策しているから大丈夫だろうと思ったら甘かったりするところも見つけられます。

やれることはまだまだたくさんあると思っていて、例えばマイクロサービスにはサーキットブレーカー（遮断機）があります。サービスが疎結合でつながっているときに、1つが止まったら連鎖して全体が止まってしまわないよう、一部が止まるだけでサービスは動き続けるように設けるものですが、設定したサーキットブレーカーが正しいかどうかも、カオスエンジニアリングで検証できると思います。

── 5分に1度という継続的な障害注入は、いつごろから始めたのでしょうか？

野口　今年（2021年）の8月ごろだったと思います。継続的な実施に切り替えても特に新しい問題はなかったのですが、監視を強化したので、間接的に監視システム側の問題が見つかったりしました。

林　意外にちゃんと動いていた背景には、KubernetesとIstioによるサービスメッシュを組んでいて、リトライなどをうまく処理しているというのがあります。

野口　Istioのリトライ機能を有効にしたのも、カオスエンジニアリングで問題を発見したことがきっかけです。Podを冗長化していても、1つが落ちたときに、アクセスしたタイミングによって落ちた方にルーティングされてしまって、リクエストがエラーになることがあります。それが見つかったんです。

Istioはサイドカーという仕組みでPodに付いて、リトライの仕組みを入れられる。アプリのコードにリトライがなかったのですが、Istioの機能を有効にすることでアプリの改修なしで対応できました。これも成果ですね。

林　カオスエンジニアリングを実施する上では、KubernetesやIstioの恩恵をかなり受けています。Kubernetesにはスケールであったり、Podがダウンしたときに自動で復旧させる仕組みがある。使っていなかったらたぶんすごく大変でした。

FORCAS Salesがクラウドネイティブな若いサービスだからこそ、カオスエンジニアリングを最初に導入できたところはあると思います。

サービスの継続性を意識する文化ができた

── カオスエンジニアリングをやってみた感想はいかがでしょうか？

野口　部分的な障害が発生してもちゃんと動くことが分かって「安心できた」ということは間違いなくあります。新しく開発したサービスで、本当に動くか不安がありましたので。

予期していなかったメリットとしては、チームのみんなが「サービスの継続性」を意識してくれて、サーキットブレーカーみたいな考え方について会話できるようになったことがあります。耐障害性に関するチームの意識や文化が生まれつつあります。

── 意識や文化が変わったことも狙った結果でしょうか？

林　狙っていたかというと、狙ってはいませんでした。ただ、それを意識すべきという課題感はあったので、カオスエンジニアリングを通してそちらに向かうのは良いことです。変化を拡大しつつ、日常的に意識する、当然にすることが大事だと思います。

私たちの組織ではTDD（テスト駆動開発）を導入していて、テストを書かないという選択肢は普通に出てこないんですね。同じように、よいサービスを作るためにカオスを注入するのは普通のことだよね、という文化にしていきたいです。

── 反対に、ここはもっと頑張らなくちゃということはありますか？

野口　その話の裏返しで、サービスの継続性をみんな意識できていなかったということを突き付けられた感はあります。SREの取り組みやKubernetesの仕組みの上でうまく動いていたのですが、なぜうまくいっているかを理解していなかったと反省しました。

── カオスエンジニアリングを全社に展開するのはいつごろになるでしょう？

林　それはあまり考えていないですね。効果がうまく発揮されないサービスもあると思ってますし、むしろ先ほど言ったように、サービスの継続性を日常的に意識することを目指しているので、特定のシステムでカオスエンジニアリングが導入されているかどうかは関係なくて、意識した上であえて導入しないならそれでもいいと思っています。

── なるほど。仕組みよりも意識が大切ということですね。

チームのキーパーソンを隔離して組織の問題をあぶり出す

── カオスエンジニアリングを、システムだけでなく組織のヒューマンリソースにも適用しているともお聞きしました。システムに導入した後でしょうか？

林　組織のカオスエンジニアリングもFORCAS Salesのチームで始めましたが、ほぼ同じタイミングだったと思います。四半期ごとにOKR（Objective and Key Result）を立てるんですが、2021年4月に「レジリエントな組織になる」というObjective（目標）を立てました。

そのとき、システム面のカオスエンジニアリングで回復力のあるシステムにし、組織面でもカオスエンジニアリングを導入したいと掲げたのが最初です。最初は別の表現を使ってたんですが、野口さんたちが言っていたレジリエント（resilient、回復性）やアンチフラジャイルという言葉を取り入れました。

── 組織へのカオスエンジニアリングは、前例としてもChaos Conf 2019におけるGoogleの発表くらいしかないようですが。

Dave Rensin: Chaos Engineering for People Systems - Chaos Conf 2019

そうですね。Googleが従業員に対しても「カオスエンジニアリング」を実践しているという記事を読んで「すごいな」と思いましたが、私の考えるエンジニア組織にもマッチするので、やらない理由はないという感じでした。

── 具体的にはどういうことを実施したのでしょうか？

林　Googleの発表に近いですね。チームに長くいる人や特定の技術に詳しくて頼られている人など、キーパーソンをチームから1週間、完全に隔離して互いにコミュニケーションが取れない状態にします。そして、組織にどういう問題があるかをあぶり出す。

一度抜けて問題をあぶり出したら、1カ月後くらいに同じ人が抜けて、どう改善されたかを確認するというサイクルです。抜ける期間を「カオスエンジニアリングウィーク」と呼んでます。これを四半期ごとに、定期的に実施しています。

── 2021年4月からということは、現在で2回実施されてますね（取材は2021年11月）。

林　そうですね。この10月からで3回目です。最初は特定のメンバーが長くいるチーム、FORCAS SalesのほかにSPEEDAの特許機能チームから始めて、それ以外にも少しずつ広げています。今四半期は6〜7チームで実施していて、トータルで25〜26回でしょうか。

── 導入チームが増えているのは、成果があったということですね。

林　そうです。ちなみに1週間という単位にしているのは、会社に「ロングバケーション」という制度があって、上期下期それぞれ5連続営業日の休みが取れるんです。

ただ、その間も「これってどうなっていますか？ 至急教えてください」と連絡が来たりするので、これをカオスエンジニアリングウィークに当てれば、完全に仕事から離れられて、健全な状態に持っていけるということも副次的な効果として考えました。

── 実際に体験した野口さんはいかがでしたか？

野口　先ほど林が言った「特定のメンバーが長くいる」というのが実は私だったので、抜ける側での体験でした。最初の四半期は私が1人、次の四半期は私ともう1人の計2人がいっしょに抜けました。

── 抜ける側も不安ですよね。かといって事前に準備するのも違うでしょうし。

野口　初回はちょっと準備をしてしまった部分があります。自分だけが持っている情報がないように気を使ってしまいました。ただし、初回で「自分がいなくても大丈夫」と分かったので、次からは準備しないようになりました。

── 抜けている間は連絡も取らないとなると、開発が進んでいるかどうかも分からず、浦島太郎状態になったりしませんか？

野口　Slackを見るだけは見てるので、状態は分かります。見るのはいいけど返信はしてはいけないというルールです。2回目は2人で抜けたので、ほかと連絡を取らなくてよいタスクを見繕って、ペアでやっていました。

── リモートワークだから遮断できたという部分もありますよね。

野口　オフィスに出社していると、連絡を取らないのも不自然ですね。隣にいるのにしゃべらないとか。

林　Googleもその期間は出社しないという方法だったかと思います。

── やってみた感想はいかがでしょうか？

野口　明確に、よかったと思っています。やる前は「自分が異動などでいなくなったらどうなってしまうのだろう？」というようなことを心配していました。やってみると、抜けて大丈夫という部分もあったし、抜けたらダメだった部分もあって、そこは直しました。

私の代わりをほかの人がやるので、本人が「この役割をやれる」と気づく効果もありました。私がいると自分でやっちゃいますが、いないことで機会が渡るわけです。

── 抜けたらダメだったのは、どういう部分でしょうか？

野口　私しか情報を持っていないことが見つかったりしました。チームで仕事をすることを徹底しているので権限はチームに与えているのですが、ちょっとしたスプレッドシートが個人の権限だったとか、そういう細かいところです。

林　基本的に、どのチームでも同じポジティブな効果が出ています。前提として、私たちの組織は特定のリーダーを置かず、全員がリーダーという「シェアードリーダーシップ」を取り入れています。ただ、長くいたり技術的に優れていたりするとどうしても頼られて、知識がその人に偏ることになります。

それが悪いわけではないのですが、むしろ本人が不安になっていることもありました。それに対してカオスエンジニアリングで抜けてみると、ほかの人がやってくれて、メンバーがより積極的に発言するようになったという効果が、ほかのチームでも見られます。

野口　意外と大丈夫だったのが、うれしいような、寂しいような（笑）。とはいえ、チームがうまくいってることの方が大きいですね。

知見はあえてドキュメントにせずに直接聞く文化

── チームに長くいる人が知見をたくさん持っていて抜けられなくなる、というのは普通によくある課題感なのではないかと思いますが、この取り組みなどを通してどのような形に改善しようとしているのでしょうか？

野口　改善したいのは、例えば「プロダクト担当」というビジネスサイドとの窓口になる役割があって、そこにどうしても情報が集まってしまう。ずっと私がその役割だったので、次の期からほかの人に変えましょうとなりました。

知見については、退職しないかぎり聞けばいいですから。

── 知見はドキュメントにまとめるのではなく、聞きに行くんですね。

野口　あえてドキュメントにせず、聞きに行くことでコミュニケーションを取ることがチームの文化なので。

── ドキュメントを残す文化の逆ですね。徹底してそうしているのでしょうか？

林　はい。1つの側面として、ドキュメントを検索する方が楽というのはあると思っています。しかし私は、ドキュメントの課題というところにフォーカスしています。例えば、ドキュメントが用意されていないと情報そのものがないと思ってしまうことがあります。

また、ドキュメントはメンテナンスしなくてはいけない。開発に関する情報は日々更新されるので、そのメンテナンスコストは個人的に費用対効果が低いケースも多いし、怠ったときには事故の元になります。書いて読んで理解するより、話して聞く方がコンテキストも把握できるので理解度が高い。そうでないことがあることも分かっていますが、トータルでは効率がいいと思っています。

ただし例外はあります。サーバーへのログイン手順のようにそれほど変わらず、実行の頻度が高くないものは憶えていないので、ドキュメントに残します。ただ、そういう場合でも、自動化できるという思考の前にドキュメントを残しておけばよいとならないよう注意しています。

── そういうカルチャーの会社は少ないと思いますが、野口さんは最初どうでした？

野口　正直、最初はとまどいました。ドキュメントがあるものとないものがあるというのなら普通ですが、ほぼ一切ない。「手順書はないの？」となりますね。

ただ、背景の考えまで分かると「これいいじゃん」という感じになりました。周りのエンジニアに聞きに行くとコミュニケーションが取れるのを見て、このやり方のメリットが分かってきました。

── これは人間関係とセットでないと、うまく動きませんよね。

林　そうです。なので、常に「聞かれた側はちゃんとすぐに答えるように」と言っています。「忙しいから後で」というコミュニケーションは絶対に取らないように。

── 同じことを何度も聞かれたりしませんか？

野口　ありますし、それは毎回答えます。ただ、一度答えると周りの人に広まるので、そんなに多くはなないです。永遠に聞かれ続けるということはありません。

林　課題はありますし「こういう情報は文書に残したい」という声はあるんですけどね。

キーパーソンが抜けることで仕事が可視化される

── 組織のカオスエンジニアリングで見えた課題はほかにありますか？

野口　普段のSlackでグループメンションが来たり、拾うべき話題がメンションなしで流れてきたりすることがありますよね。私はそういう話題を拾ってしまうのですが、私が抜けてみると誰もレスポンスしていないということが起きていて、課題として上がりました。

対策として、もうやっていませんが、ローテーションで当番を決めてみたところ、そういう仕事があるという意識付けができました。

それから、私が「ここだけはやっておきたい」と個人でやっていた作業があります。利用ログを整理して可視化したりといったことです。これも私がいないと分からなくて、チームの資産になっていない、そもそもチームでやるべき仕事だという話になりました。

運用面でも、企業情報をデータベースに入れるジョブで動いているバッチ処理がたまにコケて、リカバリーが必要になるのですが、分かる人が意外と多くない。しかも、普段なら必ずペアで作業にあたるのですが、バッチ処理は主に夜間なので、どうしても1人になる。

その結果、詳しい人しか分からない状態になっていました。今後はできるだけペアでやろうというアクションが生まれました。

── 話を聞くと、抜けた人だけが持っていて、その人には見えているがチームとしては見えていなかったタスクが可視化されることが大きいようですね。

林　そうですね。そもそもシステム面でのカオスエンジニアリングとはほぼ同じ考え方なんですが、「問題なく過ごすことが目的ではない」ということは強く言っています。自分たちの現状を知り、課題をあぶり出すことが目的だから、問題がないように過ごす必要はない。

── 1回目で問題が出るのは当然で、それが2回目で改善されていることが重要ということですね。そもそも改善の手法が、チームのカルチャーに合っていたようにも感じました。

林　確かにGoogleの記事を読んだときにも、エンジニア組織で何ができるかをスムーズにイメージできました。実践にあたっても、コミュニケーションが取れないルートを作りさえすればよかったという感じでした。

以前の記事でもお話しましたが、ペアプログラミングを通してエンジニア同士がコミュニケーションを取る文化であったり、チームを定期的に異動させて流動性が高く柔軟性のある組織であったりを目指しているので、それを加速させるためにもいい手法だと思います。

── Googleの事例では「わざと返事を遅らせるとか」とか「嘘を答える」ということもやっていたようですね。

林　そこまではやっていません。嘘はすごいですね。返事を遅らせるのは面白いと思いますが、私たちは非同期じゃなくて直接コミュニケーションをとるので難しそうです。もともとペアプログラミングをしているので。

── 現在もリモートワークでペアプログラミングですか？

林　週1〜2で出社しているチームもちらほらあります。リモートワークになった直後はやっぱりオフライン100％が良いと思っていましたが、いまはオンラインが向いている作業もあるし、ハイブリッドでいいとこ取りできればといろいろ試行錯誤しています。

リモートでは、3カ月ぐらい前からGatherというバーチャルオフィスのツールを使っています。質問したいときはGatherでその人の近くまで行って「ちょっといいですか」とリアルに会話しています。

── リアルな出社といえば、林さんが2021年9月からUB Datatechの代表取締役に就任されたので、オフィスがある沖縄に行くことも多いそうですね。

林　沖縄には毎月行っているので、そのタイミングに合わせて「私と1週間コミュニケーションが取れない」という取り組みも先月からスタートしました。

── それは野口さんから見てどうですか？

野口　「マジか」という感じでした。ただ、相談しなければならないことはあるものの、そうなったらなったでフェローに相談したり、なんとかなるものでした。

林　どうしても相談したいことは「まずフェローに聞け」として、フェローが「これは連絡が必要」と判断すれば、連絡してもいいことにしています。それは1回ありました。私が伝えきれていないことや、権限委譲できていないことが分かった1週間でした。ほかのメンバーからも「問題なかった」と言われて、ちょっと寂しいけど（笑）、よかったと思います。

※フェロー（fellow）とは、ユーザベースB2B SaaS事業で、エンジニア組織内に設置されたポジション。卓越した知見と技術力を生かして事業全体の技術クオリティーを高め、開発に深くコミットすることでプロダクトおよびエンジニアの成長を促す。UB Journalの記事も参照。

── 組織へのカオスエンジニアリングは、今後どういったアクションがありますか？

林　次のアクションの前に、まず現在の取り組みの成熟度を上げたり、範囲を広げたりしていきます。その上で、ビジネスサイドにも広げたいと思っています。今はエンジニア間のコミュニケーションだけが対象ですが、ビジネスサイドもいっしょにやってて、そこで問題が起きると面白い、というと言い方は悪いですが、一歩先の改善につながりますね。

── そういった取り組みを通して、最終的にどういう組織を目指しているのでしょう。

林　カオスエンジニアリングという文脈で言えば「アンチフラジャイル」です。そもそも目指している姿という意味では、XP（エクストリーム・プログラミング）でいうEmbrace changeな組織ですね。「変化ヲ抱擁セヨ」という訳語もありますが、ビジネスの変化するスピードは年々速くなっている中で、そのビジネスの根幹となるプロダクトを開発する組織は、その状況に対応し続けていく必要があると思っています。

だからこそアジャイルやカオスエンジニアリングをやっているわけです。

▶ 『エクストリームプログラミング』オーム社 - 達人出版会

── XPの考え方をエンジニア組織だけでなく、ビジネスでもベースにしていこうということですね。本日はありがとうございました。

Working at Uzabase.

アンチフラジャイルな働き方に興味あるなら。
すぐ応募したい方も話を聞きたい方もこちら！

リンク先では募集一覧を確認できます。すぐに転職を考えていなくても、副業やスカウトのために情報を登録できます。興味がある方は「Working at Uzabase.」をクリック！

[SponsoredContent] 企画・制作：はてな
取材・構成：高橋 正和
撮影：小野奈那子

関連記事 - ユーザベースの開発文化

本記事にも登場したペアプログラミングや技術選定など、ユーザベースのSaaS事業における開発手法の詳細については、以前に掲載した記事を参照してください。