The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。本ニュースレターは【日本語】で配信しています。登録の際はIBMプライバシー・ステートメントをご覧ください。
スキーマ・レジストリーは、 Apache Kafkaを通じて交換されるデータをシリアライズおよびデシリアライズするために使用されるスキーマを保管、管理、検証する集中管理サービスです。スキーマ・レジストリーは、各プロデューサーとコンシューマー・アプリケーションがメッセージ形式を個別に定義するのではなく、イベント・データの構造化に関する共通の「信頼できる情報源」を提供します。
Kafkaでは、イベントはしばしば、Apache Avro 、JSON Schema、Protocol Buffers（略してprotobuf）などのフォーマットを使用してシリアル化されます。スキーマ・レジストリーはこれらの形式の定義を保管し、各スキーマに一意の識別子を割り当てます。これはスキーマIDと呼ばれます。
プロデューサーがKafkaトピックにメッセージを書き込む際、通常、すべてのメッセージにスキーマ全体を埋め込むのではなく、シリアル化されたデータと一緒にスキーマIDを含めます。メッセージコンシューマーは、レジストリーから対応するスキーマを取得し、それを使用してデータを正しく逆シリアル化および解釈します。
スキーマ・レジストリーは、イベントベースのシステムにおいて重要です。なぜなら、スキーマ・レジストリーによって、プロデューサーとコンシューマーが交換されるデータの構造について合意できることが保証されるからです。これにより データ品質 と データの整合性が支えられています。
集中型レジストリーがなければ、アプリケーションはメッセージ・スキーマを個別に管理する必要があります。これにより、互換性のない変更が発生するリスクが高まり、イベントコンシューマーがエラーを起こしたり、データを誤って解釈したりする可能性があります。
また、スキーマ・レジストリーは、スキーマの進化と呼ばれるものもサポートしています。これにより、開発者は既存のアプリケーションとの互換性を維持しながら、イベント構造を徐々に変更できます。
例えば、新しいオプションフィールドを追加しても、既存のKafkaユーザーが期待するフォーマットを崩さずに済むことが多いです。互換性ルールは、スキーマの変更がデプロイされる前に、その安全性を確保するのに役立ちます。
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。本ニュースレターは【日本語】で配信しています。登録の際はIBMプライバシー・ステートメントをご覧ください。
もう一つの重要なメリットは、データ・ガバナンスの向上です。スキーマは中央リポジトリに保存されるため、組織はイベントデータの構造について、文書化、確認、バージョン管理、および監査を行うことができます。
このアプローチにより、開発チームは次のことが容易になります。
最新のデータ・プラットフォームでは、スキーマ・レジストリーによって、Kafkaのプロデューサーとコンシューマー間のデータ・コントラクトを有効にすることもできます。これらのコントラクトは、データの構造だけでなく、そのデータが時間の経過とともにどのように進化するべきかについての期待も定義します。
スキーマ・レジストリーは、スキーマの変更を公開前に検証することで、破壊的な変更が本番環境に適用されるのを防ぎ、イベント駆動型アーキテクチャーの信頼性を高めるのに役立ちます。
スキーマ・レジストリーは、イベント・スキーマを管理するための一元化されたメカニズムを提供し、それらのスキーマ間の互換性を確保し、それらのスキーマへの変更をサポートします。
レジストリーを使用すると、開発者は古いスキーマの上に新しいスキーマを構築し、スキーマ内の構造化された構成を実現できるほか、サブジェクト名戦略を用いてイベント名を標準化することも可能です。
これらの方法は、システムや要件の変更に応じてアプリケーションがデータを交換するのに役立ちます。
スキーマ・レジストリーは、プロデューサーとコンシューマーの間で交換されるイベント・データの構造を定義するスキーマを保管・管理することで機能します。プロデューサーがKafkaのトピックにデータを送信する際、登録済みのスキーマに従ってメッセージをシリアル化し、対応するスキーマを識別できる情報を含めます。これにより、コンシューマーはそのスキーマを使用して、メッセージを正しくデシリアライズし、解釈することができます。スキーマは時間の経過とともに変更されるため、レジストリーでは、新しいスキーマバージョンが登録される前に互換性チェックを行うことも可能です。これにより、プロデューサーとコンシューマーは、進化し続けるデータ構造に対応し続けることができます。
Eコマース・サイト、モバイル・アプリケーション、推奨エンジン、在庫管理システム、配送プラットフォーム、顧客分析プラットフォームなど、データを生成および消費する複数のシステムを備えた大手オンライン小売業者を想像して見てください。これらのシステムは、 Confluent クラウドを用いたApache Kafkaクラスターを通じてイベントを公開・消費し、そのイベントをデータ パイプライン 内のKafka Connectを使ってデータウェアハウスにストリーミングします。
Webサイト上での各アクションによって、小売業者のシステム全体で複数のイベントが生成されます。顧客が注文するたびに、ウェブサイトはKafkaトピックに
複数のダウンストリーム・アプリケーションが同じイベントを消費します。インベントリーシステムが購入した商品を予約し、決済システムが取引を確認し、倉庫がフルフィルメントを開始します。レコメンデーション・エンジンで顧客の嗜好が更新され、分析プラットフォームで販売が記録され、顧客通知サービスが確認Eメールを送信します。
最初は、
さて、数か月後、その企業が海外販売を支援することを決定したと想像してみてください。開発者はウェブサイトを更新して、各注文に2つの新しいフィールドが含まれるようになりました。
スキーマ・レジストリーがなければ、この変更を調整するための集中的なメカニズムはありません。イベントデータ・コンシューマーによっては新しいフィールドを予期するものもあれば、そうでないものもあります。開発者が誤って
では、スキーマ管理にConfluent Schema Registryを活用した場合、同じシナリオはどのように変わるでしょうか？
更新されたプロデューサーをデプロイする前に、開発チームは
提案された変更がこれらの互換性ルールに準拠している場合は、新しいスキーマ・バージョンを登録できます。変更が設定された互換性ポリシーに違反する場合、アプリケーションが互換性のないスキーマを使用し始める前に、レジストリはその変更を拒否できます。
つまり、開発者はデプロイ後ではなく、開発中にスキーマの互換性を損なう変更を発見できるようになります。互換性のある変更であれば、既存のユーザーは引き続き正常に利用でき、開発チームは準備が整い次第、新しいフィールドを使用するようにアプリケーションを段階的に更新することができます。
スキーマ・レジストリーのメリットは、会社が成長するにつれてより重要になります。数十のエンジニアリングチームによって開発された数百のアプリケーションが、数千種類の異なるイベントタイプを通じてデータを交換することもあります。
スキーマ・レジストリーがなければ、各チームは手書きのドキュメンテーションや会議、試行錯誤を経てスキーマ変更を手動で調整しなければなりません。この手作業では開発が遅れ、互換性のない変更が本番環境に適用される可能性が高まります。
スキーマ・レジストリーを導入すると、イベント・スキーマは集中管理型の資産となります。プロデューサーは登録されたスキーマに従ってデータを公開でき、コンシューマーはそれらのスキーマ定義を使用して受信イベントを解釈し、互換性チェックにより互換性のないスキーマの変更を特定できます。
新しいチームは、メッセージ形式をリバース・エンジニアリングするのではなく、既存のイベント定義を検出できるため、新しいアプリケーションの構築や新しいシステムの統合が容易になります。
小売業者が事業を拡大するにつれ、スキーマ・レジストリーは、生産者と消費者全体で進化するイベント・スキーマを一元的に管理する方法を提供します。
スキーマの互換性は、異なるバージョンのスキーマを使用するアプリケーションが、スキーマの進化に応じてデータを正しく交換および解釈し続けることができるかどうかを決定します。主な互換性モードには、後方互換性、前方互換性、および完全互換性があります。
一部のスキーマ・レジストリーは、これらの互換性モードの推移的なバージョンもサポートしています。推移的互換性チェックでは、新しいスキーマバージョンを直前のバージョンとのみ比較するのではなく、関連するすべての以前のバージョンと比較します。正確な互換性ルールと許可されるスキーマの変更は、スキーマ形式とレジストリの互換性設定によって異なります。
前方互換性は、古いプロデューサーが稼働を継続しなければならない一方で、新しいコンシューマーがそれらの古いプロデューサーからのデータを中断なく処理する必要がある場合に有用です。このような状況では、新しくデプロイされたアプリケーションが、プロデューサーソフトウェアの古いバージョンによって依然として生成されているメッセージとの互換性を維持できることを確保することが最優先となります。
スマートグリッドを運用する全国規模の電力会社を例に考えてみましょう。このグリッドは、家庭や企業に設置された何百万ものスマート・メーターで構成されています。これらはそれぞれ、電力使用量イベントをApache Kafkaに公開します。これらのメーターは長年にわたり稼働し続け、ファームウェアの更新は予定されたメンテナンス期間中のみ行うことができます。つまり、ソフトウェアの新しいバージョンがリリースされてからかなり経っても、多くのメーターが古いスキーマを使用してイベントを生成し続けていることになります。
一方、電力会社は中央監視および分析アプリケーションを定期的にアップグレードしています。分析プラットフォームの新しいバージョンでは、電力品質指標や再生可能エネルギー発電量などの追加情報のサポートが導入されています。これらの新しいフィールドは利用可能であれば有用ですが、プラットフォームは、それらを送信しない古いメーターからのデータも引き続き処理できなければなりません。
このシナリオでは、コンシューマーが先に更新される一方で、多くのプロデューサーが古いスキーマバージョンのままであるため、以前のバージョンとの互換性よりも前方互換性の方が重要になります。新しいコンシューマーソフトウェアは、新しく導入されたフィールドが含まれていない場合でも、古いスキーマで記述されたイベントを正しく読み取れる必要があります。アプリケーションは、欠落しているフィールドをオプションとして扱うか、デフォルト値を割り当てつつ、主要な機能を継続して実行することができます。
もし後方互換性が主な懸念事項であった場合、開発者は、新しい消費者が古い生産者スキーマで記述されたデータを読み取れるようにすることに重点を置くことになるでしょう。ただし、組織の当面の課題は、中央処理システムをモダナイズしながら、長期間使用する古いデバイスをサポートすることです。
適切な互換性ルールを持つスキーマ・レジストリーを使用すると、この電力会社は、導入されている数百万のメーターに対するファームウェアの同時更新を必要とせずに、イベント・スキーマを進化させることができます。これにより、組織が設定した互換性要件の範囲内にとどまりつつ、プロデューサーとコンシューマーを異なるタイミングで更新できる段階的な展開が可能になります。
スキーマ・レジストリーは、一般データ保護規則（GDPR）やカリフォルニア州消費者プライバシー法（CCPA）といったデータプライバシーに関する規制への準拠を支援することができます。
スキーマレジストリ自体はコンプライアンスを保証するものではありませんが、組織が規制要件を満たすために必要なデータガバナンス、一貫性確保、および監査の実践を実施する上で役立ちます。
主要なメリットの1つは、処理中のデータの可視性が向上することです。
すべてのイベントスキーマは一元化されたリポジトリに格納されており、そこにはスキーマで定義されているフィールドが記録されています。これにより、どのようなデータが存在するか、どのようなフィールドが表されているか、アプリケーションが生成または消費するデータをどのように構造化するかについての情報源が提供されます。
これにより、組織は、氏名、メールアドレス、口座番号などの個人を特定できる情報（PII）を含むスキーマを特定しやすくなります。
スキーマ・レジストリーは、GDPRの原則であるデータの最小化もサポートできます。
スキーマが承認される前に、開発者とデータ・ガバナンス・チームは、すべてのフィールドが意図したビジネス目的に必要かどうかをレビューできます。この確認プロセスは、アプリケーションが不要な個人情報を収集または共有するのを防ぐのに役立ちます。
スキーマ検証は、不正な変更や偶発的な変更によって、機密性の高いデータが本番システムに導入されるのを防ぐのにも役立ちます。
たとえば、開発者が顧客の社会保障番号や運転免許証番号を既存のKafkaイベントに追加しようとした場合、提案されたスキーマはデプロイ前に見直すことができます。
このアプローチにより、通常のアプリケーション・テストに加えて、追加のガバナンス・チェックポイントが作成されます。
バージョン管理やスキーマ履歴は監査機能を提供します。
スキーマの進化がすべて記録され、組織はフィールドがいつ追加、変更、または削除されたかを判断できます。
コンプライアンス監査の際、この履歴はデータ構造が制御された追跡可能な方法で管理されていることを証明するのに役立ちます。
スキーマ・レジストリーによって複数のシステム間の一貫性を向上させることもできます。
プロデューサーとコンシューマーは共有スキーマ定義に依存しているため、アプリケーションは共通の構造定義に従ってフィールドを解釈できます。
これにより、アプリケーション間のデータの処理の不整合を減らすことができます。
多くの組織は、データ・コントラクトの実装の一環としてスキーマ・レジストリーを使用しています。
これらのコントラクトは、イベントの構造だけでなく、イベントに含まれるデータに関するメタデータも定義します。
その後、自動検証を使用して、新しいスキーマのバージョンが定義された要件を満たし続けているかどうかを確認できます。
スキーマ・レジストリーは、より広範なデータ・ガバナンスおよびセキュリティー・ツールとも統合できます。
スキーマとともに保管されるメタデータは、次のようなシステムで利用できます。
したがって、スキーマ・レジストリーは、より広範なガバナンス・アーキテクチャーの1つのコンポーネントを形成できます。
暗号化、アクセス制御、データ保持ポリシー、監査ロギングと組み合わせることで、スキーマ管理は、組織が個人データの収集、処理、共有方法を管理するのに役立ちます。
いくつかのプラットフォームは、Kafkaおよび関連データ・システム用のスキーマ・レジストリー機能を提供しています。
Confluent Schema Registry は広く使われているKafka特有のスキーマレジストリーです。
これはConfluentシステムの一部であり、Confluent Platformのセルフマネージドコンポーネントとして、また Confluent クラウドのマネージドサービスとして利用可能です。
Avro、Protobuf、JSON Schemaをサポートし、スキーマのバージョン管理、互換性ルール、検証、Kafkaプロデューサーおよびコンシューマーとの統合を提供します。
Amazon Web ServicesはAWS Glue Schema Registryを提供します。
これは、Apache Kafka、Amazon Managed Streaming for Apache Kafka(MSK)、Amazon Kinesis、Amazon Managed Service for Apache Flink、AWS Lambdaと統合されるマネージドスキーマレジストリーです。
Avro、JSON Schema、Protobufをサポートしています。
Apicurio Registryは、Kafkaで使用できるオープンソースのスキーマおよびAPIアーティファクト・レジストリーです。
Avro、JSON Schema、Protobufなどの形式をサポートし、Kubernetesなどの環境にデプロイできます。
Apicurioは、Confluentスキーマ・レジストリーAPIとの互換性も提供するため、Confluentのスキーマ・レジストリー・インターフェースを中心に設計されたKafkaアプリケーションでより使いやすくなります。
Redpandaには、Kafka互換のストリーミング・プラットフォームの一部として、スキーマ・レジストリーとの互換性のあるサービスも含まれています。
このアプローチは、組織がApache KafkaではなくRedpandaを使用している場合に有効です。スキーマ管理はストリーミング・プラットフォーム自体の一部として提供できるためです。
Redpandaレジストリーは、代替のKafka対応ストリーミングプラットフォームにより密接に統合されています。
いいえ、スキーマ・レジストリーはコアのApache Kafkaソフトウェアの一部ではありません。Kafkaは記録を保管し、輸送します。スキーマ・レジストリーは、それらのレコードに含まれるデータのスキーマを保管・管理する個別のサービスです。スキーマ・レジストリーは、プロデューサーとコンシューマーが構造化されたイベント・データを一貫して解釈できるようにするために、一般的にKafkaと併用されます。
スキーマ ID は、特定のスキーマ定義の識別子です。スキーマのバージョンは、特定のスキーマまたはサブジェクトに対して管理されているバージョンのシーケンスの中で、そのスキーマがどの位置にあるかを示します。具体的な実装方法はレジストリによって異なります。たとえば、Confluent Schema Registryでは、スキーマIDがレジストリ内のスキーマを一意に識別するのに対し、バージョンはサブジェクトに属します。したがって、同じスキーマであっても、異なるサブジェクトの下で異なるバージョンに関連付けられている場合、同じスキーマIDを持つことがあります。
スキーマ・レジストリーは、主にアプリケーションがデータの構造を理解するために使用する、機械可読なスキーマを保存・管理するものです。また、スキーマのバージョン管理や互換性チェックなどの機能も提供できます。
データ・カタログは、人やシステムが組織全体のデータ資産を検出、理解、管理できるようにすることに重点を置いています。カタログには、ビジネスの説明、所有権情報、分類、データ・セットやデータ・システムに関するその他のメタデータを含めることができます。したがって、スキーマ・レジストリーとデータ・カタログは相互に補完し合うことができます。レジストリはアプリケーションで使用されるスキーマを管理し、カタログは組織のデータ資産に関するより広範な情報を提供します。
スキーマは、フィールドやデータ型などの要素を含むデータの構造を定義します。データ・コントラクトには、スキーマを含めることができるだけでなく、データ作成者とデータ・コンシューマーの間でより広範な期待を定義することもできます。スキーマは、整合性制約、メタデータ、ポリシーと並んで、データ・コントラクトの1つのコンポーネントである場合があります。
適切なスキーマ・レジストリーは、組織の技術要件と既存のデータ・アーキテクチャーによって異なります。考慮すべき要素には、レジストリがサポートするスキーマ形式、互換性ルール、Apache Kafkaやその他のデータシステムとの統合、APIおよびクライアントのサポート、セキュリティおよび認証機能、サービスが管理型か自己管理型かなどが含まれます。
組織は、レジストリーがスキーマの進化、データ・ガバナンス、メタデータ、データ契約をどのようにサポートするか、また既存のプロデューサー、コンシューマー、データ・パイプラインとの互換性も検討する必要があります。レジストリー製品によってこれらの機能の組み合わせは異なるため、選択は通常、レジストリーがサポートする必要があるシステムと要件によって異なります。