クックパッドの海外展開におけるSREの役割と挑戦

クックパッドSREが語るグローバルサービスへの挑戦

渡辺喬之氏（以下、渡辺）：それでは発表をはじめます。よろしくお願いします。今日の発表内容ですが、まずクックパッドの海外展開について、ご存じない方がいらっしゃると思いますので、ご紹介いたします。その後、クックパッドにおけるSREの役割についてお話し、最後に、本日のメイントピックである技術的なチームへの道のりについて、お話をしていきたいと思います。

それでは、まずはクックパッドの海外展開についてです。

クックパッドは日本では多くの人に馴染みのあるサービスだと思いますが、実は海外向けのサービスも出しています。これは、日本のクックパッドとは完全に別のサービスとして稼働しています。

現在の展開している国はご覧の世界地図の青い部分です。日本も含めると71カ国・26言語での展開がすでに進められています。その平均月間ユーザー数は9,400万人です。

また、海外のレシピ総数を見ると200万レシピに到達しており、これは昨年比約2倍になっています。

そんな海外向けのクックパッドですが、プロダクトの開発拠点は、日本ではなくイギリスのブリストルです。この拠点はおととしオープンしたばかりですが、現在はおよそ25カ国から集まった100人の社員が働いています。

海外展開におけるSREの役割

続いて、そんなクックパッドの海外展開におけるSREの役割です。「いったい誰がSREにとってのお客さまなのか？」という話ですが、僕は2つのグループがあると思っています。

1つ目のグループは、クックパッドを使ってくださるユーザーさんたちです。

僕たちはユーザー一人ひとりがクックパッドを安心・快適に利用できるようなプラットフォームと技術の開発をしています。

一方で、プロダクトを開発するためのプラットフォームづくりにも貢献しており、2つ目のユーザーグループとしてプロダクトの開発者が挙げられます。

まとめると、クックパッドのSREの役割は、ユーザー体験の最大化とプロダクト開発のしやすいプラットフォームの開発です。SREとして働いているので、サービスの可用性を向上させるというのは重要な指針の1つですが、ユーザーと開発者の幸せが僕たちの目的の本質であり、それを実現するための手段として、サービスの可用性の制御を行います。

その役割を全うするための技術的な活動領域としては、プロダクトが動くプラットフォームの開発から、可用性を制御するためのリリースエンジニアリング、レジリエンスエンジニアリングなどが主戦場となっています。

自律的なチームへ道のり

そんなSREチームですが、2018年もたくさんの挑戦をしてきました。

今年はそのなかから「自律的なチームへの道のり」というテーマに焦点を当てて、お話をしたいと思っています。

このテーマでは、とくに自律性のための開発体制の変更と、無理のないセルフサービスについてお話をしていきます。

まずは開発体制の変更についてです。その前に、「そもそも自律的なチームとは何か？」という話がまずあるのですが、ここではチーム内で素早く意思決定が完結して行動ができることを「自律的である」とさせてください。

そして、いまからお話することは、グローバルチームにおける開発体制の過去・現在・未来です。つまり、どのようなことを契機に開発体制の変更が行われ、どのような体制変更を行い、それに伴い開発スタイルはどのように変わったのか、また、現在どのような課題に直面しているのかを、順々にお話していきたいと思います。

グローバルチームでは、2017年から2018年にかけて、プロダクト開発体制の大きな変更を行いました。これは、働いている社員数が急激に増えていることが理由の1つにあります。全員が水平分割された開発体制はオーナーシップが取りにくい構造で、必要以上にコミュニケーションや開発時の確認事項が増えます。

The challenge with adding more engineers to a project. Just moving from 3 developers to 4 doubles the number of lines of communication. pic.twitter.com/sltsBUVq8w

— Rich Rogers (@RichRogersIoT) 2017年10月1日

これは、わかりやすい例ですが、エンジニアを1人追加するだけで、必要なコミュニケーションの数が爆発的に増えることを意味しています。クックパッドでもやりたいことが増えていくにあたり、エンジニアの人数を増やす必要があったのですが、結果としてコミュニケーションコストが膨らんで、その後の開発体制の変更に至りました。

左が以前の開発体制で、右側が現在の開発体制です。新しい体制では、組織はChapterとSquadというグループに分割されています。まずは横断的なグループとして、Chapterがあります。

Chapterは各分野のスペシャリストを集めたグループで、Web Chapter、iOS Chapterのようなグループがあります。

また、実際に機能を開発するグループとして、Squadがあります。

Squadには、先ほど説明したChapterのメンバーがアサインされています。例えば、RubyとRailsが得意なWeb Chapterエンジニアが、レシピの作成に関する機能を開発しているSquadにアサインされる、みたいなものをイメージしてください。

この体制の変更により、小さいチームごとに早い意思決定と価値検証ができるようになりました。そして、コンウェイの法則、つまり、「ソフトウェアのアーキテクチャは組織の構造を反映したものになる」という有名な法則がありますが、クックパッドでも開発体制を変更することで、アーキテクチャと開発スタイルに変化が現れました。

短期間で何度も試行錯誤できるようにする

続いて、その変化をリニューアルしたフィード機能を例にお話していきます。

こちらがリニューアルされたフィード機能を構成するシステムです。ピンク色の部分は新しく追加されたシステムで、今まで使われていなかったMessage brokerやFeed APIが新しく追加されました。また、この機能を開発するために、プロダクトチームでは主にフィーチャートグルとプロトタイプ環境を使っていました。

フィーチャートグルは、サーバーサイドエンジニアがコード側で新機能を一部のユーザーにリリースするためのスイッチで、プロトタイプ環境は、SREが用意したプラットフォームで一部のユーザーが新機能を使えるようにするものです。共通しているのは、プロダクションでテストを行うということです。

僕たちは、「追加した機能の良し悪しはユーザーにぶつけてみるまでわからない」という考えを持っています。そのため、フィード機能のリニューアルでは、部分的なプロダクションへのリリースを頻繁に行いました。

この開発スタイルの変更が成功だったかどうかを振り返ると、個人的には成功だったと考えています。なぜなら、フィードでは新しいアーキテクチャ技術が採用され、それが短い時間でプロダクションに100パーセントリリースできたからです。

成功の要因は、開発者が短い期間で何度も試行錯誤できたからだと考えています。開発者は技術の選定にもオーナーシップを持っていました。組織や開発スタイルが変わることで、チームの自律性が高まり、素早い意思決定、技術の選定ができるようになりました。

ここまで聞いていると良いことづくめのように聞こえるかもしれませんが、実際はそんなことはなく、課題もたくさんあります。

例えば新しい開発スタイルに適したサービス監視体制が構築できていません。

いまお見せしているのは、プロダクションの各課のプロデューサーや、コンシューマーから飛んできたアラートに対応しているSREの様子です。「何がどうなってるかわからないから助けてくれ」というメッセージを開発者に伝えています。

クックパッドは、プロダクションで発生したアラートはすべて日本のSREが受けて一次対応するという開発体制が敷かれているため、この機能が安定するまでは、SREとしては大変な経験をしました。

この一連の開発に対する幸福度を図に落とし込むと、こんな感じになると思います。

開発者とSREの幸福度

開発者とSREは、新機能を開発するということで当初は両者がhappyな状態でしたが、しかし、開発が進むにつれて、度重なるアラート対応でSREとしてはunhappyな状態になっていきました。

この新しい開発スタイルを相対的に分析すると、開発者はhappyだったが、SREはunhappyだったと考えています。いまのSREチームには献身的な人が多いので、こういう状況でもがんばって乗り切ってしまうと思うのですが、誤った方向にがんばっても組織としては良くなりません。

これが繰り返されると、最終的にチームとして限界を迎えて、最悪すべてのSREが会社を辞めるという状態になりかねず、開発はしやすくなった一方で、持続性のある開発体制になったとは言い難いです。

ここでの問題は、プロダクトオーナーと開発者とSREの3者で、可用性の目標が握れていないことです。例えば、極端ですが「ある機能は連続72時間使えない状態でも許容する」といったルールが決まっていれば、開発者もSREもその機能に対して監視のレベルを落とすことができるため、無理な対応をしなくてすむようになります。

現在は、サービスの可用性の設定などを含めたサービス監視体制の再構築に取り組んでいます。こういう組織や開発体制が劇的に変化していく環境で、DDDや逆コンウェイの法則など、すでに概念として知っているものを実際に試せるのは、なかなか経験できることではないので、楽しいフェーズにいるなと考えています。

自律的なチームのためのセルフサービス

以上が、2018年に行った自律性のための開発体制の変更です。続いて、自律的なチームのための無理のないセルフサービスに移ります。

このトピックでは、自律的なチームが成功するための重要な4つの鍵と、開発者に受け入れてもらえる無理のないセルフサービスの条件、SREが2018年に投資したスコープについて話していきます。

まず、僕が考える自律的なチームが成功するために必要な4つの鍵ですが、規律・自由・責任・最適化があると思っています。

規律は開発組織全体が従うべきルールで、例えば技術スタックや開発体制などがその例です。自由は「開発者の規律のなかで、オーナーシップを持って開発に臨める環境があるかどうか？、責任は「自分が担当するソフトウェアのすべてのライフサイクルに、責任を持てる環境があるかどうか？」、そして最適化は「開発のための社内のベストプラクティスを適用できる環境があるかどうか？」という意味です。

なぜこの4つかというと、社内でもよく言われていますが、人はやりたいことをしている時に一番力を発揮すると考えており、また、組織として機能するには、全体として譲ることのできない制約が必要だと考えているからです。

そのなかで、上の3つは僕は組織の方針による部分が多いと考えていて、1人のエンジニアがどうこうできる話じゃないと思っています。そのため、技術とビジネスのアーキテクチャを考える経営層の強いリーダーシップが求められます。

エンジニア一個人としてチームの自律性向上に貢献できるとしたら、最後の最適化の部分です。そこで、僕らは過去のサービス開発で培った経験をセルフサービス化して、開発者に提供していくことをしています。

実現可能なセルフサービスの条件

次に、開発者にとって実行可能なセルフサービスの条件を挙げます。僕はこれは2つあると思っていて、1つはラーニングコストが低いこと、もう1つはオペレーションによるプロダクションに影響がないことだと考えています。

これを満たせないセルフサービスは、開発者が実際に使うことができない、筋の悪いものだと思っています。

それを踏まえて、僕たちは昨年、アプリのコンテナへの完全移行とssh不要なデバッグツールの提供に、リソースを集中しました。

コンテナへの完全移行は、ステートレスなサーバーはすべてコンテナで動かすというものですが、これはコンテナプラットフォームでたくさんのメリットがあるからです。とくにチームの自律性向上やセルフサービス化といった観点で言うと、開発者がソフトウェアのバージョンアップを管理できることの恩恵は相当なものです。なぜなら、開発のリードタイムを大幅に減らすことができるためです。

1つ、例を挙げます。

これはバーチャルマシン環境でのRubyのバージョンアップについて話しているところですが、「バージョンアップになんでそんなに時間がかかるの？」という質問を、僕が開発者から受けています。

開発者の気持ちもわからなくはないですが、実際にはグローバルのバーチャルマシン環境はそこまで洗練されたものではないため、アップグレード作業はけっこうな量の手順があり大変です。ここに、開発者とSREの心理的なギャップがあります。

この時の幸福度をまた先ほどのように図に描いてみると、こんな感じになると思います。

SREはソフトウェアのバージョンアップの重要性は理解している一方で、コンテナ環境に慣れ親しんでいるため、その作業を深層心理では非生産性な作業と感じてしまいます。

また、開発者は、ソフトウェアのバージョンアップを依頼したのに、リードタイムが長くてバージョンアップへのモチベーションが下がってしまい、結果として、開発者もSREもunhappyな状態になってしまいます。

そして、ご存知の通り、ステートレスなアプリのコンテナ化を徹底することで、今回の問題は解決します。

現在は、アプリのコンテナ移行をどんどん進めており、94パーセントのアプリはコンテナで稼働しています。

また、アプリの完全コンテナ移行を達成することで、SREがコンテナベースのプラットフォームの開発にのみ時間を割けるようになるため、開発者により良い仕組みが提供できるようになります。

SSHを必要としないデバッグについて

次に、sshを必要としないデバッグについて話したいと思います。

先ほどはコンテナを使うメリットのことばかりの話をしたのですが、デメリットももちろんあります。とくにsshをできないことを前提とするなら、デバッグ方法を確保できないと開発者としては非常に開発しづらい環境になります。

その点、クックパッドのコンテナプラットフォームはかなり整備されており、開発者がほとんど不自由なく、サービスの開発と運用を自律して行えるようになっています。

一方で、これがグローバルのチームの開発者にとっても十分かというと足りない部分もあり、そのあたりは開発者からのフィードバックを得て、明らかにしていきました。

グローバルのチームで問題になっていたのは、デバッグの体験が悪いことだったので、これを改善するための仕組みづくりを行っていきました。一部ですが、紹介していきたいと思います。

まず、コンテナに特化したNew Relicエージェントのデプロイをする仕組みを用意しました。僕たちが扱っているECSは、例外的なコンテナをデプロイするといったことができませんが、New Relicはホスト課金なので、1つのコンテナだけで起動したいという課題がありました。

この課題に対しては、社内ではすでにRackミドルウェアでエージェント起動用のエンドポイントを用意して、エージェント起動後はconsul lockで分散ロックを取るという仕組みで、1つのコンテナのみでのエージェント起動を可能にしています。

しかし、この方法にもまだ問題があり、OOMなどでエージェントが起動しているコンテナが死んだ場合、分散ロックが解除されないため、次のデプロイがあるまで新しいコンテナでエージェントが立ち上がらないことが、問題になっていました。

そこで、共有メモリにエージェント起動用のフラグを保存しておき、それを確認することで、OOMでコンテナが死んだ際も、新しいコンテナで自動でエージェントが起動するようにしました。

また、ログの検索システムにも手を加えました。社内には、開発者が共通で使うAthenaによるログの検索システムがあり、だいたいの用途はこのシステムで間に合っています。しかし、Athenaでの検索は、ログが発生してから数分間、開発者がそのログを検索できないという問題がありました。

開発をしていると、デプロイ直後のログ監視は、開発者の関心事の1つです。僕たちはこの問題に対して、Athenaに加えてElasticsearchを導入して、直近のログ検索のみ、ElasticsearchとKibanaで行えるようにしました。

ブラウザを介したRails Consoleを提供

さらに、ブラウザを介したコンテナ環境でのRails Consoleの提供もしています。バーチャルマシンプラットフォームでは、開発者が直接sshでログインして、Rails Console経由で謎の書き込みをしたり、サンドボックスモードでトランザクションを貼るなど、バッドプラクティスの温床になっているという課題がありましたが、これに対して僕たちは、コンテナ化と、コンテナに対してブラウザからREPLを実行できるようにしました。

コンテナ環境でのREPLはアンチパターンと思われるかもしれませんが、Railsアプリ開発において、REPLは開発者の武器の1つです。その武器を奪うのもどうかと僕たちは考え、REPLのオプションをあらかじめSREが設定するなど、安全性を保証した仕組みを提供しました。

こちらが、現在のブラウザ経由のRails Consoleです。開発者はステージングであれば、リードオンリーでREPLを実行できるようになっています。以上で、sshを必要としないデバッグツールの話は終了です。

このように、完全コンテナ化やsshを必要としないデバッグツールの導入はセルフサービスの一部ですが、無理のないセルフサービスは、開発の信頼性と自律性を向上させるということがわかると思います。これからも、開発者がより開発をしやすいセルフサービスの提供をしていきたいと思います。

まとめです。

本セッションでは、クックパッドの海外展開とSREの役割についてご紹介しました。また、昨年SREが取り組んだこととして、自律性のための組織変更と無理のないセルフサービスについてご紹介しました。

以上で発表を終わります。ありがとうございました。

（会場拍手）