データベース

Spanner によりデータベース運用を改善した Glance の事例

2024年3月14日

Google Cloud Japan Team

Gemini 1.5 モデルをお試しください。

Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダルモデルです。

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

編集者注: この記事では Glance の事例をご紹介します。Glance は、ユーザーが一目で簡単に自分にぴったりの情報を見つけて参照できるよう、ニュース速報、ゲーム、エンターテイメントからパーソナライズされた商品レコメンデーションまで、多様で魅力的なコンテンツを Android スマートフォンのロック画面に直接配信しています。同社では先日、データベースの運用を改善し、データ サイエンス関連の機能向上の基盤を築くために、Azure Cosmos DB から Spanner に移行しました。その具体的な内容をご紹介します。

Glance は、さまざまな地域（インド、インドネシア、ラテンアメリカ、日本）において、業界をリードする数多くの OEM 企業との緊密な連携を通して、2 億 3,000 万人以上にのぼる多様で幅広いユーザーベースを築いています。このような大規模な環境でトランザクションを処理するため、先日当社の主要なデータベースの運用を Google Cloud Spanner に移行しました。

背景

当社がドキュメントデータベースを Azure Cosmos DB から Spanner に移行したのは、リレーショナルセマンティクスを容易に実現するとともに、データベーストランザクションの管理を改善することが目的でした。以前は、アプリケーションをドキュメントベースの Azure Cosmos DB にオンボーディングするには、トランザクションやスキーマ設計の最適化、読み取り / 書き込みの調整のためにアプリケーションを微調整する必要がありました。たとえば、Azure Cosmos DB で使用していた JavaScript Object Notation（JSON）には頻繁にフィールドが追加されていたほか、新たなコレクションが追加されることもあり、スキーマを移行して進化させるための独自のプロセスを用意する必要がありました。

ドキュメントデータベースではデータテーブル間の関係性が認識されなかったため、JOIN 操作のために最適化できず、面倒な操作を行う必要があり、複製されたデータがドキュメントとして保存されていました。同時に、ドキュメントの通信では Apache Thrift プロトコルを使用しており、正しいパイプラインをデプロイする必要もありました。

当社での運用に最適なデータベースを選定するため、1 か月かけて概念実証（POC）を行い、複数のデータベースに対してベンチマークを実施しました。ベンチマークにあたっては、既存のワークフローを理解したうえで、候補のデータベースに対して複数のテストを実施しました。行ったテストには、耐久テスト、本番環境同様のデータを使用したテスト、トラフィックの急増時におけるレイテンシテストなどがあります。また、さまざまなデータベースの機能を評価するオープンソースソフトウェア Yahoo Cloud Serving Benchmark（YCSB）を使用して一連の負荷テストを実施したほか、JMeter テストを通して実際のユースケースについてもベンチマークを行いました。

その結果、データベースの CPU とレイテンシを推奨される制限内に収めつつ、当社が必要としていた秒間クエリ数（QPS）のレベルを達成できた Spanner を選ぶことにしました。Spanner により、読み取り / 書き込みの両方において、クライアントサイドのレイテンシを 20 ミリ秒未満に抑えることができました。

さらに Spanner は、リレーショナルデータベースと非リレーショナルデータベースの両方のメリット、つまりセマンティクスとスケーラビリティを兼ね備えています。言い換えると、SQL データベースのメリットであるデータの可用性や整合性などを犠牲にすることなく、容易にデータベースの水平スケーリングを実現できます。このようにして、NoSQL データベースから SQL データベースに移行しました。また Spanner では関連するテーブルの行を物理的に同じ場所に配置できるため、ユースケースによってはインターリーブを使用しています。

シームレスなスキーマの更新による迅速な機能構築

このように Azure Cosmos DB から Spanner にデータベースを移行しましたが、Spanner ではスキーマの更新もシンプルです。Azure Cosmos DB はスキーマに依存しない仕組みだったため、当社のチームにはスキーマの更新を管理した経験がありませんでした。そのため、スキーマの更新を簡単に行える点が特に役立ちました。特に、Spanner では、新規のテーブルや列、セカンダリインデックスの追加などのスキーマの更新がバックグラウンドタスクとして行われるため、稼働中のデータベースに影響を与えず、ダウンタイムゼロを実現できます。

とはいえ、スキーマを変更すると、データアクセスレイヤでアプリケーションレベルの変更の管理が必要になる場合もあります。Spanner は、ほとんどすべての主要言語向けのクライアントライブラリを提供しており、アプリケーションを正しく変更するのに役立ちます。また当社は、データベーススキーマの変更の管理と実施のために、スキーマの変更の追跡、管理、適用に対応したデータベース非依存のオープンソースライブラリ Liquibase を使用していますが、このライブラリとの統合も可能です。

段階的な Spanner への移行

Google Cloud のチームは、トラブルシューティングのアドバイス、ベストプラクティスの提案、インタラクティブなセッションを通して、移行のプロセス全体を通じ当社のチームをサポートしてくれました。移行はいくつかの段階に分けて、約 3 か月かけて実施しました。

第 1 段階は移行の計画です。データベースやスキーマの設計、移行の戦略などについて話し合いました。移行はオフラインで行うべきか、オンラインで行うべきか、それとも両方を併用すべきか。どのようなアプリケーションの変更が予想されるか。カットオーバーやロールバックはどのように実施できるか。このような問いについて、Glance チームと Google Cloud チームとの間で徹底的に議論しました。
複数回にわたるドライランや、本番環境のシミュレーションにより、移行プロセス全体の十分なテストを実施しました。ドライランを実施するたびに、データ検証スクリプトを準備して、データの正確性を検証しました。移行は数か月にわたるため、その間にスキーマの変更が生じることも考えられます。そのため、スキーマ設計の変更を行うための手順も用意しました。
最後の段階は移行の実施です。ほとんどのワークロードが高い重要度であったため、オンライン移行を選択しました。移行のプロセスでは、変更データキャプチャ（CDC）、一括スナップショット、インポート、データ検証、逆 CDC、カットオーバーなどを行いました。

Spanner は分散型データベースであるため、その特性を活かして移行中にデータのリモデリングも実施しました。非効率な設計の修正に加えて、このデータベースが持つ SQL スキーマ設計のメリットも活かしたいと考えました。Spanner が持つテーブルのインターリーブ機能を使用することにより、複数のコレクションに分散配置されている場合でも読み取りを最適化できました。

データベース全体におけるキーの読み取り / 書き込みアクセスパターンを確認するにあたっては、Spanner の Key Visualizer が役立ちました。このツールに表示されるグラフでは、CPU 使用率、スループット、レイテンシ、アクセスパターンを確認できます。これにより、どのキー範囲の負荷が高まり、ホットスポットが生じているかを簡単に確認できます。同時に、このようなホットスポットの発生によって同じキー範囲に大量のリクエストが送信され、レイテンシが高まることのないようにデータベーススキーマを設計することもできます。

特に、このツールは POC の段階で負荷テストハーネスの検証に役立ちました。具体例として、ときどき P99 レイテンシが 20 ミリ秒を超えることがありました。そこで Key Visualizer のヒートマップを確認すると、負荷生成ツールの側で均等に負荷を分散できていないことがわかりました。この知見に基づきデータベースのスプリット間で均等にトラフィックを分散させることにより、この問題を修正できました。その結果、レイテンシは大幅に改善し、読み取り / 書き込みで 13 ミリ秒未満の P99 レイテンシを達成できました。

Key Visualizer ではわからない問題が生じた場合は、SPANNER_SYS データベースのテーブルを利用して、Spanner インスタンスの内部をイントロスぺクトしました。これらのテーブルを使用すると、クエリの統計データを使用して問題を調査したり、上位 N 個のクエリを定期的に確認したりできます。現在実行中のクエリ、最も長く実行されているクエリ、ロック / 読み取り / 書き込み / トランザクションの状態を確認することもできます。シンプルでスケーラブルな SQL インターフェースを介して、データベースの内部状態を把握できる指標にアクセスできるので、パフォーマンスに関するデバッグが非常に簡単になりました。

移行プロセス完了後、変更ストリームを使用して、レポート送信やダッシュボードへのデータ提供用のデータパイプライン、バックアップなどのバックエンド機能の移行をサポートしました。変更ストリームでは、挿入、更新、削除などのデータの変更をニアリアルタイムで監視し、ストリーミングできます。そのため、データの変更を柔軟かつスケーラブルな形でストリーミングすることが可能です。

データベース運用の簡略化によるアジリティ向上

Spanner は複数のモニタリングパネルを備え、クエリ、トランザクション、ロックについての分析情報を提供してくれるため、日々のデータベースの運用を改善できました。従来のほとんどの SQL データベースでは、このような機能は簡単には利用できません。

スキーマの更新もシンプルになりました。データベースは会社の成長とともに進化するため、これはデータベース管理のうえで非常に重要です。Glance のアプリケーションでは、Spanner でスキーマを更新している間もダウンタイムが生じないため、安心して運用を続けながら、アジリティを保ち、ビジネスのパフォーマンスを維持できます。また、ニアリアルタイムでデータの変更を処理する変更ストリームのおかげで、あらゆるシステム間の整合性と正確性を確保できます。

最後に指摘しておきたい Spanner データベースのメリットとして、特に、大規模にトランザクションを行うようなユースケースにおいて、アプリケーションのトラフィックが急増してもシームレスに対応できる点があります。

当社は、1 年前に移行を開始してから、さらにいくつかのデータベースを Spanner に移行しました。また、Spanner による BigQuery 連携を活用してデータサイエンス業務を推進できないか、検討を進めているところです。