LOVOO の Spanner への愛着

※この投稿は米国時間 2021 年 10 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: このブログでは、ドイツの出会い系アプリ「LOVOO」がモノリス システムからフルマネージドでスケーラブルな Cloud Spanner を備えたマイクロサービス アーキテクチャへと移行した経緯を紹介します。

2011 年に作られた LOVOO は、15 の言語で利用可能なヨーロッパでも有数のデートアプリです。現在、ドレスデンとベルリンにオフィスを構え、25 か国以上から集まった約 170 名の従業員が働いています。LOVOO は、出会い方を変えることで、人々の生活を変えていきます。当社は、チャットやリアルタイム動画によって、人々がマッチングに成功できるように、革新的な位置情報アルゴリズム、アプリのレーダー機能、ライブ ストリーミングを利用しています。

3 年前、当社は成長の鈍化を感じ始めました。ユーザーベースは着実に増加しており、アプリ内での活動も活発になっていました。オンプレミスのモノリス アーキテクチャでアプリを構築していました。当社の成長に伴い、古いシステムでは、ユーザーにサービスを提供するために必要なスピードとスケールに追いつくことができませんでした。

2018 年に利用できる選択肢を評価した結果、Google のオープンソース主導のアプローチと最先端のテクノロジーが、Google Cloud と Cloud Spanner を含むマネージド サービスへの移行を決定する重要な要因となりました。Spanner は現在、20 以上のデータベースをホストし、40 のマイクロサービスを強化し、他の Google Cloud サービスと完全に統合されています。Spanner のオープンソースのオートスケーラーを使えば、20,000 回という秒間クエリ数を実行するような忙しい時間帯でも、14 ノードから 16 ノードにシームレスにスケールアップできます。当社の一つのデータベースでは、1 日に 2,500 万件のクエリを処理し、毎月 100 GB の新しいデータを収集しています。このプラットフォームは、将来のニーズに合わせて拡張でき、新しいサービスや機能をサポートしながら、増加する顧客基盤に対応できると確信しています。

モノリスとの決別

Google Cloud に移行する前、当社のインフラストラクチャはオンプレミスにあり、データベースとしてオープンソースの PostgreSQL を使用していました。しかし、パフォーマンスのボトルネック、ピーク時のスケーリングの難しさ、常に新しいハードウェアを追加する必要があるなどの課題がありました。クラウドは、当社のエンジニアやプロダクト チームに、より速く、よりスムーズな開発プロセスを提供することを約束してくれました。アーキテクチャのリフト＆シフトの移行を行いましたが、移行をきっかけにモダナイズして重要な変更を行いました。モノリスからマイクロサービスにいくつかの責任を分離し、それらを直接 Google Kubernetes Engine（GKE）に移しました。最初はモノリスから 10 数個の機能をマイクロサービス化することから始めましたが、現在では先行するモノリスから分離したマイクロサービスが 40 個以上になっています。

オンプレミスの契約残存期間内に移行を終えたかったので、6 か月というタイムラインでスムーズに移行を行いました。最終的にはマイクロサービス ベースのアーキテクチャに全面的に移行する予定ですが、少しづつ進めています。当社の課金データベースとロジックは複雑で、オリジナルのデータベース ソリューションである PostgreSQL で構築されています。今回のケースでは、  Cloud SQL for PostgreSQL にワークロードを移行することを選択しました。Cloud SQL for PostgreSQL は Google のフルマネージド データベース サービスです。

Spanner に恋に落ちる

Spanner は、Google Cloud の最初のサポートレベルであり、大規模な分散データベースのための好ましいソリューションでした。Spanner は、無制限の拡張性と最大 99.999% の可用性を備えた、フルマネージド リレーショナル データベース サービスです。これにより、当社が以前抱えていた拡張性と速度の問題が効果的に解決されます。Spanner のようなマネージド サービスは、インフラストラクチャ管理、アップデート、メンテナンスなどの日常的な悩みを解決してくれます。そのため、当社は LOVOO の新機能の開発にエネルギーを注ぐことができます。

一つの Spanner インスタンスには約 20 個のデータベースがあり、本番環境用と開発用のデータベースが混在しています。これは一種のマルチテナンシー アーキテクチャで、当社のサービスのほとんどはデータベースと一対一で接続されています。現在、1 つの地域に 20 TB、14 ノード（ピーク時は 16 ノード）をデプロイしています。

Spanner の使用例としては、当社最大のデータベースである通知データベースがあります。このデータベースには、他のユーザーが自分のプロフィールに対して閲覧やマッチングなどのアクションを起こしたときに、アプリのユーザーに通知を送るために必要なデータが保存されています。そのため、あなたが相手に興味を持っていることを示し、相手がすでにあなたに興味を示している場合、それは通知テーブルの行に変換されます。相手がログインすると、相手が持っている新しい通知をクエリし、相手はあなたとマッチしたことを確認します。

また、Spanner にはユーザー メッセージ用のデータベースがあります。ユーザーはリアルタイム チャットで会話をします。その会話の中のメッセージには、写真、オーディオ、GIF など、ユーザーが互いに送信できるさまざまなメディアタイプが含まれます。このリアルタイム チャット機能を担うマイクロサービスには、クライアントとの間にウェブソケット接続があり、テキストやコンテンツは Spanner に保存されます。会話のテーブルと、個々のメッセージのテーブルがあります（各メッセージには会話 ID があります）。

Spanner の 3 つ目のユースケースは、ユーザー同士がクレジットを贈り合うことができる、アプリ内クレジット取引サービスです。仮想通貨の決済システムのようなものだといえます。つまり、すべてのユーザーのテーブルがあり、それぞれのユーザーのクレジット残高があるということになります。また、ギフトを送る際には、自分の列のクレジット数を減らし、相手の列のクレジット数を増やします。また、「支払い」の台帳には、これまでに行われたすべてのクレジット ギフトの行があります。この機能については、Spanner のトランザクションの一貫性が優れています。これらの操作をすべて 1 つのトランザクションで自動的に行うことができます。

Google Cloud で未来を描く

当社は Spanner Emulator にも満足しています。開発プロセスが格段に楽になりました。  エンジニアは Spanner に直接アクセスしなくても、  エミュレータをローカルに実行することで、自分のマシンでコードをデバッグできます。ビルドプロセスの一環として、エミュレータを起動し、ソフトウェアのテストを行うことができます。また、当社のエンジニアは、エミュレータをマシン上でオンデマンドでインテグレーション テストを実行するためにも使用しています。これにより、コードの構築時に使用したのと同じ API 呼び出しが、コードのデプロイ時にも機能するようになります。

当社の計画は、新機能のすべてを Spanner の上に構築し、モノリスからサービスを引き出していくことです。現在、ユーザーのさまざまなデバイスを追跡するユーザー デバイス表現データベースを移行中です。また、今後のユースケースでは、PHP からの脱却を進めていきたいと考えており、PHP 経由ではなく、Google のオープンソースの通信プロトコルである gRPC を使って、クライアントとマイクロサービスを直接接続したいと考えています。

Spanner をはじめとする Google Cloud のマネージド サービスは、当社の時間を節約し、スピードとスケーラビリティを提供してくれるので、当社はそれらのサービスを味方につけて将来のロードマップを描いていきます。Google Cloud は当社にぴったりです。

また、LOVOO と Cloud Spanner についてはこちらをご覧ください。さらに、フィンテック企業である Merpay が数百万人のユーザーにスケールアップする際に、Spanner がどのように貢献したかについてもお読みください。

- LOVOO 社、エンジニアリング部長 Johannes Braun