はじめに
サービスレジストリは、アプリケーションレベルの通信で使用されるデータ構造を格納するためのデータベースです。アプリケーション開発者が、特定のアプリケーションに使用されるスキーマの登録と検索を行える中心的な場所として機能します。
Apache Kafka でサービスレジストリを使用する
ユースケースとして Apache Kafka を使用し、サービスレジストリの仕組みについて見ていきましょう。Kafka はコンシューマーにデータ構造を自動的に提供せず、データ検証をしないため、この特定のユースケースにはサービスレジストリが最適です。Kafka はデータの解析や読み取りを行わないので、重要なリソースを消費せず、その結果、データをコンシューマーに直接、非常に迅速に配信できます。もし Kafka がデータの検証に時間をかけると、パフォーマンスは大幅に低下します。データガバナンスの欠如は Kafka にとって問題ではありません。むしろまったく逆で、それにより、Kafka の主な利点の 1 つである高性能がもたらされます。
しかし、消費するアプリケーションがデータを適切に消費できるようにするには、データ構造のガバナンスを別に実装する必要があります。そのソリューションが、ルールの提供だけでなく、適用も行うサービスレジストリです。
コンシューマーとプロデューサーは Kafka を介してデータを交換します。サービスレジストリを使用すると、プロデューサーとコンシューマーはトラフィックを定義するメタデータを最初から文書化して共有し、それに合意して、データ関連のエラーを回避することができます。メタデータはスキーマとしてサービスレジストリに格納および提供されます。
プロデューサー・アプリケーションの開発者は、スキーマをサービスレジストリに登録します。これにより、プロデューサーが独自のスキーマの仕様に準拠していることが保証されます。サービスレジストリは、登録されたスキーマに準拠していない不良データを拒否することさえできます。
スキーマは、上記の例に示すように、特定のプロデューサー・アプリケーションの開発者が登録することも、開発チーム間で広く使用するために組織が登録することもできます。この 2 番目のケースでは、サービスレジストリは、プロデューサー・アプリケーションの開発者およびコンシューマー・アプリケーション向けのライブラリとして機能します。
一方で、コンシューマー・アプリケーションの開発者も、ライブラリのようにサービスレジストリを利用してスキーマを取得し、プロデューサー・アプリケーションからのデータを消費するアプリケーションを構築できるようにします。スキーマに変更が加えられると、サービスレジストリは、更新された最新のスキーマをコンシューマーに提供します。
サービスレジストリのメリット
サービスレジストリは、開発チームとビジネスに次の利点をもたらします。
データ構造とアプリケーションの分離
サービスレジストリを使用して、データの構造をアプリケーションから切り離し、REST インタフェースを使用してランタイムにデータ構造と API 記述を共有および管理できます。
優れたデータ品質
サービスレジストリはスキーマを検証してデータのエラーを検出し、データの整合性を保ちます。サービスレジストリには、アップロードされたコンテンツが構文的および意味的に有効であり、他のバージョンと下位および上位互換性があることを保証するルールを含めることができます。ただし、スキーマに準拠していない不良データをプロデューサーが送信しようとした場合は、サービスレジストリがそれを阻止します。
信頼できる唯一の文書化されたソース
サービスレジストリは、信頼できる唯一のソースを提供し、関連するすべての関係者によって検証および合意されます。
開発者の生産性向上
サービスレジストリにより、スキーマと API 設計の一貫した再利用が可能になり、プロデューサーまたはコンシューマー・アプリケーションの構築にかかる開発者の時間を節約できます。
コスト削減
ランタイムではなく、開発ライフサイクルの初期段階でデータ関連のエラーを検出することで、プロセスの終了段階でエラーを修正する際に発生する開発時間のコストを節約できます。