はじめに
株式会社Omiaiでテックリードを務める渡邊です。Omiaiはサービス提供開始から10年以上経過しており、多くのユーザーに利用していただいている一方で、多くの技術的負債が蓄積している状況でした。そこで、2024年ごろからシステム全体のリアーキテクトを段階的に行っています。この記事では、データベースのリアーキテクトの取り組みについて紹介していきます。
技術的負債が蓄積した経緯
Omiaiがリリースされた当時、マッチングアプリ市場は黎明期でした。今であれば、「検索機能」「いいね機能」「マッチング機能」「プロフィール機能」といった具体的な機能を想像できますが、今ほどに市場が拡大することを想定していませんでした。そのため、最低限のデータベース設計でサービスが作られたという背景があります。
実はいうと、Omiaiは2015年にもリアーキテクトを実施したことがあります。ただ、結果的にはうまくいきませんでした。原因としては大きく2つあります。1つがプログラミング言語の変更に固執してしまったこと。データベースやパフォーマンスといった本質的な課題ではなく、開発者体験を改善する方向に舵を切ってしまったがゆえに、そこまで大きな成果を得られませんでした。
もう1つが市場拡大とともに競合他社が増えて、リアーキテクトよりもサービス提供を重視せざるを得なかったために、それほど技術負債の解消にコストを割けなかったことです。
技術的負債が蓄積したことで発生していた問題とは何か？
データが密結合しているために、一部のデータベースを書き換えるとさまざまな機能でバグが発生し、修正対応しなければいけないという問題が発生していました。そのため、何か1つの修正をするたびに、検証や調査、実装などを行わなければいけなくなりました。
この生産性が低い状態のままで開発や運用を進めると、開発コスト・検証コストが著しく増大し、いずれコア機能の改修や追加に集中できなくなる状態が訪れる（エンジニアの人件費を上げられなくなる・マーケティングの予算を割けなくなる等）ことは明白でした。そうすると、最終的にはエニトグループの事業成長の足かせにもなってしまいます。
また、データバリデーションの処理が非効率になっていることでマッチングアプリの根幹である「いいね」や「マッチング」のパフォーマンスが悪化している問題も起こっていました。月に行われた「いいね」や「マッチング」の総数は数十億を超えています。しかも、ただ「いいね」を送る処理だけではなく、すでに「いいね」したかどうかを確認するフローが必要になります。
パフォーマンスチューニングをする選択肢もありましたが、すでに蓄積されているデータが膨大であるために、大幅に工数がかかってしまいます。また、データを管理するインフラも加入プランの限界を迎えかけており、リアーキテクトをしないといけない段階に入りかかっていました。
実際に、技術的負債は機能開発にも影響が出てしまっていて。サービス成長にダイレクトに影響があったかというと、そこまで大きなインパクトはないのですが、競合他社でも実装されている「コミュニティ機能」などをデータベースの構造的な問題で追加することができませんでした。
データベースの技術的負債をどう改善したか？
まず最初に、データベースをそれぞれカテゴライズし（我々は「ドメイン」と呼んでいます）、14〜18ぐらいにまで分解しました。そのなかでも、マッチングアプリとして最も重要な「いいね」「マッチング」「検索」「プロフィール」にフォーカスしてリアーキテクトを実施していきました。この形をとると、サービス開発や機能追加に影響が出ないため、基本的にプロダクト開発を中断することなく進めることができます。インフラコストも下がり、かつこの後修正がしやすくなるという結果や数値的根拠を出せていたことも相まって、プロダクト側から反対意見が出ることはなかったです。
1.データベースの整理/インフラの最適化
ここから具体的な方法について解説していきます。まず、データのインフラについては「Amazon RDS」を採用することを前提に動いていました。ただ、先ほども書いたように保有データが膨大になっていたため、退会データを分析データとして堆積させたうえで、ユーザーが使用するドメインから全て削除しました。こうすることでデータを大幅に削減し、RDSへの移行を達成できました。
2.データベースの改修
よくあるのが、データベースそのものを壊してしまって復元できなくなるケースです。これを回避するためにダブルライト処理を行いました。読み込みモジュールを2つ構築して旧リードから新リードに一気にデータを戻した後に、旧リードの整理を行う形でデータベースの再設計を行いました。
3.テーブル設計
テーブル設計は「データをどう扱うか」という定義づけをするのが一般的です。しかし、今回は「Omiaiとして、そもそもどういうデータなのか」というところから設計しました。これをあらかじめ決めておくことで、仕様変更の際にも引きずられることなく一意性のあるデータとして残存させることが可能となります。
4.データベースシステムの一本化
1つのデータで複数のインフラリソースを処理している領域があったため、一本化しています。具体的には、検索エンジンになるのですが、当初はElasticsearchとMySQLを併用していました。しかし、MySQLのパフォーマンスが低下していることが判明したため、Elasticsearchに完全移行しました。
技術的負債を解消したことで得られた効果
技術的負債を解消したことでさまざまな効果を得られました。まず、データベースが最適化されたことでパフォーマンスが改善しました。レイテンシーでいうと平均0.15秒ほど早くなっています。また、既存の機能改修や機能改善についても1ヶ月半から2ヶ月ほどで完了できる状況になっており、開発全体のスピード向上にもつながっています。それに伴って、インフラコストもおよそ50%削減することができました。
プロダクトの成長を阻む「技術的負債」は早めに解消する
個人的には、データベースについては「技術的負債があることが判明したタイミング」で、すぐ実施した方が良いと思っています。ロジックの技術的負債は多少あったとしても直せる手段はあるし、後で直すことも可能です。ただ、データはプロダクトの核に直結しています。それこそ、フロントエンドも、バックエンドのAPIリクエスト、レスポンス、業務ロジックなども全てデータに依存しているわけなんです。
Omiaiでいうと、誰かを「検索」して、「いいね」をして「マッチング」、そして「メッセージ」をする部分が核となります。これらについては妥協しないスタンスでいかないと、システム起因でビジネスモデルが崩れる恐れもあります。
だからこそ「データに関わる技術的負債は基本認めない」というスタンスが重要になります。とはいっても、全てのデータの技術的負債を解消する必要はなくて、プロダクトの根幹に関わらないデータについては優先順位を下げる判断をして進めれば良いです。
ここで大切になるのが、経営層との目線合わせですね。なぜならば、経営層からみると機能開発をすることが効果的に映るケースが多いからです。個人的な所感としては、「これ以上、コアな機能は改善が見込めません」と説明すると響く印象がありますね。やはり、プロダクト成長に直結することを伝えられると良いと思います。
“システム”としてではなく、“プロダクト”の観点で重要かそうではないかを決めてリアーキテクトをすることが大切です。
Discussion