ローンチから10年、世界6000万ユーザーを抱える「TimeTree」
──自己紹介をお願いします。
金井栄喜氏（以下、金井）：TimeTreeのSREチームのマネージャーとして、チームの醸成やメンバーの育成を担当しています。またスタッフエンジニアという役割も担っており、主にパブリッククラウドの構築やシステム全体の設計、外部連携など技術的な観点でメンバーをリードしています。そのほか、中長期的な視点からのシステムの改善、TimeTreeが進む方向に即したシステムの成長を下支えしています。ちなみに、TimeTreeでは「ニックネーム制度」を採用しており、社内ではmiuと呼ばれています。
TimeTreeへの入社は2018年1月。2015年にサービスをローンチしてから約3年後で、当時すでにユーザー数は800万人を抱えていました。データベース移行を計画していたことから、前職でデータベースマイグレーションを経験した私が、リファラルでTimeTreeに転職。当時のデータベース移行を無事終え、そのままSREを担当することになりました。ですが、拡大するTimeTreeのSREを1人で担当するのは限界があります。そこで3年前にSREチームを立ち上げました。
Greg：私は2020年にバックエンドエンジニアとして入社しました。ニックネームはGregです。当初はAPI機能開発のプロジェクトに携わり、その後、2022年4月のSREチームの立ち上げに伴い、最初のメンバーとして参加しました。
──「TimeTree」はどのようなプロダクトですか。
金井：TimeTreeはグローバルで展開しているカレンダーシェアサービスです。家族やカップル、職場など、複数の人、コミュニティ単位で予定の共有、可視化ができ、そこで生まれるコミュニケーションによって、予定管理を誰にとっても当たり前で簡単なものにします。もちろん、個人カレンダーとしての利用も可能です。また最近ではイベント情報を発信できる「公開カレンダー」というサービスも提供を開始し、バンドやアイドルグループ、クリエイターなどのイベント情報発信の手段として利用されています。
サービスの特徴は、6000万人超の登録ユーザーを抱えていること。しかもそのうち、半分が日本国外のユーザーで占められているグローバルなサービスです。
──なぜグローバルなサービスとして成長しているのでしょうか。
Greg：一つは、元々多言語対応してきたから。もう一つは、複数人で予定を調整するために取るコミュニケーションの課題が、グローバルで共通だったからだと考えています。
急成長するサービスで見えたAuroraの限界
──2018年の800万ユーザーから、現在は6000万ユーザーとサービスが大きく拡大していますね。システム的にはどんな課題が出てきたのでしょうか。
金井：入社のきっかけがデータベースの移行という話をしましたが、当時使っていたデータベースはAmazon RDSでした。指数関数的に増えるデータ量の改善策として、自分たちでマイグレーションの仕組みを構築し、Auroraに移行しました。
無事データベースを移行し、次に課題となったのが、サービス全体のモニタリングができないこと。私たちのサービスは6時から10時半の間に、30分おきに急激なアクセスの増加（スパイクアクセス）があります。そのようなスパイクアクセスの状況が把握できないことが課題でした。もう一つの課題は、システム設計がレガシーであり、モダンなクラウド活用ができていなかったこと。例えばコンテナは利用していましたが、Amazon EC2を使っていたためオートスケーリングが柔軟にできませんでした。データの物理的な上限に対する課題もありました。
Greg：私がAuroraに感じた課題は、大規模なデータを持つスキーマ（データベースの論理的な構造）の変更の難しさです。
例えばAuroraでスキーマの変更が生じたときは、GitHubが公開しているオンラインスキーマ変更ツール「gh-ost」を使っていました。当初は問題なく使えていたのですが、データ量が増えていくにしたがい、一時的にAuroraをスケールアップさせて、スキーマ変更ができる状態にした上で変更を実施、変更が終わるとスケールダウンさせるという方法を採ることにしました。しかし、この手法ではスキーマ変更のたびにサービスのダウンタイムが多少ですが発生してしまいます。このままでは開発スピードも落ち、サービスをスケールさせる方法も選択肢が狭まると思いました。
金井：Auroraはパフォーマンスが良く素晴らしいデータベースです。ですがGregが話したように、テーブル変更する際に使用するストレージの容量が足りず、大きなテーブルのマイグレーションができない状況に陥っていました。サービスの進化を妨げる要因となっていたのです。
このままではサービスの継続が難しい……エンジニアの起案で進んだ移行プロジェクト
──Auroraからのマイグレーションをどのように推進していきましたか。
金井：課題を認識し始めたのは4年前の2021年頃で、翌年の2022年からそろそろ対応しなければと考え、私が起案して「自律プロジェクト」として立ち上げました。自律プロジェクトとは、会社の成長に寄与するアイデアがあれば、本業に影響しない範囲で誰でもプロジェクト化できる社内制度です。
まずプロジェクトという箱を作った上で、どのような課題があり、いつまでにやらないとサービス継続が厳しくなる、といった情報を整理しました。そしてボードメンバーをはじめ、会社の課題として認知をしてもらうことに注力しました。ボードメンバーに認知をしてもらったところで、正式なプロジェクトとして発足させ、Gregをメンバーに引き入れました。2022年10月のことです。
データベース移行プロジェクトで最も意識したポイントは、アプリケーション変更の有無です。それによって開発期間やリソースが変わってしまうからです。また、移行には2時間程度のダウンタイムを想定していたので、ターゲット広告などの施策に影響が出ます。そのため、ステークホルダーとの情報共有も意識しました。
Greg：会社が大きくなるにつれ、複数の開発プロジェクトが並行して動くようになりました。ですが私たちのバックエンドAPIはモノリシックな構成になっており、どのプロジェクトも必ずバックエンドのコードベースに影響します。データベースをSpannerに移行する上で、どうすれば他のプロジェクトと並走できるのかは重要なポイントでしたね。
プロダクトの未来を左右するデータベース、移行先選定のポイントは？
──データベースの移行先を決定するにあたり、どのような検討をしたのでしょうか。
金井：実際、データベースの移行が始まったのは2024年1月ですが、その前に約1年かけて、データベース移行の準備を行いました。
最初に行ったのは移行先データベースの選定です。影響を最小限にしたいという思いがあったので、MySQLがそのまま使える「Vitess」、Vitessのマネージドサービスである「PlanetScale」、そして「Spanner」の3つを候補としました。
Vitessは当社のCTOが押していましたが、自前運用が大変になることが目に見えていました。そこでPlanetScaleを検討したのですが、コストがまったく合いませんでした。
Spannerは、当時の私たちの状況では選択するのが難しいと思っていましたが、分析にBigQueryを使っており、データエンジニアがGoogle Cloudの担当に引き合わせてくれたのです。その担当者と会話をし、Spannerを導入するにあたってのワークショップを3日間開催してもらうことになりました。そこで共に、サービスやデータベース移行に関する課題の洗い出しができたのです。ここまでの協力体制を築けるのであれば、移行に対するハードルが下がると考えました。その上で、もう一度、総合的にどのデータベースが良いか判断することにしました。
──最終的にSpannerを選定した決め手は何ですか。
金井：Spannerを選定した理由は3つあります。第1に、分析ですでにGoogle Cloudを利用していること。第2に社内コラボレーションツールとしてGoogle Workspaceを使っており、アカウント管理との連携が容易なこと。第3にGoogleという巨大システムがSpannerを利用していること。今後、AI活用が当たり前になる時代において、よりフルマネージドな状態でAIと連携できる方がプラスになると判断しました。
実際のところ、Spannerへの移行はビジネスロジック側のクエリの仕様を変更する必要があり、とても大変でした。ですが移行してしまえば、運用に関してはSpannerが一番楽だと思います。
Greg：コスト面を優先的に考えるとVitessになるのですが、運用を考えると専任のチームが必要になる。しかも今は採用市場が激化しているので、スペシャリストの採用は難しいと考えました。とはいえ、Spannerはプロトコルもデータモデルも既存のデータベースと異なるので、本当に移行ができるのか不安でしたが、Google Cloudの担当者がワークショップを通して、実現可能性を示してくれたことで、ポジティブに考えられるようになりました。
Spannerへの移行は3つのステップで実施
──Spannerへの移行をどのように進めていったのでしょうか。
金井：とにかく期間を重要視していたため、基本的には私とGregの2人体制で進めました。2人なら意思決定のスピードを早めることができるからです。
まず私がロードマップを作成し、タスクの洗い出しをしました。2人とも移行プロジェクトに専念できる状態だったので、タスクはそこまで細かく洗い出しすることなく、適宜発生するタスクに関してはアジャイルに進めることにしました。
Greg：マイグレーションのステップとしては大きく3段階に分かれます。第1段階ではアプリケーション側でSpannerに対応させていく。第2段階ではAurora内のデータをSpannerに流し込む。第3段階で、Google Cloud環境に基盤を構築する。第3段階のタイミングでメンバーを一人増やしました。
金井：移行テストの実施は2024年3月から。どうすれば期間内に移行ができるのか、検証しました。それと並行してバックエンドにどんな変更が必要になるのかも調査しました。
5月から本格的にマイグレーションを開始。またデータベース周辺のアプリケーションについても、移行の有無を検証した上で、Google CloudとAWSのマルチクラウドで稼働させるための設計を行いました。
そこからは実装しながら検証するという方法で、マイグレーションしていきました。当初はGoogle Cloudが提供しているSpannerマイグレーションツール（SMT）を使って移行しようと考えていました。ですが何回か検証すると、最終的に私たちが想定していたようにはいかないことがわかったので、同じくGoogle Cloudが提供するDatastreamとDataflowというサービスを組み合わせて移行しました。
Greg：私たちのサービスはRuby on Railsを使っており、多くのテーブルではプライマリーキーであるIDを単調増加させ、レコードをデータベースに追加していくという仕様になっていました。ですが、このような仕様はSpannerとの相性が悪く、ホットスポットという問題が起きてしまう。そこで使ったのがビット反転シーケンスというSpannerの機能。この機能を使いつつ、既存データのプライマリーキーの値も変換しました。
金井：Spannerの場合、データを自動的に分割処理（オートシャーディング）してくれるのですが、当社のサービスの特性上、新しい予定が登録されると、IDが1から順に採番されます。例えば昨日作った予定は1番ですが、今日作った予定が30番となる。ですが、ユーザーが見るのは、新しい予定。新しい予定にばかりアクセスが偏ると、それを分割される危険性がある。それを回避するために、サービス移行のロジックにビット反転シーケンスを組み込み、時間をかけて検証しながらデータ移行を行いました。
データ移行は2025年1月12日午前2時から開始。当初は午前4時に終わる予定が、4時間超のダウンタイムの発生と、その後もアラートの対応に追われ、無事完了したのは午後7時のことでした。
プレッシャーの大きい移行プロジェクト、円滑に進めるための工夫とは
──移行の作業において、やってよかった点について教えてください。
Greg：実際にGoogle Cloud上にTimeTreeの小規模なAPIセットを持つミニアプリを構築し、Spannerとつなげて試したのはよかったですね。そうすることで、チューニングすべき箇所や改善すべき点が見えたと思います。
金井：インフラに関して、SREチームのメンバーがその後の運用を引き継ぐことを考え、IaC（Infrastructure as Code）化したことがよかったです。
マインド面では、妥協しないことが重要でした。大きなデータの移行は精神的にもかなりの負担があり、さらに大きなコストもかかります。問題を早期発見・解決できるように、Google Cloudの担当者とのコミュニケーションを密に取ることを心がけました。
──どのような点が特に大変でしたか。
金井：苦労したのはデータの移行ですね。本当に移行できるのか、確信が持てないまま進めるのは非常に苦しかったです。
Greg：バックエンドエンジニアの観点では、他のアプリケーションの開発プロジェクトと並走させることに苦労しました。新しい機能の追加の際、それがSpannerに対応しているかをチェックする必要があったのです。
技術的な面では、ビット反転シーケンスを利用したことです。こういう機能はフレームワークの標準の機能では存在しなかったので、本当に問題が無いと言えるよう、フレームワークを改修して対応しました。
──Spannerへの移行が完了し、どのような成果が得られましたか。
金井：まず、Google Workspaceのアカウントと連携できたことで、セキュリティ面が向上しました。次に、データベースの物理的上限がほぼ無くなったので、今後の運用が楽になったことが挙げられます。サービスの成長を妨げる不安がなくなったことは大きいですね。他にも、分析対象となるデータの移動が楽にできるようになりました。今後、Spannerで順次提供されている拡張的な検索を活用することで、私たちのサービスの成長に活かせるのではと期待しています。
TimeTreeという大きなチームで立ち向かったデータベース移行
──今回の移行プロジェクトを通して、どんな学びや気付きがあったのでしょうか。
金井：データベース移行のような大きなプロジェクトを成功に導くには、周りの協力が欠かせません。自分たちが何に取り組んでいて、その取り組みがどれだけ大切なのかを、恐れずに発信していくこと。周りの協力を得るためにもっとも大切であると学びました。
また、準備を怠らないことも当然ながら重要です。特にこのような大きなプロジェクトを完遂するためには、“準備し過ぎる”ぐらいがちょうどいいと言えると思います。
Greg：発信していくことに加え、協力を呼びかけ、周りを巻き込んでいくことも重要でした。そうすることで、各ドメインに強い人たちから、正確な情報が手に入ったりするからです。自分たちのチームだけではなく、TimeTreeという大きなチームで向かっていくんだということを、意識できたプロジェクトでした。
もう一つ学んだことは、選択肢を探し続けることの大切さです。一つのやり方がダメでも、他のアプローチを探していく。そしてその中で自分たちに適したものを選んでいく勇気も必要だと学びました。
──データベース移行が完了した現在、今後どのようなチャレンジをしていきたいですか。
金井：今後はサービスへの寄与を考えていきたいですね。企画職の人だけではなく、みんながサービスに対してアイデアを出せるような環境をつくりたいと思います。
Greg：Google Cloudに関する知見をさらに習得し、サービスの拡張に生かしていきたいと思います。
TimeTreeでは一緒に働く仲間を募集しています！
バックエンドやSREはもちろん、TimeTreeでは幅広くエンジニアを募集しています。本記事で興味を持たれた方はぜひTimeTree採用サイトからご応募ください。
