Pub/Sub スキーマ進化の一般提供を開始
Google Cloud Japan Team
※この投稿は米国時間 2023 年 3 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。
Pub/Sub スキーマは、パブリッシャーとサブスクライバー間で安全な構造化されたコミュニケーションを実現するよう設計されています。特に、スキーマを利用すると、パブリッシュされるメッセージが常にスキーマとエンコードに準拠するようになるため、サブスクライバーは、準拠を前提にデータの読み取りを行えます。
スキーマは時間の経過とともに進化する傾向にあります。たとえば、小売業者がウェブイベントをキャプチャし、BigQuery でのダウンストリーム分析のために Pub/Sub にこれらのイベントを送信するとします。現在、スキーマには Pub/Sub へ伝搬する必要がある追加のフィールドが組み込まれています。これまで、Pub/Sub では修正の必要なトピックにスキーマを関連付けることができなかったため、お客様が新しいトピックを作成する必要がありました。本日、Pub/Sub チームは、この制限を変更するスキーマの進化を発表いたします。これにより、パブリッシャーとサブスクライバーは、ダウンタイムを発生させることなく、スキーマを安全かつ容易に更新できるようになります。
スキーマ リビジョン
既存のスキーマを更新してスキーマの新しいリビジョンを作成できるようになりました。多くの場合、スキーマの更新ではオプションのフィールドの追加または削除だけが行われ、これらは互換性のある変更と見なされます。
スキーマのすべてのバージョンがスキーマ詳細ページに表示されるようになります。1 つまたは複数のスキーマ リビジョンをスキーマから削除できますが、スキーマのリビジョンが 1 つのみの場合、そのリビジョンは削除できません。また、差分表示機能を使用して 2 つのリビジョンを簡単に比較できます。
トピックの変更
現在は、既存のスキーマをアタッチするか、新しいスキーマを作成してトピックに関連付けることができます。Pub/Sub は、そのトピックにパブリッシュされるすべてのメッセージを、そのスキーマに照合して検証します。スキーマ進化機能を使用すると、トピックを更新して、Pub/Sub がメッセージの検証を行うスキーマ リビジョンの範囲を指定できます。Pub/Sub は、このリビジョンに照合しつつ、最後のバージョンから最初のバージョンまで、新しい順にメッセージの検証を試行します。最初のリビジョンが指定されていない場合には、最後のリビジョンとそれよりも古いすべてのリビジョンが使用可能です。最後のリビジョンが指定されていない場合には、最初のリビジョンとそれよりも新しいすべてのリビジョンが使用可能です。
スキーマ進化の例
スキーマ進化の一般的な使用例を説明します。トピック T と、このトピックに関連付けられているスキーマ S があります。パブリッシャーはこのトピックにパブリッシュし、サブスクライバーはこのトピックのサブスクリプションをサブスクライブします。
ここで、スキーマに新しいフィールドを追加し、パブリッシャーがフィールドをメッセージに組み込むようにしたいとします。すべてのサブスクライバーの更新とサブスクライバーが更新されるスケジュールを、トピックとスキーマのオーナーが管理しているとは限りません。また、新しいスキーマを使用してメッセージをパブリッシュするようにしたい場合に、すべてのパブリッシャーを同時に更新することができない場合もあります。新しいフィールドを利用するには、スキーマを更新した後、パブリッシャーとサブスクライバーが遅れて更新されるのを待つ必要があります。スキーマ進化により、新しいフィールドを追加するための更新を次の手順でダウンタイムなしで実行できます。
1. フィールドを追加する新しいスキーマ リビジョンを作成します。
2. トピックが受け入れるリビジョンの範囲に、この新しいリビジョンが含まれていることを確認します。
3. 新しいスキーマ リビジョンを使用してパブリッシュするように、パブリッシャーを更新します。
4. 新しいスキーマ リビジョンを使用したメッセージを受け入れるように、サブスクライバーを更新します。
すべてのスキーマ更新では後方および前方の互換性があるため、ステップ 3 と 4 を入れ替えることもできます。新しいスキーマ リビジョンへの移行が完了すると、元のリビジョンを除外するようトピックを更新することができます。このようにすると、パブリッシャーは新しいスキーマのみを使用するようになります。
この手順は、プロトコル バッファと Avro スキーマの両方で機能します。ただし、Avro スキーマを使用するときには一層の注意が必要です。サブスクライバーには、コンパイルされたスキーマのバージョン（「リーダー」スキーマ）がおそらくありますが、メッセージの解析には、メッセージのエンコードに使用されたスキーマ（「ライター」スキーマ）を使用する必要があります。Avro はライター スキーマをリーダー スキーマに変換するためのルールを定義しています。Pub/Sub では、新しいスキーマと古いスキーマの両方をリーダー スキーマまたはライター スキーマとして使用できるスキーマ リビジョンのみ使用可能です。ただし、スキーマの識別のために渡された属性を使用して Pub/Sub からライター スキーマを取得してから、リーダー スキーマとライター スキーマの両方を使用して解析しなければならない場合も依然としてあります。こちらのドキュメントには、このための最適な方法を示す例が記載されています。
BigQuery サブスクリプション
Pub/Sub スキーマ進化は、BigQuery サブスクリプションと組み合わせた場合にも効果を発揮します。この組み合わせでは、Pub/Sub にパブリッシュされたメッセージを BigQuery に直接書き込むことができます。トピック スキーマを使用してデータを書き込む場合、Pub/Sub は、トピックに関連付けられている少なくとも 1 つのリビジョンが、BigQuery テーブルとの互換性を持つようにします。BigQuery に書き込む新しいフィールドを追加するようにメッセージを更新する手順は、次のとおりです。
1. BigQuery テーブル スキーマにオプションのフィールドを追加します。
2. このフィールドを Pub/Sub スキーマに追加します。
3. トピックが受け入れるリビジョンの範囲に、この新しいリビジョンが含まれていることを確認します。
4. 新しいスキーマ リビジョンを使用したメッセージのパブリッシュを開始します。
この簡単な手順で、ニーズの変化に応じて BigQuery に書き込まれるデータを進化させることができます。
割り当てと上限
スキーマ進化機能には以下の制限があります。
一度に使用できるスキーマ名ごとのリビジョンの数は 20 です。
個々のスキーマ リビジョンは、プロジェクトあたりの最大スキーマ数（10,000）にはカウントされません。
参考情報
この機能について詳しくは、以下のリソースをご確認ください。
- Cloud Pub/Sub テクニカル リーダー、Kamal Aboul-Hosn- Cloud Pub/Sub シニア プロダクト マネージャー、Prateek Duble
