スキーマ管理──破壊的変更からシステムを守る仕組み

TL;DR

• ストリーミング基盤ではProducerとConsumerが非同期に進化するため、スキーマ不整合が発生しやすい。
• Schema Registry（Kafka）や Glue Schema Registry（Kinesis）は、契約（Contract）としてのスキーマ管理を提供する。
• 後方互換性を守るルールを徹底することで、破壊的変更を防ぐ。

Kafka / RedpandaのSchema Registry

• Avro/JSON/Protobufなどのスキーマを中央管理
• 互換性モード（Compatibility Mode）
  • BACKWARD: 新しいProducerでも古いConsumerが読める
  • FORWARD: 古いProducerでも新しいConsumerが読める
  • FULL: 双方向互換
• 運用では BACKWARD互換 が最も現実的

Kinesis + Glue Schema Registry

• Kinesis Data StreamsやFirehoseでスキーマをAWS Glueに保存
• データを投入するたびにスキーマIDを付与
• Consumerはスキーマを参照しつつデシリアライズ
• 互換性チェックをGlueに任せられるため、運用負荷が軽減

Flink / Kinesis Data Analyticsとの相性

• FlinkはSchema Registryから直接スキーマを参照可能
• Schema Evolution（列追加などの後方互換）を意識した設計が必須
• 破壊的変更（型変更、フィールド削除）は即アウト → バックアップストリームが必要になるケースあり

Djangoとの実務Tip

API経由で受け取ったデータをそのままProducerに流すとスキーマ崩壊リスク。送信前に スキーマバリデーションレイヤー を挟むのが安全。

from jsonschema import validate, ValidationError

def send_event(event, schema):
    try:
        validate(instance=event, schema=schema)
        producer.produce("events", value=json.dumps(event))
    except ValidationError as e:
        save_to_dlq(event)  # 不正データは隔離

運用チェックリスト

• スキーマ管理は中央リポジトリ化されているか
• Producerリリース前に互換性チェックをCI/CDに組み込んでいるか
• 後方互換性を守るルールをチーム内で合意済みか
• 不正データはDLQに隔離しているか

まとめ

スキーマ管理は「誰が見ても安心して進化できる契約書」。

後方互換性を守る文化がないと、ある日突然「Consumer全滅事故」が起きる。

Schema RegistryやGlue Schema RegistryをCI/CD・運用監視に組み込み、破壊的変更を未然に防ごう。