Spanner キューは、非同期作業の管理に役立つトランザクション メッセージングを提供します。この機能は、この機能を Spanner のスケーラビリティと信頼性と組み合わせることで、イベント ドリブン アプリケーションを構築できるようにします。Spanner キューは、メッセージの消費にプルモデルを使用し、受信側がメッセージをリクエストして受信するための SQL インターフェースを公開します。
Spanner キューと変更ストリームのどちらを選択するか
次の比較は、データ伝播と非同期処理に適したメカニズムを選択するためのガイダンスを提供します。
Spanner キュー最適な用途
主な特徴
|
Spanner 変更ストリーム最適な用途
主な特徴
|
主なメリット
Spanner キューには次のようなメリットがあります。
- 統合: メッセージングがデータベースに統合されています。これにより、個別のメッセージング インフラストラクチャへのデータのプロビジョニング、管理、抽出が不要になり、アプリケーション アーキテクチャが簡素化され、全体的な費用が削減されます。
- トランザクション: 他のデータベース書き込みとともに、Spanner トランザクション内でメッセージをアトミックに送信して確認できます。トランザクションが失敗した場合、キューに登録されたメッセージはロールバックされ、配信に使用できません。
- Durable: 配信できないメッセージはデータベースに保存されます。Spanner は、メッセージが明示的に確認応答されるか削除されるまで、バックオフを使用して配信を継続的に試みます。
- クエリ可能: メッセージは Spanner テーブルと同じプリミティブに基づいて構築され、行として保存されます。標準テーブルと同様に、クエリ、結合、フィルタリングを行うことができます。
- スケーラブル: Spanner テーブルと同じスケーラビリティで構築されているため、メッセージ処理はデータベースの他の部分とともにスケーリングされます。
- 信頼性: Spanner キューは、Spanner の高可用性プリミティブをすべて継承します。これにより、メッセージの送信と処理がフォールト トレラントになり、ゾーンまたはリージョンの障害に対する復元力が向上します。
- スケジュール可能: メッセージを将来の配信用にスケジュール設定できます。これにより、タスクの実行を特定の将来のタイムスタンプまで延期できます。
- アトミック: メッセージ送信（
INSERTまたはミューテーション API）と確認応答（DELETEまたはミューテーション API）はトランザクション内でアトミックに実行され、データベースの状態との整合性が確保されます。 - 拡張可能: メッセージ リースは、将来の配信と手動リース メカニズムを組み合わせることで、非常に長い処理時間をサポートするように拡張できます。
ユースケース
Spanner キューは、トランザクション内で遅延タスクをオーケストレートする場合に便利です。一般的な例:
- 計算負荷の高い作業の延期: 写真共有ウェブサイトでは、新しい写真がアップロードされたときに、集中的な画像処理が必要になることがあります。新しい写真のメタデータを書き込むトランザクションは、同時にキュー メッセージを書き込むことができます。キュー レシーバーは後でメッセージを取得し、処理を実行して、メタデータをトランザクションで更新します。
- 大規模なトランザクション更新の遅延: カレンダー アプリで、1 つのトランザクションで大規模なグループを会議に招待すると、ロックの競合とテール レイテンシが発生する可能性があります。代わりに、カレンダーの予定を作成するトランザクションで、招待者ごとにキュー エントリを追加し、受信者が招待状を個別に送信できるようにします。
- 将来のタスクのスケジュール設定: 30 日間の無料トライアルを提供するサービスとしてのソフトウェア（SaaS）企業は、ユーザーのリソースをプロビジョニングし、30 日後に配信されるようにスケジュール設定されたメッセージを同時にキューに入れることができます。ワーカーはメッセージを受信し、トライアルの有効期限切れロジックを実行します。
- 外部システムへの作業の遅延: ユーザーが登録した後、データベース登録が成功した場合にのみ、アプリケーションでウェルカム メールを送信する必要がある場合があります。登録トランザクションでキューにエントリを追加すると、ワーカーが後で外部メール API を呼び出すことができます。
- 複数ステップのパイプラインのオーケストレーション: 注文管理システムでは、注文の履行に複数のステップが含まれ、各ステップは個別に失敗する可能性があります。各ステップをキュー メッセージとして表すことで、システムはパイプラインの状態をチェックポイントし、障害が発生したポイントから続行できます。
ワークフロー
Spanner キューの一般的なワークフローは次のとおりです。
- キューを作成する: テーブルと同様に、DDL を使用してキューを定義します。
Payload列（PostgreSQL ではpayload）と主キーを含める必要があります。 - メッセージを送信する: 標準 DML（
INSERT）またはミューテーション API を使用して、他のデータベース オペレーションとトランザクションでメッセージをキューに登録します。 - メッセージを受信する:
ExecuteStreamingSQLAPI を使用して、RECEIVE_QUEUE_NAME()という名前のテーブル値関数（TVF）を呼び出します。この関数は、長時間実行されるクエリとしてメッセージをクライアントにストリーミングします。 - メッセージを処理する: アプリケーション ロジックを使用して、TVF から受信したメッセージを使用します。
- メッセージの確認応答: DML（
DELETE）またはミューテーション API（ackなど）を使用して、キューからメッセージを削除します。通常、これは処理が完了した後、トランザクション内で行われます。 - リースを管理する: メッセージ リースを管理して、リース タイムアウト時に Spanner キューがメッセージを再配信しないようにします。最も一般的な方法は、
RENEWLEASE_QUEUE_NAME()TVF を使用することです。
また、Spanner キューの次のコア動作にも留意してください。
- 1 回以上の配信: ほとんどのクラウドベースのキュー システムに共通する Spanner は、1 回以上の配信を保証します。再配信は、リースの延長によって軽減できます。
- 最大 1 回の確認応答: メッセージの確認応答はトランザクションで行われるため、Spanner の ACID セマンティクスにより、メッセージは 1 回だけ確認応答されます。1 回限りの処理と最大 1 回の確認応答ページのメソッドに従って、最大 1 回の確認応答を適切に実装します。
制限事項
Spanner キューには次の制限があります。
- 受信者の最大数: キューごとに同じ引数を持つアクティブな受信クエリは 1,000 件までです。
- 同時受信 TVF 割り当て上限: プロジェクトとリージョンごとに、同時受信 TVF の割り当て上限が 2,000 に設定されています。割り当て上限を引き上げるには、Cloud Spanner プロジェクトの割り当ての引き上げリクエスト フォームに記入してください。
- 手動分割:
AddSplitsAPI はキューではサポートされていません。ワークロードの分散は、負荷に基づいた分割に完全に依存しています。ユーザーがテーブルに分割ポイントを追加できるように、テーブル内のキューをインターリーブすることをおすすめします。 - 地域別パーティション分割のコンプライアンス: 地域別パーティション分割されたキューは、
DROP PARTITIONオペレーションの実行後にデータ所在地コンプライアンスに準拠しません。 - キュー数の上限: インスタンスは、1 つ以上のノードを持つインスタンスで 100 個のキューに制限されます。上限は、粒度の細かいインスタンス（200 個の処理ユニットを持つインスタンスは 20 個のキューに制限されるなど）に対して比例して縮小されます。
- キューの削除と再作成: 同じ名前のキューの削除と再作成は完全にサポートされていません。キューの
RECEIVETVF は、同じ名前でメッセージを再度受信できるようになるまで、リセットに時間がかかることがあります。 - PostgreSQL の列命名: Spanner は、メッセージの配信時間の
deliver_time列とDeliverTime列の両方を公開します。標準の PostgreSQL 命名規則に準拠するため、また、将来のリリースでDeliverTime列が情報スキーマから非表示になるため、deliver_time列を使用することをおすすめします。 - 名前付きスキーマ: 名前付きスキーマにキューを作成することはできません。
次のステップ
- ベスト プラクティスとモニタリングを含む、Spanner キューの使用方法について学習する。
- Spanner キューのシナリオと例をご覧ください。
- 1 回限りの処理と最大 1 回の確認応答について学習する。
- キューのきめ細かいアクセス制御を使用してアクセス制御を構成します。