データベース移行プロジェクト始動、技術選定のポイントは？
──アプリケーション側はどのようになっているのでしょう？
河野：1つのAPIは1つのことしかできないような設計にすることで、コードやテストをシンプルに保つようにしています。いろんなことができてしまうエンドポイントで苦労した経験もあるので。ただ、クライアントの実装とのトレードオフもあるので、みんなで話し合いながら全体としてシンプルな構成を目指しています。
金井：私が入社した2018年時点ではユーザー数が1000万人ほどで、それでもデータ量がかなりありましたが、そこからユーザー数やデータ量が増え続けてもパフォーマンスは落ちていません。データが増えても影響が出ないようなAPIになるように考えられているからだと思います。
河野：社風かもしれませんが、シンプルさは常に意識しています。エンジニアは仕様がおりてきたらその通りに開発するのではなく、目的を意識したうえで「それならこうしたほうがよりシンプルにできる」とアイデアを出したりしています。
──技術的な課題はどんなところにありますか？
河野：データ量が大きいにつきます。何か新しいことをやろうとしても5400万のユーザーがアクセスすることを想定し、パフォーマンスを考えた設計にしなくてはなりません。特にデータベースに変更を加えるような機能実装が難しくなってきています。
金井：ストレージ容量が大きくなり、物理的なスケールアップ上限が目前に迫ってきています。以前から課題でしたが、昨年から本格的にデータベース改善プロジェクトとして動いています。移行する際の選択肢としては「Vitess（シャーディングツール）を自前で運用する」「VitessのマネージドサービスとなるPlanetScaleを使う」「Google Cloud Spannerを使う」という3つがありました。その後、コストやサポート、運用負荷などを総合的に考慮した結果、Google Cloud Spannerへの移行を決断し、作業が進んでいます。
河野：大きな決断でしたので、エンジニアだけではなく経営層も巻き込んで決断しました。
金井：エンジニアから声をあげ、プロジェクトとして立ち上げて、最終的にクラウドの移行まで動けた。ボトムアップの会社であるTimeTreeの強みが出た事例だと思います。
──ツール選定はどのように進めていったのでしょうか？
河野：ベタですが、大規模サービス運用をしているサイトの記事からバックエンド構成を調べて、自分たちに合うものを議論しました。Vitessだとデータベース分割のミドルウェアのようなもので、使用するデータベースは問わないのでアプリケーション的に親しみがあり、AWSのままでいいというメリットがありました。しかしシャーディング運用しなくてはいけないので、マネジメントコストがかさんでしまう。VitessのマネージドサービスとなるPlanetScaleでは、我々のデータ量だと予算超過になってしまう。あとまだ日本語のサポートがなくて時差が生じるのも厳しいという判断になりました。
──そのような技術選定を進めるうえでのポイントは？
河野：ありきたりですが必ずメリットとデメリットを列挙して、みんなで議論して決めることです。実は私、最初は「Vitessの自前運用」推しでした。移行コストを過大評価していたのですが、最終的にはGoogle Cloud Spannerで納得しました。
金井：私はGoogle Cloud Spannerを推していました。最初の意見は異なっていましたが、理由を説明したら納得してくれましたね。
河野：新しいことは悪影響が少なければ試そうという雰囲気も大事です。「新しいからやりたいです」だけではダメですけど、ちゃんと理由があればみんな話は聞きます。いつもみんなで決めているので、過去の試行の共通認識も持った上で話を進められます。
──現在データベース移行作業中とのことですが、どんなところが辛いですか？
金井：やはり最も辛いのはデータの大きさです。データが小さければ試行のスパンを短くできますが、データ量が大きいので移行するだけで数カ月かかってしまいます。長い期間をかけて行うプロジェクトですが、期限内に必ずやり遂げなくてはならないプレッシャーはありますね。また、経営層への説明用にプロジェクトのロードマップを作る時には、どの程度の粒度で資料を作るか迷いました。
あとAWSからGoogle Cloudへの移行にあたり、大量のインプットも必要になります。チャレンジングでなかなかしんどいことも多いですが、その分やりがいがあって楽しくもありますね。
河野：プロダクトの特性もあり、昔のデータにもアクセスがあるので、全てのレコードをアクティブにしなくてはならないのが難しさを助長させています。
