https://docs.confluent.io/cloud/current/sr/fundamentals/schema-evolution.html

以下は、Confluent ドキュメント「Schema Evolution and Compatibility for Schema Registry on Confluent Cloud」の内容を、日本語に和訳し、Markdown形式でまとめたものです。

Schema Registry におけるスキーマ進化と互換性（Confluent Cloud）

スキーマ進化（Schema Evolution）は、データ管理の重要な側面です。アプリケーションがスキーマを変更する際に、下流のシステムが古いスキーマ・新しいスキーマによるデータをシームレスに処理できる必要があります。これが困難になると、本番環境での対応コストが高まります。 Confluent Schema Registry は、スキーマのバージョン管理と互換性チェック機能を提供し、この課題に対応します。(Confluent Documentation)

スキーマ進化の基本

Schema Registry は各スキーマをバージョン管理し、一意の ID を付与します。
互換性の設定により、新スキーマがどのように既存スキーマと整合するかを制御できます。(Confluent Documentation)

互換性タイプの概要

以下は、サブジェクトごとに設定可能な互換性タイプと、その変更許可内容です（デフォルトは BACKWARD）。(Confluent Documentation)

互換性タイプ	許可される変更内容	対象となるスキーマ	アップグレード時の注意点
`BACKWARD`	フィールドの削除、オプションフィールドの追加	最新バージョンに対して	コンシューマを先にアップグレード
`BACKWARD_TRANSITIVE`	同上	全過去バージョンに対して	同上
`FORWARD`	フィールドの追加、オプションフィールドの削除	最新バージョンに対して	プロデューサを先にアップグレード
`FORWARD_TRANSITIVE`	同上	全過去バージョンに対して	同上
`FULL`	オプションフィールドの追加・削除	最新バージョンに対して	両者独立でアップグレード可能
`FULL_TRANSITIVE`	同上	全過去バージョンに対して	同上
`NONE`	すべての変更を許可	制限なし	アップグレード順注意

BACKWARD: 新スキーマで古いデータを読み込めるようにする。(Confluent Documentation)
BACKWARD_TRANSITIVE: 過去すべてのバージョンに対して backward を保証。(Confluent Documentation)
FORWARD / FORWARD_TRANSITIVE: 新しく書かれたデータが古いコンシューマでも読み込めるようにする（transitive は全過去バージョン対象）。(Confluent Documentation)
FULL / FULL_TRANSITIVE: 双方向の互換性確保。FULL_TRANSITIVE は全過去バージョン対象。(Confluent Documentation)
NONE: 互換性チェックを行わない。重大な変更はトピック再作成などが推奨。(Confluent Documentation)

トランジティブ互換性について

トランジティブ（transitive）互換性が有効な場合、新スキーマはすべての過去バージョンに対して互換性を維持することが保証されます。非トランジティブでは直前バージョンのみがチェック対象です。(Confluent Documentation)

クライアントのアップグレード順序について

互換性タイプに応じて、プロデューサやコンシューマのアップグレード順序が異なります。(Confluent Documentation)

BACKWARD / BACKWARD_TRANSITIVE → 古いコンシューマでも新スキーマのデータを扱えるとは限らないので、先にコンシューマをアップデートする必要があります。
FORWARD / FORWARD_TRANSITIVE → 新スキーマで書かれたデータを古いコンシューマが扱えない場合があるため、先にプロデューサをアップデートしましょう。
FULL / FULL_TRANSITIVE → 双方向互換性があるため、プロデューサ・コンシューマの順序を気にせずアップグレード可能です。
NONE → 互換性が一切保証されないため、慎重な計画が必要です。(Confluent Documentation)
Kafka Streams アプリの場合、BACKWARD, BACKWARD_TRANSITIVE, FULL, FULL_TRANSITIVE のみがサポートされ、ストリーム状態との整合性のため、先にストリームアプリをアップグレードする必要があります。(Confluent Documentation)

フォーマット別の互換性実装差

互換性の概念は Avro / Protobuf / JSON Schema のすべてに共通しますが、細かい実装や対応振る舞いはフォーマットによって異なります。

Avro：スキーマ進化を念頭に設計されており、互換性のルールも明確。(Confluent Documentation)
Protobuf：互換性の詳細は仕様依存。BACKWARD_TRANSITIVE を使うのがベストプラクティスとされています。(Confluent Documentation)
JSON Schema：仕様上の互換性ルールは曖昧。詳細は追加ドキュメントやブログ記事で確認を。(Confluent Documentation)

グローバル設定とコンテキスト

グローバル互換性設定とサブジェクト単位の設定（トピック毎等）が可能で、サブジェクト設定は優先されます。(Confluent Documentation)
スキーマコンテキスト（Schema Context）：同じ名前でも別コンテキストで異なるスキーマを管理可能な機能。互換性チェックはコンテキスト単位で行われ、グローバルでは担保されません。(Confluent Documentation)

まとめ

スキーマ進化には慎重な互換性設計が不可欠。
BACKWARD, FORWARD, FULL, NONE とそれぞれのトランジティブ版を理解し、適切な設定を行いましょう。
クライアント（プロデューサ／コンシューマ／ストリーム）のアップグレード順序も要注意。
使用フォーマットに応じた互換性制御の違いも押さえておくと安心です。

kenzo0107/Schema Evolution and Compatibility for Schema Registry on Confluent Cloud.md