Schema Registry の全体像：スキーマ管理と互換性チェック

Schema Registry は、Kafka 上のイベントスキーマを一元管理し、進化を安全にするための中核コンポーネントです。互換性チェックを正しく選ぶだけで、長期運用の事故率は大きく下がります。

本稿は CCDAK 対策を意識しつつ、Avro/Protobuf/JSON Schema の違い、Subject 設計、互換性モードの選択、運用の落とし穴を具体的に解説します。

Schema Registry の役割と基本アーキテクチャ

Schema Registry は、スキーマの登録・バージョニング・検索と、互換性チェックを提供するサービスです。スキーマは Kafka の内部トピック（既定では _schemas）に保存され、書き込みはリーダーを通して直列化されます。クライアントは通常、Confluent のシリアライザを介してスキーマ ID を解決し、メッセージに埋め込みます。

重要なポイントは、毎メッセージで REST を呼ばないことです。一度スキーマ ID を解決すれば、以降はキャッシュされた ID を使って直列化・逆直列化できます。Registry が一時的に停止しても、未登録のスキーマを使わない限りは送受信を継続できます。

• 保存先: Kafka 内部トピックに永続化（典型例: _schemas）
• API: REST で登録・取得・互換性設定（subjects, versions, config）
• クライアント: Confluent シリアライザがスキーマ ID を解決し wire format に埋め込む
• 可用性: リーダー選出で一貫性を確保しつつ複数ノードで冗長化
• キャッシュ: クライアント・サーバ双方がスキーマと ID をキャッシュ

Producer/Consumer と Schema Registry の連携イメージ

スキーマ登録と Subject 設計の勘所

Schema Registry は Subject 単位でスキーマを版管理します。デフォルトの TopicNameStrategy では topic-value と topic-key が Subject 名になります。RecordNameStrategy や TopicRecordNameStrategy を使うと、レコード名（完全修飾名）を主語にして複数トピックで同一スキーマを共有できます。

本番では勝手登録を避けるため、プロデューサで auto.register.schemas を無効化し、事前登録または CI/CD で承認付き登録を行う運用が一般的です。互換性レベルはグローバルとサブジェクト単位の両方で設定できますが、サブジェクト設定が優先されます。

• Subject 命名: TopicNameStrategy（既定）、RecordNameStrategy、TopicRecordNameStrategy
• 登録フロー: 事前登録 → 互換性チェック通過 → ID 付与 → 直列化で埋め込み
• 変更審査: CI で schema registry に対し dry-run 的に互換性を検証してからマージ
• 実務推奨: auto.register.schemas=false、use.latest.version の活用を検討
• キーと値で別 Subject: key と value は互換性・進化を独立に設計する

Avro スキーマの登録と Java Producer 設定例

# Avro スキーマ登録（orders-value）
# 注意: JSON 内で schema を文字列としてエスケープ
curl -s -X POST \
  -H 'Content-Type: application/vnd.schemaregistry.v1+json' \
  --data '{"schema":"{\"type\":\"record\",\"name\":\"Order\",\"namespace\":\"com.example\",\"fields\":[{\"name\":\"id\",\"type\":\"string\"},{\"name\":\"amount\",\"type\":\"double\",\"default\":0.0}]}"}' \
  http://localhost:8081/subjects/orders-value/versions

// Java Producer の主要プロパティ例（KafkaAvroSerializer を利用）
Properties p = new Properties();
p.put("bootstrap.servers", "broker:9092");
p.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("value.serializer", "io.confluent.kafka.serializers.KafkaAvroSerializer");
p.put("schema.registry.url", "http://sr:8081");
// 本番は勝手登録を避ける
p.put("auto.register.schemas", "false");
// 既登録の最新バージョンを解決して使用（要要件確認）
p.put("use.latest.version", "true");
// Subject 命名戦略例（既定は TopicNameStrategy）
p.put("value.subject.name.strategy", "io.confluent.kafka.serializers.subject.TopicNameStrategy");

互換性レベルの種類と判定ロジック

互換性チェックは、新しいスキーマと既存スキーマの関係を検証します。latest のみ比較するか、全履歴（transitive）と比較するかで厳しさが変わります。Avro/Protobuf/JSON Schema で細部の許容差はありますが、モードの意味は共通です。

典型的には、先にコンシューマを更新できる環境では Backward、先にプロデューサを更新して既存コンシューマを壊せない環境では Forward、双方を確実に守るには Full を選びます。

• Backward: 新スキーマで旧データを読めること（reader=new, writer=latest）
• Forward: 旧スキーマで新データを読めること（reader=latest, writer=new）
• Full: Backward と Forward の両方を満たす
• Transitive: 比較対象が latest ではなく全履歴になる
• None: チェックなし（試験でも推奨されない選択肢になりがち）

データフォーマットと SerDe の選択肢

Confluent Schema Registry は Avro、Protobuf、JSON Schema をサポートします。いずれも REST API と互換性チェックの対象ですが、表現力やワイヤフォーマットの特性が異なります。サイズ効率やツールチェーン、スキーマ参照の有無などで選択します。

Confluent のシリアライザは、先頭にマジックバイト 0 と 4バイトのスキーマ ID を埋め込みます。これにより、コンシューマは受信時に ID からスキーマを引いて逆直列化できます。

• Avro: バイナリ効率と進化の実績があり、CCDAK で頻出
• Protobuf: 強い型付けとサービス間契約で人気。フィールド番号で進化管理
• JSON Schema: JSON 生態系との親和性が高いが、サイズはやや大きめになりがち
• 共通: マジックバイト + スキーマ ID によりスキーマ解決を高速化
• スキーマ参照: 大規模スキーマを分割可能（フォーマットにより表現方法が異なる）

運用ベストプラクティス：可用性・パフォーマンス・セキュリティ

高可用性のために Schema Registry を複数ノードで構成し、Kafka を利用したリーダー選出で書き込みを直列化します。スキーマは Kafka に複製されるため、バックアップは Kafka クラスタの耐障害性に依存します。

レイテンシを抑えるには、クライアント側のスキーマキャッシュを尊重し、新規スキーマの出現頻度を制御します。セキュリティ面では、ブローカー接続の SASL/SSL、Registry の mTLS、ACL、認可を組み合わせて制御します。

• 勝手登録の抑止: CI/CD による登録と互換性チェックのゲート
• キャッシュ効果: スキーマ ID は再利用、Registry への呼び出しは新規スキーマ時のみ
• Subject 粒度の互換性設定で影響範囲を限定
• 監視: 互換性違反、登録エラー、_schemas のレプリケーションを可視化
• セキュリティ: mTLS、SASL、ACL、認可ハンドラで REST を保護

CCDAK 試験対策の要点と落とし穴

互換性モードの読み替えを間違えないことが最重要です。既存コンシューマを更新できない状況でプロデューサが先に新しいスキーマで送るなら Forward、逆にコンシューマを先に上げるなら Backward です。双方守るなら Full。

Subject 命名戦略やグローバル/サブジェクトの優先順位、ワイヤフォーマット（マジックバイトとスキーマ ID）も頻出です。エッジケースとして、型昇格の可否やデフォルト値の必要性はフォーマットに依存する点に注意してください。

• 優先順位: サブジェクト設定がグローバル設定より優先
• Forward/Backward の reader/writer の向きを図にして覚える
• デフォルト値の有無が互換性に与える影響を押さえる
• Subject 設計と Topic/RecordNameStrategy の使い分け
• None はほぼ不正解の誘導肢

問題で確認

よくある質問