サービスレジストリとは

サービスレジストリは、アプリケーションレベルの通信で使用されるデータ構造を格納するためのデータベースです。アプリケーション開発者が、特定のアプリケーションに使用されるスキーマの登録と検索を行える中心的な場所として機能します。

先進的なソフトウェア設計には、アプリケーション・プログラミング・インタフェース (API) を介してデータを交換する分散型の疎結合マイクロサービスが不可欠です。

大規模組織の内外で、アプリケーション間のこのデータ交換が極めて重要です。すべてのアプリケーションは、ビジネスを継続して実行するために、常に秒単位でデータを送受信しています。したがって、そのデータの整合性を確保することは非常に重要です。しかし、これらの多様なアプリケーションすべてにおいて、実際にこの重要データを消費する準備が整っていることを確認するにはどうすればよいでしょうか。主要なソリューションの 1 つが、サービスレジストリです。

たとえば Apache Kafka のような、データを転送するメッセージングシステムには、データ検証の機能は備わっていません。消費できないデータをデータプロデューサーが送信したら、どうなるでしょうか。たとえば、プロデューサーがフィールドの追加や削除を行ったり、データ形式を変更したりすれば、どうなるでしょう。データのコンシューマーにこの変更が通知されない場合、そのデータを適切に処理することはできません。最悪の場合はシステム全体が停止します。

データコンシューマーは、データ交換を行う前に、プロデューサーが使用しているデータ構造 (スキーマと呼ばれる) を知る必要があります。また、そのスキーマに変更が加えられた場合、それも知る必要があります。データを拡張してもメッセージングシステムに障害が発生しないようになっていなくてはなりません。

ファイルが添付された E メールを送信するなどの方法で、プロデューサーがコンシューマーに手動でスキーマを送信することはできます。しかし多くの手動プロセスと同様、このような方法は複雑になりかねないうえエラー発生の可能性を否定できず、監査も難しくなってしまう場合があります。結果どうなるかといえば、サービスの停止や、障害の原因を特定する簡単な方法の欠如につながります。

一方、サービスレジストリは、簡単にアクセスできるプラットフォームを介してこの情報を提供できます。これは、プロデューサー・アプリケーションの開発者が、特定のアプリケーションに使用しているスキーマを登録できる中心的な場所として機能します。また、コンシューマー・アプリケーションの開発者は、サービスレジストリを使用してそのスキーマを検索し、アプリケーションがそのプロデューサーからのデータを消費できるようにします。サービスレジストリに格納できるスキーマには、Apache Avro、JSON Schema、Google Protocol Buffer などがあります。

サービスレジストリには、スキーマの他にもアセットを格納でき、それらは「アーティファクト」とも呼ばれます。たとえば、アプリケーションレベルの同期通信の API 仕様をサービスレジストリに格納することもできます。サービスの数が増えて複雑になれば、サービスレジストリの有益性はさらに高まっていきます。

サービスレジストリは長年使用されてきた概念ですが、マイクロサービスにおけるこの目的に極めて適しているため、最近、新たな関心の的になっています。サービスレジストリは、プロデューサーおよびコンシューマー・アプリケーションの開発者が合意している、特定のアプリケーションのデータ構造に関する信頼できる唯一のソースとして機能します。また、「コントラクトファースト」のアプローチをサポートしています。サービスレジストリは、最初にアプリケーションをコーディングしてから、他のアプリケーションや組織がそのアプリケーションと通信できるように後付けとしてコントラクトを提供するのではなく、入力、出力、ペイロードの仕様、場合によっては検証ルールなど、コントラクトを事前に指定します。すべてが明確に指定されているため、相互作用がどのように機能するかについて疑問の余地はありません。

ユースケースとして Apache Kafka を使用し、サービスレジストリの仕組みについて見ていきましょう。Kafka はコンシューマーにデータ構造を自動的に提供せず、データ検証をしないため、この特定のユースケースにはサービスレジストリが最適です。Kafka はデータの解析や読み取りを行わないので、重要なリソースを消費せず、その結果、データをコンシューマーに直接、非常に迅速に配信できます。もし Kafka がデータの検証に時間をかけると、パフォーマンスは大幅に低下します。データガバナンスの欠如は Kafka にとって問題ではありません。むしろまったく逆で、それにより、Kafka の主な利点の 1 つである高性能がもたらされます。

しかし、消費するアプリケーションがデータを適切に消費できるようにするには、データ構造のガバナンスを別に実装する必要があります。そのソリューションが、ルールの提供だけでなく、適用も行うサービスレジストリです。

コンシューマーとプロデューサーは Kafka を介してデータを交換します。サービスレジストリを使用すると、プロデューサーとコンシューマーはトラフィックを定義するメタデータを最初から文書化して共有し、それに合意して、データ関連のエラーを回避することができます。メタデータはスキーマとしてサービスレジストリに格納および提供されます。

プロデューサー・アプリケーションの開発者は、スキーマをサービスレジストリに登録します。これにより、プロデューサーが独自のスキーマの仕様に準拠していることが保証されます。サービスレジストリは、登録されたスキーマに準拠していない不良データを拒否することさえできます。

スキーマは、上記の例に示すように、特定のプロデューサー・アプリケーションの開発者が登録することも、開発チーム間で広く使用するために組織が登録することもできます。この 2 番目のケースでは、サービスレジストリは、プロデューサー・アプリケーションの開発者およびコンシューマー・アプリケーション向けのライブラリとして機能します。

一方で、コンシューマー・アプリケーションの開発者も、ライブラリのようにサービスレジストリを利用してスキーマを取得し、プロデューサー・アプリケーションからのデータを消費するアプリケーションを構築できるようにします。スキーマに変更が加えられると、サービスレジストリは、更新された最新のスキーマをコンシューマーに提供します。

サービスレジストリは、開発チームとビジネスに次の利点をもたらします。

データ構造とアプリケーションの分離

サービスレジストリを使用して、データの構造をアプリケーションから切り離し、REST インタフェースを使用してランタイムにデータ構造と API 記述を共有および管理できます。

優れたデータ品質

サービスレジストリはスキーマを検証してデータのエラーを検出し、データの整合性を保ちます。サービスレジストリには、アップロードされたコンテンツが構文的および意味的に有効であり、他のバージョンと下位および上位互換性があることを保証するルールを含めることができます。ただし、スキーマに準拠していない不良データをプロデューサーが送信しようとした場合は、サービスレジストリがそれを阻止します。

信頼できる唯一の文書化されたソース

サービスレジストリは、信頼できる唯一のソースを提供し、関連するすべての関係者によって検証および合意されます。

開発者の生産性向上

サービスレジストリにより、スキーマと API 設計の一貫した再利用が可能になり、プロデューサーまたはコンシューマー・アプリケーションの構築にかかる開発者の時間を節約できます。

コスト削減

ランタイムではなく、開発ライフサイクルの初期段階でデータ関連のエラーを検出することで、プロセスの終了段階でエラーを修正する際に発生する開発時間のコストを節約できます。

Red Hat Integration データシートを入手する