ライフスタイル

Google Cloud、Spanner queues の一般提供を発表：メッセージキューをデータベーストランザクションに組み込み、AIエージェントの信頼性向上を狙う

Google Cloud は Spanner queues の一般提供開始を発表しました。メッセージの作成をデータベーストランザクションの一部とすることで、AIエージェントの「状態」と「アクション」が食い違う問題の解決を目指しています。本記事では公式の説明、主な機能、一般読者にとっての意味を整理します。

読了目安 10 分

Google Cloud、Spanner queues の一般提供を発表：メッセージキューをデータベーストランザクションに組み込み、AIエージェントの信頼性向上を狙う
画像：Mokaair (Original editorial artwork)

Google Cloud が発表した内容

Google Cloud は公式ブログで、Spanner queues の一般提供（general availability、つまりプレビュー版ではなくなったこと）を発表しました。Spanner は Google Cloud のデータベースサービスです。同社の説明によると、Spanner queues は Spanner データベースに直接組み込まれたネイティブのトランザクション型メッセージング機能です。記事にはプロダクトマネージャーの Nitin Sagar 氏とエンジニアリングマネージャーの Matthew Mucklo 氏が署名しています。

ここでいう「キュー」は、処理待ちの作業を並べたリストのことです。「トランザクション」はひとまとまりのデータ変更で、すべて完了するか、すべて取り消されるかのどちらかになります。Google Cloud によると、Spanner queues を使う場合、メッセージの作成はトランザクション内の書き込みの一つにすぎません。言い換えれば、AIエージェント（返金や在庫管理などの作業を自律的に実行するAIプログラム）による自身の状態の更新と、「次に何をするか」という指示は、同じ一つの処理として書き込まれます。その結果、すべて成功するか、すべて無効になるかのどちらかになります。

解決を目指す課題：状態とアクションの不一致

Google Cloud の指摘によると、AIエージェントはデータベースに内部状態を記録しつつ、別のメッセージングやイベントキューのシステムを通じて非同期アクション（すぐに完了を待つ必要がなく、後で実行される作業）を送ることが多いとされます。同社は、2つのシステムがそれぞれ別にコミットすると、トランザクションの一貫性が損なわれると考えています。

Google Cloud は2つの失敗パターンを挙げています。1つは、データベースは更新されたのにアクションが送られず、エージェントが「決めたのに実行しなかった」ケースです。もう1つは、アクションは送られたのにデータベースの更新がロールバック（取り消し）され、エージェントが無効な状態に基づいて行動してしまうケースです。同社によると、開発者はこれまで outbox パターン、冪等性レイヤー（同じアクションが繰り返し実行されても結果が重複しないようにする仕組み）、突合プログラムといった補完策を自前で構築する必要がありました。同社はこれを重い信頼性の負担だと表現しています。

従来の方法と Spanner queues の比較（いずれも Google Cloud 公式ブログの説明に基づき整理）
観点従来の方法（Google Cloud の説明による）Spanner queues（Google Cloud の説明による）
状態とメッセージデータベースとメッセージングシステムが別々にコミット同一トランザクション内でまとめてコミットまたはまとめて失敗
遅延とスケジュール外部の cron スケジューラー（定時にジョブを実行するツール）やポーリング（定期的に状態を問い合わせる方式）が必要メッセージは即時配信も、将来の時点への配信予約も可能
信頼性の補強outbox、冪等性レイヤー、突合プログラムを自前で構築少なくとも1回の配信と最大1回の確認応答を保証し、これにより厳密に1回の処理を実現可能
監視方法メッセージの保管がブラックボックスになりがち標準 SQL（データベースを操作するための標準的な言語）でキューテーブルを照会

主な機能のポイント

  • 判断とエンキュー（キューへの登録）のアトミック化：Google Cloud によると、エージェントは同一トランザクション内でメモリや状態を更新し、タスクを他のエージェントに引き渡すことができます。両者は不可分に一緒に完了します。
  • スケジュールと遅延：同社によると、遅延リトライ、定期チェック、SLA（サービスレベルの約束）エスカレーションのタイマーなどを状態更新と一緒に書き込めます。
  • 人による承認とタイムアウト：Google Cloud の例では、上長の承認を待つ間、承認待ちの状態を記録し、72時間後にエスカレーションするよう予約できます。上長が早めに承認すれば、同じトランザクション内でそのエスカレーションタスクを取り消せます。
  • リース管理：「リース」とは、処理プログラムがタスクを一時的に引き受ける期限のことです。Google Cloud によると、Spanner はメッセージのリースを自動管理します。時間のかかる LLM（大規模言語モデル）の推論や外部 API 呼び出しを処理する際には、リースを延長できます。
  • SQL による監視：同社によると、GoogleSQL でキューを定義・確認・管理でき、標準 SQL で実行記録を監査できます。

Google Cloud は、Spanner change streams と Spanner queues の違いも明確にしています。前者は、データベースのデータ変更を継続的に取得し、下流の分析やストレージにストリーミングするためのものです。後者は、トランザクション型のタスクオーケストレーション（複数のタスクの実行や受け渡しを管理すること）専用に設計されています。

一般読者への影響

一般ユーザーが Spanner queues を直接操作することはありません。ただし、同機能が解決しようとしている問題を間接的に体感する可能性はあります。Google Cloud は返金と承認を例に挙げています。エージェントの「記録」と「実際のアクション」が食い違うと、やるべきことが実行されなかったり、承認後なのに催促の通知が届いたりする事態が起こりうると説明しています。Google Cloud によると、この機能はまさにこうした一貫性の問題をデータベース側で処理するものです。

Google Cloud によると、Spanner queues はAIエージェント以外の用途にも使えます。たとえば、ソーシャルフィード、ニュースのリアルタイム更新、小売の注文・在庫フロー、金融サービスの取引通知などです。実際の効果は各企業の設計や使い方次第です。現時点では、その性能を独立に検証した情報源もありません。

よくある質問

Spanner queues とは何ですか？

Google Cloud によると、Spanner データベースに直接組み込まれたトランザクション型メッセージング機能です。メッセージの作成はトランザクション内でデータを1件多く書き込むのと同じです。そのため、他のデータ更新とまとめて成功するか、まとめて失敗します。

Google Cloud がAIエージェントに特に適していると言うのはなぜですか？

Google Cloud の指摘によると、AIエージェントは状態を記録しながらアクションを送ることが多いとされます。両者が別々のシステムにあると、決めたのに実行されない、あるいは無効な状態に基づいて実行されるといった事態が起こりえます。Spanner queues は両者を同一トランザクション内で完了させます。

タスクが1回だけ実行されることを保証できますか？

Google Cloud によると、少なくとも1回の配信と最大1回の確認応答を保証しており、利用者はこれにより厳密に1回の処理を「実現」できます。つまり、適切なアプリケーション設計が引き続き必要です。たとえば同社の例では、タスク番号を外部 API の冪等キーとして使い、重複して送られたリクエストが2回実行されないようにしています。

Spanner change streams とはどう違いますか？

Google Cloud の説明によると、change streams はデータ変更を継続的に取得し、下流の分析やストレージにストリーミングするためのものです。一方、Spanner queues はトランザクション型のタスクオーケストレーション向けです。メッセージのリース、配信予約、SQL によるプル、トランザクション内での確認応答をサポートします。

これらの説明は独立に検証されていますか？

いいえ。本記事の情報は Google Cloud の公式ブログのみに基づくもので、ベンダーによる発表です。現時点で、独立した第三者によるテストや確認は確認されていません。

このトピックの最新ニュースを見る

同じテーマの記事

最新の旅の情報・ガイド

出典

ライフスタイル