Spanner

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

Wed, 24 Jun 2026 01:00:00 +0000

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

エージェント型 AI を導入する企業にとって必要なのは、事後対応型のインテリジェンスシステムから、プロアクティブなアクションシステムへの転換です。これは、必要とされるコンテキストとパフォーマンスを備えたエージェントを構築するとともに、すべての意思決定について説明と監査が可能な、規制当局の要求に対応できるレベルの説明責任を担保するためです。

Google Cloud Next ‘26 では、Agentic Data Cloud でアクションシステムを実現する方法について解説しましたが、まさにこのビジョンの好例となるのが Yahoo のデジタルメディア購入プラットフォームです。Yahoo は Google Cloud と提携し、Google データクラウドのグラフ技術を活用して、Seller Agent デジタルメディア購入プラットフォームを構築しました。Seller Agent は、数週間かかる手動プロセスをわずか数秒に凝縮して、完全に管理されたライブキャンペーンを実行できます。自律システムが厳格な説明責任を維持しながら驚異的なスピードで動作できることを証明するこのシステムは、さまざまな業界で活用できる強力なブループリントとなります。

「Yahoo! の使命は、デジタルの世界を案内する、信頼されるガイドになることです。Google Cloud とのパートナーシップを通して迅速性、透明性、効果、信頼性を確保したエージェント型メディア購入を実現することで、私たちは広告主様に対してもこの約束を果たしていきます。」- Yahoo、収益化責任者、Gabriel DeWitt 氏

このブログでは、エージェント型 AI への移行について詳しく説明し、Yahoo の Seller Agent アーキテクチャがメディア購入におけるスピードと信頼性の課題をいかに解決しているかを検証します。また、このグラフベースのパターンを応用して、皆様の組織で信頼できるアクションシステムを構築する方法もご紹介します。

ケーススタディ: エージェント型メディア購入

長年にわたり、プレミアムデジタル広告キャンペーンのような複雑で価値の高いワークフローでは、人手を介した数週間にわたる引き継ぎ、断片化したスプレッドシート、そして手動の分析が必要とされてきました。Yahoo は、エージェント型 AI を使えば、このタイムラインを劇的に短縮し、わずか数秒でキャンペーンを計画して実行できる可能性があることに着目しました。「手動から自律的な実行へ」というこの飛躍は、運用効率を大幅に改善し、投入した予算をより確実に測定可能な成果へと結びつける大きなチャンスでした。

しかし、リスクの高いワークフローに LLM をただ組み込むだけでは問題は解決しません。もし、リアルタイムの広告在庫や、価格設定ルール、ビジネス上の制約を決定論的に理解できていないエージェントが契約や広告掲載の交渉を行えば、ハルシネーションが生じやすくなり、甚大な損失を招く取引となるおそれがあるからです。信頼できるエージェントプラットフォームには、統計的な推測ではなく、確固たる事実に基づいて行動するためのリアルタイムかつ決定版の情報源が不可欠です。

しかも、「スピード」と「事実へのグラウンディング」は必要とされる条件の半分にすぎません。AI エージェントが実際の予算を動かし始めた瞬間、その動作は規制当局の厳しい監視の対象となります。そして規制当局は、特定の決定がなぜ行われ、どのポリシーが適用されたのかについて即座に説明できることを求めてきます。事後にシステムログをさかのぼって調べるような手法は、自律的な実行を管理する手段としては不適切です。実用できるレベルのアクションシステムには、後付けではなくワークフローに直接組み込まれた、規制当局の要求に対応可能なガバナンスと監査可能性が必要です。

信頼できるアクションシステムのアーキテクチャ

Yahoo! の使命は、デジタル世界を案内する、信頼できるガイドになることです。エージェント型メディア購入は、予算を Yahoo に託し、真の説明責任が果たされることを期待する広告主、代理店、パブリッシャー、そして規制当局に対しても、その約束を広げていくものです。課題は、説明可能、管理可能、監査可能な方法でキャンペーンの実施を自動化することでした。

この課題に対処するため、Yahoo は Google Cloud で実行されるマルチエージェントシステムとして Seller Agent を構築しました。バイヤーのリクエストは、Google Kubernetes Engine（GKE）で実行され、Google の Agent Development Kit（ADK）でオーケストレーションされる計画スーパーバイザーエージェントを介して入力されます。スーパーバイザーは、在庫の検出、オーディエンスのマッチング、予測、価格分析、パッケージの推奨、ガバナンスのレビュー、実行など、各リクエストを専門的なタスクに分解します。エージェントは、オープンな Agent2Agent（A2A）プロトコルを介して連携します。一方、Gemini Enterprise Agent Platform は、エンベディング、予測、グラフ学習のためのモデルをホストします。

しかし真のブレークスルーは、自律的な実行における迅速性と完全な透明性を両立させている「デュアルグラフ基盤」のプラットフォームです。このプラットフォームは、行動に最適化されたナレッジグラフと、記憶と学習を担うコンテキストグラフという、意図的に役割を分離した 2 つの特殊なグラフシステムによって支えられています。

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

Spanner Graph を活用した Yahoo のナレッジグラフは、収益化ビジネスの各要素を相互に関連付けられた運用モデルとして表すことで、エージェントのあらゆる意思決定をビジネスの実態にグラウンディングします。広告サービス、プレースメント、オーディエンスセグメント、広告枠、契約、ガバナンス管理は、それぞれファーストクラスエンティティとして、その相互関係とともにモデル化されます。重要なのは、ポリシーをアプリケーションロジックに埋め込むのではなく、バージョン管理された関係としてグラフ内に直接組み込んでいることです。この設計により、商品、契約上の義務、同意に関する要件、規制上の制約を、単一の統合されたグラフ操作でまとめて評価することが可能になっています。

グラフは、エージェントプラットフォーム全体でセマンティックコントラクトとして機能します。キャンペーンの評価中、エージェントは 1 つのクエリプラン内で、バイヤーの初期要件から対象となるオーディエンスや管理ポリシーまでを横断的に参照できます。Gemini Enterprise Agent Platform のエンベディングは、セマンティック類似性によってこれらのエンティティの情報を拡充し、グラフニューラルネットワークは推論された関係を提供します。これにより、エージェントは単に利用可能な広告枠を取得するだけでなく、広告枠選定の根拠を正確に把握したうえで、あらゆるガバナンス上の制約を確実に遵守できるようになります。

Yahoo のナレッジグラフオントロジー（IAB AdCOM などの業界標準に準拠）

コンテキストグラフ: 監査可能なメモリの作成

エージェント規模での実行が安全なのは、完全な透明性が確保されている場合のみです。その透明性を確保することが、コンテキストグラフの核となる役割です。Seller Agent がアクションを実行するたび、その正確な実行プロセスが BigQuery Agent Analytics プラグインによってキャプチャされます。システムは、未加工のイベントをログに記録するだけでなく、Yahoo の意思決定トレースオントロジーを活用した BigQuery Agent Analytics SDK を使用して、このエビデンスから型付きのクエリ可能なコンテキストグラフを作成し、BigQuery Graph に格納します。

その結果、すべての意思決定ポイント、候補パッケージ、ポリシー評価、スペシャリストエージェントへの委任、実行結果を相互に関連付けた、エビデンスのグラフが出来上がります。このトレースは型付きグラフとして構造化されているため、エージェントの意思決定プロセスを簡単なクエリによって説明することができます。監査人は、元のキャンペーンの概要、割り当てられたすべてのスコア、適用されたポリシーなどの意思決定までのプロセスを即座にトレースできます。これにより、自律的な動作が「不透明なプロセス」から「完全に透明で継続的に改善される意思決定記録」に変わり、絶対的な説明責任を確保するのに役立ちます。

Yahoo のコンテキストグラフオントロジー

人間ができる範囲からエージェントならではの規模へ

このアーキテクチャが実際にどのように機能するのか、具体例として広告キャンペーンの実施を考えてみましょう。従来は計画、販売、運用、コンプライアンスの各部門で数週間を要していた調整作業を、2 つのプロセスを同時進行させることで数秒で完了できるようになっています。

ナレッジグラフに基づくアクションの実行: このパイプラインでは、バイヤーのリクエストからナレッジグラフに基づくキャンペーンの公開まで、直線的に予算を動かしていきます。このプロセスは、以下の 4 つのステップで構成されます。

キャンペーンの概要の送信: バイヤーエージェントは、対象オーディエンス、予算、地域、ビジネス目標を記述したキャンペーン概要を Ad Context Protocol（AdCP）を介して送信します。
ナレッジの検索: Seller Agent は、ナレッジグラフに対してクエリを実行し、関連する広告枠、オーディエンス、契約上の利用可能性、過去のパフォーマンス、管理ポリシーを特定します。
評価とスコアリング: エージェントはこれらの要素を総合的に評価して、メディア購入候補のパッケージを組み立てます。予測モデルが各機会をスコアリングする一方で、ガバナンスエージェントが同意、ブランド保護、規制上の制約を個別に確認します。
承認と実行: パッケージは、ポリシーのしきい値に基づいて自動的に承認されるか、人間による審査のためにエスカレーションされます。承認されるとメディア購入が実行され、配信が開始されます。

コンテキストグラフを使用した監査と学習。実行パイプラインが進行する一方で、この並列ループはシステムの推論プロセスをコンテキストグラフに継続的に記録します。これにより、透明性が確保され、将来のサイクルの改善が可能になります。この監査と学習プロセスには、次の機能があります。

継続的なキャプチャ: 検討されたすべての候補、割り当てられたスコア、適用されたポリシー、ガバナンスの意思決定は、紐付けられた記録としてコンテキストグラフ内で元のキャンペーンセッションにリンクされます。
クローズドループ学習: 配信、アトリビューション、成果のシグナルが届くと、それらが生成元の意思決定に紐付けられ、将来の推奨事項を改善するためのトレーニングデータが作成されます。
即時の説明可能性: 広告主が特定のパッケージが選択された理由や、成果に影響を及ぼしたポリシーについて質問すると、回答がコンテキストグラフに保存され、1 回のクエリでアクセスできます。

これにより、ナレッジ、意思決定、ガバナンス、測定、学習が連携して機能するプラットフォームが実現し、自律的なメディア購入の説明可能性と監査可能性を確保しつつ、継続的な改善を図ることが可能になります。

あらゆる業種に適用できる設計

単なるアドバイザーとしての AI の時代は終わりを迎えつつあります。企業がいま求めているのは、複雑な複数ステップのワークフローを実行できる自律型エージェント、つまり「アクションシステム」です。しかし、規制の厳しい業界では、意思決定の根拠を証明できない場合、AI がもたらすスピードがむしろリスクに変わってしまいます。自律的な実行の主な障壁となるのは、もはやインテリジェンスではなく、信頼性です。

Yahoo と Google Cloud が構築したアーキテクチャは、この問題を解決できる、幅広く適用可能なブループリントを提供します。デジタルメディアの購入におけるボトルネックを解消するために設計されたものではありますが、その基盤となるパターンは、金融取引からサプライチェーンのロジスティクスまで、リスクの高い意思決定を管理するあらゆる業界に適用可能です。エージェントならではのスピードで運用しながら、人間による監督を維持していくために、企業は以下のような新しいアーキテクチャのベースラインを採用する必要があります。

ビジネスの実態に基づく意思決定: 確率モデルだけでエージェントを運用することはできません。ビジネスロジック、有効な契約、コンプライアンスルールを決定論的にマッピングするナレッジグラフによって、エージェントをグラウンディングする必要があります。
監査可能なメモリの構築: 追跡できないものを管理することはできません。エージェントのすべてのアクションをコンテキストグラフに記録し、クエリ可能な不変のレコードを作成して、意思決定の理由や却下された代替案を正確に把握できるようにする必要があります。
オープンな相互運用性の重視: 信頼には透明性が不可欠です。オープンプロトコルと来歴標準を基盤とすることで、エージェントの動作に関する、業界共通の監査可能な枠組みを確立できます。

基盤モデルがコモディティ化するにつれ、企業の競争優位性は変化してきています。長期的に優位性を守る鍵となるのは、デプロイする言語モデルではなく、自社独自のビジネスオペレーショングラフと、統制された履歴データです。同様に、エンタープライズ AI の未来は、単に動作できるシステムではなく、その動作を説明、管理し、責任を負うことができるシステムにあります。

使ってみる

信頼できるアクションシステムを構築する準備はできましたか？まず、Spanner Graph を使用して、エージェントワークフローをビジネスの実態にグラウンディングしましょう。次に、BigQuery Graph を使用して監査可能なメモリを構築すれば、クローズドループ学習と、規制当局の要求に応じられるレベルの説明可能性を実現できます。BigQuery Agent Analytics プラグインと SDK を使用して、これらの運用トレースのキャプチャと分析を今すぐ開始できます。最後に、Ad Context Protocol を確認して、Yahoo のエージェントプラットフォームを支えるオープンコミュニケーション標準をぜひ理解しておきましょう。

- Yahoo、エンジニアリング担当ディレクター、Mikul Bhatt 氏

- Google Cloud、シニアスタッフソフトウェアエンジニア、Bei Li

Spanner Graph アルゴリズムの発表: 接続されたデータに Google グレードのインテリジェンスを提供

Fri, 12 Jun 2026 01:00:00 +0000

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

Google Cloud Next では、Spanner Graph によるグラフアルゴリズムのプレビュー版を発表しました。Google Research の最先端のグラフマイニング機能をデータベースにネイティブに組み込めるようになり、グラフインテリジェンス機能を活用することで、グラフデータから、より迅速で低コストかつ大規模に、貴重な分析情報を導き出すことができます。

不正行為の検出、ソーシャルネットワーク分析、エンティティ解決、医療研究などのユースケースにおいて、データの複雑な関係を明らかにするために、多くの企業がグラフ技術を活用するようになっています。ノード中心性やコミュニティ検出などのグラフアルゴリズムは、こうした構造を分析するために使用される計算手法であり、エンティティ間の接続のパターンや強度を定量化することで機能します。しかし、これまで、グラフアルゴリズムを大規模に実行することは、困難かつリソースを大量に消費するものであり、多くの場合、専用の分析ソリューションに複雑な ETL パイプラインが必要になったり、グラフデータベースのトランザクションパフォーマンスが低下したりするリスクがありました。

Spanner Graph アルゴリズムは、オペレーショナルデータベースのパフォーマンスを損なうことなく、要求の厳しいエンタープライズワークロードに対応できるように設計されています。このアーキテクチャには、以下のような明確な利点があります。

GQL との緊密な統合: ISO Graph Query Language（GQL）を使用してアルゴリズムを直接呼び出し、データ全体で構造分析を実行します。Spanner Graph は、アルゴリズムと標準クエリを順次組み合わせることで、外部エンジンへの複雑なデータ移動を最小限に抑え、アーキテクチャを簡素化し、分析情報取得までの時間を短縮します。
トランザクションにほとんど影響を及ぼさずに TCO を削減: アルゴリズムの実行は専用のコンピューティングリソースで行われるため、本番環境のライブトラフィックに影響を与えることはありません。Spanner はリソースを自動的にプロビジョニングし、Data Boost を介してデータを安全にルーティングするため、カスタム ETL パイプラインを作成する必要はありません。料金は使用した分に対してのみ発生するため、従来のソリューションに見られる運用上のオーバーヘッドや高額なライセンス費用を回避できます。
数十億エッジに及ぶグラフのグローバルな分析情報を数分で取得: スケールとスピードを重視して構築されたエンジンにより、数十億エッジに及ぶグラフに対して数分でアルゴリズムを実行できます。ランダムアクセスに最適化された高密度形式でトポロジをエンコードすることで、大規模なデータセットに対する高性能な構造分析を実現します。

Google Research は、これまでに、グラフマイニングツール（マルチコアクラスタリングなど）に基づく研究論文をいくつか発表しており、ワークショップの開催や、オープンソースプロジェクトのリリースなども行っていますが、こうした機能を Google Cloud のお客様に広く提供するのは今回が初めてです。以下に、グラフアルゴリズムの仕組みと、Spanner Graph での使用方法について詳しく見ていきましょう。

アルゴリズム: 接続されたデータからより深い分析情報を取得

Spanner Graph を初めてリリースしたときの私たちの目標は、Google のスケーラビリティに優れた分散データベースである Spanner 内で、ネイティブなグラフデータベースエクスペリエンスを通じてグラフデータ管理を再構築することでした。Spanner Graph はリレーショナルモデルとグラフモデルを統合し、ISO GQL を使用して接続されたデータをクエリできるようにするとともに、Spanner の既存の表形式、検索、ベクトル機能と相互運用できるようにします。これにより、複雑なデータパイプラインの作成、データの複製といった作業や、セキュリティやガバナンスのリスクの増大を伴うことなく、インテリジェントなアプリケーションを構築できます。

この基盤の上に構築された Spanner Graph アルゴリズムは、接続されたデータからさらに深い分析情報を抽出するのに役立ちます。グラフアルゴリズムは、データ内の関係やつながりを分析し、従来の分析手法では見逃されがちな隠れたパターンや分析情報を明らかにします。今回のリリースにより、接続性を分析することが可能になり、詐欺組織の検出、エンティティ解決のためのクラスタリング、複雑なネットワークにおける障害点の特定、接続されたユーザーの好みに基づく商品の推奨などを実施できるようになります。

Google ではグラフを幅広く使用しています。実際、Google 検索を支える基盤技術である PageRank など、多くの人気アルゴリズムが Google で開発されています。Spanner Graph のネイティブアルゴリズムサポートは、Google の最先端のグラフインテリジェンス機能の一部を Google Cloud のお客様に直接提供するものであり、これにより、データ内の隠れた構造を簡単に発見できる必須グラフアルゴリズムのセットを利用できるようになります。

中心性: 中間中心性、近接中心性、PageRank を使用して、ネットワーク内で最も影響力のある中心的なノードを特定します。
コミュニティ検出: ラベル伝播、相関クラスタリング、モジュール性クラスタリング、弱連結成分、クリーク集約を活用し、接続性の高いエンティティを自動的にグループ化して、隠れたセグメントを明らかにします。
類似性と経路探索: セット間の最短経路を使用して最適なルートを見つけたり、ジャカード、コサイン、共通近傍、全近傍を使用してノードの類似性を測定したりできます。

デベロッパーエクスペリエンスの統合

グラフ全体やサブグラフ、選択したノードとエッジのセットに対して、GQL を使用してグラフアルゴリズムを直接呼び出すことができます。Spanner は統合されたワークフローを提供し、グラフアルゴリズムの実行結果を Spanner Graph に直接書き戻すことができます。これにより、あるオペレーションの出力を次のオペレーションの入力として使用して、アルゴリズムと標準クエリを順番に呼び出せるほか、この結果を Cloud Storage バケットに保存することもできます。

例: 詐欺組織の首謀者を特定する

マネーロンダリング対策のために金融取引を分析するシナリオを考えてみましょう。不正行為者は通常、互いにやり取りする一連の「運び屋」アカウント（マネーロンダリングの中継アカウント）を操作して、集団で不正行為を行います。不正行為対策の専門家は、通常、検出した運び屋アカウントと隠れた運び屋アカウントの間の連携を把握するために、リンク分析やコミュニティ検出といったグラフアルゴリズムを利用します。以下に、Spanner Graph でアルゴリズムとクエリを組み合わせて、不正行為を特定する方法を示します。

ステップ 1: アカウントのコミュニティを特定する（アルゴリズム）まず、モジュール性クラスタリングアルゴリズムを適用して、アカウントをコミュニティにクラスタリングします。次に、この結果で得られた community_id を Spanner Graph 内の Account に直接書き戻します。

code_block: <ListValue: [StructValue([('code', "-- Runs community detection and update results to the graph\r\nEXPORT DATA OPTIONS(\r\n format ='CLOUD_SPANNER',\r\n table = 'Account',\r\n write_mode = 'update_ignore_all'\r\n) AS\r\nGRAPH FinGraph\r\nCALL ModularityClustering(\r\n node_labels => ['Account'],\r\n edge_labels => ['Transfer']\r\n)\r\nYIELD node, cluster\r\nRETURN node.id, cluster AS community_id;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa378a71490>)])]>

ステップ 2: 不審なコミュニティを特定する（クエリ）すべてのアカウントがコミュニティに属するようになったので、GQL クエリを使用して各コミュニティに対して分析クエリを実行して、異常な行動を明らかにできます。たとえば、各コミュニティ内の既知の不正アカウントの総数を確認できます。

code_block: <ListValue: [StructValue([('code', '-- Finds the community with the highest concentration of flagged fraud\r\nGRAPH FinGraph\r\nMATCH (a:Account)\r\nWHERE a.community_id IS NOT NULL\r\n AND a.fraud_flag = TRUE\r\nRETURN a.community_id AS community_id, COUNT(*) AS fraud_count\r\nORDER BY fraud_count DESC;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa378a71310>)])]>

ステップ 3: 影響力を算出して「首謀者」を特定する（サブグラフのアルゴリズム）上記のクエリにより、Community 2 で不正行為が急増していることが明らかになったとします。このステップでは、グラフをフィルタリングして、その特定のコミュニティのアカウントのみを抽出し、PageRank アルゴリズムを実行して、そのグループ内の中心的な首謀者を特定します。

code_block: <ListValue: [StructValue([('code', "EXPORT DATA OPTIONS(\r\n format = 'CLOUD_SPANNER',\r\n table = 'Account',\r\n write_mode = 'update_ignore_all' \r\n) AS\r\n-- Specifies a suspicious subgraph\r\nGRAPH FinGraph\r\nMATCH (n:Account {community_id: 2})\r\nRETURN n\r\nFULL UNION ALL\r\nMATCH -[e:Transfer]->\r\nRETURN e\r\nNEXT\r\n-- Runs PageRank \r\nCALL PER() PageRank(max_iterations => 20) \r\nYIELD node, score\r\nRETURN node.id, score AS pagerank_score;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa378a71190>)])]>

ステップ 4: ターゲットを調査する（クエリ）Community 2 のアカウントに pagerank_score が付与されたことで、最も中心的なアカウントを特定して、その首謀者が最近どこに資金を移動させたかを即座に追跡するクエリを作成できます。

code_block: <ListValue: [StructValue([('code', "-- Finds the top scorer (ringleader) and trace their money\r\nGRAPH FinGraph\r\nMATCH (ringleader:Account {community_id: 2})\r\nORDER BY ringleader.pagerank_score DESC\r\nLIMIT 1\r\nWITH ringleader\r\nMATCH (ringleader)-[e:Transfer]->{1, 5}(receiver:Account)\r\nWHERE e.ts > '2025-12-01'\r\nRETURN ringleader.id AS ringleader_id, receiver.id AS receiver_id, e.amount, e.ts;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa378a71550>)])]>

Spanner Graph では、標準の GQL クエリと高性能なアルゴリズムを組み合わせることができるため、オペレーショナルデータベースと外部分析エンジン間でデータをやり取りする必要がなくなります。この統合アプローチにより、データアーキテクチャが大幅に簡素化され、分析情報を取得するまでの時間が短縮されます。

業界のリーダーからの信頼

DaVita、Yahoo!、SoundCloud、WPP といったお客様が、すでに Spanner Graph アルゴリズムを活用して、極めて複雑なデータの課題解決に取り組んでいます。

「当社の Patient 360 イニシアチブに Spanner Graph を活用することで、複雑な医療データを一つの統合ビューに集約できるようになりました。コミュニティ検出や中心性といったネイティブグラフアルゴリズムが追加されたことは大きな進歩であり、患者ネットワーク内の深い分析情報をより迅速かつ大規模に発見できるようになりました。これらのフルマネージド機能により、当社のチームは複雑なデータパイプラインの管理という運用上の負担を負うことなく、患者ケアのイノベーションの推進に注力できます。」- DaVita Kidney Care、チーフエンタープライズアーキテクト、Sam Ghosh 氏

「Yahoo を象徴する消費者向けサービスをグローバル規模で運用するには、数十億のユーザープロファイルを一つのリアルタイムビューに統合する必要があります。当社の Unified User Profile（UUP）は、Spanner Graph によって一つのグラフとしてモデル化されており、これまで分散していたシステムを信頼できる一元的な情報源として統合しています。また、Spanner にフルマネージドのグラフアルゴリズムが追加されたことで、大規模なパーソナライズを実現する能力がさらに増強されました。コミュニティ検出や PageRank などのアルゴリズムを活用してオーディエンスのセグメンテーションをより深く行い、プラットフォーム全体でより関連性が高く魅力的なユーザーエクスペリエンスを提供できるようになりました。」 - Yahoo、エンジニアリング担当ディレクター、Chris James 氏

「190 か国以上、4,000 万人以上のアーティストによる 5 億曲以上の楽曲を擁する SoundCloud は、新進気鋭のアーティストが自分のサウンドを見つけたり、隠れた名曲を発見したり、音楽文化をリアルタイムで形成したりする場所です。当社は長年にわたり、グラフアルゴリズムをバッチモードで実行してきましたが、数十億エッジに及ぶ巨大な音楽グラフを分析するために、カスタムクラスタで数時間かかることもよくありました。Spanner Graph アルゴリズムの登場は、まさにゲームチェンジャーです。当社が必要とする大規模なスケーラビリティを得られるだけでなく、複雑なカスタム Python ワークフローからフルマネージドサービスに移行することもできます。特に重要なのは、クリエイターハブの特定やレコメンデーションの改善といったユースケースにおいて、最新のデータに対してグラフアルゴリズムを実行できるようになったことです。複雑な ETL パイプラインを必要とせず、Spanner で実行されている低レイテンシのトランザクションワークロードに影響を与えることもありません。」 - SoundCloud、エンジニアリング - データ基盤担当バイスプレジデント、Sergey Chekanskiy 氏

「私たちは、Open Intelligence（当社の基盤となるインテリジェンスレイヤ）に高度なグラフアルゴリズムを活用することを切望していました。Open Intelligence は、クライアント、パートナー、WPP からの数兆ものライブデータポイントを、プライバシーを最優先にしながら安全に接続するものであり、現在は WPP のエージェント型マーケティングプラットフォームである WPP Open に統合され、その基盤を支えています。数十億ものエンティティにわたる複雑な関係性を即座に探索し、計画、モデリング、試験運用を推進するためには、詳細なグラフ走査、構造的パターン認識、高度なアルゴリズムに対するネイティブなサポートが必要となります。Spanner Graph のアルゴリズムサポートは、運用上のオーバーヘッドや高額なライセンス費用を伴わずに、極めて困難なグラフ分析の問題に取り組むためのパフォーマンスとスケーラビリティを提供してくれます。」 - WPP、データ＆インテリジェンス担当戦略責任者、Rob Marshall 氏

よりインテリジェントなアプリケーションの構築

Spanner Graph でアルゴリズムがネイティブにサポートされるようになったことで、基本的な関係性の探索にとどまらず、最新のトランザクションデータに対して、詳細な構造分析を直接実行できるようになりました。定番のグラフアルゴリズムを大規模に適用することで、エンタープライズアプリケーションに新たな機能をもたらすことができます。

不正行為の事前検出とマネーロンダリング対策: コミュニティ検出（モジュール性クラスタリングなど）を使用して、接続された運び屋アカウントを自動的にグループ化することで、詐欺組織を特定します。その後、中心性（PageRank など）を適用して、違法な資金の流れを統率している首謀者を特定します。
Customer 360 とエンティティ解決: ジャカードなどの類似性関数や、ラベル伝播などのコミュニティ検出を使用して、断片化されたクロスチャネルデータを単一の正規プロファイルに統合します。これらのプロファイルは、各ノードに対して PageRank などのトポロジ特徴を生成することで、ダウンストリームの ML トレーニング用にさらに強化できます。
自律的なネットワーク運用とデジタルツイン: IT や通信インフラストラクチャをデジタルツインとしてモデル化し、類似性や経路探索（セット間の最短経路など）を使用して、重大な脆弱性をプロアクティブに特定し、連鎖的な障害を予測します。
高度にパーソナライズされたプロダクトレコメンデーション: 基本的な購入履歴にとどまらず、より広範にユーザー行動を分析します。類似性アルゴリズム（共通近傍など）を使用してエンティティ間の嗜好の重複を特定し、さらに、中心性（パーソナライズされた PageRank など）を使用することで、それらのグループにとって最も関連性の高いレコメンデーションを提示します。
レジリエンスに優れたサプライチェーンとロジスティクス: 中心性（中間中心性など）を使用して、過度に依存している物流センターを特定し、経路探索を使用して、障害発生時に効率的な代替ルートを即座に計算することで、サプライチェーンを隠れたボトルネックから保護します。
サイバーセキュリティの脅威ハンティングと影響範囲分析: コミュニティ検出（相関クラスタリングなど）を適用して異常なマシン通信を特定し、経路検出を使用して攻撃者の正確なラテラルムーブメントと影響範囲を追跡することで、脅威ハンティングを加速します。
顧客離れの予測分析: コミュニティ検出を使用して結束の固いサブスクライバーグループを特定し、連鎖的な顧客離れを防ぎます。そのうえで、中心性を適用して影響力の大きいコアメンバーを特定し、離脱が拡大する前に定着を図る施策を実施します。

使ってみる

Spanner Graph アルゴリズムは、Spanner の Enterprise エディションと Enterprise+ エディションでサポートされています。詳細については、ドキュメントをご覧いただくか、こちらの Codelab をお試しください。また、こちらの動画では、Spanner Graph でのグラフアルゴリズムのサポートについて概要を説明しています。

- シニアスタッフソフトウェアエンジニア、Bei Li

-Google Research、グラフマイニング担当バイスプレジデント兼 Google Fellow、Vahab Mirrokni

運用から分析へ: Spanner Graph と BigQuery Graph による統合ソリューション

Fri, 24 Apr 2026 01:00:00 +0000

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

データ内の関係性を理解することは、隠れたインサイトを発見し、インテリジェントなアプリケーションを構築するために不可欠です。しかし、運用（OLTP）と分析（OLAP）のグラフワークロードを管理するには通常、切り離されたデータベースに悪戦苦闘し、脆弱なデータパイプラインを構築し、複雑なインテグレーションを管理することになります。このような断片化により、データサイロが生まれ、運用上のオーバーヘッドが増加し、スケーラビリティが制限されます。

本日は、Spanner Graph と BigQuery Graph を活用した、グラフデータベースと分析の統合ソリューションをご紹介します。このソリューションは、デプロイ方法に関する推奨ブループリントと、代表的なユースケースのスタートガイドの 2 つの部分で構成されています。このブログ記事では、ソリューションの構成要素を確認し、最も一般的なユースケースの概要を説明します。また、実際にソリューションをデプロイしたお客様の声もご紹介します。

運用ワークロード向けの Spanner Graph

Spanner Graph は、グラフ、リレーショナル、検索、生成 AI の各機能を 1 つのデータベースに統合することで、グラフデータマネジメントを刷新します。これは Spanner の特徴である無制限のスケーラビリティ、高可用性、強整合性を基盤としています。

Spanner Graph により、以下のことが可能になります。

テーブルからグラフへの統合マッピング: 既存の Spanner リレーショナルテーブル上に直接グラフを定義し、データを複製することなく、運用データをグラフとして表示およびクエリできます。
相互運用可能なグラフクエリとリレーショナルクエリ: ISO 規格の Graph Query Language（GQL）インターフェースを活用して直感的なパターンマッチングを行い、GQL と SQL を 1 つのクエリに組み合わせてグラフデータと表形式データをまとめて走査できます。
高度な検索と AI のインテグレーション: 組み込みのベクトル検索、全文検索、Vertex AI のインテグレーションを利用して、セマンティックな意味でデータを取得し、データベース内で直接インテリジェントアプリケーションを強化します。

お客様はすでに、Spanner Graph を使用して高スループット、低レイテンシのアプリケーションを強化しており、数百万のエンティティにわたる ID 解決、広大で複雑な環境にわたる依存関係の特定、データリネージ、Customer 360 のユースケース、リアルタイムの不正行為検出の強化などに取り組んでいます。

「Open Intelligence は、クライアント、パートナー、WPP からの数兆ものライブデータポイントをプライバシー最優先で安全に接続する、当社の基盤となるインテリジェンスレイヤです。現在では、WPP のエージェント型マーケティングプラットフォームである WPP Open に統合され、支えています。Google Cloud の Spanner Graph を基盤とする Open Intelligence は、AI を活用したマーケティングにおける大きな進歩であり、BigQuery Graph で分析グラフワークロードのユースケースを拡大できることを嬉しく思います。」- WPP、データ＆インテリジェンス担当戦略責任者、Rob Marshall 氏

分析ワークロード向けの BigQuery Graph

Spanner Graph はアクティブなオペレーションを処理しますが、真に大規模な分析では、数十億のノードとエッジの関係を探索してパターンを特定し、過去のデータをクエリする必要があります。SQL でデータベースとデータウェアハウスにそれぞれ異なるツールが使用されるのと同様に、グラフでもワークロードごとに専用のツールが必要です。そこで、BigQuery Graph を構築しました。

BigQuery Graph は、接続されたデータ分析をデータウェアハウスに直接取り込みます。既存の BigQuery データをグラフスキーマにマッピングし、SQL または GQL でクエリを実行することで、データを移動することなく、膨大なデータセットに隠された関係を明らかにできます。

主な機能は次のとおりです。

テーブルからグラフへの統合マッピング: 既存の BigQuery テーブルをグラフに即座にマッピングし、ETL パイプラインを構築することも、データを一切移動させることもなく、データウェアハウスに隠された関係を明らかにします。
相互運用可能なグラフクエリとリレーショナルクエリ: GQL の表現力豊かなパターンマッチングを大規模な過去のデータセットに適用し、SQL と GQL を 1 つのクエリに組み込んで、使い慣れたデータウェアハウスと強力なグラフ走査を組み合わせることができます。
高度な検索と AI のインテグレーション: BigQuery AI とのネイティブインテグレーションを利用して予測分析を行うとともに、組み込みのベクトル検索、全文検索、地理空間機能を使用して、数十億件のレコードにわたって接続された情報を見つけます。

統合ソリューションとしての Spanner Graph と BigQuery Graph

各プラットフォームは単体でも強力ですが、一緒にデプロイすることで真価を発揮します。運用環境と分析環境を接続することで、データサイロを排除し、データベースのパフォーマンスを損なうことなく分析情報を得るまでの時間を短縮できます。

「Spanner Graph を使用することで、Yahoo はグローバル規模で接続された基盤にデータを統合し、エージェント型広告プラットフォーム全体でリアルタイムのインテリジェントな意思決定を可能にしています。これにより、AI 主導のアプローチを強化し、最大規模のデジタル広告エコシステムを推進しています。Spanner Graph と BigQuery Graph を連携させることで、より深い分析と予測機能が可能になり、将来のイノベーションを推進できることを楽しみにしています。」- Yahoo、消費者向け収益化責任者、Gabriel DeWitt 氏

例として、金融詐欺の検出について考えてみましょう。アプリケーションは Spanner Graph を使用して不審な接続を即座に特定し、決済時にトランザクションをブロックできます。一方、BigQuery Graph はペタバイト規模の過去のトランザクションデータを分析して、詐欺行為を引き起こした複雑で長期的な詐欺組織を暴きます。

以下では、これら 2 つのエンジンを統合してエンドツーエンドのグラフワークフローを作成する方法について説明します。

1）グラフクエリとスキーマの統合エクスペリエンス

このソリューションの主な利点は、両方のプラットフォームで一貫したスキーマと GQL が共有されることです。共通の言語を使用することで、開発時間を短縮し、コンテキスト切り替えの摩擦を最小限に抑えることができます。

たとえば、特定のアカウントを起点としてつながっている可能性のある詐欺組織をリアルタイムで検出するには、次の Spanner Graph クエリを使用します。

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

同じ分析を実行して、過去の詐欺組織に関与したすべてのアカウントを特定する場合、BigQuery Graph クエリは、以下のようにほぼ同じです。

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

2）Data Boost を使用して BigQuery Graph で Spanner データをクエリする

Data Boost を使用すると、トランザクションワークロードのパフォーマンスに影響を与えることなく、BigQuery から Spanner Graph データを直接クエリできます。これにより、データを移動することなく、Spanner のリアルタイムの運用データと BigQuery の過去の分析データを組み合わせた「仮想グラフ」を構築できます。

たとえば、Spanner Graph のリアルタイムの アカウント ノードとユーザー ノードを、BigQuery の過去のログインエッジと組み合わせて、さまざまなデバイスにわたる不審なログインパターンを特定できます。

これを行うには、まず CREATE EXTERNAL SCHEMA ステートメントを使用して BigQuery を Spanner に接続します。

code_block: <ListValue: [StructValue([('code', "CREATE EXTERNAL SCHEMA spanner\r\nOPTIONS (\r\n external_source = 'google-cloudspanner:/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE',\r\n location = 'LOCATION'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3736c3fd0>)])]>

次に、Spanner と BigQuery の両方のテーブルを組み込んだ BigQuery Graph を定義します。

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROPERTY GRAPH bigquery.FinGraph\r\n NODE TABLES (\r\n -- Account and Person are stored in Spanner,\r\n -- made available in BigQuery through the `CREATE EXTERNAL SCHEMA` statement.\r\n spanner.Account KEY (account_id),\r\n spanner.Person KEY (person_id),\r\n -- Media is stored in BigQuery.\r\n bigquery.Media KEY (media_id)\r\n )\r\n EDGE TABLES (\r\n -- Transfers and Owns are stored in Spanner.\r\n spanner.Transfers AS Transfers\r\n KEY (transfer_id)\r\n SOURCE KEY(account_id) REFERENCES Account\r\n DESTINATION KEY(target_account_id) REFERENCES Account,\r\n spanner.Owns AS Owns\r\n KEY (person_id, account_id)\r\n SOURCE KEY(person_id) REFERENCES Person\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n -- LogIn is stored in BigQuery.\r\n bigquery.LogIn AS LogIn\r\n KEY (login_id)\r\n SOURCE KEY(media_id) REFERENCES Media\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3736c3340>)])]>

最後に、BigQuery Graph でクエリを実行して、Spanner（accounts、users、transfers、owns）と BigQuery（logins、devices）の両方のデータにアクセスし、不審なログインパターンを特定します。

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(owner:Person)-[:Owns]->\r\n (:Account)<-[login:LogIn]-\r\n (media:Media {blocked: true})\r\nRETURN TO_JSON(p) AS full_path\r\nORDER BY login.time\r\nLIMIT 20;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3736c3f10>)])]>

3）リバース ETL を使用して BigQuery データを Spanner Graph にエクスポートする

分析データを Spanner に戻して低レイテンシのリアルタイムクエリを実行する必要がある場合は、リバース ETL を使用できます。パイプラインを追加する必要はありません。たとえば、BigQuery から Spanner Graph に過去のデバイスデータ（IP アドレス、デバイス ID）をインポートして、リアルタイムの不正行為検出オペレーションを強化できます。

code_block: <ListValue: [StructValue([('code', 'EXPORT DATA\r\n OPTIONS (\r\n uri = \'https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE\',\r\n format=\'CLOUD_SPANNER\',\r\n spanner_options="""{ "table": "Media" }"""\r\n ) AS \r\nSELECT * FROM Media;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3736c3a60>)])]>

4）グラフデータを可視化する

接続されたデータの可視化は、分析、データ探索、調査の要です。Spanner Studio とBigQuery Studio（近日提供開始予定）を使用すると、使い慣れた環境から離れることも、外部ツールを設定することもなく、グラフデータを即座に可視化できます。プログラムによる詳細なデータ探索では、Spanner Graph ノートブックと BigQuery ノートブックを利用して、既存のデータサイエンスワークフロー内でクエリ結果を直接レンダリングすることもできます。

5）グラフ可視化パートナーとのインテグレーション

Spanner Graph と BigQuery Graph は、主要なグラフ可視化パートナーとも統合されており、包括的な探索ツールスイートを提供しています。

Kineviz: GraphXR を介して最先端の可視化と高度な分析を組み合わせます。
Graphistry: GPU アクセラレーションを活用したビジュアルグラフインテリジェンスプラットフォームを使用して、大規模なデータセットから重要な分析情報を抽出します。
G.V(): 高パフォーマンスの可視化とノーコードのデータ探索のための、手軽にインストールできるクライアントを提供します。
Linkurious: Linkurious Enterprise プラットフォームを介して、大量の接続されたデータ内の脅威を検出して分析します。

グラフに関するあらゆるニーズに対応する統合ソリューション

Spanner Graph と BigQuery Graph を組み合わせることで、さまざまなユースケースにわたる運用ニーズと分析ニーズに対応する統合ソリューションが実現します。

分野	Spanner Graph	BigQuery Graph
金融サービス	通常とは異なる、不審なトランザクションを即座にブロックします。	複雑で長期的な詐欺組織を検出します。
小売業、e コマース	パーソナライズされたおすすめの商品情報をその場で提案します。	膨大な購入履歴を分析して需要を予測します。
サイバーセキュリティ	アクティブな脅威を隔離し、攻撃の発生源を即座に追跡します。	過去の脆弱性をモデル化して防御を強化します。
医療	医療現場で臨床判断支援システムを強化します。	公衆衛生の傾向と病気のリスク要因を分析します。
サプライチェーン	世界中で商品を追跡し、チームに中断の発生を即座に知らせます。	システム上のボトルネックを特定し、今後のルーティングを最適化します。
通信	ネットワークのデジタルツインを作成して、異常の検出と根本原因の分析をリアルタイムで行います。	トラフィックパターンを大規模に分析して、将来のインフラストラクチャアップグレードを計画します。

Spanner Graph と BigQuery Graph を今すぐ使ってみる

Spanner Graph と BigQuery Graph を組み合わせることで、運用と分析の両方のニーズを満たす統合されたグラフデータマネジメントを実現できます。

運用ワークロード向けの Spanner Graph のユースケースと設定ガイド、分析ニーズ向けの BigQuery Graph の概要と作成ガイドをご覧ください。この組み合わせを最大限に活用する方法をご体験いただくには、統合ソリューションガイドをご覧になり、Codelab をお試しください。

- スタッフソフトウェアエンジニア、Bei Li

- プロダクトマネージャー、Candice Chen

Spanner Omni を発表：あらゆるインフラで Google のイノベーションを活用

Wed, 22 Apr 2026 03:50:00 +0000

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

本日、Google Cloud は Spanner Omni のプレビュー版を発表しました。Spanner Omni は、Google Cloud 外でも利用可能なダウンロード版の Spanner であり、業界を牽引する分散データベース機能をさらに拡張するものです。これにより、企業は Spanner を自社のデータセンターや複数のクラウド、あるいはノート PC 上で実行できるようになります。事実上無制限の水平スケーラビリティ、高可用性、強力な整合性、エンタープライズグレードのセキュリティ、そしてマルチモデル機能を AI 対応アプリケーションが稼働するあらゆる場所で活用可能です。

Spanner Omni が重要である理由

10 年以上前、Google Cloud は Spanner によって分散 SQL 市場を切り拓きました。Spanner は、NoSQL の水平スケーラビリティと、従来のリレーショナルデータベースが持つ ACID（原子性、整合性、独立性、永続性）準拠および強力な整合性を兼ね備えた、まさに理想的なソリューションを提供しました。それ以来、Spanner は SQL、グラフ、キーバリュー、全文検索、ベクトル検索、そしてカラム型エンジンによる分析処理を統合した、相互運用可能なマルチモーダルデータベースへと進化を遂げました。この進化は AI 時代に必要な機能を提供するとともに、お客様のワークロードの簡素化と統合を可能にします。こうした進化は、すでに多くのお客様に大きな価値をもたらしています。

お客様の IT 環境は、パブリッククラウドやハイブリッドクラウド、あるいはネットワークから隔離されたよりセキュアな環境まで多岐にわたります。Spanner Omni は、現代企業の多様なニーズに応えるべく、お客様が運用するあらゆる環境へ柔軟に導入いただけます。具体的には、以下のニーズに対応します。

ビジネスの継続性： ミッションクリティカルなワークロードには、クラウドの枠を超えた、真にレジリエントで高可用なアーキテクチャが求められます。ビジネス状況や世界情勢の変化によりクラウドの利用方針を変更せざるを得ない場合でも、これらのワークロードは稼働を続ける必要があります。
規制遵守： 金融サービスなど、規制の厳しい業界のお客様は、データ主権などの規制要件を満たす必要があります。コンプライアンス維持のために大規模なオンプレミス環境を運用している企業も多い一方で、AI エージェント時代に向けたモダナイズも急務となっています。
アプリケーションのポータビリティ： SaaS プロバイダーや独立系ソフトウェアベンダー（ISV）にとって、マルチクラウドやプライベートデータセンターなど、お客様が運用するあらゆる環境でサービスを提供できることは、ビジネス成長の鍵となります。イノベーションのための高度な機能を維持しつつ、開発や運用のオーバーヘッドを最小限に抑えるため、環境を問わず一貫したテクノロジースタックが求められています。

Spanner Omni の紹介

Spanner Omni は、フルマネージドサービスである Spanner と同等のコア機能を提供し、かつ必要な場所に自由にデプロイできる柔軟性を備えています。仮想マシン（VM）や Linux コンテナから Kubernetes クラスターまで、柔軟な構成オプションに対応しています。また、オンプレミス、マルチクラウド、マルチリージョンに加え、適切なレイテンシを維持できるハイブリッド環境、さらにはエアギャップ環境やネットワーク接続環境など、多様な形態で運用いただけます。スケーラビリティにおいても、単一のサーバーから数千台規模のクラスターまで柔軟に拡張可能です。Google Cloud 内部のベンチマークテストでは、Spanner Omni が単一リージョンのデプロイにおいて、ペタバイト規模のデータに対する秒間数百万件のクエリ（QPS）処理が実証されています。

Spanner Omni の特徴

Spanner Omni は新しい可能性を切り拓きます。初期段階で導入いただいたお客様との取り組みを通じて、Spanner Omni の活用における 3 つの主要なアーキテクチャをご紹介します。

ハイブリッドおよびマルチクラウドのレジリエンス： Google Cloud 上の Spanner マネージドサービスをメインデータベースとして運用し、セカンダリクラウドやオンプレミスのデータセンターに Spanner Omni をホット / コールドフェイルオーバーサイトとしてデプロイする構成です。このプライマリ / セカンダリアーキテクチャはビジネスにおける確かな備えとなり、特に規制の厳しい業界において、ディザスタリカバリや事業継続計画（BCP）の要件を満たすのに役立ちます。また、特定の法域でデータ主権が求められ、Google Cloud のデータセンターが 1 つしか存在しない地域においても、マルチリージョンでの高可用性（HA）構成を構築可能です。
環境を問わない統一された技術スタック： マルチクラウドやハイブリッド戦略をとる組織にとって、Spanner Omni は環境を問わず「一度書けばどこでも実行できる」アプリケーション開発体験を提供します。データベース層を標準化することで、チームは運用のオーバーヘッドを大幅に削減し、最先端のデータベース技術を活用しながら、あらゆる環境で真のアプリケーションポータビリティを実現できます。
オンプレミス環境のモダナイズ： 大規模なオンプレミス資産を持つ組織や自社管理を重視する組織も、クラウドネイティブなイノベーションを活用できるようになります。Spanner Omni により、既存のハードウェアインフラストラクチャ上で、スケーラビリティの確保、高可用性、グローバルな整合性などを実現する Spanner の革新的な技術を用い、マルチモデル機能を備えた次世代 AI アプリケーションの構築や刷新が可能になります。

Spanner Omni を支える技術

私たちのビジョンはシンプルです。コンピューティングリソースとデータベース用に利用可能なローカルファイルシステムがあれば、どこでも Spanner Omni を実行できるようにすることです。これを実現するために、一連のイノベーションにより、Google Cloud 独自のインフラへの依存を解消しました。Paxos コンセンサス、自動シャーディング、同期レプリケーションといった Spanner のコア技術を継承しつつ、Colossus や TrueTime といった Google 独自のコンポーネントを、創造的で革新的な新しいソリューションへと置き換えています。

あらゆる場所での分散ストレージを実現するため、Spanner Omni は Google の分散ファイルシステムである Colossus への依存を解消し、Colossus 相当の機能を提供する抽象化レイヤーを導入しました。このレイヤーは接続されたローカルファイルシステムにデータを書き込み、ネットワーク経由で他のノードから利用可能にします。ソフトウェアがシャードの分割と再配置を自動的に処理し、利用可能なすべてのサーバー間でストレージのバランスを整えることで、最適なパフォーマンスを確保します。Spanner Omni のファイルレイヤーは Colossus そのものではありませんが、ほとんどのワークロードにおいて、Spanner マネージドサービスに匹敵するパフォーマンスを発揮します。

また、原子時計と GPS を使用して世界規模で時間を同期させる、Spanner の象徴的な技術の一つであるTrueTime も再構築しました。Spanner Omni のために開発したソフトウェアベースの代替ソリューションは、Google Cloud 上の TrueTime と同様に、Spanner Omni がデプロイされたサーバー間において、誤差範囲が限定された極めて信頼性の高い時刻同期を提供します。Spanner は強力な外部整合性を実現するために時刻同期に依存していますが、時刻の不確実性に起因する待機時間を他のデータベース処理とオーバーラップさせて実行する機能を備えています。この仕組みにより、実際の TrueTime が提供するよりも緩やかな不確実性の範囲を許容することが可能です。TrueTime はこの柔軟性を活かし、Spanner の可用性やパフォーマンスを損なうことなく、多種多様な環境における正確な時刻管理を実現しています。

aside_block: <ListValue: [StructValue([('title', 'お客様からのコメント'), ('body', <wagtail.rich_text.RichText object at 0x7fa378e077f0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

アクセス方法

Spanner Omni のデベロッパーエディションは、本日よりプレビュー版として公開（ダウンロード）しています。このエディションには、非商用および非本番環境での開発やテストに適した Spanner のコア機能が含まれています。エンタープライズ向けセキュリティ機能は含まれていませんが、次なるプロジェクトのサンドボックスとして最適です。フル機能を備えた商用エディションへの早期アクセスについては、https://cloud.google.com/consulting/spanner-omni までお問い合わせください。

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 0x7fa378d83e20>)])]>

高速化: このクエリは、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 0x7fa378d83490>)])]>

高速化: このクエリは、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 0x7fa378d83040>)])]>

高速化: このクエリは、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 0x7fa378357640>)])]>

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

クエリ 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 0x7fa37384efa0>)])]>

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

今すぐ 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 0x7fa378a61160>), ('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 0x7fa37812d130>), ('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 0x7fa37a713a90>), ('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 0x7fa378492940>), ('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 0x7fa37a99ac70>), ('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 0x7fa3786870a0>)])]>

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 0x7fa3782b38b0>), ('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

Spanner

グラフ技術を活用した信頼できるエージェント プラットフォームの構築: Yahoo の事例

ケーススタディ: エージェント型メディア購入

信頼できるアクション システムのアーキテクチャ

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

コンテキスト グラフ: 監査可能なメモリの作成

人間ができる範囲からエージェントならではの規模へ

あらゆる業種に適用できる設計

使ってみる

Spanner Graph アルゴリズムの発表: 接続されたデータに Google グレードのインテリジェンスを提供

アルゴリズム: 接続されたデータからより深い分析情報を取得

デベロッパー エクスペリエンスの統合

業界のリーダーからの信頼

よりインテリジェントなアプリケーションの構築

使ってみる

運用から分析へ: Spanner Graph と BigQuery Graph による統合ソリューション

運用ワークロード向けの Spanner Graph

分析ワークロード向けの BigQuery Graph

統合ソリューションとしての Spanner Graph と BigQuery Graph

グラフに関するあらゆるニーズに対応する統合ソリューション

Spanner Graph と BigQuery Graph を今すぐ使ってみる

Spanner Omni を発表：あらゆるインフラで Google のイノベーションを活用

Spanner Omni が重要である理由

Spanner Omni の紹介

Spanner Omni を支える技術

アクセス方法

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 のカラム型エンジンを使い始めましょう。

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

信頼できるアクションシステムのアーキテクチャ

コンテキストグラフ: 監査可能なメモリの作成

デベロッパーエクスペリエンスの統合

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

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

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

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

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

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

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

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

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

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