Spanner

Spanner カラム型エンジンで Iceberg レイクハウスの最新データを迅速に提供

Thu, 05 Mar 2026 03:00:00 +0000

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

運用データベースのデータと分析データレイクハウスのデータの間の境界は急速に消えつつあります。ゼロ ETL レイクハウスアーキテクチャを導入する企業が増えるにつれ、課題は単に Apache Iceberg のようなオープンデータ形式でデータを保存することから、最新のアプリケーションや AI エージェントが必要とするデータを低レイテンシのパフォーマンスとスピードで提供することに移っています。脅威検出に関する分析情報をリアルタイムで必要とする Palo Alto Networks のようなサイバーセキュリティプロバイダであれ、より優れたカスタマーエクスペリエンスを提供するためにデータワークフローの再構築を検討している Vodafone のような通信業界の大手企業であれ、組織は事前に計算された分析情報と AI モデルを大量に提供しなければなりません。

そこでこのたび、Spanner カラム型エンジンのプレビュー版をリリースしたことをお知らせいたします。これにより、Google の Spanner が持つスケーラビリティと低レイテンシで Iceberg レイクハウスのデータを提供できるようになります。

OLTP と分析の統合: Spanner カラム型エンジン

従来、組織は OLTP データベースの高性能なトランザクション機能と、カラム型ウェアハウスの分析能力のどちらかを選択せざるを得ませんでした。Spanner のカラム型エンジンは、これら 2 つの世界を水平方向にスケーラブルな 1 つのシステムに統合することで、このトレードオフの問題を解消します。

カラム型エンジンでは、特別なストレージメカニズムが採用されています。このメカニズムは、ライブ運用データのスキャンを最大 200 倍に高速化して分析クエリを加速させるように設計されています。Spanner は、従来の行ベースのストレージと並行してカラム形式でデータを保存することにより、複雑なクエリを自動的に実行できます。その際は、データを行単位ではなく一度にバッチ処理するベクトル化された実行を使用します。最も重要な点は、このパフォーマンスの向上を重要なトランザクションワークロードから分離できることです。これにより、顧客向けアプリケーションの応答性を維持しながら、運用データストアからリアルタイムの分析情報を取得できます。

新機能

Spanner カラム型エンジンを初めて発表して以来、パフォーマンスを加速させ、ユーザビリティを高めるための新機能がいくつか追加されています。たとえば、以下のようなものが挙げられます。

ベクトル化された実行: エンジンは、ベクトル化された実行を使用して、より高速なカラム型スキャンと集計に対応し、より効率的にデータを処理します。
自動クエリ処理: Spanner は、大規模スキャン分析クエリを自動的にカラム型表現にリダイレクトし、同時に実行しているトランザクションワークロードに影響を与えることなく分析クエリを高速化して、真のハイブリッド処理を実現します。
オンデマンドのカラム型データ変換: 自動化されたカラム型データ変換に加えて、新しいメジャーコンパクション API により、既存の非カラム型データをカラム型形式に変換するプロセスが加速します。

Iceberg データに高速かつ低レイテンシのサービングプラットフォームが必要である理由

オープンレイクハウスアーキテクチャの標準となっている Apache Iceberg は、クラウドベースのストレージで大規模なオープン形式のデータセットを管理する堅牢な手段となります。ただし、レイクハウスは大規模な分析には優れていますが、ライブアプリケーションで求められる、同時実行性の高い 1 秒未満での「ポイント検索」や集計サービス向けには、通常は設計されていません。

Spanner が独自の価値提案を提供するのはこの部分です。キュレートされた処理済みデータをレイクハウスから Spanner に移動するプロセス（リバース ETL と呼ばれます）により、「コールド」分析データが「ホット」運用データに変換されます。Spanner は、アプリケーションが必要とするグローバルな整合性と高可用性を提供します。低レイテンシの API を介して Iceberg データにアクセスできるようにすることで、リアルタイムの意思決定やエージェント型 AI 機能の利用が可能になります。

Spanner カラム型エンジンのベンチマーク

Spanner の新しいサービング機能を実証するために、業界をリードする分析データベースベンチマークの Clickbench を使用しました。Clickbench は、ウェブ解析やリアルタイムダッシュボードでよく使われるクエリタイプに焦点を当てています。これはまさに、低レイテンシのサービングが重要となるシナリオです。

単一の Spanner ノードを使用したベンチマークの結果から、カラム型エンジンが持つ力がわかります。

Clickbench のクエリ	Spanner カラム型エンジンの高速化
Q01	46.3 倍
Q02	32.7 倍
Q19	46.7 倍
Q32	58.6 倍

上述の結果は、Spanner カラム型エンジンにおける実際のワークロードの高速化を表しており、Spanner がスキャン負荷の高い複雑なクエリを実行し、ミリ秒単位で結果を返すことができることを示しています。これは、リアルタイムダッシュボードやユーザー向け機能の強化に最適です。今や Spanner は、最新のデジタルエクスペリエンスが求めるスピードで複雑な分析結果を提供できる、高性能なエンジンとなっています。

ユニバーサルリバース ETL: すべてのレイクハウスのデータを提供

Spanner は、データエコシステム全体のサービングレイヤとして機能するように設計されています。レイクハウスが BigQuery、Snowflake、Databricks、Oracle のいずれにある場合でも、Spanner は高速サービングのための統合経路を提供します。

最新のリバース ETL ワークフローにより、分析の世界と運用の世界を簡単につなぐことができます。

BigQuery: Spanner と BigQuery の緊密な統合により、運用環境と分析環境の両方で Iceberg データを管理するための強力な双方向ブリッジが実現します。BigQuery の Spanner 外部データセットを使用して BigLake Iceberg テーブルと Spanner テーブルに対する連携クエリを実行できるため、データを移動しなくてもリアルタイムで分析できます。キュレートされた BigQuery の分析情報を大規模に提供する必要がある場合は、リバース ETL ワークフローを使用して、BigQuery と BigLake Iceberg テーブルからデータを Spanner に直接 push できます。さらに、Datastream を使用して、Spanner でライブ運用データの変更をキャプチャし、BigQuery と BigLake Iceberg のテーブルにストリーミングできます。これにより、レイクハウスでは Spanner のトランザクションデータと同期された状態が保たれ、エージェント型 AI やリアルタイムでの意思決定を実現できます。
Databricks: Databricks の Universal Format（UniForm）を使用すると、Delta Lake テーブルの Iceberg メタデータを自動的に生成できます。これにより、Spanner は BigQuery または Dataflow を介して処理された Databricks データを取り込むことができるため、エンジニアリングのオーバーヘッドを最小限に抑えながら、「キュレーション済み」のデータセットをアプリケーションの強化に活用できます。
Snowflake: Iceberg テーブルを Google Cloud Storage にエクスポートし、BigQuery BigLake をゼロコピーの中間ストレージとして使用することで、EXPORT DATA コマンド経由でデータを直接 Spanner に push できます。代わりに、よりシンプルな移行方法として、Snowflake データを CSV としてエクスポートし、Dataflow テンプレートを使用して Spanner に高スループットで取り込むこともできます。
Oracle Autonomous AI Lakehouse: Oracle Goldengate 26ai では、Oracle Autonomous AI Lakehouse のデータを Spanner に複製し、Spanner のスケーラビリティと整合性を活かして Oracle のデータエコシステムから生成された分析情報を提供できるようになりました。

使ってみる

レイクハウスのクエリが完了するのを待つのはもうやめましょう。Spanner カラム型エンジンを搭載した Google Spanner を使用して、更新頻度の高いホットデータをすばやく提供してください。Spanner カラム型エンジンは現在プレビュー版で公開されています。DDL を簡単に変更するだけで、既存の Spanner テーブルに対してすぐに有効にできます。

GitHub で入手できる Spanner で Clickbench クエリを実行すると、Spanner カラム型エンジンのパフォーマンスの向上を実際に確認できます。

すぐに使用を開始できるよう、Spanner へのリバース ETL パイプラインを構築する Codelab をご紹介します。

Databricks:

および

Snowflake:

- グループプロダクトマネージャー、Jagan R. Athreya

- エンジニアリング担当ディレクター、Girish Baliga

従来の Apache Cassandra スタックを廃止し、Spanner で未来志向の基盤を構築

Thu, 05 Mar 2026 00:10:00 +0000

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

従来の NoSQL 環境である Apache Cassandra などから Spanner へ移行するお客様が増えています。その戦略的な背景は明確です。総保有コスト（TCO）の大幅な削減、弾力的なスケーラビリティ、そしてほぼゼロに近い運用負荷です。

Cassandra Query Language（CQL）API を Spanner 上で利用できるネイティブエンドポイントが一般提供されたことで、既存の Cassandra アプリケーションは、使い慣れた CQL をそのまま活用しながら、強整合性、事実上無制限のスケール、99.999% の可用性を備えた Spanner のエンタープライズ基盤を利用できるようになりました。

さらに、CQL インターフェースを用いた Spanner への移行は、通常、コードの 1 行を変更するだけで済みます。既存の CQL 文はそのまま有効だからです。Google が提供する統合型の高性能バルクマイグレーションツールおよびライブマイグレーションツールと組み合わせることで、Cassandra から Spanner への移行はシンプルに実現できます。

NoSQL の先へ: Cassandra ユーザー向けの戦略的ソリューション

CQL API は移行を容易にしますが、Spanner は、従来の Cassandra アーキテクチャに内在するデータの完全性と運用上の制約そのものを解決します。

グローバル ACID トランザクション: 結果整合性に伴う懸念を最小限に抑えます。あらゆる規模においてデータの完全性を確保できるよう、包括的なグローバル ACID トランザクションを実現します。
強力なインデックス: 強整合性のセカンダリインデックスにより、複雑なクエリパターンにも対応できます。最適化が組み込まれており、完全性に関するリスクもありません。
豊富な SQL: 結合や集計をサポートする高度な SQL インターフェースを活用できます。
高い信頼性: リージョン構成では 99.99%、マルチリージョン構成では 99.999% の可用性を享受できます。
コンプライアンスとレイテンシ: 地域的パーティショニングにより、データレジデンシ要件への対応を簡素化します。グローバルなユーザー基盤に対して、低レイテンシのローカル読み書きを提供できます。
組み込みのオブザーバビリティ: 追加費用なしで、Google Cloud コンソール上から各種パフォーマンス指標やチャート一式にアクセスできます。

ネイティブ CQL エンドポイントは、既存の Cassandra アプリケーションを切り離し、Spanner の能力を最大限に活用してモダナイズするための明確な道筋を提供します。次に、Cassandra から Spanner へデータとアプリケーションを移行した後のステップを見ていきましょう。

ワークロードに合わせた Spanner の最適化

移行後は、以下の方法で Spanner 環境をワークロードに合わせて最適化できます。

1. コストと運用効率の最適化

ワークロードの特性	おすすめの解決策	主なメリット
書き込み負荷が高いトラフィック	スループットを最適化した書き込み	リクエストのバンドリングにより、書き込みスループットが最大 6 倍に向上（レイテンシへの影響は最小限）。
トラフィックが変動または増減する	オートスケーラー	需要に応じて容量を自動調整し、過剰プロビジョニングによるコストを排除。
安定したベースライン容量が必要	確約利用割引（CUD）	定常的な運用コストを最大 40% 削減。
ストレージ集約型ワークロード	階層型ストレージ（HDD）	費用対効果の高い HDD ストレージを活用し、長期的なストレージ費用を大幅に削減。

2. 低レイテンシの実現Spanner は、ミッションクリティカルかつ高並行性のワークロードを支えるため、継続的にパフォーマンスを強化しています。

シングルディジットミリ秒のパフォーマンス: 読み取りおよび書き込みの両方で、常に 5 ms 未満のレイテンシを実現します。
反復可能な読み取りの分離: 楽観的同時実行制御を活用し、読み取り中心かつ競合の少ないシナリオにおいて、レイテンシとトランザクション中断を低減します。
読み取りリース: マルチリージョン構成において、リージョン間の調整を行わずに強整合な読み取りを可能にします。これにより、ノード効率とパフォーマンスを最大化します。

3. トラフィック急増への備えマーケティング施策のローンチや大規模データ取り込みなど、計画的なイベントに備えて、容量を事前に管理できます。

Manual split API: Spanner はは通常、自動でデータをパーティション分割しますが、事前分割機能を使うことで、ピーク負荷の前にデータ分散方法を正確に定義できます。これにより、新たに追加した容量を即座に活用でき、安定したパフォーマンスを確保できます。

4. 運用系と分析系のパイプラインを分離BI や ETL プロセスをコア業務処理から分離し、リソース競合を防ぎます。

専用リソース: 読み取り専用レプリカや有向読み取りを活用することで、ワークロードの分離を実現します。
高度な分析機能: Spanner はカラム型エンジンにより高性能なオペレーショナル分析を提供します。また、Data Boost、リバース ETL、継続的クエリを通じて BigQuery と統合できます。

Cassandra エコシステムを再構築する

Apache Cassandra から Spanner への移行は、複雑に絡み合ったサイドカーユーティリティ群からアーキテクチャを切り離す戦略的な機会です。Cassandra 互換 API はあくまで入口にすぎません。真の価値は、運用上の「Cassandra 税」ともいえる負担を、統合されたマネージド型マルチモデルエコシステムへと集約できる点にあります。

こちらは、TCO を大幅に削減しながら、パフォーマンスを大きく向上させるためのクイックガイドです。

1. コネクタを活用してスムーズに移行

Spanner Cassandra アダプタや各種コネクタを活用することで、管理レイヤーとアプリケーションレイヤーを、コード変更をほぼ伴わずに移行できます。これにより、移行初期の負担を最小限に抑えられます。

オーケストレーション: Spanner プロキシに付け替えることで、既存の Airflow DAG を維持できます。
アプリケーションフレームワーク: Spring Data Cassandra から Spring Data Spanner へ移行し、既存のリポジトリパターンを保ちながら、より優れたトランザクションモデルを活用できます。
データ処理: Spanner のネイティブ CQL エンドポイントに接続するか、Spark 向けの専用 Spanner Connector を使用することで、Apache Spark の活用を継続できます。

2. ネイティブ統合でサイドカーを整理

Cassandra では運用面の「付き添い」レイヤーが不可欠ですが、Spanner はそれを自動化します。従来の保守ツールを段階的に廃止し、Spanner の高度な機能を活用できます。

アンチエントロピー: Cassandra Reaper を廃止できます。Spanner は Paxos ベースのレプリケーションにより整合性をネイティブに管理するため、手動のリペアサイクルが不要になります。
データ保護: Medusa は Spanner ネイティブのバックアップに置き換えられます。脆弱な SSTable スナップショットから脱却し、信頼性の高いポイントインタイムリカバリ（PITR）へ移行できます。
オブザーバビリティ: 複雑な JMX エクスポータの代わりに Cloud Monitoring を利用できます。保守負債を増やす監視ではなく、Query Insights や Lock Statistics といった高付加価値の指標に注力できます。
統合検索: 外部の Elasticsearch サイドカーや複雑な ETL パイプラインを Spanner の全文検索で置き換えられます。これにより、インデックス同期の問題を解消できます。
モダンなストリーミング: 従来の CDC を Spanner 変更ストリームに置き換えられます。Dataflow や Kafka とネイティブに統合できます。
グラフ分析: JanusGraph は Spanner Graph に移行できます。複雑な ETL を介さずに、運用データに対して openCypher クエリを直接実行できます。
クエリフェデレーション: Trino / Presto は、Data Boost を介した BigQuery Federation に置き換えられます。本番環境の I/O に影響を与えることなく、リアルタイムのトランザクションデータと大規模なデータレイクを結合できます。

Spanner のマルチモデルの強みで未来を築く

Spanner は、リレーショナル、Key-Value、グラフ、検索、ベクトル検索といった機能を 1 つの相互運用可能なプラットフォームに統合した常時稼働型のデータベースです。Spanner に移行することで、分断された複数データベースを管理する負担を解消し、統一されたデータ基盤の上で革新的なアプリケーションを開発できるようになります。新規アプリケーションの構築にも、既存アプリケーションのモダナイゼーションにも、Spanner の機能を最大限に活用できます。

今すぐ始めましょう

運用管理の負担から解放され、構築に集中する準備はできていますか？今すぐ移行を開始し、既存の Cassandra Query Language をそのまま活用しながら、Spanner の能力を体験してください。

Codelab: ネイティブ CQL エンドポイントを使ったハンズオンで、実践的なスキルを習得できます。
無料トライアル: Spanner を 90 日間無料で試すことができます。あるいは、月額 65 ドルから、中断なくスケールできるプロダクションレディなインスタンスを開始できます。
移行ガイド: 詳細な技術ドキュメントと包括的な移行リソースにアクセスできます。

- プロダクトマネージャー、Nitin Sagar

Gartner® の Critical Capabilities レポートの軽量トランザクションユースケースで Google（Spanner）が第 1 位を獲得

Fri, 27 Feb 2026 03:40:00 +0000

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

Google（Spanner）は、Gartner レポート「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（運用ケース向けクラウドデータベース管理システムの重要機能）において 2 年連続で高く評価され、軽量トランザクションユースケースで第 1 位を獲得しました。これは、このプロダクトの効率性、低レイテンシ、高パフォーマンスに一貫性があることを示していると Google は考えています。また、同プロダクトは OLTP トランザクションユースケースの最新のランキングでも 第 2 位を獲得しました。これは、「無限」の水平スケーリングが、従来のトランザクションパフォーマンスを犠牲にせずに実現されていることを示していると私たちは考えています。この 2 年連続の受賞は、世界で最も要求の厳しいデータ環境に対する継続的な卓越性とイノベーションを実現するという Google の理念を裏付けています。

こちらから Gartner レポートの全文をご確認いただけます。

運用パフォーマンスについて

Critical Capabilities の評価を見ると、Spanner のパフォーマンスこそが、さまざまなカテゴリで継続的に評価されている理由だと Google は考えています。

軽量トランザクションユースケースで第 1 位（2 年連続）: マイクロサービスとイベントドリブンアーキテクチャが一般的になるにつれ、高頻度で低レイテンシのトランザクションを処理する能力が非常に重要になります。Spanner が 1 位にランクインしたことは、Spanner が最新のワークロードにとって最も効率的なエンジンであることを示していると言えるでしょう。
分散トランザクションのサポート（スコア: 5.0 点中 5.0 点）: Spanner は、複数のノード、リージョン、地域をまたがる分散トランザクションをサポートする機能で 5.0 点を獲得した唯一のサービスです。
AI / ML と生成 AI（スコア: 5.0 点中 4.6 点）: このスコアは、AI を Spanner に直接統合するために Google が 2025 年に実施した、大規模な数々のイノベーションの結果であると考えています。
トランザクションの整合性（スコア: 5.0 点中 4.9 点）: Spanner は地球規模で外部整合性を提供するため、いつどこで発生したトランザクションでも、常にグローバルレベルで正確であることを保証します。
OLTP ユースケースで第 2 位: Spanner は、従来型の大量のトランザクションワークロードにますます使用されるようになっています。これは、Spanner の「無限」の水平スケーリングが、レガシーからの移行時の最適な選択肢になっていることが理由だと Google は考えています。

これらの評価は、Spanner がグローバル規模の特殊なソリューションから、ほぼすべてのミッションクリティカルなアプリケーションに対応できる、技術面で特に優れたデータベースへと進化したことを示していると考えられます。

エージェントを活用している企業の基盤

2025 年、数多くの新機能が追加された Spanner は、AI エージェントの「頭脳」となりました。

Spanner Graph（一般提供を開始しました）: グラフとリレーショナルデータを統合したエクスペリエンスを提供します。Spanner Graph では、ISO 規格の GQL と SQL を使用して複雑な関係性をトラバースできます。これは、AI エージェントを実世界の事実に基づいてグラウンディングするためのナレッジグラフを構築するうえで非常に重要です。
統合ハイブリッド検索: 2025 年に一般提供が開始された Spanner は、SQL モダリティとグラフモダリティ内で大規模な全文検索とベクトル検索を直接サポートしています。これにより、統合された低レイテンシの検索拡張生成（RAG）を大規模に実現できます。
Spanner カラム型エンジン: このアーキテクチャ上の画期的な進歩により、Iceberg テーブルから取得したライブ運用データに対する分析クエリが最大 200 倍高速化されます。これにより、エージェントは必要なリアルタイムのコンテキストを「ETL（抽出、変換、読み込み）の負担」を負わずに得ることができます。
相互運用性の拡大: 新しい Cassandra 互換 API により、コードを変更せずにスケールアウトワークロードを Spanner に取り込むことがこれまで以上に簡単になり、従来のデータを AI 革命に活用できるようになりました。

未来に向けた青写真

Gartner によるこの評価は、データ管理は今後、オープンかつ統合され、AI が組み込まれたものに移行していくだろうという Google の信念を裏付けていると私たちは考えています。お客様は、日常的に Spanner の最新のイノベーションを活用しています。

Palo Alto Networks: 世界的なサイバーセキュリティリーダーである Palo Alto Networks は、マルチテナントアーキテクチャの中核として Spanner を利用しています。99.999% の可用性を備えた Spanner と Spanner Graph を活用することで、同社は重要なアクセス制御のユースケースを地球規模で実現しました。この統合アプローチにより、専用のグラフデータベースサイロがなくても、重要な顧客ワークフローを管理する一貫性のあるアーキテクチャを構築し、AI を大規模に保護できます。
Mercado Libre: ラテンアメリカの e コマースおよびフィンテックを扱うこの大手企業は、社内システムの基盤となる整合性とスケーラビリティの確保に Spanner を活用しています。Spanner を社内の「Fury」プラットフォームと統合することで、ほぼ完ぺきな稼働状況で毎日数百万件の金融取引を管理しています。Spanner Data Boost を活用して、トランザクションのパフォーマンスに影響を与えることなくリアルタイム分析を実現しています。また、AI を活用した次世代金融エージェントの信頼できるメモリストアとして Spanner を使用するようになりました。
Unico: この大手 ID テクノロジー企業は、2021 年以降、12 億件以上のデジタル ID 認証を実施可能にすることで、数十億ドル規模の不正行為を防止しています。Spanner の統合ベクトル検索により、Unico は数十億のベクトルを対象に複雑な 1:N（1 対多）の顔生体認証検索を高精度かつ低レイテンシで実行しています。これにより、別のベクトルデータベースが不要になるため、同社の「ID ネットワーク」は高速かつ高精度で、メンテナンス不要の状態を維持できます。

Spanner が評価された理由とは

今後はデータ管理は統合され、AI 向けに構築されていきます。軽量トランザクションで 1 位を獲得した Spanner は、ミッションクリティカルなアプリケーションに最適な選択肢であると Google は確信しています。

2025 年 Gartner® Magic Quadrant のクラウドデータベース管理システム（DBMS）のレポート全文をご覧ください。
2025 年度の「Gartner Critical Capabilities for Operational Cloud DBMS」レポートをご覧ください。
Spanner を無料で試して、AI 対応アプリケーションの構築を今すぐ始めましょう。

^{Gartner、「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（作成者: Ramke Ramakrishnan、Masud Miraz、Xingyu Gu、Henry Cook、Aaron Rosenbaum、2025 年 11 月 19 日）}

^{Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、本リサーチの商品性や特定の目的への適合性を含め、いかなる保証も行いません。}

^{上の図は、リサーチドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Google Cloud までご請求ください。}

- グループプロダクトマネージャー、Jagan R. Athreya

- プロダクト管理担当ディレクター、Jagdeep Singh

Google Cloud データベースで次世代のエージェントを強化する

Thu, 26 Feb 2026 03:00:00 +0000

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

カスタムエージェントや chatbot などの AI アプリケーションを構築する開発者は、オープンソースの Model Context Protocol（MCP）標準により、作成したイノベーションがデータやツールに一貫性のある方法で安全にアクセスできるようにすることができます。Google は 2025 年末、Google マップや BigQuery などのサービス向けにマネージドおよびリモート MCP のサポートを導入することで、AI がツールに接続するための標準的な方法を確立し、アプリケーションのユニバーサルインターフェースを効果的に作成しました。このたび、このサービスを拡張し、PostgreSQL（AlloyDB、Spanner、Cloud SQL）と、高パフォーマンスの NoSQL ワークロード向けの Firestore および Bigtable を追加しました。また、IDE を Google のドキュメントに接続する API を備えた新しい Developer Knowledge MCP サーバーも導入します。これらのサーバーは Google Cloud で実行され、Gemini やその他の MCP 準拠のクライアントがデータやインフラストラクチャと簡単にやり取りできる安全なインターフェースを提供します。

Gemini 3 のリリースにより、開発者は高度な推論機能を利用して、複雑な問題を計画、構築、解決できるようになりました。しかし、AI モデルが有用な「エージェント」として機能するには、信頼できる方法で環境とやり取りする必要があります。今回の発表は、これらの機能を、お客様が作業環境のバックボーンとして日常的に利用しているデータベースツールにまで幅広く拡張するものです。

エージェントをこれらのサーバーに接続するために、インフラストラクチャをデプロイする必要はありません。エージェント構成で MCP サーバーエンドポイントを構成するだけで、エンタープライズグレードの監査、オブザーバビリティ、ガバナンスに裏付けられた運用データに即座にアクセスできます。インフラストラクチャの管理が不要なため、運用上のオーバーヘッドを発生させることなく、エージェントのワークロードをスケーリングできます。

エージェントに運用データを提供

これらの新しいマネージドサーバーにより、エージェントは Google のポートフォリオ全体で特定の機能にアクセスできるようになります。

AlloyDB for PostgreSQL: エージェントは PostgreSQL ワークロードとやり取りして、スキーマの作成、複雑なクエリの遅延の診断、ベクトル類似性検索の実行などのタスクを可能にします。
Spanner: Spanner の統合マルチモデル機能（Spanner Graph など）を使用すると、エージェントは標準（SQL および GQL）クエリを使用し、リレーショナルデータやセマンティックデータと並行して複雑な関係をモデル化およびクエリできます。これにより、エージェントは MCP ツールを自由に使用して、詐欺組織の特定や商品のレコメンデーション生成など、深い分析情報を迅速に発見できます。
Cloud SQL for PostgreSQL、MySQL、SQL Server: 開発者とデータベース管理者は、MySQL、PostgreSQL、SQL Server のフリート全体で Cloud SQL MCP Server を使用し、データベースとの自然言語でのやり取り、AI によるアプリ開発の支援、クエリパフォーマンスの最適化、エージェントによるデータベースのトラブルシューティングを行うことができます。
Bigtable: Bigtable の柔軟なスキーマと高スループットの取り込み機能は、デジタル統合ハブの構築や時系列データの管理によく使用されます。MCP を使用すると、運用ワークフローの自動化が簡素化され、カスタマーサポート、CRM、人事、IT 運用、サプライチェーン、ロジスティクス分野でこのデータを使用したエージェントアプリケーションを開発しやすくなります。
Firestore: モバイルとウェブの開発に重点を置いた Firestore MCP サーバーにより、エージェントはライブドキュメントコレクションと同期できます。その結果、自然言語プロンプトを介してユーザーセッションの状態を確認したり、注文状況を確認したりするなどの動的なインタラクションがサポートされます。

アプリケーションとインフラストラクチャの管理

Google は、エージェントがデータの取得だけでなく、アプリケーションの構築と管理を支援できるようにしています。Developer Knowledge MCP サーバーは、IDE を Google のドキュメントに接続し、エージェントが関連性の高いコンテキストを使用して技術的な質問に答えたり、コードのトラブルシューティングを行ったりできるようにします。

セキュリティとガバナンス

エージェントをデータベースに接続するには、堅牢なセキュリティとガバナンスが必要です。これらのサーバーは、Google Cloud の標準的な ID およびオブザーバビリティフレームワークに基づいて構築されています。

ID ファーストのセキュリティ: 認証はすべて、共有キーではなく、Identity and Access Management（IAM）を通じて処理されます。これにより、エージェントはユーザーが明示的に承認した特定のテーブルまたはビューにのみアクセスできるようになります。
完全なオブザーバビリティ: エージェントのアクティビティを追跡できるように、これらの MCP サーバーを介して行われたすべてのクエリとアクションは Cloud Audit Logs に記録されます。これにより、セキュリティチームはすべてのデータベース操作の記録を取得し、可視性を維持しながら簡単にアクセスできます。

デモ: ローカルコードからマネージドデータへ

新しい MCP サーバーの動作例を見てみましょう。

フィットネスコミュニティ向けのフルスタックイベント管理プラットフォームの移行を自動化するエージェントを想像してみてください。Gemini CLI で一連の自然言語の指示を使用することにより、エージェントは Cloud SQL リモート MCP サーバーを利用して、マネージド PostgreSQL インスタンスをプロビジョニングし、正しいスキーマを適用して、ローカルデータを安全に移行します。複雑な gcloud コマンドを習得したり、Cloud SQL のエキスパートになったりする必要はありません。面倒な作業はエージェントが行います。この移行は、Developer Knowledge MCP サーバーが公式ドキュメントを参照してエージェントをベストプラクティスに導くことによって、リアルタイムで設計されます。その結果、アプリケーションのバックボーンがローカルストレージからフルマネージドのエンタープライズデータベースに簡単にアップグレードされます。

サードパーティエージェントのサポート

これらのサーバーはオープンな MCP 標準に準拠しているため、お気に入りの AI エージェントとも連携できます。設定でカスタムコネクタを追加することで、Anthropic の Claude などのクライアントを簡単に接続できます。Google Cloud データベースの MCP エンドポイントを指定するだけで、すぐに構築を開始できます。複雑な構成ファイルはいりません。

次のステップ

今後数か月以内に、Looker、Database Migration Service（DMS）、BigQuery Migration Service、Memorystore、データベースセンター、Pub/Sub、Kafka などのマネージド MCP サポートが追加され、このエコシステムはさらに拡大する予定です。

安全なデータドリブンエージェントの構築を開始するには、AlloyDB、Spanner、Cloud SQL、Bigtable、Firestore のガイドをご覧ください。Cloud SQL と Spanner の Codelab や、Google Cloud へのアプリの移行手順について説明するこちらのデモ動画もご覧ください。

- AI およびデータベース担当バイスプレジデント、Amit Ganesh

- データベース向け AI 担当シニアプロダクトマネージャー、Rahul Deshmukh

2025 年の Spanner: インテリジェントなマルチモデル AI アプリケーションを強化するイノベーション

Wed, 04 Feb 2026 02:00:00 +0000

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

Google は 10 年以上にわたり、常時稼働でほぼ無制限のスケーリングが可能なデータベースである Spanner を基盤として、Gmail、YouTube、Google フォトなどの世界規模のアプリケーションを支えてきました。現在、Spanner が処理する秒間クエリ数は 60 億以上（ピーク時）、データ量は 17 エクサバイトを超え、99.999% の可用性とグローバルな整合性を実現しています。

2025 年は、Google Cloud 上の Spannerにとって、大きな年でした。Walmart、Goldman Sachs、Palo Alto Networks、Mercado Libre などのお客様の要求の厳しいワークロードを Spanner が支えているからです。同時に、AI が中心となる時代において、データベースの役割は大きな変革を遂げつつあります。データベースは、受動的なデータリポジトリとしての従来の機能を超えて進化し、インテリジェントなコンテキストハブになりつつあります。Spanner は現在、商品検索とレコメンデーション、不正行為の検出、ID の解決、自律型ネットワーク運用（ANO）などの主要なユースケースをサポートしています。

2026 年に向けて期待が高まるなか、昨年のハイライトをいくつか振り返ってみましょう。Google は 2025 年に、以下を達成しました。

AI ワークロードの主要な基盤としての Spanner の位置付け
運用データと分析データのギャップ解消
移行の簡素化
費用対効果の基準引き上げ
エンタープライズレベルの安全性とデータ保護の強化

おさらいしていきましょう。

マルチモデルをサポートする Spanner AI

真にインテリジェントな生成 AI アプリケーションを構築するために、複数のポイントソリューションを組み合わせる必要はありません。こうした理由から Google は、2024 年に AI モデルへのコンテキスト提供を目指してベクトル、グラフ、リレーショナルデータを統合しました。2025 年には、これらのマルチモデル機能を拡張し、グラフ、ベクトル、テキスト検索、そして Vertex AI との連携を含め、新しい機能を追加しました。

AI 機能: Spanner を AI ファーストのデータベースにするために、複数の機能を導入しました。これには、自然言語クエリ用の ML.PREDICT、データベース向け MCP ツールボックス、Gemini CLI 用 Spanner 拡張機能、会話型データエージェント、Spanner 用 Agent Development Kit などの組み込みの AI インテグレーションが含まれ、これらを併用することで、デベロッパーは Spanner を使用して高度なエージェントアプリケーションを構築できます。また、マルチモデルプラットフォームを拡張して、GraphRAG ユースケースでグラフにベクトル検索を活用するといった、高度な AI ユースケースに対応できるようにもなりました。最後に、Vertex RAG Engine では、データのインデックス作成と取得オペレーションに、RAG が管理するデータベースとして Spanner を使用できるようになりました。
グラフの機能強化: Spanner Graph にスキーマレスデータのサポートが追加されました。これにより、スキーマを変更しないでも、反復型開発と頻繁な更新が可能になりました。また、名前付きスキーマ オブジェクトと SQL ビューでグラフを構築し、アプリの重要な要素を整理してカプセル化できるようにもなりました。
全文検索: enhance_query オプションにより、多数の関数に対する類義語の自動マッチとスペル修正が可能になるため、再現率を高めるために必要な手動チューニングの手間を省くことができます。
近似最近傍（ANN）: Google の ScaNN を使用した ANN は高速でスケーラブルなベクトル検索手法です。この検索手法は、高次元ベクトル検索の効率を重視して最適化されており、AI レコメンデーションシステム、画像検索、セマンティック検索で不可欠です。2025 年には、ANN 検索の一般提供を発表しました。これにより、デベロッパーはベクトルエンベディングに対する高速な類似検索を実行できるようになり、大規模な整合性が重要となる生成 AI アプリケーションを支えています。

AI を活用した運用

2025 年には、デベロッパーがアプリケーションに Spanner を活用しやすくなるよう、AI を活用した複数の機能が強化されました。

Spanner インデックスアドバイザー: インデックスアドバイザーは、クエリパターンを分析し、パフォーマンスと費用を最適化するために新しいインデックスをプロアクティブに提案します（または、使用されていないインデックスを特定します）。
スキーマに関する推奨事項（プレビュー版）: スキーマ設計をスキャンしてホットスポット化しやすい主キーなどのアンチパターンがないかを確認し、本番環境で問題が発生する前に改善を提案するインテリジェントなツールです。
Spanner CLI: gcloud に直接バンドルされた新しいコマンドラインインターフェース（CLI）で、この CLI により、既存のデベロッパーワークフロー内で SQL の実行、セッションの管理、スクリプトの自動化が可能になります。

統合分析: サイロと複雑さを最小限に抑える

昨年、Google は複数の新機能によって運用データと分析データのギャップを埋めました。

Spanner カラム型エンジン（プレビュー版）: このエンジンを使用すると、Spanner のグローバルな整合性、高可用性、強力なトランザクション保証を維持しながら、大量の運用データをリアルタイムで自動的に分析できます。トランザクションワークロードに影響を与えることはありません。Verisoul.ai は、偽アカウントの検出を自動化するオールインワンプラットフォームのプロバイダです。同社は Spanner と Spanner カラム型エンジンを活用して、低レイテンシのトランザクション書き込みと豊富な分析をサポートし、ユーザーに迅速なレスポンスを提供しています。
「BigQuery でさらに向上」エコシステム: Spanner と BigQuery のインテグレーションを強化し、運用エンジンと分析エンジンを統合することでリアルタイムの分析情報を提供しています。

Apache Iceberg のサポート: この機能により、データアナリストは、BigQuery 上の Apache Iceberg テーブルと Spanner のライブデータの結合、および Iceberg データの Spanner へのエクスポートができます。これによって、リアルタイムの運用データ（Spanner から取得）をクエリして、その結果をキュレートされたデータレイクハウス（Iceberg 内）と組み合わせることができます。
Spanner 外部データセットのマテリアライズドビュー: BigQuery の Spanner 外部データセットの一般提供を発表しました。これにより、BigQuery ユーザーは ETL を必要とせずに Spanner のライブ運用データをクエリできるようになりました。さらに、この機能を拡張して BigQuery マテリアライズドビューと統合し、事前に計算されたクエリ結果に基づく超高速のレポート作成を実現しました。
リバース ETL を使用した継続的クエリ（BigQuery から Spanner）: BigQuery の継続的クエリ機能を Spanner へのリバース ETL と組み合わせることで、不正行為アラートや動的料金設定シグナルなどの計算された分析情報を BigQuery から Spanner にリアルタイムでストリーミングし、これらの分析情報を低レイテンシで提供できるようになりました。Fastweb + Vodafone は、まさにそれを実現しました。具体的には、両社はこの機能を活用し、Spanner を BigQuery と連携させたリアルタイムのサービングレイヤとして使用しました。

シンプルな移行

お客様は、99.999% の可用性、事実上無制限のスケーリング、低い運用上のオーバーヘッド、グローバルな整合性といったメリットを得るために、Spanner に移行することがよくあります。Google は 2025 年に、Cassandra と MySQL のワークロードを Spanner に簡単に移行できるようにしました。

Cassandra インターフェース: Spanner の Cassandra インターフェースを使用すると、使い慣れた Cassandra ツールと構文を使用して、Spanner のフルマネージドで、スケーラブルかつ高可用性のインフラストラクチャを活用できます。既存の CQL アプリケーションを、ほぼ変更なしでリフト＆シフトできます。
MySQL の相互運用性: 80 個の MySQL 関数のライブラリをインストールできるようになりました。これにより、MySQL ワークロードを Spanner に移行するために必要なアプリケーションの変更を減らすことができます。

パフォーマンスと費用の改善

Spanner チームにとって、費用対効果の基準を継続的に引き上げることは、常に目指すべき目標です。2025 年に Google は、クエリのパフォーマンス向上と費用削減に役立つ複数の機能を導入しました。

Repeatable Read 分離（プレビュー版）: この新しい分離レベルでは、ロック管理のオーバーヘッドが削減されるため、読み取り / 書き込みの競合が少ないワークロードのレイテンシが改善されます。
JSON インデックス作成機能: Spanner の全文検索と同じ基盤を使用する JSON インデックス作成機能は、構造やデータに関する事前定義がなくても、JSON に対する一般的なクエリを高速化します。これにより、デベロッパーはパフォーマンスを損なうことなく柔軟に作業できます。
読み取りリース: 読み取りリースは、読み取り操作が大半を占める一般的なワークロードに対する書き込みパフォーマンスを多少犠牲にする代わりに、マルチリージョン構成の強整合性データの読み取りレイテンシを改善できます。
階層型ストレージ: 階層型ストレージを活用すると、同じインスタンス内で SSD ストレージと HDD ストレージを使用できるため、データライフサイクルの費用を効率的に管理できます。すべての管理は構成を通じて行われ、データにアクセスするために使用する API を変更する必要はありません。この機能は、古いデータを低コストの HDD ストレージ（最大約 80% 安価）に移動し、新しいデータは高パフォーマンスの SSD に自動的に保持します。
マネージドオートスケーラー: マネージドオートスケーラーの一般提供を発表し、読み取り専用レプリカを読み取り / 書き込みレプリカとは別にスケールできるように機能を強化しました。これにより、トラフィックパターンに基づいて費用を最適化しながら、読み取りパフォーマンスが向上しました。
手動分割点: Spanner はシャーディングを自動化して、インスタンス内のノード間で作業を分散しますが、トラフィックパターンは Google よりもお客様の方がよくご存じの場合があります。新しい分割点 API を使用すると、期間限定セールやゲームのリリースなど、予想されるトラフィック急増に合わせてデータを「ウォームアップ」または事前分割しておけるため、トラフィックに即座に対処できます。
クエリオプティマイザー: 新しいデフォルトのクエリオプティマイザー（バージョン 8）には、自動化された拡張機能が多数導入されたほか、結合戦略とインデックスの使用が最適化され、クエリのパフォーマンスと予測可能性が向上しました。
多重化されたセッション と遅延デコード: 主要な SDK（Java、Go）で多重化されたセッションをデフォルトで有効にし、スループットとリソース使用率を大幅に向上させました。また、パーティション分割されたクエリに対して遅延デコードでクライアントライブラリを最適化し、アプリケーションが大幅に少ないメモリ使用量で大規模なデータセットを処理できるようにしました。さらに、新しい組み込みのクライアント指標により、アプリケーションのデータベースパフォーマンスをきめ細かく把握できます。

エンタープライズレベルの安全性の水準を引き上げる

特に金融サービス、小売、ヘルスケアなどの業界のお客様にとって、信頼性は絶対条件です。今年、Google は、あらゆるシステムで最も予測不可能な要素である人為的ミスからのデータ保護を強化する、追加の「セーフティネット」を導入しました。

削除からの保護機能: 誤ってデータを削除すると、致命的な事態が生じる場合があります。Google は、本番環境の安全対策としてスキーマオブジェクトの削除からの保護機能を導入しました。これは、重要なテーブル、インデックス、列が誤って削除されるという運用上のミスを防ぐ役割を果たします。
デフォルトのバックアップスケジュールによるゼロタッチコンプライアンス: データ保護は手動のチェックリストに委ねるべきではありません。データベースが作成された瞬間に復元のベースラインが確保されるよう、デフォルトのバックアップスケジュールを導入しました。これにより、バックアップを忘れるリスクを最小限に抑え、ワークロードを初日から組織のガバナンスとコンプライアンスの基準に準拠させることができます。

受賞歴と評価

Google は、お客様のニーズと業界のトレンドに基づいて Spanner を強化し続けていますが、その取り組みが業界で認められることは常に素晴らしいことです。実際、2025 年に以下のような評価を受けました。

Spanner は、Gartner Magic Quadrant のクラウドデータベース管理システム（DBMS）部門のリーダーに選ばれたほか、2025 年の 「Critical Capabilities for Operational Databases」レポートの軽量トランザクションユースケースで第 1 位（すべてのカテゴリで上位 3 位）にランク付けされ、「OLTP トランザクション」で AWS Aurora を抑えて第 2 位を獲得しました。
技術的なパフォーマンスのほかに、2025 年 3 月の Forrester Total Economic Impact™（TEI）調査では、Spanner がもたらす大きなビジネス価値が検証されました。その調査によると、代表的なモデル組織は 3 年間で 132% の ROI と 774 万ドルの総利益を達成し、投資回収期間はわずか 9 か月でした。
また、Google は「リレーショナルデータマネジメントを再考し、グローバル規模で外部整合性のある直列化可能性を実現した」ことが評価され、2025 ACM SIGMOD Systems Award を受賞しました。

今後の対応

Google は、2025 年にお客様に提供してきたイノベーションを誇りに思っており、お客様が Spanner で構築する革新的なソリューションを楽しみにしています。このイノベーションはまだ始まったばかりであり、2026 年にはさらに多くの魅力的な機能の提供が予定されていることは言うまでもありません。

Spanner の独自性や使用例について詳しくは、こちらをご覧ください。

また、90 日間無料で、あるいは月額わずか 65 米ドルから、中断を伴う再構築やダウンタイムなしでビジネスの成長に合わせて拡張できる、プロダクションレディなインスタンスをお試しください。

- グループプロダクトマネージャー、Shubhankar Chatterjee

- グループプロダクトマネージャー、Piyush Mathur

DeNA: Spanner、C4A インスタンスを駆使して世界規模のゲームアプリ『Pokémon TCG Pocket』の安定運用を実現

Mon, 22 Dec 2025 02:30:00 +0000

2024 年 10 月 30 日より、150 の国と地域でサービスを開始した、スマートフォン向けポケモンカードゲーム『Pokémon Trading Card Game Pocket（以下、ポケポケ）』。株式会社ポケモン、株式会社クリーチャーズ、そして株式会社ディー・エヌ・エー（以下、DeNA ）の合同プロジェクトである本アプリに、Google Cloud がどのように貢献しているのか。本プロジェクトでサーバー・アプリ開発を担当した DeNA のお二人に伺います。

利用しているサービス:
Spanner、Google Kubernetes Engine（GKE）、BigQuery など

利用しているソリューション:
データベース

Spanner の存在が Google Cloud を選んだ最大の理由

『ポケポケ』は世界中で楽しまれているポケモンカードを、手軽にコレクションできるアプリです。2025 年 10 月には全世界累計 1.5 億ダウンロードを突破し、世界規模で圧倒的な支持を集めています。

本タイトルは、パブリッシュと全体プロデュースを担う株式会社ポケモン、カードゲーム開発を担う株式会社クリーチャーズ、そしてサーバー・アプリ開発と運用を担う DeNA の 3 社合同プロジェクトとしてスタート。世界中から膨大なアクセスを受け付けるアプリの安定運用は、これまでさまざまなビッグタイトルを手がけてきた DeNA の手腕に委ねられていました。

同社 IT 本部 IT 基盤部副部長として『ポケポケ』のインフラ周りを統括した天野知樹氏は、DeNA がかねてより、サービス基盤のほとんどをパブリッククラウド化していることもあり、『ポケポケ』に関しても当初からクラウドで運用されることが決まっていたと話します。

「『ポケポケ』のような世界規模のサービスを展開するには、パブリッククラウドの迅速なリソース調達力が不可欠です。特に、負荷試験やサービス開始直後にドカンとリソースを使い、その後、徐々に落ちついていくゲーム特有の性質はパブリッククラウドに好適。現在では『ポケモンマスターズEX 』など、弊社タイトルの 99.99% が各種パブリッククラウド上で運用されるまでになっています。そこで、今回のプロジェクトにおけるインフラ基盤として、Google Cloud の利用をさらに拡大することにしました。」

天野氏は、 Google Cloud を選んだ最大の理由が Spanner だったと断言。サーバーの開発初期から本プロジェクトに携わり、現在はサーバーチームのリードエンジニアとして活躍する柴田佳祐氏は、Spanner の価値を次のように説明してくれました。

「『ポケポケ』のような多くのお客様がアクセスする大規模ゲームアプリでは、データベースのシャーディングやデータ整合性の維持などといった技術的課題をどう解決するかが大きな問題になります。従来のデータベース技術では、シャーディングの制御やシャードまたぎのトランザクションの考慮、シャード数の増減などが大変なのですが、Spanner はそれらの難度の高い処理を全て自動化してくれます。さらに、レプリケーション遅延を考慮する必要がなく、トランザクションが強い整合性を持つため、アプリ開発が容易になります。これはゲーム開発において大変魅力的な性質でした。サーバーの開発開始当初、他のパブリッククラウドには類似の機能を持つサービスはありませんでしたし、また、現在においても、トータルでは最も我々の用途に合致した選択肢だと考えています。」

「事前分割（Pre-splitting）」の活用で、ローンチ直後の大規模アクセスにも対応

もちろん、『ポケポケ』ほどの大規模アクセスをさばくのは Spanner であっても容易なことではありません。実際、毎秒 1,000 万クエリを Spanner に発行するなど、膨大なトラフィックを想定して行われた事前の負荷試験ではパフォーマンスの立ち上がりに課題が見つかったと、柴田氏は当時を振り返ります。

「Spanner には内部的にスプリットと呼ばれるシャードのようなものが存在します。これは基本的には自動で増減しますが、急激な負荷のスパイクが発生するとスプリットの増加が間に合わず、ローンチ直後や新しい拡張パックの追加直後にレイテンシの悪化が起こる懸念がありました。ダミーの負荷をかけて分割を促すこともできるのですが、お客様が遊んでいる状態で大きなダミーの負荷をかけるのはリスクを伴います。」

柴田氏がこの問題を Google Cloud に相談したところ、当時はまだプライベートプレビュー段階であった事前分割（Pre-splitting）機能を前倒しで提供（2025 年 4 月 28 日より一般提供開始）。あらかじめスプリットを割っておけるようになったことで、必要な時に必要なパフォーマンスを発揮できるようになったと言います。

「実際、2024 年 10 月のローンチ時も、ほぼ垂直にトラフィックのグラフが上がっていく中、見事に耐えきってくれて感動しました。チームの仲間たちと『恐ろしいほど問題が起きないね』と話していたくらいです（笑）。」（柴田氏）

事前分割機能はその後も、新しい拡張パックの公開時など、トラフィック増大が予想されるケースで活躍しています。

「Spanner があったからこそ、安定した運用ができているのは間違いありません。別のデータベースを使っていたら、もっと大変だったろうと想像しています。」（天野氏）

C4A インスタンスはコスパも安定性も優れた理想的な選択肢

『ポケポケ』のサービス安定性を支えているのは Spanner だけではありません。『ポケポケ』ではそのサービスを維持するため、膨大な数のサーバーを動かしており、サービス開始当初は、すでに多くの過去タイトルで採用実績のある Tau T2D インスタンスを採用していました。しかし、いくつかの理由から、当時登場したばかりの C4A インスタンスへ移行することを決断します。

「最大の理由はコストです。ポケポケでは API サーバーとバトルサーバーで合計約 2 万コアものサーバーを動かしており、その料金を削減したいという気持ちがありました。サービス開始前の試算では Tau T2D インスタンスが最も費用対効果に優れた選択肢だったのですが、C4A インスタンスがなんとポケポケのサービス開始と同日に発表され（笑）、すぐに移行を検討し始めました。また、パフォーマンスの安定性という観点からも『さまざまなワークロードに対して一貫して高いパフォーマンスを実現』と謳う C シリーズの方がポケポケのようなゲームタイトルと相性が良いと考えました。」（天野氏）

x86-64 アーキテクチャの Tau T2D インスタンスから、arm64 アーキテクチャの C4A インスタンスへの移行は、マルチアーキテクチャイメージを作成することで実現しています。

「クロスコンパイルが容易な Go 言語を使っていたこともあり、マルチアーキテクチャイメージのビルドは想定していたよりも苦労なく移行できました。」（柴田氏）

なお、インスタンスの移行は、サービスを中断せずにノーメンテナンスで実施。移行後は大きなチューニングも必要なく、すぐに大きな性能向上があったとのことです。

「特に API サーバーのコストパフォーマンス向上が著しく、Tau T2D インスタンスの時と比べて約 73% もの改善を達成しています。リアルタイム性の高いバトルサーバーは安定性を重視したため API サーバーほどの成果は得られませんでしたが、それでも約 11% の改善ができました。以前はコストパフォーマンス重視なら Tau T2D インスタンス、安定性重視なら C シリーズでしたが、C4A インスタンスは、とりわけ我々の用途においてはコスパも安定性も優れた理想的なインスタンスだと感じました。」（天野氏）

今回の成果は株式会社ポケモン、株式会社クリーチャーズからも高く評価されているとのこと。最後に、天野氏は、Spanner および C4A インスタンスの活用について、今後の展望を語ってくれました。

「『ポケポケ』での成果を踏まえ他のゲームタイトルでも Google Cloud を積極的に活用していくことになっていくでしょう。また、DeNA として AI に ALL IN していくことを表明しており、AI を用いた事業変革の中心にいる Google のポテンシャルにも期待しています。例えば重要性の高くない作業を AI エージェントに代替させていくことでエンジニアがより創造的な仕事に取り組んでいけるようにしたいですね。そのためにもこれからはより一層、コミュニケーションを密接にし、強力な信頼関係のもと、スピード感を高めた開発をしていければと思っています。」

株式会社ディー・エヌ・エー
「一人ひとりに　想像を超えるDelightを」のミッションのもと、ゲーム、ライブコミュニティ、スポーツ・まちづくり、ヘルスケア・メディカルなど幅広い事業を展開。事業価値の最大化と課題解決のためのAI活用と独自のデータ分析手法によって、顧客ニーズを的確に捉えた付加価値の高いサービス開発から運用までを行っている。

株式会社ポケモン
「ポケモン」を永続的なブランドに育てるべく 1998 年に設立。コンテンツや商品づくり、マーケティング、その他あらゆる活動を通じて、ポケモンの個性を引き出し、魅力を引き出すことを目的とする。グループは自社を含め世界に 13 社、オフィスは 14 拠点にあり、それぞれのマーケットで、ポケモンプロデューサーとして取り組んでいる。

株式会社クリーチャーズ
1995 年設立。任天堂株式会社、株式会社ゲームフリークと並ぶポケモン原作著作者企業（株式会社ポケモンはこの 3 社の共同出資により設立）。ポケモンのトレーディングカードゲーム・ビデオゲームの開発、『ポケットモンスター』シリーズなどの CG モデル・モーションの開発事業などを展開し、ますます広がるポケモンの世界を支えている。

インタビュイー（写真右から）
株式会社ディー・エヌ・エー
・IT 本部 IT 基盤部副部長　天野知樹氏
・ゲームサービス事業本部開発運営統括部第二技術部サーバー
　第一グループエンジニア　柴田佳祐氏

その他の導入事例はこちらをご覧ください。

Mercado Libre の多面的な Spanner アーキテクチャの概要

Thu, 27 Nov 2025 01:01:00 +0000

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

ラテンアメリカの e コマースとフィンテックのパイオニアである Mercado Libre は、驚くべき規模で事業を展開しており、復元力とスケーラビリティだけでなく、迅速なイノベーションの触媒となるインフラストラクチャを必要としています。Google の Spanner は、基盤となる整合性とスケーリングを実現するサービスとして知られていますが、さらに詳しく見ていくと、洗練された多層戦略に基づいていることがわかります。Spanner は単なるデータベースではありません。社内開発者プラットフォーム、多様なデータモデル、高度な分析ループ、インテリジェントな機能、さらには次世代 AI アプリケーションのロードマップを支えるコアエンジンです。

本ブログでは、Fury プラットフォームなどの社内イノベーションとともに Spanner を活用し、大きなビジネス効果を達成して AI 主導の未来への道筋を描いている、Mercado Libre の技術的基盤について説明します。

2 つの課題: インターネット規模での運用と開発者の速度

Mercado Libre は、インターネット規模のサービスに共通する課題に直面しています。それは、毎日数百万件の金融取引を安全に保つこと、デベロッパーが簡単にアプリを構築できるようにすること、ほぼ 100% の稼働時間を維持することです。このソリューションでは、十分なパワフルさを備えたデータベースを中核に据え、幅広いデベロッパーが採用したくなるほど優れた抽象化レイヤが必要でした。

Fury: Mercado Libre の開発者ゲートウェイ

Mercado Libre の戦略の中核をなすのは、社内のミドルウェアプラットフォームである Fury です。Fury は、さまざまなバックエンド技術の複雑さを抽象化し、アプリケーションを構築するための、標準化され、簡素化されたインターフェースを開発者に提供するように設計されています。

抽象化と標準化: Fury を使用すると、開発チームは分散データベース管理の微妙な違い、特定のエンジン向けのスキーマ設計、最適な接続プーリングではなく、ビジネスロジックに集中できます。

信頼性に優れたコアとなる Spanner: Spanner は、グローバルな整合性を備えた常時稼働のマルチモデルデータベースで、実質的に無制限のスケーリングが可能です。Mercado Libre は、Fury 内で Spanner を選択することで、Spanner を使用してプラットフォーム上に構築されたアプリケーションが、Spanner の優れた機能を継承できるようにしています。つまり、グローバルに整合性が保たれ、スケーリングしても中断されず、ダウンすることもほとんどありません。

図 1 - Fury のコアサービス

Spanner – 汎用性に優れたバックボーン

Fury を通じて、Spanner は Mercado Libre の開発者に驚異的な汎用性を提供します。複雑なトランザクションが必要なアプリもあれば、高速な検索が必要なアプリもあります。Spanner は両方に対応しているため、チームは 1 つのシステムのみを使用できます。

複雑なトランザクションのためのリレーショナル機能: 注文管理、支払い、在庫システムなどの高度なトランザクションワークロードでは、Spanner のリレーショナル機能（SQL、ACID トランザクション、結合）が依然として重要です。
高パフォーマンスの Key-Value ストア: 最新のアプリケーションの多くは、高速なポイント検索とシンプルなデータ構造を必要とします。Mercado Libre では Spanner を一般的な Key-Value ワークロードに対するデフォルトのバックエンドとしては利用していませんが、大規模な非リレーショナル KV スタイルのワークロードを Spanner で実行する特定のアプリケーションがあります。

グローバルな整合性を実現する TrueTime と、簡単なスケーリングを実現する自動シャーディングは、Spanner の基盤となるアーキテクチャであるため、Spanner は Fury プラットフォームを通じてこれらのアクセスパターンを確実に処理する理想的な候補です。

ピーク時の需要への対応

Mercado Libre の Spanner インスタンスは、約 214,000 秒間クエリ数（QPS）と、1 秒あたり 30,000 トランザクション（TPS）を処理する優れた処理能力を発揮しています。この膨大なワークロードを管理するために、Spanner インフラストラクチャは 400 ノード以上に動的にスケール（30% 増）し、基盤システムには需要の高いシナリオに対応する堅牢性と弾力性があります。このレベルのスループットとスケーラビリティは、最も多忙な時期に Mercado Libre のサービスのパフォーマンスと信頼性を維持するために不可欠です。

図 2 - Spanner で構築されたソリューションの図。現在の検索データを使用して、顧客が購入する可能性が最も高い商品を予測して推奨する。

データをアクションに変える

Mercado Libre は、高度な分析を活用して分析情報を運用システムに直接取り込む、Cloud Spanner を中心とした動的なデータエコシステムを構築しています。

また、Spanner Data Boost と BigQuery フェデレーションを組み合わせることで、リアルタイム分析を実現しています。Data Boost は分析クエリを分離し、重要なトランザクションのパフォーマンスに影響を与えないようにします。これにより、BigQuery 内の最新の Spanner データに対して、強力な大規模分析を直接実行できるうえ、他のデータソースとシームレスに統合できます。

BigQuery からの分析情報（顧客セグメントや不正スコアなど）は、リバース ETL を介してアクションが実行され、Spanner に直接取り込まれます。これにより、運用データが充実し、パーソナライズされたコンテンツの提供やリアルタイムのリスク評価の実施など、現場で使用されるアプリケーションによる即時のアクションが可能になります。

さらに、Spanner 変更ストリームと Dataflow を組み合わせることで、重要なサービス統合を推進します。Spanner からリアルタイムでデータの変更をキャプチャすることで、Mercado Libre は堅牢なパイプラインを確立しています。これにより、変更を BigQuery に読み込んで分析したり、Fury Stream などのサービスにストリーミングしてリアルタイムで利用したりできるようになり、低レイテンシのデータ伝播が保証され、システム全体でイベントドリブンアーキテクチャが実現します。

効果: コスト削減、アジリティ、将来への備え

Spanner の戦略的な導入と、Fury などの社内プラットフォームや高度なデータワークフローの活用により、Mercado Libre は次のような大きなメリットを得ています。

大幅な費用削減と低い総所有コスト: Spanner のマネージドな性質（手動シャーディングやメンテナンス作業の削減）、効率的なリソース使用率、Fury が提供する抽象化の組み合わせにより、総所有コストが削減され、大幅な費用削減が実現しました。
ビジネスへの影響とアジリティ: Fury によってインフラストラクチャの複雑さから解放され、Spanner の汎用性に優れた機能を手にした開発者は、新しい機能やアプリケーションをより迅速に提供できます。Spanner の高い信頼性が重要なビジネスオペレーションを支え、中断を最小限に抑えます。
運用上のオーバーヘッドが低い: Spanner では、スケーリング、シャーディング、メンテナンスが自動化されているため、大規模なデータベースインフラストラクチャを管理するために必要な人的労力が大幅に削減されます。

AI 向けに構築: Spanner 上の次世代アプリケーション

今後、Mercado Libre は、より多くの AI ワークロードをサポートするために Spanner の活用を検討しています。

Spanner の特性は、基盤として最適です。

一貫した状態管理: 状態コンテキストを維持し、確実に更新する必要がある AI システムに不可欠です。
スケーラブルなメモリ / ナレッジストア: AI システムのメモリ、ログ、コンテキスト情報に関する、膨大な量のデータを保存および取得する機能があります。
トランザクション処理: AI システムが他のシステムとやり取りするアクションを、優れた信頼性で実行できるようにします。
分析と ML の統合: 既存のデータループと ML.PREDICT 機能により、リアルタイムの分析情報とインテリジェンスで AI システムを強化できます。

Spanner は、このような高度な AI アプリケーションに必要なトランザクションの基盤を提供します。

まとめ: 統合されたインテリジェントなデータ基盤

Mercado Libre による Spanner の採用方法は、強力でグローバルに整合性のあるデータベースを、そのコア機能だけでなく、開発者の生産性、運用の効率性、高度な分析、将来の AI に関する展望を実現するための戦略的なイネーブラーとして使用する方法を示しています。Fury プラットフォームを通じて、私たちは Spanner の機能へのアクセスを簡素化し、リレーショナルと非リレーショナルの両方のニーズに対応できる柔軟な基盤として Spanner を活用できるようにしました。Data Boost を介した BigQuery との統合は、インテリジェントでデータドリブンな企業を構築するための包括的なアプローチを示しています。Mercado Libre が AI アプリケーションを構築するにあたり、Spanner は、次なるイノベーションの波を支える一貫性のあるスケーラブルな基盤としての役割を今後も果たしていくことでしょう。

詳細

-ソフトウェアテクニカルリーダー、Mercado Libre、Pablo Leopoldo Arrojo 氏

Spanner カラム型エンジン: 運用データの次世代分析を強化

Wed, 13 Aug 2025 01:00:00 +0000

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

長年にわたり、組織はオンライントランザクション処理（OLTP）と分析クエリ処理のワークロードの違いに悩まされてきました。Spanner などの OLTP システムは、大量の低レイテンシトランザクション向けに最適化されており、個々のレコードへのアクセスに効率的な行指向のストレージを使用します。一方、分析ワークロードでは、大規模なデータセット全体にわたる迅速な集計とスキャンが必要です。これらのタスクは従来、カラム型ストレージとトランザクションシステムからの受信データパイプラインを使用する個別のデータウェアハウスによって処理されてきました。OLTP ワークフローと分析ワークフローを分離すると、定期的なデータ転送が必要になるため、データが古くなったり、ETL パイプラインが複雑になったり、運用上のオーバーヘッドが発生したりすることがよくあります。

そこでこのたび、Spanner カラム型エンジンを発表いたします。これにより、Spanner データベースで直接新しい分析機能を利用できるようになります。AlloyDB のカラム型エンジンが PostgreSQL の分析を強化したように、Spanner の新しいカラム型エンジンでは、Spanner のグローバルな整合性、高可用性、強力なトランザクション保証を維持しながら、膨大な量の運用データをリアルタイムで分析できます。トランザクションワークロードに影響を与えることもありません。

Spanner のカラム型エンジンの機能により、Verisoul.ai などの組織は、大量のトランザクションシステムと高速分析を組み合わせる際に通常発生するデータサイロの問題を解消しています。「不正行為をリアルタイムで検出することは、私たちが行っていることの半分にすぎません。お客様に『なぜ』不正行為が起こったのかを示すことで、お客様はより迅速に行動し、信頼を測定可能な ROI に変えることができます」と、偽のユーザーと不正行為を阻止する ML プラットフォームである Verisoul.ai の創業者である Raine Scott 氏と Niel Ketkar 氏は述べています。「Spanner の新しいカラム型エンジンにより、高速なトランザクション書き込みと豊富な分析を 1 か所で実行できます。データのコピーやレプリケーションの遅延がなくなるため、お客様は即座に回答を得られます。」

カラム型ストレージとベクトル化実行

図: Spanner カラム型エンジンのアーキテクチャ

Spanner カラム型エンジンの核となるのは、カラム型ストレージとベクトル化されたクエリ実行を組み合わせた革新的なアーキテクチャです。

Spanner のカラム型ストレージ: ハイブリッドアーキテクチャ

従来の行指向ストレージでは、行全体が連続して保存されますが、カラム型ストレージでは、データが列ごとに保存されます。カラム型ストレージには次のようなメリットがあります。

I/O の削減: 分析クエリは、一度にアクセスする列が少ないことがよくあります。カラム型ストレージでは、ディスクから読み取る必要があるのは関連する列のみであるため、I/O オペレーションが大幅に削減されます。
圧縮率の向上: 通常、1 つの列内のデータは同じデータ型であり、多くの場合、同様のストレージパターンを示すため、圧縮率が大幅に向上します。つまり、より多くのデータをメモリに格納でき、読み取る必要があるバイト数が少なくなります。
効率的なスキャン: 列をスキャンするときに、連続する値をまとめて処理できるため、データ処理がより効率的になります。

Spanner カラム型エンジンは、既存の行指向ストレージにカラム形式を統合します。この統合されたトランザクション処理と分析処理の設計により、Spanner は OLTP パフォーマンスを維持しながら、ライブ運用データに対する分析クエリを最大 200 倍高速化できます。

ベクトル化実行: クエリを大幅に加速

カラム型ストレージを補完するために、カラム型エンジンは Spanner のベクトル化実行機能を利用します。従来のクエリエンジンはデータをタプル単位（行単位）で処理しますが、ベクトル化エンジンはデータを複数の行のバッチ（ベクトル）で処理します。このアプローチにより、以下を実現することで CPU 使用率が大幅に向上します。

関数呼び出しのオーバーヘッドの削減: ベクトル化エンジンでは、個々の行ごとに関数を呼び出すのではなく、バッチ全体に対して関数を 1 回呼び出すだけなので、オーバーヘッドが大幅に削減されます。
最適化されたメモリアクセス: ベクトル化された処理では、キャッシュフレンドリーなメモリアクセスパターンになることが多く、パフォーマンスがさらに向上します。

カラム型ストレージとベクトル化実行を組み合わせることで、Spanner での分析クエリを桁違いに高速化し、グローバル規模のデータに関するリアルタイムの分析情報を得ることができます。

BigQuery でさらに向上: 連携クエリの高速化

Spanner のカラム型エンジンは、Google のデータクラウドエコシステムとの統合をさらに一歩進め、特に Spanner と BigQuery の統合を強化します。データウェアハウジングと分析に BigQuery を活用している企業にとって、クエリを Spanner に直接連携させることは常に価値のある機能です。Spanner のカラム型エンジンにより、オペレーションデータの分析情報をより迅速に提供できるようになることで、この統合がさらに強力になります。

Data Boost は、分析ワークロード向けのフルマネージドで弾力的にスケーラブルな Spanner のコンピューティングサービスであり、この高速化を実現する最前線にあります。BigQuery が Spanner に対して連携クエリを発行し、そのクエリがカラム型スキャンとベクトル化実行の利点を活用できる場合、Data Boost は Spanner のカラム型エンジンを自動的に利用します。これには、次のような利点があります。

分析情報の迅速な取得: Spanner データを対象とする BigQuery から開始された複雑な分析クエリが大幅に高速化され、ほぼリアルタイムの運用データがより広範な分析環境に取り込まれます。
OLTP への影響を軽減: Data Boost は、分析ワークロードがプライマリ Spanner コンピューティングリソースからオフロードされるように支援し、トランザクション処理への影響を防止します。
データアーキテクチャの簡素化: 複雑な ETL パイプラインでデータを複製する必要がなく、Spanner のトランザクション整合性と BigQuery の分析能力という両方のメリットを得られます。

この統合により、データアナリストやデータサイエンティストは、Spanner のライブ運用データを BigQuery の他のデータセットと組み合わせて、より豊富でタイムリーな分析情報の取得と意思決定を実現できます。

カラム型エンジンの活用: 分析クエリの高速化

Spanner のカラム型エンジンで大幅な高速化が期待できるクエリの例をいくつか見てみましょう。分析ワークロードやグラフワークロードで一般的なこれらのタイプのクエリは、カラム型スキャンとベクトル化された処理のメリットを享受できます。

シナリオ: 大規模な e コマースデータベースを前提とします。デモ用に、TPC-H ベンチマークと同じスキーマを使用します。

クエリ 1: 特定の年の割引が適用された出荷による収益

SQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT\r\n sum(l.l_extendedprice * l.l_discount) AS revenue\r\nFROM\r\n lineitem l\r\nWHERE\r\n l.l_shipdate >= date "1994-01-01"\r\n AND l.l_shipdate < date_add(date "1994-01-01", INTERVAL 1 year)\r\n AND l.l_discount BETWEEN 0.08 - 0.01 AND 0.08 + 0.01\r\n AND l.l_quantity < 25;'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fe848ee7e80>)])]>

高速化: このクエリは、lineitem テーブルから l_shipdate、l_extendedprice、l_discount、l_quantity の列のみをスキャンすることで大きなメリットが得られます。ベクトル化実行では、日付、割引、数量のフィルタが迅速に適用され、条件を満たす行が特定されます。

クエリ 2: 割引対象外のアイテムの合計数量

SQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT\r\n sum(l_quantity)\r\nFROM\r\n lineitem\r\nWHERE\r\n l_discount = 0;'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fe848ee7f70>)])]>

高速化: このクエリは、lineitem テーブルから l_discount 列と l_quantity 列のみをスキャンすることで大きなメリットが得られます。ベクトル化実行により、等価フィルタ（l_discount = 0）が迅速に適用され、一致する行が特定されます。

クエリ 3: 特定の税率区分の商品数と割引額の範囲

SQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT\r\n count(*),\r\n min(l_discount),\r\n max(l_discount)\r\nFROM\r\n lineitem\r\nWHERE\r\n l_tax IN (0.01, 0.02);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe848ee7490>)])]>

高速化: このクエリは、lineitem テーブルから l_tax 列と l_discount 列のみをスキャンすることで大きなメリットが得られます。ベクトル化実行では、l_tax 列に IN フィルタが迅速に適用され、一致するすべての行が特定されます。

クエリ 4: Spanner Graph を使用してグラフ内のつながりが最も多い N を見つけるために、友達関係をスキャンする

GQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nGRAPH social_graph\r\nMATCH (p:Person)-[k:Knows]->(:Person)\r\nRETURN COUNT(k) AS friend_count GROUP BY p ORDER BY friend_count DESC LIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe848ee7550>)])]>

高速化: このクエリは、サブグラフをスキャンし、グラフから関連する列のみを読み込むことで、大きなメリットが得られます。

クエリ 5: K 近傍法によるベクトル類似性検索を実行して、意味的に最も類似したエンベディング上位 10 件を取得する（再現率 100%）

GQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT e.Id as key, COSINE_DISTANCE(@vector_param, e.Embedding) as distance\r\nFROM Embeddings e\r\nORDER BY distance LIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe848ee7040>)])]>

高速化: このクエリは、連続して保存されたベクトルエンベディングをスキャンし、テーブルから関連する列のみを読み込むことで、大きなメリットが得られます。

今すぐ Spanner のカラム型エンジンを使い始めましょう。

Spanner のカラム型エンジンは、Spanner の基本的な強みを損なうことなく、運用データからより迅速かつ詳細なリアルタイムの分析情報を引き出したいと考えている企業向けに設計されています。これにより、デベロッパーとデータアナリストの両方に新たな可能性が切り開かれることをとても嬉しく思います。Spanner のカラム型エンジンをぜひ真っ先にお試しください。Spanner カラム型エンジンのプレビュー版へのアクセスをリクエストするには、今すぐご登録ください。皆様がどのようなものを構築されるか楽しみにしております。

-グループプロダクトマネージャー、Jagan R. Athreya

-ソフトウェアエンジニア、Alan Jin

TimeTree: Spanner への移行でサービスの継続性を確保、ビジネスのさらなる成長を支える土台を確立

Fri, 25 Jul 2025 01:00:00 +0000

カレンダーシェアアプリ「TimeTree」を開発・運営している株式会社TimeTree（以下、TimeTree）。多様なユーザーの予定管理を支える同社では、さらなるビジネスの成長に備えてサービス基盤の刷新に着手。他クラウドのデータベースサービスから、 Google Cloud の Spanner へ移行したことにより、サービスの継続性を確保するとともに、運用体制の大幅な改善を実現しました。今回は、この移行プロジェクトを担当したエンジニア 2 名に話を伺いました。

利用しているサービス:
Spanner, Cloud Run, Datastream, BigQuery, Cloud Load Balancing, Cloud CDN, Memorystore for Valkey, Cloud Storage, Pub/Sub, Looker

利用しているソリューション:
データベースの移行

ビジネスの順調な拡大に影を落とす 3 つの懸念、その対策として Google Cloud を採用

「あの人と共に生きる未来へ誘おう」というビジョンを掲げる TimeTree では、家族や恋人、友人、チームなど、複数人で予定を共有できるカレンダーシェアアプリ「TimeTree」を開発・運営しています。このアプリはスケジュールを管理するだけでなく、予定ごとにコメントを投稿できたり、通知でやり取りを促したりする機能で、日常の中に自然にコミュニケーションが生まれる仕組みを備えている点が大きな特徴です。こうした工夫が評価され、2015 年のサービス開始以来、国内外で高い支持を獲得。2025 年 5月時点で登録ユーザー数は累計 6,500 万人を突破し、200 以上の国と地域で利用されるグローバルサービスへと成長しました。

しかし、ビジネスが順調に成長する一方で、サービスを支えるバックエンドのシステムには大きな懸念が発生していました。メインのデータを格納しているクラウドデータベースサービスが、TimeTree のサービス規模の拡大に対応できなくなってきたのです。

従来のデータベースサービスには、主に 3 つの問題がありました。1 つ目は、近い将来、データ量の増加によってストレージ容量の上限に到達する可能性が高いこと。2 つ目は、ユーザー数やセッション数の増加により、同時コネクション数が上限に到達しそうなこと。そして 3 つ目は DDL（データ定義言語）のオペレーションに必要なローカルストレージが、大きなテーブルを処理する際に枯渇してエラーになるケースが出てきたことです。

SRE チームマネージャーの金井栄喜氏は次のように説明します。

「TimeTree のデータは、1 つの予定に対してさまざまな情報がひも付いてくるため、データが増えるペースが速いという特性があります。今後のサービスの成長目標を考慮してデータ量やアクセス量を見積ったところ、近い将来、3 つのいずれの課題にも対処するのが難しくなることがわかりました。弊社はこれから新サービスの追加やグローバル展開の強化などを目指しており、ビジネスの重要な局面を迎えます。そこで、ビジネスが成長できる土台を用意する必要があると考え、問題が顕在化する前にシステム基盤の移行に踏み切りました。」

3 つの課題解決に向けて、TimeTree が移行先のデータベースサービスとして選んだのが Spanner です。金井氏によれば、シャーディング機能に大きなアドバンテージがあることが採用の決め手でした。

「もともと今回は、データ量の増加に起因する致命的な問題に対して、シャーディングで解決するアプローチを取る方針でした。その点、フルマネージドな Spanner であれば、すべて自動でシャーディングが行われるので、運用負荷を上げることなく導入できるという大きな魅力があります。拡張性が高く、最大コネクション数などの要件も満たしていたので、今後のビジネスの成長を見据えたときに、弊社に 1 番合っているのが Spanner だと判断しました。」

SRE チームソフトウェアエンジニアの Greg 氏は、従来より BigQuery や Google Workspace といったプロダクトを使用していたことも、Spanner の採用を後押ししたと言います。

「システム基盤を Google Cloud に統一することで、データ分析基盤として利用している BigQuery とのシームレスな連携が可能になり、運用負荷の軽減やコスト削減といった効果が期待できました。また、ユーザー認証基盤として Google Workspace を利用していたので、セキュリティの強化と運用簡易化にもつながると考えました。」

Google Cloud チームと連携した入念な準備で、大規模データのスムーズな移行に成功

Spanner の採用を検討している過程で、TimeTree では Google Cloud Tech Acceleration Program（TAP）を利用し、Google Cloud のエンジニアと共に短期集中のワークショップを実施。移行に向けた課題やその解決策を議論することによって、実践的な視点で実現の可能性を探りました。Greg 氏は、TAP での取り組みを次のように振り返ります。

「移行前のデータベースが MySQL だったので、Spanner への移行は大きなリスクが伴うとも考えていました。例えば、シャーディングのパフォーマンスへの影響を最小化するには、どのようなスキーマ設計にすればいいのか。あるいはレコード数が 150 億以上にもなるデータをスムーズに移行できるのかなど、多くの心配事がありました。そこで TAP では、事前に想定されるさまざまな問題に対して、小さなプロトタイプを作ったりしながら議論し、ひとつずつ解決策を見つけていきました。この段階で疑問や不安が解消されたことで、Spanner 採用の準備はかなりスムーズになったと思います。」

データのクレンジングや、Spanner に最適化したスキーマ設計、アプリケーションの変更など、移行のための準備は 1 年以上の時間をかけて入念に行いました。また、Google Cloud の開発チームとも連携し、大容量データを移行するための Spanner 移行ツールの性能向上など、短時間での移行を可能にする環境も整えました。その成果もあり、実際の移行作業では致命的な問題は発生せず、計画停止の範囲内で実施することができました。

移行作業を成功させた要因として、金井氏は緻密なプロジェクトマネージメントも挙げています。

「もともと今回のプロジェクトには、将来的なビジネスの成長に備えるという目的があったので、タイムラインが非常に重要でした。この点に関しては、少人数体制で進めていくことで意思決定の遅れを回避できたことが、成功の要因だと考えています。Google Cloud チームとしっかり連携したうえで協力いただけたことも、大きかったと感じています。」

自動シャーディングを備えた Spanner により、データベース運用の負担が大幅に改善

TimeTree が抱えていた 3 つの課題は、Spanner への移行によって完全に解消されました。懸念されていたシャーディングによるパフォーマンスへの影響も発生せず、自動スケーリングによってコスト最適化も実現できました。それに加えて、データベース運用の負担も大幅に軽減されています。Greg 氏は、こうした運用面での改善を特に重要な成果と捉えていました。

「移行前はデータ容量やコネクション数の上限を意識して、常にメトリクスを監視しながら調整する必要があり、大きな負担となっていました。シャーディングを導入したとしても、手動で運用するの場合、データ量に応じた調整が困難なので高いリスクが付きまといます。Spanner ではその心配がまったくないので、運用上の手間が大幅に改善され、心理的な負担も払拭されました。」

Spanner の多彩な機能や高い柔軟性は、TimeTree の社内文化にも大きな変革をもたらす可能性があると金井氏は語ります。

「これまで新しい機能やサービスを導入する際には、企画チームが立案し、それをエンジニアが実装するという進め方が一般的でした。一方で、Spanner の多様な機能を活用できるようになれば、エンジニア自らが、技術的な視点から企画を提案することも可能になると考えています。今回の Spanner への移行をきっかけに、エンジニアリング主導の発想や提案で社内全体に活気が生まれ、サービスの成長スピードも加速できるのではないかと期待しています。」

TimeTree では、これからも積極的に Google Cloud を活用していく方針です。直近の目標としては、今回のプロジェクトでは対象外だった、NoSQL データベースの Google Cloud への移行が挙げられます。また AI の導入にも意欲的です。具体的には、イベント表や予約表の画像から予定を自動作成する機能や、アルバムの画像を分析してグルーピングする機能などに、Vertex AI をはじめとする AI サービスの活用を検討しています。マスターデータのデータベースを Google Cloud に移行したことで、AI を使った新しい機能を提供できる可能性が広がっています。

最後に金井氏は、Google Cloud を活用した TimeTree の未来に強い意欲をのぞかせました。

「Google Cloud はグローバルな利用を前提にしたサービスが多く、グローバル展開を目指している弊社とは非常に相性が良いと感じました。プロダクトの成長も早く、欲しいと思う機能がどんどん追加されるので、まだまだ伸びしろが大きいクラウドだと実感しています。我々としても、もっといろいろなサービスを積極的に利用してナレッジを高め、自社のプロダクトを成長させていきたいと考えています。」

株式会社TimeTree
2014 年 9 月 1 日設立。「あの人と共に生きる未来へ誘おう」というビジョンのもと、カレンダーシェアアプリ「TimeTree（タイムツリー）」の開発・運営を行う。TimeTreeは、家族・恋人・友人・職場など、複数人でスケジュールを共有・調整できる仕組みにより、コミュニケーションの円滑化や予定管理の効率化を支援します。国内外での累計登録ユーザー数は 6,500 万人を超えており、ユーザーの多様な利用シーンに対応する機能拡充を進めながら、カレンダーを起点として多様なライフスタイル支援サービスの展開を目指しています。

インタビュイー（写真右から）
・SRE チームマネージャー　金井栄喜氏
・SRE チームソフトウェアエンジニア　Greg 氏

その他の導入事例はこちらをご覧ください。

Spanner の永続的な影響: 2025 ACM SIGMOD Systems Award の受賞

Tue, 08 Jul 2025 03:00:00 +0000

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

今年に入り、Association for Computing Machinery's Special Interest Group on Management of Data（ACM SIGMOD）は、Google のグローバル分散型データベースである Spanner が 2025 SIGMOD Systems Award を受賞したと発表しました。SIGMOD Systems Award は、大規模なデータマネジメントの理論や実践に技術的な貢献を通じて大きな影響を与えたシステムを特に称えるものです。Spanner チーム全体、特に Spanner の開発初期から携わってきたエンジニアを代表して、このような名誉あるコミュニティから評価をいただいたことを、心から光栄に思います。Google は、6 月 22～27 日にドイツのベルリンで開催される 2025 SIGMOD カンファレンスにプラチナスポンサーとして参加します。

2022 SIGOPS Hall of Fame Award に続いてこの賞を受賞したことを鑑みると、この光栄がさらに意義のあるものに感じられます。SIGOPS Hall of Fame Award では、TrueTime や Google のネットワークインフラストラクチャなどのテクノロジーの重要な役割が強調され、最初の Spanner 論文で示された当初のビジョンの永続的な重要性が再確認されました。

Spanner の中核的なイノベーション: TrueTime と外部整合性

Spanner がこのように評価されたことは、Google が数年前に掲げたビジョンと、Spanner が実現する新しいアプリケーション構築方法の強力な裏付けとなります。アワードの授与理由によると、Spanner は「リレーショナルデータマネジメントを再考し、グローバル規模で外部整合性のある直列化可能性を実現した」ことが評価されました。

なぜ「再考」と言われているのでしょうか。Spanner 以前のデータベースでは、ACID トランザクションと SQL か、またはスケーリングとマルチデータセンターの信頼性か、どちらかを選ぶ必要がありました。スケールと可用性を確保するには分散システムが必要であり、それは結果整合性や他の形式のベストエフォート型同期を意味していました。Spanner は、この選択が絶対的なものではないことを示しました。つまり、分散システムの水平スケーラビリティに加えて、トランザクションと SQL のパワーおよび使いやすさを兼ね備えたデータベースを構築できることを示しました。スケールが最優先事項となっている企業は、Spanner によりデベロッパーの速度とアジリティを取り戻すことができました。Spanner は、分散アプリケーションに必要なロジックを大幅に簡素化します。デベロッパーは、データベースが世界中にまたがっている場合でも、単一の一貫したエンティティであるかのようにデータベースの状態を推論できます。

Spanner が外部整合性を実現できる主な要因は TrueTime です。TrueTime は、単なる同期グローバルクロックを超えて、クロックの不確実性を区切られた間隔として公開するスマートな API です。これにより、より高度なアルゴリズムでイベントの順序を推論することが可能になります。Google の TrueTime 実装では、GPS 受信機や原子時計などの特殊なハードウェア参照を使用して、信頼性が高く、非常に厳密な時間制限を実現しています。Spanner は、この区切られた不確実性を利用して外部整合性を実現します。トランザクションが commit されると、Spanner は TrueTime から派生した commit タイムスタンプを割り当てます。その後、Spanner は「commit wait」を強制します（これは、トランザクションの永続化と同時に行われることがあります）。その結果、トランザクションの効果を可視化する前に、commit タイムスタンプが確実に過去のものになります。これにより、割り当てられた commit タイムスタンプには、データセンターをまたいでも、トランザクションの真のグローバルシリアル化順序が決定的に反映されます。結果は驚くべきもので、パフォーマンスを犠牲にせずに外部整合性を実現できます。

整合性とスケールのジレンマに対処する

この道のりについて本当の意味で理解するには、2000 年代初頭から半ばまでの Google を振り返ってみるのがよいでしょう。インターネットが爆発的に普及したため、最大の課題は、それに遅れないようソフトウェアインフラストラクチャをスケールすることでした。インターネットのコピーを、大量の汎用サーバーを使用して保存および処理できるデータベースが必要でした。これにより、驚異的なパフォーマンスとスケーラビリティを実現する内部システムが開発されましたが、トレードオフも伴いました。

これらのシステムに慣れ、Gmail のような大規模なインタラクティブアプリケーションの構築に使用し始めると、結果整合性やクロスシャード同期の処理の難しさ、あらゆる問題（複雑さにかかわらず）を Key-Value ペアとしてモデル化する際の摩擦について、社内の開発者から絶えず聞くようになりました。すぐに明らかになったのは、従来のリレーショナルデータベースの使いやすさと保証（ACID トランザクション、直列化可能性、外部整合性など）を備えた、グローバルに分散したデータベースを構築する必要があるということでした。これを、より多くのユーザーにサービスを提供できるより大きなデータベースという、Google の増大するニーズをあきらめることなく行う必要がありました。加えて、お客様との緊密な連携を通じて、これは実際には Google が構築できるものであることが明らかになりました。その後のことは周知のとおりです。

クラウドサービスとしての Spanner

Google のインフラストラクチャの要である Spanner は、Google 広告、Google 検索インデックス、Gmail、YouTube、Google フォト、Cloud Storage 用メタデータ、BigQuery など、Google の最も重要な地球規模のサービスに使用されており、極端な負荷下でもその堅牢性とスケーラビリティが実証されています。

論理的な次のステップは、Google Cloud を通じて社外のお客様がこれらの機能を利用できるようにすることでした。Spanner のリリースとそれに続く進化は、このテクノロジーを民主化することを目的としており、グローバルに整合性がありスケーラブルなデータベースの機能を、スタートアップからグローバル企業まであらゆる規模の組織にもたらし、アプリケーションの開発と運用を簡素化しました。

Spanner がお客様に提供する主要な価値は、その独自のアーキテクチャから直接生じたものです。

強整合性を伴うグローバルスケール: Spanner は、当初の約束を果たしています。つまり、リージョンや大陸をまたいで水平方向にスケール可能なデータベース全体にわたる外部整合性を備えた ACID トランザクション、そして必要に応じて自動的にデータ分散（シャーディング）を管理する機能です。これは、SIGMOD アワードで評価された機能に直接対応するものです。
比類のない可用性: 複数のゾーンまたはリージョンにわたる Paxos ベースの同期レプリケーションを活用することで、Spanner はマルチリージョン構成において業界トップクラスの 99.999% の可用性サービスレベル契約（SLA）を提供しています。これにより、極めて高いフォールトトレランスが実現し、ミッションクリティカルなアプリケーションのダウンタイムリスクが最小化されます。
運用の簡素化: Spanner はフルマネージドサービスであるため、シャーディング、レプリケーション管理、バックアップ、メンテナンスなどの複雑な運用タスクを自動化できます。これにより、開発チームは運用上の大きな負担から解放され、データベースインフラストラクチャの管理ではなく、アプリケーションの構築に集中できるようになります。これは、従来のシャーディングされたデータベースで必要となる手作業の量や、NoSQL システムのアプリケーションレイヤに整合性ロジックを実装する際の複雑さとは対照的です。
デベロッパーの生産性: Spanner には、Google SQL と PostgreSQL の両方の言語をサポートする、使い慣れた SQL クエリインターフェースが備わっています。これにより、デベロッパーの学習曲線が大幅に平坦化されます。さらに、強整合性により、結果整合性システム上に構築されたアプリケーションでよく発生する、データの同期と調整に関連する一連の複雑な問題がすべて解消されます。

お客様と業界を支援する

もちろん、2012 年に Spanner に関する最初の論文が公開されてから、現在のデータ環境は変化しています。AI ファーストとなった現代のデータ環境では、お客様はこれまで以上に、データの価値を最大限に引き出すことに注力しています。データは多くの場合、データモデル、スケーラビリティ、信頼性が異なる多数のシステムに分散しています。Google は、Spanner Graph、AI アプリケーション向けベクトル検索、統合された全文検索を導入することで、これらの新たな課題に正面から取り組んでいます。これにより、幅広いデータを統合し、整合性のある、スケーラブルな単一のプラットフォーム内で迅速に反復処理できるようになります。さらに、コンピューティングおよびストレージ密度の向上、エディションを通じた階層的料金設定、階層型ストレージなどの費用最適化機能により、データが増加しても費用対効果の高い運用を実現できるようお客様を支援してきました。最後の点として、Cassandra 互換 API など、各種ツールや機能との相互運用性を強化することにより、スケールアウトワークロードを Spanner に取り込みやすくしてきました。

SIGMOD アワードのような学術的評価は嬉しいことである一方、システムの影響を真に測る尺度は、ユーザーが現実の問題を解決し、革新的なアプリケーションを構築するうえでどの程度役立つかにあると、Google は常に感じてきました。Spanner における機能の独自の組み合わせは、さまざまな業界で変革をもたらすことが実証されています。

金融サービスでは、整合性、可用性、セキュリティが最重要事項ですが、Spanner は多くの重要なシステムの基盤となっています。Goldman Sachs などの企業は取引台帳の統合に、arigatobank などの企業はピーク時の負荷下でも完全な整合性を維持して大量の金融トランザクションを処理するために、このソリューションを利用しています。みんなの銀行などのデジタルネイティブの銀行は、インフラストラクチャ全体を Spanner 上に構築し、その可用性と整合性を活用して、厳格な規制要件と顧客の期待に応えています。

ゲーム業界は、スケールとリアルタイムインタラクションの限界を常に押し広げています。Spanner は、ゲームデベロッパーが、コロプラの「ドラゴンクエストウォーク」のような世界的に成功を収めているタイトルをリリースできるよう支援し、初日から数百万人の同時プレーヤーに対応しています。世界中のプレーヤーベース全体にわたってプレーヤープロフィール、ゲーム内のインベントリ、リーダーボードを整合性のある方法で管理し、予測不可能なトラフィックの急増に弾力的に対応する機能は、シームレスなプレーヤーエクスペリエンスを提供するうえで極めて重要な役割を担ってきました。

小売業と e コマースでは、Spanner は企業が現代の商取引の複雑さを管理できるよう支援しています。Walmart は、Spanner を使用して在庫と支払いの管理をモダナイズし、オンライン店舗と実店舗の間でリアルタイムかつ一貫したビューを提供しています。グローバルなオンラインショッピングモールおよび e コマースプロバイダである MercadoLibre は、Spanner を活用して、主要な商品の発売時に発生する需要の急増など、世界中の顧客のニーズに対応しています。

Uber などの運輸業界のリーダーは、Spanner を利用して、10,000 を超える都市で毎月数百万人の同時ユーザーと数十億回の移動を処理し、1 日あたり数十億件のデータベーストランザクションを処理しています。

これらの例は、多くの最新のアプリケーションにとって、グローバルな整合性、大規模なスケーラビリティ、高可用性、相互運用可能なマルチモデルという Spanner の独自の組み合わせが、単なる技術的なメリットではなく、ビジネスを可能にする基盤であることを示しています。リアルタイムのグローバル在庫、瞬時に整合性が保たれる財務記録、世界規模のシームレスなマルチプレーヤーエクスペリエンスを基盤とするビジネスモデルは、Spanner を使用することで大幅に簡素化され、リスクが軽減されて、実装が容易になります。

Spanner が形作る未来

SIGMOD アワードは、Spanner の開発と進化の過程に携わった 30 人以上の個人と、無数の現職および元職の Google 社員の貢献を称えるものです。当初の野心的なコンセプトから、現在では世界に影響を与えるシステムに至るまでの道のりを目の当たりにできたことは光栄に思います。公開された OSDI 原著論文から今回の 2025 SIGMOD Systems Award に至るまでの道のりは、Google による 10 年以上にわたる継続的な研究、エンジニアリング、投資に光を当てるものです。このような長期的な取り組みは珍しく、Spanner の継続的な成功と影響力の背後にある重要な要素となっています。

お客様のおかげで、Spanner は進化し続ける生きたシステムとなっており、社内での使用とクラウドを利用しているお客様のニーズの両方によって推進される継続的な改善の恩恵を受けています。今後も、分散データベースの可能性の限界を押し広げていくことに尽力してまいります。Google は、AI を活用したアプリケーションなど、新しい種類のアプリケーションの実現を Spanner が支援することに期待を寄せています。また、世界を変える次世代のアプリケーションを構築するデベロッパーのために、データマネジメントを簡素化するというミッションを継続していきます。

Spanner の違いを体験する

2025 ACM SIGMOD Systems Award は大きな名誉であり、数年前に Google が歩み始めた道の正しさを証明するものです。2025 SIGMOD カンファレンスに参加される方は、6 月 24 日（火）午後 4 時 30 分に直接お会いして、Google チームの講演をお聞きいただけます。

整合性、スケーラビリティ、可用性に関する Spanner の機能が、直面している課題のお役に立てそうであれば、ぜひ以下の方法で詳細をご確認ください。

Spanner を実際に使用し、サポートされている機能とユースケースをご確認いただけます。90 日間の Spanner 無料トライアルインスタンスをご利用ください。
ドキュメントで詳細をご確認いただけます。
学術的な内容に関心をお持ちの場合、Spanner に関する原著論文と後続論文をお読みください。

最後に、Spanner は信頼性、スケーラビリティ、グローバルな整合性を備えたアプリケーションを構築するための新たな可能性を切り開くものであり、お客様が Spanner を使用してどのようなアプリケーションを構築されるのか、楽しみにしています。

-Spanner 創設者エンジニア、Google Fellow、Christopher Taylor

-Spanner、グループプロダクトマネージャー、Jagan R. Athreya

MySQL から Spanner へのアプリの移行がさらに簡単に

Mon, 26 May 2025 16:00:00 +0000

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

これからのアプリケーションは、AI を活用した動的なエクスペリエンスを、予測不可能な規模でダウンタイムなく提供することが求められますが、これまでのデータベースではこれに十分対応することができません。Google Cloud はその解決手段として、MySQL から Spanner へのデータベースワークロードのモダナイゼーションをシンプルにするための新しい機能、パフォーマンスの向上、そして移行ツールを Google Cloud Next 25 で発表しました。Spanner は、Google Cloud の水平方向にスケーラブルな常時稼働のオペレーショナルデータベースです。

MySQL は、現在の最も差し迫ったスケーリングと可用性のニーズに対応できるよう設計されてはいません。シャーディングや手動レプリケーションなどの一般的な修正は、複雑でリスクが高く、ビジネスが最も許容できないまさにそのタイミングで発生します。セルフマネージドデータベースにおけるスケーリングの計画と実行には通常、高額なアフターマーケットソリューションが必要になります。その設計とテストには数か月かかることもあり、開発チームのマンパワーを、より緊急性の高いユーザー向け機能に割けない状況にしています。また、スケーリングのオーバーヘッドのため、組織はピーク時の使用量に合わせてプロビジョニングすることが多く、その容量がほとんど使用されないこともあります。

これからのアプリケーションは、トランザクション処理以上のことも行う必要があります。セマンティック検索、協調レコメンデーション、リアルタイムの不正行為検出、動的料金設定などの新しいエクスペリエンスでは、それぞれデータの保存とクエリの方法が異なります。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud データベースを試用'), ('body', <wagtail.rich_text.RichText object at 0x7fe8487aa940>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

MySQL から Spanner へのライブマイグレーションがシンプルに

Spanner には、アプリの成長とモダナイズに苦労している組織を支援するため、ダウンタイムをほぼゼロに抑えながら、本番環境のワークロードを MySQL から安全かつ簡単に移行するための明確な移行パスが用意されています。移行後は、Spanner のハンズフリーの信頼性と、リッチなグラフ、全文検索、統合 AI 機能を利用できます。

そのカギとなっているのが Spanner 移行ツールです。このツールは、スキーマとデータの移行を自動化して、ライブカットオーバーをサポートします。たとえば、ペタバイト規模のシャーディングされた MySQL データベースを数か月ではなく数日で統合できます。改良されたデータ移動テンプレートにより、大幅に少ない費用でスループットを高めることができるほか、移行時にデータを変換できる柔軟性も得られます。また、組み込みのリバースレプリケーションが更新され、シャーディングされた MySQL インスタンスに対して Spanner からデータが再同期されるようになったため、障害発生時に準リアルタイムでフェイルオーバーできます。最後の点として、新しい Terraform 構成と CLI インテグレーションにより、実装を柔軟にカスタマイズすることができます。

Spanner 移行ツールのアーキテクチャ

コードとクエリの変更量は少なくして、レイテンシの改善を実現

アプリケーションコードとクエリの移行にかかる費用と複雑さをさらに軽減するため、MySQL に密接にマッピングされる、リッチな新しいリレーショナル機能セットが Spanner に導入されました。

Repeatable Read は MySQL のデフォルトの分離レベルであり、パフォーマンスと整合性のバランスを取っています。この柔軟性が Spanner にも導入されます。新しい Repeatable Read 分離（現在プレビュー版で提供中）は、Spanner の既存の Serializable 分離を補完するものです。MySQL デベロッパーにも馴染みがある分離レベルで、パフォーマンスを大幅に向上させるための追加の手段となります。実際、一般的なワークロードのほとんどでは、以前の Spanner と比較してレイテンシが最大 5 倍改善されます。さらに、新しい auto_increment キー、SELECT…FOR UPDATE、80 個近い新しい MySQL 関数により、アプリケーションを Spanner に移行するために必要な変更が大幅に減少します。

「当社のカレンダー共有サービスの人気が高まるにつれ、需要は着実に増加しました。ユーザーが 5,500 万人に達したとき、データ量とアクティブ接続の両方において Aurora MySQL のスケーラビリティの限界に達しました。しかし、問題はスケーラビリティだけではありませんでした。アプリチームはデータベースの管理に多くの時間をとられたため、機能開発にかけられる時間が減りました。フルマネージド Spanner がこの問題を解決し、費用の大幅な削減と将来の成長が可能になりました。移行は簡単なことではありませんが、Google Cloud のサポートと Spanner 移行ツールのおかげで、最小限のダウンタイムで完了することができました。」 - TimeTree、SRE マネージャー、Eiki Kanai 氏

Forrester Consulting による最近の Total Economic Impact 調査でも、インタビュー対象のお客様を代表する複合組織において、Spanner は 3 年間で 132% の ROI と 774 万ドルの総利益をもたらしたことがわかっています。これは主に、セルフマネージドデータベースを廃止したこと、そして Spanner の弾力性のあるスケーラビリティと、組み込みのハンズフリーの高可用性オペレーションを活用したことによるものです。Forrester の調査によると、Spanner を使用することで、計画外のダウンタイムやシステムメンテナンスによる中断が減り、新しいアプリの導入にかかる時間が短縮され、開発チームは複雑な再設計プロジェクトや新たな資本支出なしで新しい機会に対応できるようになりました。

使ってみる

組織の次の成長マイルストーンにおいてストレスを軽減し、開発チームを成功に導く点で Spanner がどのように役立つかについて詳しくは、https://cloud.google.com/spanner をご確認ください。リファレンスアーキテクチャ、移行の成功事例に加えて、無料評価を実施している認定パートナーのディレクトリをご覧いただけます。MySQL からの移行を成功させる方法についてのドキュメントもご用意しております。Spanner を実際にお試しいただくには、90 日間の無料トライアルをご利用ください。本番環境インスタンスは月額 65 米ドルからご利用可能です。

-シニアプロダクトマネージャー、Justin Makeig

Google Cloud Spanner が Gartner® の軽量トランザクションユースケースで第 1 位に

Thu, 08 May 2025 02:00:00 +0000

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

Google Cloud Spanner が、Gartner レポート「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（運用ユースケース向けクラウドデータベース管理システムの重要機能）において、軽量トランザクションユースケースで第 1 位、OLTP トランザクションユースケースとアプリケーションステート管理ユースケースで第 3 位に選ばれたことをお知らせいたします。この評価は、最も要求の厳しいワークロードを処理する Spanner の能力の高さと汎用性を示すものです。

こちらから Gartner レポートの全文をご確認いただけます。

従来のトランザクションを超えて: 機能の拡張

Gartner の評価は、単にパフォーマンスに対するものではなく、現代の企業の複雑なニーズに対応するために設計された、Spanner の包括的な機能セットに対するものであると Google は考えます。Spanner は、トランザクションの整合性とグローバルなスケーラビリティに定評があるだけでなく、優れたマルチモデルエクスペリエンスを提供し、最新のアプリケーションに必要なグラフ検索、全文検索、ベクトル検索の機能をシームレスに統合します。

グラフデータベース機能: 関係をモデル化してクエリする Spanner の機能は、ソーシャルネットワーク、不正行為の検出、レコメンデーションエンジンなど、グラフ分析を必要とするアプリケーションに最適です。
全文検索: 全文検索機能の統合により、非構造化データを効率的に取得して、商品カタログ、コンテンツ管理システム、ナレッジベースなどの機能を強化できます。
ベクトル検索: AI と ML の台頭とともに、Spanner のベクトル検索機能によって類似性検索を容易にし、画像認識、セマンティック検索、パーソナライズされたレコメンデーションなどのアプリケーションを実現することが可能になりました。

この柔軟性により、デベロッパーは動的な弾力性と運用効率を兼ね備えた単一のプラットフォームで多様なアプリケーションを構築することができます。多数の専用データベースの管理に伴う複雑な作業は必要ありません。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud データベースを試用'), ('body', <wagtail.rich_text.RichText object at 0x7fe82ce93160>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

真にグローバルなサービス: トランザクションと分析の組み合わせ

Spanner は全世界で提供されているため、ユーザーがどこにいても、トランザクションワークロードの低レイテンシと高可用性を確保できます。そして、その能力はトランザクションだけにとどまりません。Spanner と BigQuery の緊密な統合により、連携クエリが可能になり、複雑な ETL プロセスを必要とすることなくトランザクションデータのリアルタイム分析を実現できます。この統合は BigQuery からのリバース ETL にも対応しており、分析情報を Spanner にプッシュして運用に使用することができます。

実際の効果: お客様成功事例

お客様が得ている効果を見れば、Spanner の能力の真価がわかります。実際にどのように使用されているか、例を見てみましょう。

高可用性、外部整合性、および無限の水平方向のスケーラビリティを持つ Spanner は、Deutsche Bank のオンラインバンキング用のビジネスクリティカルなアプリケーションに最適な選択肢でした。
COLOPL は、ログを除くすべてのユーザーデータを 1 つのデータベースに統合して開発を行うことで、水平方向または垂直方向にパーティショニングされたデータベースを大規模なサービスに使用するときに発生していたスケーラビリティの制約を排除できました。
Kroger は、Spanner のフルマネージドリレーショナルデータベースを使用して、真にイベントドリブンな台帳を構築しました。これにより、ユニークイベントをキャプチャして、従業員の生産性を高めるためにどのような指示を出すべきかについて、より十分な情報に基づいた意思決定を行えるようになりました。

今後の対応

Gartner の Critical Capabilities レポートで Spanner が評価を得たことは、クラウドデータベース管理システム市場における Google の立場を強化するものと私たちは考えています。今後も Google は Spanner の機能の革新と拡張を続け、お客様が次世代のミッションクリティカルなアプリケーションを構築できるよう支援してまいります。

グローバルトランザクション、マルチモデルアプリケーション、リアルタイム分析など、お客様が必要とされるデータベースの用途にかかわらず、Spanner は信頼してご利用いただけるソリューションです。Spanner の無料トライアルアカウントに登録して、マルチモデル Spanner の能力を今すぐお試しください。

Gartner「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（Ramke Ramakrishnan、Henry Cook、Xingyu Gu、Masud Miraz、Aaron Rosenbaum、2024 年 12 月 18 日）

GARTNER は、米国およびその他の国における Gartner, Inc. またはその関連会社の登録商標およびサービスマークであり、許可を得て使用しています。権利はすべて同組織が有しており、上の図は、リサーチドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Google までご請求ください。Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner のリサーチの刊行物は、Gartner のリサーチ組織の見解により構成されるものであり、事実を述べたものとは解釈しないでください。Gartner は、明示または黙示を問わず、本リサーチの商品性や特定の目的への適合性を含め、いかなる保証も行いません。

-グループプロダクトマネージャー Jagan R. Athreya

-プロダクト管理担当ディレクター Jagdeep Singh

Forrester の調査で明らかになった Spanner による大きなメリットと費用削減

Fri, 21 Mar 2025 03:00:00 +0000

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

従来のデータベースがもたらすコストの上昇、ストレスの溜まるダウンタイム、スケーラビリティの問題に悩まされていませんか？最高のパフォーマンスとアジリティを目指す組織にとって、従来のデータベースシステムはイノベーションの大きな障害になる可能性があります。

しかし、心配はいりません。Forrester の新しい Total Economic Impact™（TEI）調査によると、Google Cloud の Spanner という、常時稼働でグローバルな整合性を備え、実質的に無制限にスケール可能なマルチモデルデータベースを導入することで、大きなメリットを実現できる可能性があります。どのようなメリットがあるのでしょうか。代表的な複合組織の場合、3 年間で 132% の費用対効果を達成し、数百万ドルの利益と費用削減を実現しています。

詳しくは以下をお読みいただき、調査結果の全文をダウンロードして、Spanner が費用削減と利益の増加、信頼性と運用効率の向上にどのように役立つかをご確認ください。

現状維持にかかる高額なコスト

従来のオンプレミスデータベースは、初期のハードウェアとソフトウェアの投資をはるかに上回る高額な費用がかかりがちです。Forrester の TEI 調査によると、こうしたデータベースは維持に負担がかかり、専任の IT スタッフと専門的な知識が必要になるほか、高額の資本的支出と運用上のオーバーヘッドも必要になります。また、新しいゲームや話題の新製品に対する需要が急増するなど、変化する市場の需要やお客様のニーズに迅速に対応する能力も制限される可能性があります。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud データベースを試用'), ('body', <wagtail.rich_text.RichText object at 0x7fe8486ce3d0>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

Spanner の経済効果: Forrester の主な調査結果

Forrester は Spanner が組織にもたらすメリットを定量化するために、TEI 手法を使用して Spanner を導入した世界中の 7 つの大手組織に詳細なインタビューを実施しました。これらの組織は、小売、金融サービス、ソフトウェアとテクノロジー、ゲーム、輸送など、さまざまな業界にわたっています。Forrester は、調査結果に基づいて、代表的な架空の複合組織（年間収益 10 億ドルの B2C（一般消費者向け取引）組織）を作成し、Spanner の導入による潜在的な財務効果をモデル化しました。

調査によると、この複合組織は 9 か月の回収期間で 132% の投資収益率（ROI）を達成しただけでなく、3 年間でさまざまなソースから 774 万ドルの総利益を実現しました。

オンプレミスの従来型データベースの廃止による費用削減: オンプレミスの従来型データベースを廃止し、Spanner に移行することで、この複合組織は 3 年間で 380 万ドルの費用を削減できます。これは、インフラストラクチャの資本的支出、メンテナンス費用、システムライセンス費用の削減によるものです。

「移行前のシステムはもっと高額で、アプリケーション、データベース、モニタリングなど、システム全体に高額な費用がかかっていました。メインフレームには 500 万ドルから 1,000 万ドルを支払いましたが、今後数年でその費用はほぼ倍増することになるだろうと思います。現在、Spanner はそれよりも 90% 少ないコストで済んでいます。」- ソフトウェアおよびテクノロジー企業のシニアプリンシパルアーキテクト

計画外のダウンタイムの削減による利益の維持と費用の削減: Spanner を導入する前は、技術的な不具合、人為的ミス、データ統合の問題、自然災害によって、データベースに計画外のダウンタイムが発生していました。Spanner では、最大 99.999% の可用性により、計画外のダウンタイムは事実上発生しません。Forrester の試算によると、複合組織は、計画外ダウンタイムの短縮により、120 万ドルの費用削減と利益維持を実現しています。

「Spanner に移行してから 7 年間、Spanner が原因で発生した障害は 1 件もありません。Spanner を導入する前は、年に 1 回程の重大な問題を含め、毎月 1 回はなんらかの問題が発生していました。」- ゲーム企業のテクニカルリーダー

ピーク時のオーバープロビジョニングの削減による費用削減: オンプレミスのデータベースシステムでは、インフラストラクチャの調達サイクルが長く、初期費用が大きいため、組織は通常、ほとんどの時間がオーバープロビジョニングであっても、ピーク時の使用量に合わせてプロビジョニングします。Spanner の柔軟なスケーラビリティにより、組織は小規模からスタートし、使用量の変化に応じて簡単にスケールアップ、スケールダウンできます。データベースは、必要な期間だけスケールアップし、その後スケールダウンできるため、費用を削減でき、使用量を予測する必要もありません。複合組織の場合、3 年間で 100 万ドルの費用削減につながります。

「Spanner を使用する主な理由の一つは、トランザクションの数を増やせることです。また、Spanner は整合性が高いため、データベースの管理に必要なエンジニアの数を減らすことができます。」- 金融サービス組織の SRE、DevOps、インフラストラクチャ責任者

新しいアプリケーションのオンボーディングで得られる効率性: Spanner は、リソースの事前計画の必要性を排除することで、新しいアプリケーションの開発を加速します。その結果、複合組織において新しいアプリケーションのオンボーディングにかかる時間が 80% 短縮され、$981,000 のコスト削減が実現しました。

数字では表せない効果

Forrester の TEI 調査では、定量化可能な ROI に加え、Spanner の価値を高めている定量化できないメリットも強調されています。たとえば、次のようなものが挙げられます。

予算の予測可能性の向上: Spanner は支出を資本的支出から運用的支出にシフトするため、より効果的なリソースの割り当てと予測が可能になります。
テストとデプロイの柔軟性の向上: ソフトウェア開発エンジニアは、テスト用の開発環境を迅速にスケールし、徹底した負荷テストを実施して、リソースを迅速にシャットダウンできます。
Google Cloud の専門的なカスタマーサービス: Spanner のメリットを最大限に引き出すための有益なガイダンスを提供します。

「Spanner チームは専門家です。自社で開発したプロダクトを深く理解しており、当社がプロダクトをどのように使用しているかについて、質問すれば詳細な分析情報を提供してくれます。」- 金融サービス組織、エンジニアリング責任者

イノベーションに適したアーキテクチャ: 新しいビジネス機能の設計と実装、ビジネスの拡大を容易にし、ダウンタイムを発生させることなく、自動化を強化し顧客満足度を向上させます。

これらの戦略的優位性が相まって、組織のアジリティと長期的な成功につながります。

Spanner でデータの可能性を引き出す

Forrester TEI の調査は、Spanner が単なるデータベースではなく、ビジネス変革を促進する触媒であることを明確に示しています。Spanner は、従来のシステムの制約を取り除くことで、組織が大幅な費用削減を実現し、運用効率を改善して、新たなレベルのイノベーションを実現できるようにします。データインフラストラクチャを変革し、組織の可能性を最大限に引き出しませんか？

Forrester Total Economic Impact 調査の全文をダウンロード

-クラウドネイティブデータベースプロダクトマーケティングリード、Ashish Chopra

-シニアプロダクトマネージャー、Justin Makeig

Unico、Spanner ベクトル検索で最先端の ID テクノロジーを構築

Fri, 21 Mar 2025 01:00:00 +0000

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

Unico は、ID 管理と不正行為防止という世界的な課題に取り組む、認証および生体認証の分野をリードする企業です。

ブラジル市場で 20 年近く事業を運営しており、ブラジルの 5 大銀行のうちの 4 行や大手小売業者など、800 社以上の企業に信頼されているサプライヤーです。2021 年以降、デジタル ID を通じて 12 億件以上の認証を円滑化し、当社のソリューションによって、2023 年末時点で 140 億ドル相当の不正行為を阻止したと推定されています。当社の評価額は 26 億ドルを超えており、General Atlantics、SoftBank、Goldman Sachs の支援を受け、ラテンアメリカで 2 番目に価値の高い SaaS 企業として位置付けられています。2024 年には、ラテンアメリカで 3 番目に革新的な企業として Fast Company に評価されました。

現在はグローバルな事業拡大に取り組んでおり、世界における主要な ID ネットワークとなるという野心的なビジョンを掲げて、従来の ID 認証の枠を超え、より幅広い ID 関連テクノロジーを取り入れています。この記事では、Google Cloud と Spanner（Google が提供するスケーリングの制限が事実上存在しない常時稼働のデータベース）が、Unico の目標達成にどのように役立っているかをご紹介します。

ベクトル検索が Unico のソリューションで効果的に機能

Unico は、革新的で最先端のデジタル ID ソリューションを提供することに取り組んでいます。この取り組みの基盤となるのが、ベクトル検索テクノロジーの活用です。これにより、1:N（1 対多）検索（画像にある多数の顔の中から特定の顔を検索する機能）などの強力な機能を実現できます。当社の ID ソリューションを推進するこのテクノロジーにより、特定のクエリに関連する一致を高精度かつ高速に複数検索し、ランク付けできます。

しかし、1:N 検索の開発には大きな課題があります。それは、数百万から数十億の顔ベクトルが登録されたデータベースの中から、顔の一致を効率的に検証する必要があることです。個人の顔の特徴を各エントリと 1 つずつ比較するのは現実的ではありません。この問題に対処するためには、ベクトルデータベースがよく使用され、近似最近傍探索（ANN）を実行して、類似性の高い上位 N 件の顔を返します。

当社は、Spanner がベクトル検索機能をサポートしており、以下の機能により、これらの問題を解決できることを確認しました。

セマンティック検索: Unico のソリューションでは、ベクトルエンベディングを活用することで、完全一致ではなく、より深いセマンティックな関係に基づいて結果を取得できます。これにより、ソース画像とターゲット画像にわずかな違いがあっても、関連する顔の一致を特定するなど、本人確認の精度が向上します。
多様性と関連性: ANN や厳密な k 近傍（KNN）ベクトル検索などのアルゴリズムを使用することで、多様性と関連性のバランスを考慮した結果が得られ、不正行為の検出と身元確認の信頼性が高まります。
マルチモーダルアプリケーション: ベクトル検索は、テキスト、画像、音声など、複数のデータタイプからのエンベディングをサポートしているため、複雑なマルチモーダル ID シナリオで使用できます。
ハイブリッド検索: 最新のベクトル検索フレームワークでは、類似性検索とメタデータフィルタが組み合わされているため、地域やユーザーの好みなどのコンテキストに基づいて結果をカスタマイズできます。

ベクトル検索を統合することで、より迅速でスマートな不正検出ツールをお客様に提供することができます。高精度アルゴリズムを活用したこれらのツールは、不正な顔を非常に高い精度で識別でき、なりすまし犯罪やその他の脅威から企業や個人を効果的に保護します。このイノベーションは、テクノロジーリーダーとしての当社の地位を固めるだけでなく、人々の身元を確実に検証するための統合エコシステムを構築することで、より安全で信頼できる世界を構築するという当社のミッションを明確にするものです。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud データベースを試用'), ('body', <wagtail.rich_text.RichText object at 0x7fe84413e250>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

成果の一例

低レイテンシで動作しつつ、正確性を維持することは、Unico のビジネスにとって極めて重要です。銀行業務のような、リアルタイムのパフォーマンスが求められるアプリケーションにおいてはなおさらです。Spanner は、ベクトル検索のサポートが統合されており、専用のベクトルデータベースソリューションを別途用意する必要がないという点で、第一候補となりました。

Spanner は、運用データに対するトランザクション保証、最新かつ一貫性のあるベクトル検索結果の提供、水平方向のスケーラビリティを実現できます。GRPC（Google リモートプロシージャコール）のサポート、地域別パーティションニング、マルチリージョンストレージ構成、RAG と LLM の統合、高い SLA レベル（99.99%）、メンテナンス不要のアーキテクチャといった特長もあります。また、Spanner は現在、KNN と ANN のベクトル検索もサポートしています。

現在はブラジルとメキシコで 1:N サービスを運用しており、これまでに 10 億を超える顔画像のエンベディングを Spanner に保存しています。この設定により、高いパーセンタイルでの低レイテンシ、840 RPM の高スループット、96% の適合率 / 再現率を実現しています。これはまだ始まりにすぎず、毎月約 3,500 万件の新しい顔画像を処理しており、その数は増え続けています。

Unico は、顧客基盤の拡大、既存プロダクトの強化、国際市場における新たな機会の開拓に引き続き注力し、安全なデジタル ID サービスの提供範囲をブラジル国外にも拡大することを目指しています。Spanner と Google Cloud のエコシステムの力を最大限に活用することで、当社の野心的なビジョンが実現され、人々と企業の信頼関係を築く革新的なソリューションを提供できると確信しています。

詳細:

Spanner でビジネスを変革する方法を確認する。
Spanner の 90 日間無料トライアルインスタンスを今すぐ試す。または、Spanner ベクトル検索を試す。

Spanner ベクトル検索、ハイブリッド検索、Spanner Graph のほぼ無制限のスケーリングによって AI アプリを強化する方法を確認する。

-Unico、エンジニアリングマネージャー Gustavo Monti Rocha 氏
-Unico、ソフトウェアエンジニアリングマネージャー Vinícius Mariano 氏

Spanner Graph の一般提供開始のお知らせ

Mon, 10 Feb 2025 02:00:00 +0000

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

昨今の複雑なデジタル環境で真にインテリジェントなアプリケーションを構築するためには、元データがあるだけでは不十分で、そのデータに潜む入り組んだ関係を理解する必要があります。グラフ分析は、こうした隠れたつながりを明らかにしてくれるほか、全文検索やベクトル検索などの手法と組み合わせることで、新しいタイプの AI 対応アプリケーションエクスペリエンスを実現します。しかし、ニッチなツールに基づく従来のアプローチでは、データサイロ、運用上のオーバーヘッド、スケーラビリティの課題が生じることになります。Google Cloud が Spanner Graph をリリースしたのはこのような理由からであり、このたび一般公開の運びとなったことを嬉しく思います。

前回の投稿では、Spanner Graph がグラフデータマネジメントをどのように刷新するのかについて説明しました。グラフ、リレーショナル、検索、生成 AI の各機能を統合して一元化したデータベースは、スケーラビリティが事実上無制限です。Spanner Graph を使用すると、ISO 標準の直感的な Graph Query Language（GQL）インターフェースを利用して、簡単にパターンマッチングと関係のトラバースを実施できます。GQL と SQL の完全な相互運用性を活用して、グラフデータと表形式データを緊密に連携させることも可能です。また、強力なベクトル検索と全文検索により、語義上の意味とキーワードを使った高速なデータ取得が実現し、Spanner のスケーラビリティ、可用性、整合性を活用して強固なデータ基盤を確立できます。そして、Vertex AI と統合されているため、強力な AI モデルに Spanner Graph から直接アクセスできます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースを試用するための 300 ドル分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7fe8487ff610>), ('btn_text', '無料で始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

Spanner Graph の新機能

プレビュー版以降、Spanner Graph を使った構築をさらに容易に進められるように、魅力的な新機能やパートナー機能とのインテグレーションを追加してきました。具体的に見ていきましょう。

1）Spanner Graph Notebook: グラフを使った開発では、グラフの可視化が重要です。Spanner Graph Notebook はオープンソースの新しいツールであり、Spanner Graph を視覚的にクエリする効率的な方法を提供します。このツールは Google Colab にネイティブにインストールされているため、環境内で直接使用できます。また、Jupyter Notebook などのノートブック環境でも利用できます。このツールを使うと、マジックコマンドを GQL で使用して、複数のレイアウトオプションを使ったクエリ結果やグラフスキーマの可視化、ノードやエッジのプロパティの検査、隣接関係の分析を行うことができます。

オープンソースの Spanner Graph Notebook

2）LangChain とのインテグレーションによる GraphRAG の活用: Spanner Graph と LangChain のインテグレーションにより、GraphRAG アプリケーションの迅速なプロトタイピングが可能です。従来の RAG では、ベクトル検索を使用してデータから関連コンテキストを提供することで LLM のグラウンディングを可能にしていましたが、データ内に存在する暗黙的な関係は利用できません。GraphRAG は、このような複雑な関係をとらえたグラフをデータから作成することで、この制限を克服します。GraphRAG はデータの取得時に、グラフクエリとベクトル検索を組み合わせて活用することで LLM に豊富なコンテキストを提供し、より正確で関連性の高い回答を生成できるようにします。

3）Spanner Studio のグラフスキーマ: Spanner Studio のエクスプローラパネルに、定義済みグラフとそのノードやエッジ、関連付けられたラベルやプロパティのリストが表示されるようになりました。グラフデータの構造を一目で確認して理解できるため、アプリケーションの設計、デバッグ、最適化が容易になります。

4）グラフクエリの改善: Spanner Graph でパス固有のデータ型と関数がサポートされるようになり、特定のノードシーケンスと、グラフ内で 2 つのノードをつなげる関係を取得し、分析できるようになりました。たとえば、次のようにパスパターン内でパス変数を作成し、IS_ACYCLIC 関数を使用してパスにノードの繰り返しがあるかどうかをチェックして、パス全体を返すことができます。

code_block: <ListValue: [StructValue([('code', 'GRAPH FinGraph\r\nMATCH p = (:Account)-[:Transfers]->{2,5}(:Account)\r\nRETURN IS_ACYCLIC(p) AS is_acyclic_path, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe826f4f550>)])]>

5）パートナーのグラフ可視化機能とのインテグレーション: Spanner Graph は現在、業界をリードするパートナーのグラフ可視化機能と統合されています。たとえば、Spanner Graph のお客様は Kineviz のフラグシッププロダクトである GraphXR を使用できます。これは、最先端の可視化テクノロジーと高度な分析機能を組み合わせて、複雑なつながりのあるデータの理解を可能にするツールです。

「Google Cloud と提携し、ビッグデータのグラフ分析を実現できたことを嬉しく思います。GraphXR と Spanner Graph のインテグレーションにより、これまで想像もできなかった方法でデータを可視化し、操作できるようなります。」- Kineviz、CEO、Weidong Yang 氏

Kineviz GraphXR と Google Spanner Graph を使った乗り換えの不正調査

同様に、GPU アクセラレーションを活用した Graphistry のビジュアルグラフインテリジェンスプラットフォームを使用して、Spanner Graph の大規模で複雑なデータから重要な分析情報を抽出することもできます。

「企業はグラフデータの処理において、ようやくスピードとスケールを両立できるようになりました。Graphistry の GPU アクセラレーションを活用したグラフの可視化と AI を Spanner Graph のグローバル規模のクエリ機能と組み合わせることで、簡単に元データからグラフに基づくアクションに到達できます。このパートナーシップによって、不正行為の検出、行動パターンの分析、ハッカーの追跡、リスクの検出などを、自信を持って行えるようになります。」- Graphistry、創設者 / CEO、Leo Meyerovich 氏

Graphistry のビジュアル分析機能: ズーム、クラスタリング、フィルタ、ヒストグラム、タイムバーフィルタ、ノードのスタイル設定（色）により、ポイントアンドクリック分析を行ってデータやクラスタを迅速に理解し、パターンや異常などを特定できます。

さらに、手軽にインストールできるグラフデータベースクライアントである G.V() と Spanner Graph を組み合わせると、日常的なグラフ可視化タスクやデータ分析タスクを容易に行えます。データの専門家の方に、高パフォーマンスなグラフ可視化、ノーコードのデータ探索、そしてカスタマイズ性に優れたデータ可視化のオプションのメリットをお届けします。

「グラフはつながりが大事であるため、G.V() と Google Cloud Spanner Graph の新しいパートナーシップには大いに期待しています。Spanner Graph はビッグデータをグラフ化し、G.V() はグラフをインタラクティブなデータとして可視化してくれます。データ専門家が両ソリューションを組み合わせて何を構築するのか楽しみにしています。」- gdotv Ltd.、創設者、Arthur Bigeard 氏

G.V() を使用した Spanner Graph の視覚的なクエリと探索

お客様の声

一般提供までの間、Google Cloud は複数のお客様と協力して Spanner Graph を活用したイノベーションを推進してきました。

「Commercial Financial Network は 3,000 万社を超える米国企業の信用データを管理するネットワークです。企業が多層的に階層化されており、吸収合併に伴う変化も頻繁に発生することから、管理は複雑になりがちです。Equifax は、貸主が融資の判断に必要とする正確で信頼できる情報をタイムリーに提供できるよう尽力しています。Spanner Graph は、当社がこうした急速に変化する動的な企業階層を大規模かつ容易に管理できるよう支援してくれます。」- Equifax、グローバルプラットフォーム担当チーフアーキテクト、Yuvaraj Sankaran 氏

「当社は不正検出機能の強化に努めており、その成功には Google Spanner のような堅牢なマルチモーダルデータベースの存在が不可欠です。トランザクションデータマネジメント用の SQL を高度なグラフデータ分析と統合することで、評価された不正データを効率的に管理および分析できます。Spanner の新機能により、これまでよりもずっと高い精度でデータの完全性を維持しつつ複雑な不正パターンを明らかにすることができるため、システムのセキュリティと信頼性を確保できます。」- Transmit Security、データプラットフォームグループマネージャー、Hai Sadon 氏

「Spanner Graph は、パフォーマンスに優れた斬新なデータのクエリ方法を実現し、当社ではより迅速に、そして安心して機能を提供できるようになりました。柔軟なデータモデリングと高パフォーマンスのクエリ機能により、オンラインアプリケーションに蓄積された膨大な量のデータをはるかに容易に活用できるようになりました。」- U-NEXT、シニアプリンシパルエンジニア、Aaron Tang 氏

今すぐ Spanner Graph を始めましょう

Spanner Graph は、スケーラビリティに優れた単一の統合データベースをもとに、リレーショナル、検索、AI の各機能とグラフデータマネジメントを提供します。Spanner Graph のメリットとユースケースの詳細については、こちらをご覧ください。こちらのクイックセットアップガイドに沿って Spanner Graph の機能をすぐにご利用いただくこともできます。また、金融投資、不正検出、Customer 360（顧客の総合的な情報）と商品のレコメンデーションに関連するサンプルアプリケーションもお試しいただけます。

-シニアスタッフソフトウェアエンジニア、Bei Li
-プロダクト管理担当ディレクター、Jagdeep Singh

クラウドアプリケーションをパーティショニングして影響範囲を縮小し、グローバルなサービス停止を回避する

Mon, 27 Jan 2025 01:00:00 +0000

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

Google Workspace のようなクラウドアプリケーションには、共同編集、可用性、セキュリティ、コスト効率といった利点があります。一方、クラウドアプリケーションのデベロッパーにとって、高可用性とクラウドアプリケーションの絶え間ない進化の両方を実現することは根本的に矛盾します。新しいコードの追加、構成の更新、インフラストラクチャの再配置など、アプリケーションに変更を加えると、バグが発生したり、サービスが停止したりする可能性があります。こうしたリスクは、サービスの停止を最小限に抑えながら、安定性と革新性のバランスを取らなければならないデベロッパーの課題となっています。

以前、Google Workspace サイト信頼性エンジニアリングチームは、容量を増やす必要があったため Google ドキュメントのレプリカを新しいデータセンターに移行したことがあります。ですが、膨大な関連データを移行したことでデータベースの主要インデックスに過剰な負荷がかかり、ドキュメントの新規作成機能が制限されてしまいました。幸い、迅速に根本原因を特定して問題を緩和することができました。それでも、このときの経験から、単純なアプリケーション変更がグローバルなサービス停止につながるリスクを減らすことは必要だと確信しています。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fe826fc0850>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

影響範囲を制限する

グローバルなサービス停止のリスクを低減するための Google のアプローチは、サービススタックを垂直方向にパーティショニングすることにより、サービス停止の「爆発半径」（影響範囲）を制限することです。基本的な考え方は、アプリケーションサーバーとストレージを分離したインスタンス（「パーティション」）を実行することです（図 1）。各パーティションには、ユーザーリクエストをエンドツーエンドで処理するために必要なさまざまなサーバーがすべて含まれています。また、個々のプロダクションパーティションにはユーザーとワークロードが擬似的にランダムに混在するため、すべてのパーティションのリソースニーズはほぼ同じになります。アプリケーションコードに変更を加える際は、一度に 1 つのパーティションに新しい変更をデプロイしていきます。不適切な変更があった場合、パーティション単位ではサービス停止が発生するかもしれませんが、アプリケーションがグローバルにサービス停止することはありません。

このアプローチを、カナリア手法のみを使った場合と比較してみましょう。カナリア手法では、新機能やコード変更を少数のユーザーにリリースしてから、残りのユーザーに展開します。この手法では、まず少数のサーバーに変更をデプロイしますが、問題の拡散を防ぐことはできません。たとえば、カナリア手法での変更により、デプロイ対象の全サーバーが使用しているデータが破損するというインシデントが生じたことがあります。パーティショニングを実行すれば、不適切な変更の影響は 1 つのパーティションに隔離され、そうした悪影響の伝播を防止できます。当然ですが、実際には両方のテクニックを組み合わせて、新しい変更を 1 つのパーティション内の数台のサーバーにカナリア手法でデプロイしています。

パーティショニングの利点

大まかに言って、パーティショニングには多くの利点があります。

可用性: 当初、パーティショニングを実行する主な理由は、サービスの可用性を向上させ、グローバルなサービス停止を回避することでした。グローバルなサービス停止が発生すると、サービス全体が停止（ユーザーが Gmail にログインできないなど）したり、重要なユーザー機能が停止（ユーザーがカレンダーの予定を作成できないなど）したりする可能性があります。それでも、パーティショニングの信頼性の利点を定量化することは難しいかもしれません。グローバルなサービス停止が生じることは比較的まれなので、しばらく生じない場合、それはパーティショニングのおかげかもしれなければ、単に運がよいだけかもしれないからです。とは言え、サービス停止を 1 つのパーティションにとどめられたケースは何度か経験しています。パーティションがなければ、グローバルなサービス停止に発展していたことでしょう。
柔軟性: Google は、システムへの多数の変更を、データを使ったテストで評価しています。UI 要素の変更など、ユーザー向けの多くのテストでは、別個のユーザーグループを使用します。たとえば Gmail では、メールのメッセージ本文をメッセージのメタデータと一緒にインラインで保存するオンディスクレイアウトを選択することも、複数のディスクファイルに分割するレイアウトを選択することもできます。適切な判断は、ワークロードの微妙な側面によって変わります。たとえば、メッセージのメタデータと本文を分離すると、一部のユーザー操作の待ち時間は短縮されるかもしれませんが、本文とメタデータ列の結合を実行するために、バックエンドサーバーではより多くのコンピューティングリソースが必要となります。パーティショニングを実行すれば、このような選択による影響を、分離されたコンテナ環境で簡単に評価できます。
データの保管場所: Google Workspace では、企業のお客様はデータを特定の地域に保存するよう指定できます。パーティショニングされていない、これまでのアーキテクチャでこのような保証を提供することは困難でした。なぜなら、サービスは、待ち時間を短縮し、利用可能な容量を最大限に活用するためにグローバルに複製するよう設計されていたからです。

課題

パーティショニングの導入には利点もありますが、課題もいくつかあります。場合によっては、これらの課題により、パーティショニングされていない設定からパーティショニングされた設定への移行が難しくなったり、リスクが高くなったりすることがあります。また、パーティショニングした後も課題が残る場合があります。Google が考える問題点を以下に挙げます。

すべてのデータモデルを簡単にパーティショニングできるとは限らない: たとえば、Google Chat ではユーザーとチャットルームの両方を複数のパーティションに割り当てる必要があります。もちろん、パーティション間でトラフィックが生じないよう、チャットとチャットメンバーを 1 つのパーティションに割り当てるのが理想的です。ただし、実際にこれを行うことは困難です。複数のチャットルームとユーザーが 1 つのグラフの作成に使用されます。ユーザーは多数のチャットルームに参加し、チャットルームには多数のユーザーが参加します。最悪の場合、このグラフに 1 人のユーザーという 1 つの連結成分しかない可能性もあります。仮に 1 つのグラフを複数のパーティションに分けたとしても、すべてのユーザーが各自のチャットルームと同じパーティションに割り当てられるよう保証することはできません。
稼働中のサービスのパーティショニングには注意が必要である: ほとんどのサービスは稼働前にパーティショニングを行います。そのため、パーティショニングを導入することは、稼働中のサービスのルーティングとストレージ設定を変更することを意味します。最終的な目標がより高い信頼性であったとしても、稼働中のシステムでこのような変更を行うことは、しばしばサービス停止の原因となり、リスクを伴います。
サービス間でパーティションにずれがある: Google の各サービスは頻繁に相互通信を行います。たとえば、カレンダーの予定に新しい人物が追加されると、カレンダーサーバーは Gmail の配信サーバーにリモートプロシージャコール（RPC）を行い、新しい招待者にメール通知を送信します。同様に、カレンダーの予定にビデオ通話リンクがある場合、カレンダーは Meet サーバーと通信して会議 ID を確認する必要があります。サービス間でもパーティショニングの利点を受けられると理想的です。ただし、サービス間でパーティションを調整することは大変です。主な理由は、使用するパーティションを決定する際、サービスによって異なるエンティティタイプを使用する傾向があるためです。たとえば、カレンダーパーティションではカレンダーオーナーが使用され、Meet パーティションでは会議 ID が使用されます。そのため、サービス間でのパーティションの明確なマッピングが存在しないのです。
パーティションはサービスより小規模である: 最新のクラウドアプリケーションは、数百～数千のサーバーによって提供されています。トラフィックが飽和したサーバーは一般的にパフォーマンスが低下するため、トラフィックの急増に耐えられるよう、サーバーはフル稼働より低い稼働率で稼働させます。500 台のサーバーがあり、それぞれの CPU 使用率の目標値を 60% に設定している場合、負荷の急増を吸収するために 200 台の予備サーバーを実質的に用意していることになります。パーティション間でフェイルオーバーが行われないため、各パーティションで使用される予備容量はかなり少なくなります。パーティショニングをしていない設定では失われた容量を吸収する余裕が十分にあるため、サーバーがいくつかクラッシュしても気付かない可能性があります。ただし、より小規模なパーティションでは、このようなクラッシュにより、利用可能なサーバー容量のかなりの部分が影響を受け、残りのサーバーが過負荷になる可能性があります。

重要ポイント

サービススタックをパーティショニングすることで、ウェブアプリケーションの可用性を高めることができます。パーティション間でフェイルオーバーが行われないため、これらのパーティションは分離されます。ユーザーとエンティティは、リスク許容度順に変更を展開できるよう、固定された方法でパーティションに割り当てます。このアプローチにより、不適切な変更は 1 つのパーティションにしか影響しないことを確信しながら、一度に 1 つのパーティションに変更を展開していくことができます。さらに、そのパーティションに組織のユーザーしか含まれていなければ理想的です。

要するに、パーティショニングとは、より強力かつ信頼性の高いサービスをユーザーに提供しようとする取り組みを支援するものです。皆様のサービスにも適用できるかもしれません。たとえば、地域別パーティショニングをすぐに利用できる Spanner を使用して、アプリケーションの可用性を高めることができます。地域別パーティショニングのベストプラクティスについては、こちらをご覧ください。

参照

-テクニカルプログラムマネジメント Karan Anand

-シニアスタッフ信頼性エンジニア John Lunney

2024 年の Spanner: イノベーションの一年

Tue, 07 Jan 2025 03:00:00 +0000

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

Spanner は、Google が提供するほぼ無制限のスケールが可能な常時稼働のデータベースで、Gmail、YouTube、Google フォトなどの世界規模のアプリケーションの基盤となっています。Google 以外でも、Spanner は Yahoo!、The Home Depot、Wayfair、Pokémon Go といった家庭向けブランドの要求の厳しいワークロードを支えています。現在、Spanner が処理する秒間クエリ数は 40 億以上（ピーク時）、データ量は 15 エクサバイトを超え、99.999% の可用性とグローバルな整合性を実現しています。

2012 年の発表以来、Spanner は画期的な分散型 SQL データベースから、多用途でインテリジェントなイノベーションプラットフォームへと進化してきました。2024 年は Spanner にとって大きな一年となり、複数のリリースによる機能拡張、コストパフォーマンスの向上、再設計による最高水準の信頼性とセキュリティ、デベロッパーエクスペリエンスの強化が達成されました。今回は、2024 年に実現された、特に重要な Spanner のイノベーションとそのメリットを振り返ります。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースを試用するための 300 ドル分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7fe849bd7550>), ('btn_text', '無料で始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

1. マルチモデル: 1 つのデータベースで多くの可能性を実現

Spanner Graph、全文検索、ベクトル検索のリリースにより、Spanner は、高可用性、グローバルな整合性、スケーラビリティを兼ね備えたデータベースから、AI 対応アプリケーションを構築できるインテリジェントで相互運用可能な機能を備えたマルチモデルデータベースへと進化しました。市場に出回っている他のマルチモデルデータベースとは異なり、Spanner は異なるデータモデル間の相互運用性をダウンタイムなしで実現する真のマルチモデルエクスペリエンスを提供します。

Spanner のマルチモデルサポートによってデータベースを統合することで、コストを削減し、運用上のオーバーヘッド、ガバナンスの負担、セキュリティタッチポイントを低減できます。また、相互運用性によってデータの移動が不要になることで、「真のゼロ ETL」エクスペリエンスを実現し、すべてのモデルでデータの整合性を確保できます。これにより、準リアルタイムの不正行為検出、サプライチェーンの最適化、商品のレコメンデーションなどのユースケースに対応できます。

図 1: グラフモデル、リレーショナルモデル、ベクトルモデル、全文検索の使用がインターリーブされた Spanner の SQL クエリ

2. コストパフォーマンスの向上

Spanner はコストパフォーマンスに優れているため、大きな目標を立てながら小規模（月額 65 ドル～）から始めることができ、急激な変動なく直線的にスケールできます。2022 年にはノードあたりのストレージを 2 TB から 4 TB に増やし、2023 年にはさらに追加料金不要でスループットを 50% 向上、ストレージを 2.5 倍増量しました。

今年は、新しいマルチモデル機能をリリースし、新機能ごとに追加料金を請求することなく、これらの機能をシンプルに、優れた費用対効果で提供することを目指しました。そして、その結果誕生したのが Spanner の各エディションでした。この直感的なティアベースの価格設定アプローチでは、多様なニーズと予算に合わせてさまざまな機能をさまざまな価格で提供することで、柔軟性やコストの透明性の向上、さらなるコスト削減を可能にします。

3. Cassandra ワークロードのための新たな環境

Cassandra NoSQL データベースは、そのスピードとスケーラビリティが高く評価されています。一方で、複雑なクエリのサポートが限定的であることや、複雑な関係のモデル化が困難であることなどの制限もあります。Spanner は、NoSQL のスケーラビリティと可用性、従来のデータベースの強整合性とリレーショナルモデルを組み合わせ、両方のメリットを取り入れます。

今年は、Cassandra to Spanner Proxy Adapter がリリースされました。これは、アプリケーションロジックをほぼ変更せず、Cassandra ワークロードをこれまで以上に簡単に Spanner に移行するための、オープンソースのプラグアンドプレイツールです。Yahoo! や Reltio などのお客様は Cassandra Proxy Adapter の使いやすさに満足されており、Google Cloud は今後も他のお客様が Spanner で Cassandra をさらに活用できるよう支援していきます。

4. 生成 AI と Spanner のエコシステム

この 1 年間で、組織における生成 AI の活用方法は大きく変化しました。ただし、生成 AI にはハルシネーションのリスクが伴います。Google Cloud は、トランザクションデータベースや分析データベースがこのリスクを低減し、基盤モデルとエンタープライズ生成 AI アプリのギャップを解消できると考えています。この実現方法は、以下のとおりです。

ベクトル サポート: Spanner のベクトルサポートにより、デベロッパーはデータベースに保存されたベクトルエンベディングに対して類似検索を実行できます。Spanner ベクトル検索は、厳密最近傍（KNN）検索と近似最近傍（ANN）検索の両方をサポートしており、Google のスケーラブルな最近傍（ScaNN）検索アルゴリズムを活用するさまざまなワークフローに対応する柔軟性を実現し、大規模なデータセットでも高速かつ正確に結果を提供します。Spanner は現在、100 億を超えるベクトルにスケーリング可能なベクトル検索をサポートしています。デベロッパーは、ベクトル検索を標準の SQL クエリやグラフ GQL クエリと組み合わせて、RAG アプリケーションなどのユースケースに使用できます。
BigQuery と Spanner の連携によるメリット: Spanner と BigQuery の新しい画期的なインテグレーションにより、企業は運用ワークロードと分析ワークロードを接続し、貴重な分析情報を活用して、意思決定を改善できます。BigQuery の Spanner 外部データセットにより、データを移動または複製しなくても、Spanner に存在するトランザクションデータに対するクエリを BigQuery 内で直接実行できます。Spanner では、BigQuery から Spanner にデータをエクスポートする BigQuery からのリバース ETL もサポートされ、BigQuery で提供される分析情報を運用化できるようになりました。

5. 信頼性、可用性、セキュリティ、ガバナンス

Spanner のお客様は、ミッションクリティカルなワークロードに対して最高レベルの信頼性、可用性、セキュリティ、ガバナンスコントロールを期待しています。今年は、可用性 SLA の改善、マルチリージョンワークロードのアプリケーションパフォーマンスの向上、ガバナンス要件への対応を支援するために、デュアルリージョン構成と地域別パーティション分割のサポートが開始されました。

デュアルリージョン サポート: Spanner のデュアルリージョン構成により、地域のデータ所在地要件を満たしながら、リージョンが 2 つのみの地域で 99.999% の可用性を実現し、目標復旧時点（RPO）ゼロを保証します。
地域別パーティション分割: 世界中のテーブルデータを行レベルで分割し、ユーザーに近い場所でデータを提供できます。地域別パーティション分割により、ゲーム、e コマース、金融サービスなどの業界に属する Spanner のお客様が、アプリケーションレイテンシの短縮、コストの最適化、データ所在地（特定の地域内への機密性の高いユーザーデータの保存など）に関するメリットをユーザーに提供できます。

最後に、Spanner データをより低コストで簡単にバックアップできるよう、増分バックアップとスケジュールバックアップのサポートを開始しました。

6. デベロッパーエクスペリエンス

Google Cloud は、Spanner を含む Google Cloud のデータベースを基盤とするアプリケーションを非常にシンプルに構築、管理できるようにすることを目指しています。

Protobuf の改善: プロトコルバッファ（Protobuf）は、言語に依存せずにデータ構造をエンコードおよびデコードして、転送と保存を効率化する手段です。Spanner で Protobuf 値を管理し、事前にテーブルに正規化することなく、SQL のドット演算子（dimensions.size.width など）を使用してそれらのフィールドにアクセスできるようになりました。これにより、Protobuf 内の特定の値によるフィルタ、グループ化、並べ替えが必要なクエリの記述が大幅に簡素化されます。
トラブルシューティングと Database Center のサポート: Database Center は、さまざまなデータベースサービスをモニタリング、管理するための、AI 搭載の統合データベース管理ソリューションです。今年は、お客様が Database Center で Spanner データベースを管理できるようになりました。また、パフォーマンス上の問題のトラブルシューティングを容易にするために、エンドツーエンドのトレースとクライアントトレースのサポートも追加されました。

Google Cloud は、2024 年にお客様に提供してきたイノベーションを誇りに思っており、お客様が Spanner で構築する革新的なソリューションを楽しみにしています。このイノベーションはまだ始まったばかりであり、2025 年にはさらに多くの魅力的な機能の提供が予定されていることは言うまでもありません。

使ってみる

Spanner の独自性や使用例について詳しくは、こちらをご覧ください。また、90 日間無料で、あるいは月額わずか 65 米ドルから、中断を伴う再構築やダウンタイムなしでビジネスの成長に合わせて拡張できる、プロダクションレディなインスタンスをお試しください。

-グループプロダクトマネージャー Piyush Mathur
-プロダクト管理担当ディレクター Jagdeep Singh

Cassandra から Spanner への新アダプタで Yahoo の移行プロセスを簡素化

Thu, 12 Dec 2024 01:15:00 +0000

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

Key-Value NoSQL データベースである Cassandra は、その速度とスケーラビリティが高く評価されており、キャッシュ保存、セッション管理、リアルタイム分析など、迅速なデータ取得と保存を必要とするアプリケーションで幅広く利用されています。シンプルな Key-Value ペア構造により、特に大規模なデータセットでは、高いパフォーマンスと管理性を保証します。

しかし、このシンプルさゆえに、複雑なクエリのサポートが不十分であること、データの重複が起こりうること、複雑な関係のモデリングが困難であることなどの制限もあります。Spanner は、常時稼働でグローバルな整合性を備えた、規模の制限が事実上存在しない Google Cloud のデータベースであり、NoSQL のスケーラビリティと可用性を従来のデータベースの強整合性とリレーショナルモデルと組み合わせることで、従来の Cassandra ワークロードに対応します。そして今回、アプリケーションロジックを変更することなく、Cassandra ワークロードを Spanner にプラグアンドプレイで移行するためのオープンソースツールである Cassandra to Spanner Proxy Adapter の導入により、Cassandra から Spanner への切り替えがこれまで以上に簡単になりました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースを試用するための 300 ドル分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7fe848690a60>), ('btn_text', '無料で始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

NoSQL ワークロード向け Spanner

Spanner は強整合性、高可用性、事実上無制限のスケーラビリティを提供し、さらにデータの完全性を確保するための SQL および ACID トランザクションをサポートする使いやすいリレーショナルデータモデルを提供します。フルマネージドサービスであるため運用が簡素化され、チームはデータベース管理ではなくアプリケーション開発に集中できるようになります。さらに、Spanner の高可用性は、大規模かつグローバル規模であってもデータベースのダウンタイムを最小限に抑えることで、ビジネスの継続性をサポートします。

現代のビジネスニーズに応えるため、Google は Spanner を絶えず進化させています。最新の Spanner 機能には、グラフ、全文検索、ベクトル検索などの強化されたマルチモデル機能、Spanner Data Boost による分析クエリのパフォーマンス向上に加え、地域別パーティショニングやデュアルリージョン構成といった独自のエンタープライズ機能などがあります。これらの強力な機能と Spanner の魅力的なコストパフォーマンスにより、Cassandra ユーザーにとって新しいエキサイティングな可能性の世界が解き放たれます。

Cassandra から Spanner へのアダプタ - Yahoo! での実績

「Spanner は Cassandra から飛躍的に進歩しているようだが、どうやって始めればいいのだろう」とお考えですか？そんな方のために、プロキシアダプタはクライアントアプリケーションの Cassandra クエリ言語（CQL）トラフィックを Spanner に転送するための、プラグアンドプレイの方法を提供します。仕組みとしては、アダプタはアプリケーションの Cassandra クライアントとして機能しますが、すべてのデータ操作タスクについては Spanner とやり取りすることで内部的に動作します。Cassandra to Spanner Proxy Adapter を使用すると、アプリケーションコードの移行は必要なく、そのまま動作します。

Yahoo は Cassandra から Spanner への移行に成功し、パフォーマンス、スケーラビリティ、整合性、運用効率の向上といったメリットを実現しました。また、プロキシアダプタのおかげで移行処理も簡単でした。

「Cassandra Adapter は、CQL クエリを一切変更することなく、Yahoo Contacts ワークロードを Cassandra から Spanner に移行するための基盤を提供してくれました。当社の移行戦略の柔軟性がより高まり、コードベースを更新せずに Spanner のスケール、冗長性、サポートを活用しながら、他のエンジニアリング活動に集中できています。Spanner は当社のニーズに適した費用対効果の高いソリューションであり、私たちのような規模のビジネスに必要なパフォーマンスを提供します。この移行により、費用とパフォーマンスを最適化しながら業務の継続性を維持できるようになりました。」- Yahoo、コアメールおよびアナリティクス担当主任プロダクトマネージャー、Patrick JD Newnan 氏

最近、Cassandra から Spanner への移行に成功した Google Cloud の別のお客様として、Reltio があります。Reltio は、簡単な移行プロセスにより、フルマネージド、グローバル分散、強整合性を備えたデータベースの利点を享受しながら、ダウンタイムとサービスの中断を最小限に抑えることに成功しました。

これらの成功事例は、データインフラストラクチャのモダナイズ、新しい機能の実現、イノベーションの加速を目指す企業にとって、Cassandra から Spanner への移行が革新的なステップになり得ることを示しています。

新しいプロキシアダプタは移行をどのように簡素化してくれるのでしょうか。一般的なデータベース移行は、次のような手順で行われます。

これらの手順のうち、アプリケーションの移行（手順 4）とデータの移行（手順 6）は他の手順よりも複雑です。プロキシアダプタを使用すると、Cassandra ベースのアプリケーションを Spanner へ移行する作業が大幅に簡素化されます。新しいプロキシアダプタを使用する際に必要な手順の概説をしていきましょう。

1. 評価: Cassandra スキーマ、データモデル、クエリパターンを評価し、Spanner への移行後に簡素化できるものを特定します。

2. スキーマの設計: Spanner のテーブル宣言の構文とデータ型は Cassandra のものと類似しています。ドキュメントでは、これらの類似点と相違点について詳しく説明しています。Spanner を使用すると、最適なパフォーマンスを実現するためにリレーショナル機能やインターリーブされたテーブルなどの機能を活用することもできます。

3. データ移行: データを移行するには、いくつかの手順があります。

一括読み込み: Cassandra からデータをエクスポートし、Spanner Dataflow コネクタや BigQuery リバース ETL などのツールを使用して Spanner にインポートします。
受信データのレプリケーション: Cassandra の変更データキャプチャ（CDC）を使用して、Cassandra クラスタへの受信更新を Spanner にリアルタイムで複製します。これとは別に、アプリケーションロジックを更新して、Cassandra と Spanner に二重書き込みを行うという方法も考えられます。ただ、アプリケーションコードの変更を最小限に抑えたい場合はこのアプローチはおすすめしません。

4. プロキシ アダプタを設定し、Cassandra 構成を更新: Cassandra to Spanner Proxy Adapter をダウンロードして実行します。このプロキシアダプタは、アプリケーションと並行してサイドカーとして動作します。デフォルトでは、プロキシアダプタはポート 9042 で実行されます。別のポートを使用する場合は、プロキシアダプタを参照するようにアプリケーションコードを更新することをお忘れなく。

5. テスト: 移行したアプリケーションとデータを非本番環境で徹底的にテストし、すべてが期待どおりに動作することを確認します。

6. カットオーバー: 移行に自信が持てたら、アプリケーショントラフィックを Spanner に切り替えます。問題がないか注意深くモニタリングし、必要に応じてパフォーマンスのファインチューニングを行います。

新しいプロキシアダプタの仕組み

新しいプロキシアダプタは、アプリケーションに対して Cassandra クライアントとして機能します。アプリケーションの観点から言うと、唯一の顕著な変更点は、Cassandra エンドポイントの IP アドレスまたはホスト名がプロキシアダプタを指すようになったことです。これにより、アプリケーションコードを大幅に変更する必要がなく、Spanner の移行を合理化できます。

プロキシアダプタは、各 Cassandra クラスタと対応する Spanner データベースの間に 1 対 1 のマッピングを確立するよう設計されています。プロキシインスタンスはマルチリスナーアーキテクチャを採用しており、各リスナーは個別のポートにバインドされています。これにより、複数のクライアント接続を同時に処理しやすくなり、各リスナーが指定された Spanner データベースとの個別の接続を管理します。

プロキシの変換レイヤは、Cassandra プロトコルの複雑な部分を処理します。このレイヤはメッセージのデコードとエンコードの実行、バッファとキャッシュの管理を行い、さらに重要なこととして、受信した CQL クエリを解析して Spanner と互換性のある形式に変換します。

プロキシアダプタは OpenTelemetry をサポートしており、トレースを収集して Cloud Trace にエクスポートできます。

アダプタのさまざまな設定方法、制限事項、CQL データ型の Spanner へのマッピングなどについての詳細は、プロキシアダプタのドキュメントをご確認ください。

一般的なの懸念と課題への対応

移行に伴い考えられるいくつかの懸念事項についてご説明します。

費用: Spanner が一貫したレイテンシとスループットだけでなく、費用対効果も保証することを示した Accenture のベンチマーク結果をご覧ください。さらに Spanner では、Spanner のすべての機能を活用していただけるよう、費用の透明性を向上し、費用削減の機会を提供する新しい段階的料金モデル（Spanner エディション）が提供されるようになりました。
レイテンシの増加: クエリのレイテンシ増加を最小限に抑えるには、プロキシアダプタをクライアントアプリケーションと同じホストで（サイドカープロキシとして）実行するか、プロキシアダプタを Docker コンテナで実行する場合は同じ Docker ネットワーク上で実行することをおすすめします。また、プロキシアダプタホストの CPU 使用率を 80% 未満に保つことを推奨しています。
スキーマの柔軟性: Cassandra はスキーマの柔軟性を提供しますが、Spanner のより厳密なリレーショナルスキーマは、データの完全性、クエリ能力、整合性の点で優位性があります。
学習曲線: Spanner のデータ型には Cassandra のデータ型といくつかの相違点があります。移行を容易にするために、包括的なドキュメントをご覧ください。

使ってみる

強整合性、簡素化された運用、強化されたデータの完全性、グローバルなスケーラビリティといった利点により、Spanner は NoSQL ワークロードにクラウドの可能性を最大限活用したいと考えている企業にとって魅力的な選択肢となっています。新しい Cassandra to Spanner Proxy Adapter により、移行戦略の計画と実行が容易になり、データドリブン型のイノベーションで新時代を切り開けます。

新しい Cassandra to Spanner Proxy Adapter をダウンロードし、Spanner 無料トライアルインスタンスで今すぐお試しください。

-Google Cloud、シニアプロダクトマネージャー Nitin Sagar

-Google、エンジニアリングマネージャー Eike Falkenberg

Spanner への近似最近傍（ANN）検索の導入

Fri, 23 Aug 2024 01:05:00 +0000

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

ベクトル検索は、大規模なデータセットの中から、指定されたクエリアイテムに似たアイテムを見つけるために使用する手法です。従来の（完全一致に基づく）検索手法があまり効果的ではない、画像、テキスト、音声などの非構造化データを扱う場合に特に有用です。また、大規模言語モデル（LLM）のプロンプトの強化、関連性の向上、ハルシネーションの削減にも使用できるため、生成 AI アプリケーションにおけるベクトル検索の役割は重要です。この機能が汎用データベースに組み込まれているということは、スケーラブルなベクトル検索機能がオペレーショナルデータベースに直接統合され、別のデータベースや ETL パイプラインを管理する必要がないということです。

現在プレビュー版で提供している Spanner の厳密 K 最近傍（KNN）ベクトル検索は、個人の写真を検索するなど、個々のクエリに関連するエンティティの数が比較的少ない、高度にパーティショニング可能なワークロードに適しています。今年初めに KNN ベクトル検索をリリースして以来、Spanner のお客様による導入が増加しています。そしてこのたび、パーティション分割されていない大規模なワークロードでも、Spanner で近似最近傍（ANN）検索を利用して、以下を実現できるようになりました。

スケールとスピード: 10 億以上のベクトルに対応する高速、高再現率の検索
運用の簡素化: 専用のベクトル DB へのデータのコピーが不要
整合性: 最新のアップデートが反映された、常に最新の結果を表示

ANN 検索機能の追加により、Spanner はベクトル検索ニーズに対して、スケーラビリティに優れた効率的なサポートを提供できるようになりました。とはいえ、Google の言葉を鵜呑みにしないでください。お客様の声をご紹介しましょう。

「Spanner のベクトル検索がもたらすセマンティックな理解の力を活用することで、関連性の高いコンテンツとエクスペリエンスをお客様に提供し、エンゲージメントとコンバージョン率の向上を実現できると考えています。」 - Optimizely、最高技術責任者 Aniel Sud 氏

ANN を使用する

大規模なベクトル検索を実現する Spanner のイノベーションについて、詳しく見ていきましょう。

Spanner は、Google Research の高効率なベクトル類似検索アルゴリズムである ScaNN（スケーラブルな最近傍）を活用しています。これは、Google および Google Cloud アプリケーションに不可欠な要素です。現在 Spanner には、以下のような主要な ScaNN ベースの最適化が組み込まれています。

ツリー状構造へのクラスタ エンベディングにより、スコア空間を枝刈りしてクエリ時間を短縮し、精度と引き換えにパフォーマンスを大幅に向上
生のベクトル エンベディングを量子化し、スコアリングの高速化とストレージの削減を実現
ベクトルの最も関連性の高い部分に焦点を当てて距離計算を最適化し、パーティショニングとランキングを改善して再現率を向上

Spanner で ANN を実行するには、標準 SQL DDL を使用し、検索ツリーの形状と距離の種類を指定して、ベクトルエンベディングのベクトルインデックスを作成する必要があります。

ツリーの形状

データセットのサイズにより、ツリーは 2 レベルまたは 3 レベルになります。3 レベルのツリーでは、ルートとリーフの間にブランチノードのレイヤが追加され、10 億以上のベクトルデータセットまでスケーリングできる階層的なパーティショニングが可能になります。セントロイドと呼ばれるリーフパーティションの代表は、それ自体がエンベディングでもあり、計算され、ルートノードとブランチノードに格納されます。

クエリ時には、受信したクエリエンベディングは、まずルートに格納されているすべてのセントロイドと比較されます。最も近いセントロイドと、それに対応するリーフ（2 レベルのツリーの場合）またはブランチ（3 レベルのツリーの場合）のみが、さらなる評価のために選択されます。上の図では、青いブロックがスコアリングのために読み込まれる検索ツリー部分を表し、灰色のブロックが枝刈りされる部分（ツリー全体の大部分）を表しています。

ツリーのブランチとリーフの数はインデックス作成時に設定できます。一方、検索するリーフの数はクエリ時に調整できます。クエリオプションと同様にインデックス作成ノブを調整することで、求めているパフォーマンスと精度のトレードオフを実現できます。

距離関数

距離関数は、ベクトルエンベディング間の類似度を測定する手段です。Spanner はすでに KNN 検索のための厳密な距離関数をサポートしています。ANN については、ベクトルインデックスとともに使用する ANN 検索用に以下の近似距離関数が導入されています。

APPROX_COSINE_DISTANCE()
APPROX_EUCLIDEAN_DISTANCE()
APPROX_DOT_PRODUCT()

ベクトルインデックスの作成時には、求めている距離の種類をインデックスオプションとして指定する必要があります。指定可能な値は COSINE、EUCLIDEAN、DOT_PRODUCT です。

ベクトルインデックスに対するクエリでは、対応する距離関数を使用する必要があります。

例: 投資信託の検索

ANN のデモで紹介された例を見ていきましょう。あるお客様が投資に適した投資信託を探しています。MutualFunds テーブルの各行は 1 つの投資信託を表しています。

FundId は、投資信託の固有識別子です。他のテーブルで相互参照される場合があります。
FundName は、投資信託の正式な名称です。
InvestmentStrategy は、ファンドの戦略を記述した構造化されていないテキスト文字列です。
Attributes は、運用益など、ファンドに関する構造化データを格納するプロトコルバッファです。
InvestmentStrategyEmbedding は、投資戦略のベクトル表現です。ML.PREDICT 関数を使用して生成できます。

code_block: <ListValue: [StructValue([('code', 'CREATE TABLE MutualFunds (\r\n FundId INT64,\r\n FundName STRING(MAX),\r\n InvestmentStrategy STRING(MAX),\r\n Return10Years FLOAT32,\r\n InvestmentStrategyEmbedding ARRAY<FLOAT32>(vector_length=>128)\r\n) PRIMARY KEY(FundId);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486edf40>)])]>

次のステートメントを使用して、MutualFunds のベクトルインデックスを作成します。

code_block: <ListValue: [StructValue([('code', "CREATE VECTOR INDEX FundIndex2Level on MutualFunds(InvestmentStrategyEmbedding)\r\n WHERE InvestmentStrategyEmbedding IS NOT NULL OPTIONS (\r\n tree_depth = 2,\r\n num_leaves = 10000,\r\n distance_type = 'COSINE'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486ed730>)])]>

投資信託の数が多い場合は、3 レベルのツリーの方が適切かもしれません。

code_block: <ListValue: [StructValue([('code', "CREATE VECTOR INDEX FundIndex3Level on MutualFunds(InvestmentStrategyEmbedding)\r\n WHERE InvestmentStrategyEmbedding IS NOT NULL OPTIONS (\r\n tree_depth = 3,\r\n num_branches = 1000,\r\n num_leaves = 1000000,\r\n distance_type = 'COSINE'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486ed310>)])]>

インデックスが作成されたら、以下のようにクエリを実行します。query_embedding は、InvestmentStrategyEmbedding 列を生成したものと同じエンベディングモデルを使用し、ユーザー入力のテキストに基づいて ML.PREDICT により生成された、求めている投資戦略のベクトル表現です。

code_block: <ListValue: [StructValue([('code', 'SELECT b.FundId\r\n FROM MutualFunds@{FORCE_INDEX=FundIndex3Level} b\r\n WHERE\r\n b.InvestmentStrategyEmbedding IS NOT NULL\r\n ORDER BY\r\n APPROX_COSINE_DISTANCE(@query_embedding,\r\n b.InvestmentStrategyEmbedding,\r\n OPTIONS => JSON \'{"num_leaves_to_search": 50}\')\r\nLIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486ed8b0>)])]>

このクエリでは、50 件のリーフを検索し、クエリの投資戦略に最も近い上位 10 件の投資信託を見つけます。num_leaves_to_search の値を調整して、レイテンシと再現率をトレードオフします。

現時点では、以下に注意してください。

使用するベクトルインデックスは、クエリヒントとして明示的に指定する必要があります。
クエリでは、ベクトルインデックスと同じ NULL フィルタリング（IS NOT NULL）句を使用する必要があります。
近似距離関数は、ベクトルインデックスの distance_type と一致している必要があります。
距離関数を唯一の ORDER BY キーにして、LIMIT を指定する必要があります。

高度なユースケース

ポストフィルタリング

ANN の検索結果は、クエリの WHERE 句に属性を追加することでフィルタできます。次のクエリは、クエリ戦略が一致し、10 年間の利益率が 8% を超えるファンドを返します。

code_block: <ListValue: [StructValue([('code', 'SELECT b.FundId\r\n FROM MutualFunds@{FORCE_INDEX=FundIndex3Level} b\r\n WHERE b.InvestmentStrategyEmbedding IS NOT NULL AND\r\n b.Return10Years > 0.08\r\n ORDER BY\r\n APPROX_COSINE_DISTANCE(...\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486ed190>)])]>

マルチモデルクエリ

FundName フィールドに全文検索インデックスも作成する場合は、以下のようになります。

code_block: <ListValue: [StructValue([('code', 'ALTER TABLE MutualFunds ADD COLUMN FundNameTokens TOKENLIST AS\r\n (TOKENIZE_FULLTEXT(FundName)) HIDDEN;\r\nCREATE SEARCH INDEX FundNameIndex ON MutualFunds(FundNameTokens) OPTIONS (\r\n sort_order_sharding = true);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486eda90>)])]>

以下のクエリを実行すると、クエリ戦略（「balanced low risk socially responsible fund（バランスの取れた低リスクの社会的責任ファンド）」のようなフレーズのベクトル表現など）が似た、名前に「emerging markets（新興市場）」が含まれているファンドを探すことができます。

code_block: <ListValue: [StructValue([('code', 'SELECT i.FundId\r\nFROM\r\n (\r\n SELECT b.FundId\r\n FROM MutualFunds@{FORCE_INDEX = FundIndex3Level} b\r\n WHERE b.InvestmentStrategyEmbedding IS NOT NULL\r\n ORDER BY APPROX_COSINE_DISTANCE(@query_embedding, b.InvestmentStrategyEmbedding,\r\n OPTIONS => JSON \'{"num_leaves_to_search": 50}\')\r\n LIMIT 10\r\n ) AS ann\r\nJOIN MutualFunds AS i\r\nON i.FundId = ann.FundId\r\nWHERE SEARCH(i.FundNameTokens, \'emerging markets\');'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486ed2b0>)])]>

また、求めている戦略に似たファンドか、ファンド名に「emerging markets（新興市場）」が含まれているファンドを探すことで、必ずしもこれらの言葉がすべて含まれているとは限らないテキスト一致や意味的一致を見つけることができます。

code_block: <ListValue: [StructValue([('code', 'SELECT FundId\r\nFROM\r\n (\r\n SELECT b.FundId\r\n FROM MutualFunds@{FORCE_INDEX = FundIndex3Level} b\r\n WHERE b.InvestmentStrategyEmbedding IS NOT NULL\r\n ORDER BY APPROX_COSINE_DISTANCE(@query_embedding, b.InvestmentStrategyEmbedding,\r\n OPTIONS => JSON \'{"num_leaves_to_search": 50}\')\r\n LIMIT 10\r\n )\r\nUNION DISTINCT\r\n (\r\n SELECT FundId\r\n FROM MutualFunds\r\n WHERE SEARCH(FundNameTokens, \'emerging markets\')\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486ed970>)])]>

このようにすると、従来のテキスト検索結果を、意味的に関連性のある検索結果でフィルタしたり増やしたりすることができます。

使ってみる

Spanner の詳細情報を確認し、今すぐお試しください。その他の情報については、以下をご覧ください。

Spanner ベクトル検索のデモ
Spanner ANN ユーザーガイド
ベクトルエンベディングについて、および Spanner のベクトル検索を小売業で活用する方法
Spanner の ML.PREDICT SQL 関数を使用したデータベース内ベクトルエンベディング生成（チュートリアル）、LLM クエリ（チュートリアル）、Vertex AI が提供するカスタムモデルによるオンライン推論（チュートリアル）
LangChain と、オープンソースの spanner-analytics パッケージ（Python での一般的なデータ分析オペレーションを容易にし、Jupyter Notebooks とのインテグレーションが含まれます）を含む Spanner の AI エコシステムのインテグレーション

-ソフトウェアエンジニア Zhiyan Liu

オーバープロビジョニングに別れを: Spanner で費用対効果の高い弾力性を実現する方法

Wed, 21 Aug 2024 01:40:00 +0000

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

データベースに関して、多くの企業はジレンマに直面しています。それは、サービスの品質、レイテンシ、スループットを維持しつつ、費用対効果の高い方法でスケーリングするにはどうすればよいかということです。

特にこれが難しいのは、企業のワークロードではトラフィックパターンが大きく変動することが多いためです。たとえば e コマースやリテールバンキングのアプリケーションのトラフィックは変動し、多くの場合、下図のように日中に利用がピークに達し、夜になると大幅に減少します。

このような変動性に対応するには、パフォーマンスを損なわずにピーク負荷を処理できるデータベースインフラストラクチャが必要です。ピーク負荷を処理するための従来のアプローチは、CPU、RAM、ディスク I/O、ストレージなどのリソースのオーバープロビジョニングです。

オーバープロビジョニングの欠点は、ピーク時以外はリソースのほとんどがアイドル状態のままになり、余計な費用が発生することです。ステートレスなアプリケーション階層とは対照的にデータベースは本質的にステートフルであるため、実際の使用率に沿って都度データベースリソースのサイズを適正化することは、通常は選択肢にはありません。さらに、コンピューティングリソースとストレージリソースを緊密に結合させると通常はダウンタイムが発生し、可用性や少なくともサービスの品質に影響を与える可能性があります（レイテンシの悪化など）。そのため、データベースサービスは SLA を満たすために、リソースをかなり浪費することになるにもかかわらず、レイテンシとスループットの一貫性を優先する必要があります。

e コマースの例に戻ると、ほとんどのオンライン小売ウェブサイトでは、データベースのオーバープロビジョニングよりも、ユーザーの不満に起因するトラフィックの損失の方が収益に悪影響を及ぼすことがわかっています。それでも、予想されるピーク負荷によっては、平均のリソース使用率が 20% 前後になることも珍しくありません。つまり、割り当てられたリソースの 80% が無駄になっているということです。

オーバープロビジョニングに伴う無駄の削減に Spanner がどのように役立つか

従来のデータベースシステムとは異なり、Spanner はコンピューティングリソースとストレージリソースを切り離します。Spanner のオートスケーラーはこのコンピューティングリソースとストレージリソースの分離を活用し、ダウンタイムをなくしてレイテンシへの影響を抑えながら、コンピューティングリソースを弾力的に調整します。ワークロード需要に合わせてコンピューティング容量を調整するこの種の動的スケーリングでは、余分な費用をかけずに最適なパフォーマンスを確保できます。

Spanner のオートスケーラーはノード数を調整し、レイテンシの中央値を犠牲にすることなくトラフィックパターンを忠実に追い、非常に短い時間枠内で p90 以上の急増を正常化します。

従来のデータベースシステムでは、データベーストラフィックの処理に必要なコンピューティングリソースに加え、ストレージリソースも慎重に考慮する必要があります。Spanner は、従量課金制のストレージモデルで物事をシンプルにしています。ディスクストレージと I/O に関して、事前にプロビジョニングしたり事前に支払ったりする必要がありません。さらに、Spanner では有効期間（TTL）機能により、「ホット」な OLTP データベース内で保持する必要のなくなったデータを削除できるため、ストレージの使用率、ひいては費用をビジネスニーズに忠実に追従させることができます。

つまり、Spanner はコンピューティングリソースとストレージリソースを弾力的に拡大縮小することで、オーバープロビジョニングを不要にします。しかし、ベースラインより一桁多くなるなど、需要の突然な急増があった場合はどうなるのかと疑問に思うかもしれません。次のセクションでは、Spanner のスケールアウトアーキテクチャとプレウォーミングにより、需要の極端な急増に対するガードレールを導入する方法について説明します。

ピークイベントについて

再び小売業界に目を向けると、ピークイベントの身近な例としては、サイバーマンデーやブラックフライデーといった販売促進期間が挙げられます。そうした状況では、サービスの提供を犠牲にしたり、アイドル状態のリソースに過剰に支出したりすることなく、例外的なトラフィックの急増に対応するには、綿密な計画と調整が必要になります。

たとえ綿密な計画を立てても、ピークイベントでは、すでにオーバープロビジョニングされている容量では対応できないレベルで、需要の急増が起きる可能性があります。もちろん、ピークイベントのために年間を通じてリソースをオーバープロビジョニングすると、費用が非常に高くなります。そのため、予測可能なピークイベントに直面している組織は、事前に容量をデプロイするプロセスを導入しています。

従来のデータベースシステムでは、このプロセスはどのようになるでしょうか。必要となる大まかな手順を下図に示します。

ピークイベントに至るまでの手順:

ステップ 1: 予想されるイベントを計画し、調整します。ビジネスチーム（マーケティングなど）と緊密に連携し、正確な需要予測を行って、それに応じて IT チームが準備できるようにする必要があります。
ステップ 2: サービスを一時的に停止します。部分的に運用できるようにするために、ガードレール（リードレプリカを有効にするなど）を導入することもあります。
ステップ 3: CPU と RAM を追加でプロビジョニングします。このステップでは、予想される急増を処理するためにコンピューティングパワーとメモリを増やします。

ピーク後の手順:

ステップ 4: サービスを再びオフラインにします。
ステップ 5: 余分な CPU と RAM をデプロビジョニングし、日常業務の容量に戻します。
ステップ 6: システムを再起動します。

もちろん、ダウンタイムを最小限に抑える方法はあります。組織によっては、ミラーリングしたデータベースインスタンスをプロビジョニングし、対象のピークイベントの前後でトラフィックをルート変更しているケースもあります。

しかし、ダウンタイムの有無にかかわらず、上記のアプローチは全体的に多大な労力を要し、追加の費用とリスクが生じます。

来ることのないピークを予測してリソースを大幅にオーバープロビジョニングすると、費用が高くつきます。
逆に、予測が不正確なせいでアンダープロビジョニングになり、パフォーマンスが低下して収益に影響を与えたり、顧客に不満を抱かせたりするおそれもあります。
想定の範囲を超える予想外の急増（クチコミによる急増など）が発生して、全面的なサービス停止につながることもあります。

Spanner のポリシー: 常時適切に対応

対照的に、Spanner では弾力的なコンピューティングモデルと自動スケーリングを組み合わせているため、サービスの健全性やユーザーエクスペリエンスを損なうことなく、トラフィックの大幅な急増を適切に対応できます。ほとんどの場合、Spanner インスタンスは大規模なリリースの調整や容量の計画を必要としません。また、たとえ必要な場合であっても、ユーザーは煩雑なアップグレード手順を実施せずに済みます。

Spanner には、データを自動的にシャーディングし、基盤となるリソースを適切にスケーリングして、サービスの品質が低下しないようにするメカニズムが組み込まれています。しかし、Spanner インスタンスがトラフィックの急増に遭遇することなく、かなりの期間にわたって定常状態にある場合には、パフォーマンスの低下を避けるためにウォームアップ手順が必要になることがあります。これは、トラフィックの大幅な急増が予想される新サービスのリリースイベントでは特にあてはまります。Spanner のプレウォーミングについて詳しくは、こちらの記事をご覧ください: Cloud Spanner のウォームアップツールとベンチマークツールでアプリケーションのリリースを簡単に

まとめ

コンピューティングリソースとストレージリソースを分離し、自動スケーリングを利用することで、Spanner は変動するトラフィックパターンに動的に対応します。高需要のピークに応じてスケールアウトし、無駄を防ぐためにスケールバックすることで、費用を最適化しながら一貫したパフォーマンスを実現します。そのため Spanner は、予想外のトラフィックの急増や計画済みのイベントへの対応に適しています。企業はアイドル状態のリソースに過剰な支出をすることなく、信頼性の高いサービスを提供できるようになります。

Spanner の独自性や使用例について詳しくは、こちらをご覧ください。また、90 日間無料で、あるいは月額わずか 65 米ドルで、中断を伴う再構築やダウンタイムなしでビジネスの成長に合わせて拡張できる、本番環境対応のインスタンスをお試しください。

ー Spanner、シニア スタッフ ソリューション アーキテクト Szabolcs Rozsnyai

ー Spanner、シニア スタッフ ソリューション アーキテクト Karthi Thyagarajan

Spanner

Spanner カラム型エンジンで Iceberg レイクハウスの最新データを迅速に提供

OLTP と分析の統合: Spanner カラム型エンジン

新機能

Iceberg データに高速かつ低レイテンシのサービング プラットフォームが必要である理由

Spanner カラム型エンジンのベンチマーク

ユニバーサル リバース ETL: すべてのレイクハウスのデータを提供

使ってみる

従来の Apache Cassandra スタックを廃止し、Spanner で未来志向の基盤を構築

NoSQL の先へ: Cassandra ユーザー向けの戦略的ソリューション

ワークロードに合わせた Spanner の最適化

Cassandra エコシステムを再構築する

Spanner のマルチモデルの強みで未来を築く

今すぐ始めましょう

Gartner® の Critical Capabilities レポートの軽量トランザクション ユースケースで Google（Spanner）が第 1 位を獲得

運用パフォーマンスについて

エージェントを活用している企業の基盤

未来に向けた青写真

Spanner が評価された理由とは

Google Cloud データベースで次世代のエージェントを強化する

エージェントに運用データを提供

アプリケーションとインフラストラクチャの管理

セキュリティとガバナンス

デモ: ローカルコードからマネージド データへ

サードパーティ エージェントのサポート

次のステップ

2025 年の Spanner: インテリジェントなマルチモデル AI アプリケーションを強化するイノベーション

マルチモデルをサポートする Spanner AI

AI を活用した運用

統合分析: サイロと複雑さを最小限に抑える

シンプルな移行

パフォーマンスと費用の改善

エンタープライズ レベルの安全性の水準を引き上げる

受賞歴と評価

今後の対応

DeNA: Spanner、C4A インスタンスを駆使して世界規模のゲームアプリ『Pokémon TCG Pocket』の安定運用を実現

Spanner の存在が Google Cloud を選んだ最大の理由

「事前分割（Pre-splitting）」の活用で、ローンチ直後の大規模アクセスにも対応

C4A インスタンスはコスパも安定性も優れた理想的な選択肢

Mercado Libre の多面的な Spanner アーキテクチャの概要

2 つの課題: インターネット規模での運用と開発者の速度

Fury: Mercado Libre の開発者ゲートウェイ

Spanner – 汎用性に優れたバックボーン

ピーク時の需要への対応

データをアクションに変える

効果: コスト削減、アジリティ、将来への備え

AI 向けに構築: Spanner 上の次世代アプリケーション

まとめ: 統合されたインテリジェントなデータ基盤

Spanner カラム型エンジン: 運用データの次世代分析を強化

カラム型ストレージとベクトル化実行

Spanner のカラム型ストレージ: ハイブリッド アーキテクチャ

ベクトル化実行: クエリを大幅に加速

BigQuery でさらに向上: 連携クエリの高速化

カラム型エンジンの活用: 分析クエリの高速化

今すぐ Spanner のカラム型エンジンを使い始めましょう。

TimeTree: Spanner への移行でサービスの継続性を確保、ビジネスのさらなる成長を支える土台を確立

ビジネスの順調な拡大に影を落とす 3 つの懸念、その対策として Google Cloud を採用

自動シャーディングを備えた Spanner により、データベース運用の負担が大幅に改善

Spanner の永続的な影響: 2025 ACM SIGMOD Systems Award の受賞

MySQL から Spanner へのアプリの移行がさらに簡単に

Google Cloud Spanner が Gartner® の軽量トランザクション ユースケースで第 1 位に

Forrester の調査で明らかになった Spanner による大きなメリットと費用削減

Unico、Spanner ベクトル検索で最先端の ID テクノロジーを構築

ベクトル検索が Unico のソリューションで効果的に機能

成果の一例

Spanner Graph の一般提供開始のお知らせ

Spanner Graph の新機能

お客様の声

今すぐ Spanner Graph を始めましょう

-シニア スタッフ ソフトウェア エンジニア、Bei Li-プロダクト管理担当ディレクター、Jagdeep Singh

クラウド アプリケーションをパーティショニングして影響範囲を縮小し、グローバルなサービス停止を回避する

影響範囲を制限する

パーティショニングの利点

課題

重要ポイント

2024 年の Spanner: イノベーションの一年

1. マルチモデル: 1 つのデータベースで多くの可能性を実現

2. コスト パフォーマンスの向上

3. Cassandra ワークロードのための新たな環境

4. 生成 AI と Spanner のエコシステム

Iceberg データに高速かつ低レイテンシのサービングプラットフォームが必要である理由

ユニバーサルリバース ETL: すべてのレイクハウスのデータを提供

Gartner® の Critical Capabilities レポートの軽量トランザクションユースケースで Google（Spanner）が第 1 位を獲得

デモ: ローカルコードからマネージドデータへ

サードパーティエージェントのサポート

エンタープライズレベルの安全性の水準を引き上げる

Spanner のカラム型ストレージ: ハイブリッドアーキテクチャ

Google Cloud Spanner が Gartner® の軽量トランザクションユースケースで第 1 位に

-シニアスタッフソフトウェアエンジニア、Bei Li
-プロダクト管理担当ディレクター、Jagdeep Singh

クラウドアプリケーションをパーティショニングして影響範囲を縮小し、グローバルなサービス停止を回避する

2. コストパフォーマンスの向上

6. デベロッパーエクスペリエンス

-グループプロダクトマネージャー Piyush Mathur
-プロダクト管理担当ディレクター Jagdeep Singh

新しいプロキシアダプタの仕組み

ポストフィルタリング

マルチモデルクエリ