突然増える利用者数、特定の国で悪化するユーザー体験…Cookpadはグローバルサービス特有の問題をどう解決したか

海外展開を進めるクックパッド

渡辺喬之氏（以下、渡辺）：それでは、僕のセッションではクックパッドのグローバルサービスにおけるSREの挑戦についてお話しします。ラストスパートになるので、みなさんよろしくお願いします。

まず自己紹介です。SREグループの渡辺といいます。

ふだんはクックパッドのグローバルサービスの開発に携わっており、業務としては、とくにエンジニアリングでサービスの信頼性に関わる課題解決をしていくことに取り組んでいます。

続いて今日お話ししたいことですが、今日はこの3つをお話ししようと思っています。

はじめの2つでは、クックパッドのグローバルサービスの今について、またもう1つで、海外展開をするなかでSREが経験した課題と挑戦についてお話しします。

それではまず「そもそもグローバルサービスって何？」というお話ですが、実はクックパッドでは海外向けのレシピサービスを提供しています。これは日本のクックパッドとまったく異なるサービスで、月間利用者数は3,000万人以上、22言語で68ヶ国に展開しておりまして、各プラットフォームで提供しています。

また、プロダクトのメインの開発拠点ですが、これは日本ではなく、イギリスのブリストルというところでやっています。

ただ、このグローバルサービスに携わっているスタッフは世界中におります。例えば、各地域のコミュニティを活性化させるコミュニティマネージャーという人がいるのですが、彼らは世界中にいますし、僕のように東京で開発に携わっているエンジニアもたくさんいます。

まとめるとこんな感じになるのですが、伝えたいことは、クックパッドはガンガン海外展開を進めています、というところです。

1年で社員数が10倍に、広がり続けるサービス

続いて、2017年のグローバルサービスの成長についてお話ししたいと思います。数字を見たほうがわかりやすいと思いますので、いくつか見ていきたいと思います。

まずは対応言語数です。ちょうど1年前は15個の言語でサービスを展開していましたが、それが現在は22言語に対応しています。1年で7言語増やすことができました。

ここで言語と展開国についてですが、クックパッドはレシピや料理が地域性や文化などに大きく影響をしていると考えているため、地域ごとにレシピや検索の辞書に緻密なローカライズをしています。このあたりの詳細に関しては、昨年TechConfで発表されたスライドがございますので、そちらをご参照ください。

これを踏まえて、展開中の国の数を見ていきたいと思います。昨年の時点で58ヶ国でグローバルサービスを展開しておりましたが、現在はそれが68ヶ国になっていて、10ヶ国増やすことができました。

さらにイギリスのオフィスで働く社員数を見ていくと、昨年本格始動したイギリスのオフィスですが、当初は社員は5人でしたが、今では約50人の社員が働いています。1年で社員数も10倍になりました。

また、昨年末、グローバルサービスはGoogle Playで7つの地域が「ベスト オブ 2017」に選出されまして、この同時入賞数というのは日本発のアプリでは最多です。

このように、2017年はサービスや組織が大きく成長した1年でした。一方で、各チームで課題がたくさんありまして。そこでここからは、本日の本題である、グローバルサービスにおけるSREの課題や挑戦についてお話ししていきたいと思います。

海外展開をしていくうえでの課題とは？

こちらが今日話す課題一覧です。

「なんのことだ？」みたいなものもなかには含まれていると思うので、1つずつ見ていきたいと思います。

まず1つ目の課題ですが、特定の国のユーザー体験が悪いというものがありました。これは、例えばインドネシアのユーザーが米国のユーザーより画面に文字が表示される速度が遅いとか、そのような類の問題で、いろいろな国にサービスを展開してきたからこそ国ごとの差が現れるようになってきました。

2ヶ国くらいなら私が実際に足を運んで解決することは方法としてはありかもしれませんが、現在は68ヶ国にサービスを展開しているので、その方法は現実的ではなくて、また問題を報告してくれた人が時差のある国に住んでいる場合、なかなかコミュニケーションが前に進まないという課題もあります。

そしてこの手の問題を解決するときに、まず何が原因になっているのかを明らかにする必要があります。そこで僕たちは世界中のユーザー体験を測定して、それを改善することに取り組みました。

はじめにしたことは、ユーザー体験の測定です。これには「Catchpoint」を使いました。Catchpointは、世界中に存在する観測用のサーバからある特定のエンドポイントに向けてリクエストを決まった周期で投げるサービスです。これにより世界中の観測サーバからさまざまなメトリクスが収集できます。

また、収集したメトリクスを使ってAPIのレスポンスタイムの中央値を確認できたり、どの地域のユーザー体験が悪いのかを地図上に表現したり、特定のタイミングのメトリクスをウォーターフォールチャートで深掘りしたりできます。ご覧のとおり、Catchpointのおかげで原因を調査できる状態になっています。

次に、ユーザー体験が悪い国の分析をしていきました。ここでインドネシアを例に挙げているのですが、インドネシアはユーザー数がグローバルサービスのなかで最大であり、重要な国なので、ここで例に挙げています。

そしてインドネシアと米国で差がある部分を見ていくと、とくに際立っていたのは、TTFB（Time To First Byte）と、TLSの接続の時間の差です。

これを見るとインドネシアは米国と比べて時間がかかっていました。またほかの国も、多少値は違うのですが、同じ傾向があることがわかり、これらの国の共通点は「米国から地理的に遠い」ということでした。そしてこの事象はネットワークレイテンシーが高いときに起こることが多いです。

少ない手数で効率的に改善する

ここでクックパッドのグローバルサービスのインフラについて少しだけ触れておきますと、グローバルサービスのサーバはすべて米国リージョンで管理されています。

昨年のTechConfでは、日本のクックパッドとcookpad.comのドメインを共有しているので、Route 53のレイテンシーベースルーティングを使って米国または日本の近いほうのデータセンターにユーザーをアクセスさせているという話をしました。

また、国内サービスとグローバルサービスの判定はURLのパスで行っていて、それはリバースプロキシの正規表現で行っています。こんな感じの多少不細工な正規表現がリバースプロキシに施されているのですが、実際はこれくらいのほうが単純でいいと今は思っています。

そして、このような事情があるので、ユーザー体験が悪い国は米国から地理的に遠いところが多かったです。

そしてこれを解決するには、データセンターをユーザーに近づけるというアプローチをするのですが、具体的な手段としてはサーバをマルチリージョンに展開するなどの方法が挙げられます。

ただ、この方法は運用コストが飛躍的に上がるので、今の段階では導入したくないものでした。また、少ない手数で効率的に改善したかったので、今回はCDNを導入することにしました。

CDNとしてはFastlyを導入しています。ほかのCDNも検証しましたが、一番改善効果が大きかったです。Fastlyの導入効果を測るためにAPIのレスポンスタイムの変化を見ると、導入前はおよそ1.25秒かかっていましたが、導入後は約0.45秒まで短縮されました。

これを見るとインドネシアのレスポンスタイムはおおよそ3分の1になったと言えます。

また、ほかの国のレスポンスタイムを見てみると、軒並み改善されることがわかりました。

これにより課題1は解決され、SREが68ヶ国足を運ぶ必要もなくなり、私たちはほっとすることができています。

世界中でイベントが開催されるたびにアクセスが急増する

続いて、2つ目の課題に移ります。次の課題は、とにかくイベントのバリエーションが多いことです。ここでいうイベントは、祝祭日など、毎年開催されるものを指していますが、国や宗教などのくくりで催されます。

例えばアルゼンチンでは、記念日にパステリートスというお菓子を作って食べる文化があります。

またイスラム圏では、イドゥルアドハというお祭りで肉を食べて、ラマダンでは日没後に家族で食事を楽しみます。

このようなイベントがあるとサービスへのアクセスが急増します。日本ではバレンタインのときがユーザーが最もクックパッドを使う時期になるのですが、奇しくも今日はバレンタイン直前の土曜日なので、こうして僕がここで話している間もサーバたちは大変なことになっているかもしれないです。

グローバルサービスでも同じように、イドゥルアドハでは数日間アクセスが2倍になり、ラマダンではなんと1ヶ月間アクセスが2〜3倍になります。

これ1日じゃなくて1ヶ月間です。本当に「やってられない……」みたいになります。

（会場笑）

また、イベントが増える要因としては、海外のレシピサービスがクックパッドの仲間になるケースがあります。展開国数を増やす取り組みの1つですが、ユーザーがいきなり100万人増えるみたいなことも経験しました。

このように展開する国の数が増えると、イベントも比例して増えていきます。そして、展開している国それぞれでユーザー数が増えていくのは私たちとしては非常にうれしいことなのですが、一方でSREはこうなってくると大変で、毎月バレンタインがあるような状態になります。

イベント対応されたことがある方はわかると思いますが、これは本当に大変なことで、しかもすべてのイベントにSREが対策を講じるというのは、時差もあるので現実的には難しいです。

システムと組織をスケールして大量のイベント対応を可能に

そこでSREがすべてを対応するという発想ではなくて、システムと組織のスケーラビリティを考慮した仕組みを導入することが重要になってきます。

例えば、システムの文脈で言いますと、ここではデータベースを例に挙げますが、プロダクションのデータベースはすべてAuroraを使っています。理由は、高いIOPSを持っていてディスクの容量を気にしないで済む。また、リードレプリカがすぐに増やせるなどのメリットがあるからです。

さらにアプリケーションの開発スタイルも少しずつ変えていっています。昨年はECSとHakoというデプロイツールを使ったDockerアプリの開発環境を積極的に導入しました。

このシステムにはいい点がたくさんありまして、例えば以前はアプリが増えるたびに自前でオートスケールの実装みたいなのをしていたのですが、このシステムはそのへんも考慮されているので自前の実装は不要です。また、開発者自身が環境変数や秘匿値、パスワードなどをSREに依頼することなく自分で設定することができるので、つまりシステムも開発もスケールしていくことができます。

さらに社内には「hako-console」というデプロイしたアプリのさまざま情報が見れる便利な管理コンソールがありまして、ログが見れたりだとか、リソースの使用状況が見えたりだとか、たいへん便利になっています。

これは日本で培われた技術なのですが、このように、時には日本で培った技術もグローバルに応用をしています。

あとは開発者が自分たちのアプリケーションをセルフマネジメントできる状態にすることも、組織をスケールする上では非常に重要だと考えています。

例えば、全開発者がデータストアのスロークエリを見れるようにしたり、サーバの各種メトリクスを見れるようにしたり、デプロイ前後のHTTPのステータスコードの変化を追えるようにできるようにダッシュボードを共有したりと、このような取り組みを続けています。

そして、このような取り組みを続けることで日頃からイベントの対策ができるようになりますので、今後もいろいろ試していきたいと思っています。

デプロイできない人がいない世界を目指す

次の3つ目の課題に移りたいと思います。3つ目の課題は「デプロイのオペレーションコストが高い」です。これは日本でできるオペレーションが必ずしも海外でできるとは限らないということです。

例えば、ネットワークが安定しない国だとか、日常的に停電起きる国だとか、世界にはいろいろな国があります。そのような国は開発者の手元でツールを実行してデプロイすることができないみたいなことも、たまにあります。

こうなるとなにが起きるかというと、デプロイをほかの人に依頼するようになります。こんな状態で開発してるのは依頼する人もされる人もとてもしんどい状態なので、私たちはデプロイできない人がいない世界を目指す必要があります。

はじめは単純に米国にデプロイ用のサーバを用意しましたが、これで「デプロイできない」という人はいない状態にすることができます。

ただし、デプロイサーバを単純に用意するだけでは問題があって、例えばオペレーションが統一されないだとか、サーバにアクセスするのが面倒だとか、あるいは問題発生時にデプロイのログを追うのがつらいだとか、いろいろな問題があります。

そして今はデプロイ環境はこのような環境になっています。

Slackからボットを介してデプロイするようになっていて、こうすることでデプロイサーバへのSSHが不要になります。またボットが起動するデプロイジョブはあらかじめスケジューラーに登録されているものなので、全開発者のオペレーションが統一されます。

さらにジョブスケジューラーにはデプロイ時刻だとか、デプロイした人、ログの情報などが残るので、問題が発生した場合の切り分けも容易になります。これで3つ目の課題も解決することができました。

社員数が増えることにより起きる問題、急増するtoil

最後の課題に移りたいと思います。最後は「toilが急増する」です。この「toil」という用語ですが、近年、Googleによって提唱されている用語で、この『Site Reliability Engineering』という有名な本があるんですけど、ここに記載されています。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

そしてtoilはこのような性質を持つ業務を指していますが、ただ、ここではわかりやすいように、僕たちSREがやりたい本業を邪魔する割り込みのような業務だと考えてください。

そして、冒頭で組織の成長の話をしましたが、2017年はとくに成長しました。それに伴い、SREが対応する依頼業務数も急激に増えており、その推移を見ていくと、ご覧のとおり、かなり多くなっていることがわかりました。

また、業務の割合の推移を見ていくと、このような割合になっています。

ピンクで囲ったのがSREが本来やりたい業務なのですが、それはソフトエンジニアリングだとかシステムエンジニアリングに分類されるものです。一方で、青のtoilに分類されるものは常に一定数あります。一定以上あります。

2017年2月に何が起きたかというと、このtoilが急増して、結果、やりたいことがぜんぜんできない時期がありました。組織が大きく成長することでこのような問題も発生します。

そして、その時期のtoilを分析すると、アカウント管理周りの業務が増えていることがわかりました。

つまり、SREとしてやりたいことをやるには、これらの業務を自動化するなり、自主コストを下げるなり、殲滅する努力をする必要がありました。

そしてアカウント管理業務というのはボディブローのように効いてくる業務の1つで、このへんが僕が思うつらいところなのですが、社員数の増加はほかの組織でも経験されている方もいらっしゃるかもしれません。

多様化する開発ルールというのは、こんな感じでほかにもあるんですが、節操なくどんどん増えていきます。

そしてそれでもサイトの信頼性を守る身としては、これらのツールに対してなんらかのアクセス制御は入れたいところです。

このようなときは一般的にVPNを導入することが多いと思いますが、ただ世界中のオフィスがVPNを使える環境にある保証はないですし、また、東京にVPNを張るとしても、アフリカに住んでいるコミュニティマネージャーがVPNを安定に張るのは難しいです。

このように、世界中に社員がいるからこそ発生する問題というのもたくさんあります。また、社内ツールが増えるたびにBasic認証を入れるみたいなこともやりたくないです。

これらを踏まえて、アカウント管理に関する依頼業務を減らすために実際にやったことをお話します。

地道な環境整備で本来の仕事に集中できるように

まずは社内ツールへのアクセス制御は基本的にnginxとomniauthで行っています。社員は入社時にG Suiteのアカウントを必ず付与されるので、それを使ったアクセス制御です。これにより社内ツールへのアクセスにはVPNやBASIC認証が不要になっています。

これはSentryのログイン画面で、実際にアクセス制御されているものです。

また2017年の途中からAD（Active Directory）やLDAPを用いたシングルサインオン環境が整備されてきたため、それを境にアカウント管理業務のセルフサービス化なども進めました。

これは同じチームに所属している人間が作った管理コンソールなのですが、開発者がセルフサービスでLDAPのパスワードを設定できたりだとか、SSHの鍵の変更、そしてその自動デプロイを実現しています。

このような地道な活動を続けることで、大量にあったtoilは今ではほぼなくなっています。

2017年のSREへの依頼業務の変化を見ていくと、その結果は一目瞭然です。

これで4つ目の課題も解決することができています。

余談ですが、この課題に対してはほかの取り組みもしていて、SREのマルチリージョン対応をしています。これはSREの人的リソースを増やしてtoilに対応することもあるのですが、時差の壁を乗り越えたり、ほかの地域にいる社員とのコミュニケーションを円滑にしたりする、そういう目的もあります。

なので、これからもUKと東京を中心にSREの採用をできればと思っています。

以上で僕が経験してきたSREが挑戦してきたことのお話は終わりです。

まとめます。本セッションでは、グローバルサービスにおけるSREの挑戦についてお話ししました。グローバルサービスならではのお話を中心にまとめたのですが、ほかにもたくさん取り組んでいることがあって、それはどこかの機会でまたお話しできればなと思っています。

これで発表を終わりとさせていただきます。ありがとうございました。

（会場拍手）