世界6000万ユーザーの「TimeTree」、サービスの未来を見据えて挑んだデータベース移行の舞台裏

AuroraからGoogle Cloud Spannerへの移行が無事完了、成功の秘訣とは？

　全世界で登録ユーザー数6000万人を超えるカレンダーシェアアプリを展開するTimeTree。同社ではそれら大量のデータを管理するデータベースをAmazon Aurora（以下、Aurora）からGoogle CloudのCloud Spanner（以下、Spanner）に移行した。Spannerを選択した背景、移行プロジェクトがうまくいった秘訣などを、同プロジェクトの立ち上げから携わった技術本部SREチーム マネージャーの金井栄喜（miu）氏とSREチーム バックエンドエンジニアのGreg氏に話を聞いた。

ローンチから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万人超の登録ユーザーを抱えていること。しかもそのうち、半分が日本国外のユーザーで占められているグローバルなサービスです。

株式会社TimeTree 技術本部 SREチーム マネージャー 金井栄喜（miu）氏

──なぜグローバルなサービスとして成長しているのでしょうか。

Greg：一つは、元々多言語対応してきたから。もう一つは、複数人で予定を調整するために取るコミュニケーションの課題が、グローバルで共通だったからだと考えています。

急成長するサービスで見えたAuroraの限界

──2018年の800万ユーザーから、現在は6000万ユーザーとサービスが大きく拡大していますね。システム的にはどんな課題が出てきたのでしょうか。

金井：入社のきっかけがデータベースの移行という話をしましたが、当時使っていたデータベースはAmazon RDSでした。指数関数的に増えるデータ量の改善策として、自分たちでマイグレーションの仕組みを構築し、Auroraに移行しました。

　無事データベースを移行し、次に課題となったのが、サービス全体のモニタリングができないこと。私たちのサービスは6時から10時半の間に、30分おきに急激なアクセスの増加（スパイクアクセス）があります。そのようなスパイクアクセスの状況が把握できないことが課題でした。もう一つの課題は、システム設計がレガシーであり、モダンなクラウド活用ができていなかったこと。例えばコンテナは利用していましたが、Amazon EC2を使っていたためオートスケーリングが柔軟にできませんでした。データの物理的な上限に対する課題もありました。

Greg：私がAuroraに感じた課題は、大規模なデータを持つスキーマ（データベースの論理的な構造）の変更の難しさです。

　例えばAuroraでスキーマの変更が生じたときは、GitHubが公開しているオンラインスキーマ変更ツール「gh-ost」を使っていました。当初は問題なく使えていたのですが、データ量が増えていくにしたがい、一時的にAuroraをスケールアップさせて、スキーマ変更ができる状態にした上で変更を実施、変更が終わるとスケールダウンさせるという方法を採ることにしました。しかし、この手法ではスキーマ変更のたびにサービスのダウンタイムが多少ですが発生してしまいます。このままでは開発スピードも落ち、サービスをスケールさせる方法も選択肢が狭まると思いました。

株式会社TimeTree CTO室 SRE Backend Engineer Greg氏

金井：Auroraはパフォーマンスが良く素晴らしいデータベースです。ですがGregが話したように、テーブル変更する際に使用するストレージの容量が足りず、大きなテーブルのマイグレーションができない状況に陥っていました。サービスの進化を妨げる要因となっていたのです。