Red Hat - Open Innovation Labs の技術ブログ

全900件

2022/10/30

Red HatのService Registryを使用してスキーマの進化に対応しよう！

こんにちは。Red Hatでソリューションアーキテクトをしている杉本拓です。今回の記事では、サービスレジストリの重要性について解説し、APIとスキーマを一元的に管理するための Red Hat の Service Registry の概要と基本的な使い方について紹介したいと思います。この Red Hat Service Registry は Red Hat Application Foundations (Red Hat Integration) に含まれており、Red Hat のマネージドサービス Red Hat OpenShift Service Registry としても提供されています（この Red Hat OpenShift Service Registry は、Red Hat OpenShift API Management と Red Hat OpenShift Streams for Apache Kafka の利用者であれば無償で利用することが可能であり、トライアルでの利用も可能です）。マイクロサービスの連携においてサービスレジストリが重要な理由企業の中に存在するアプリケーションは様々な形でデータの連携を行います。異なるシステムがデータの連携を行うことができるようにするためには、やり取りされるデータのフォーマットや属性をスキーマとして定義します。しかし時間の経過とともにアプリケーションの変更が必要となれば、アプリケーションで使用されるスキーマにも変更が必要となることは多々あります。連携対象となるシステムが1対1であればスキーマの変更による影響は限定的かもしれませんが、企業の中には様々なシステムが存在し、さらに分散する複数のマイクロサービスでやり取りされるデータを検証し、不整合を防ぐためには、アプリケーションの進化とともにスキーマの進化（スキーマエボリューション）への対応を検討しておくことが重要になってきます。サービスレジストリというのはそのためのソリューションとなるものです。 Apache Kafka をマイクロサービス間の連携やデータ連携のためのハブとして利用するケースが増えていますが、Apache Kafka そのものにはデータ検証を行う機能は無いため、スキーマの進化に対応するためにはサービスレジストリを組み合わせて使用する必要があります。メッセージのプロデューサーは Apache Kafka にメッセージを送信し、コンシューマーのアプリケーションがそのメッセージを取得して処理をしますが、プロデューサー側のアプリケーションで属性の追加やデータ型の変更があった場合、コンシューマーでもその対応ができなければデータを適切に処理することができなくなってしまいます。イベント駆動型アーキテクチャにおいては、各マイクロサービスは疎結合な連携をするとしても、プロデューサーが使用しているスキーマをコンシューマーのアプリケーションがあらかじめ把握しておくことは必要であり、スキーマに変更が生じた場合にはどのような変更が発生したのかを知る必要があります。サービスレジストリはスキーマ定義の情報を一元的に格納するための場所であり、プロデューサーのマイクロサービス開発者はスキーマをサービスレジストリに登録し、コンシューマーのマイクロサービス開発者はサービスレジストリを使用してスキーマを検索し、プロデューサーから受け取ったデータを処理できるように実装します。コンシューマーの種類が増えてくる場合、このサービスレジストリの役割は更に重要になってきます。さらにサービスレジストリを使用することで、プロデューサーもコンシューマーも事前に定義されたスキーマを元に開発を行うことができるため、コントラクトファーストの開発アプローチを採用しやすくなります。 Red Hat が提供するサービスレジストリ Red Hat が提供するサービスレジストリの機能は OSS の Apicurio Registry をベースとしています（ Apicurio のサブプロジェクトとしては、以前の赤帽エンジニアブログでも紹介しているように、APIドキュメントやスキーマ（OpenAPI、AsyncAPI、Apache Avro、JSON Schema、Protocol Buffer）を GUI ベースでグラフィカルに設計できる Apicurio Studio / Apicurito もあります）。この Red Hat の Service Registry では、Apache Kafka で使用されるスキーマを格納することができるだけでなく、OpenAPI のドキュメントや Apache Kafka のプロデューサーとコンシューマーが使用する非同期メッセージングのためのAPI仕様である AsyncAPI のドキュメントも一元的に管理することができるようになります。この Red Hat の Service Registry はオンプレミス環境に導入することも可能ですが、ここでは Red Hat がマネージドサービスとして提供している Red Hat OpenShift Service Registry の使い方について説明をしていきたいと思います。 Red Hat OpenShift Service Registryの使い方 Red Hat OpenShift Service Registry を使用するには Red Hat アカウントが必要です。まだ Red Hat アカウントを持っていない場合には、 Red Hat Hybrid Cloud Console にアクセスして、Red Hat アカウントを作成しましょう。Red Hat のマネージドサービスとアカウントの作り方については、こちらの赤帽エンジニアブログの記事もご参照ください。アカウントを作成したら、 Red Hat Hybrid Cloud Console にログインして左の Application and Data Services メニューを選択します。さらにメニューから Service Registry をクリックすると以下のような画面が表示され、Service Registry のインスタンスを作成していくことができます。 [Create Service Registry instance] ボタンをクリックすると、Service Registry インスタンスの新規作成画面が表示されるので、任意の名前をつけて [Create] ボタンをクリックしましょう。 Service Registry のインスタンスが作成できたら、そのリンクをクリックしてAPIドキュメントやスキーマ定義などのアーティファクトをレジストリにアップロードすることができるようになります。以前ご紹介した OpenShift API Designer を使用すると、API Designer と Service Registry の連携機能を利用して API Designer で作成したアーティファクトを API Designer の画面上からこの Service Registry にインポートすることも可能です。アーティファクトのアップロード画面は以下のようになっており、Group & ID、Type、Artifact を入力します。 Group (オプショナル): アーティファクトを管理する上でのユニークな組織やアプリケーションなどのグループ名（デフォルトでは "default" グループ） ID (オプショナル): アーティファクトを識別するためのユニークなID（明示的に指定しない場合には Service Registry によって生成されるUUID） Type (必須): Avro Schema や OpenAPI など、アーティファクトの型を指定（自動的に検出も可能） Artifact (必須): ドラッグ&ドロップやアップロード、URL などでアーティファクトのコンテンツを指定（テキスト入力エリアに直接入力も可能）例えば、Artifact のテキスト入力エリアに以下の Avro Schema をコピー&ペーストし、[Upload] ボタンをクリックしてアップロードしてみましょう（"FullName"という名前のシンプルなAvro Schemaです）。 { "type": "record", "namespace": "com.example", "name": "FullName", "fields": [ { "name": "first", "type": "string" }, { "name": "last", "type": "string" } ]} アップロードが完了すると、以下のように "FullName" という名前のAvroスキーマのメタデータ情報（ID、説明、ステータス、作成日、所有者など）が表示されます。コンテンツルールのセクションでは検証ルール（Validity rule）と互換性ルール（Compatible rule）を設定することができるようになっています。検証ルールではアーティファクトのコンテンツの有効性を検証を行うことができ、互換性ルールでは後方互換や前方互換のルールを設定して新バージョンとの互換性チェックを行うことができます。[Upload new version] ボタンをクリックして新しいバージョンのスキーマを追加することも可能です。アーティファクトの Content タブをクリックすると、アーティファクトの中身を JSON あるいは YAML 形式で表示して確認することができるようになっています。 Service Registry へのアクセス方法プロデューサーやコンシューマーなどのクライアントアプリケーションから Service Registry にアクセスするには、Service Registry インスタンスに接続するための URL とサービスアカウントの情報が必要となります。Service Registry の URL 情報は、Service Registry インスタンスの一覧ページで表示したいインスタンスのオプションメニューから [Connection] を選択すると以下のように表示されます。 Service Registry の API の URL として3つ表示されていますが、Service Registry を使用する新規アプリケーションを開発する場合には、通常 Core Registry API のURLを使用して Service Registry にアクセスしますので、クライアントアプリケーションではこの URL 情報が必要になります。Schema Registry compatibility API は Confluent 社の Schema Registry と互換性のある API、CNCF Schema Registry API は CNCF Schema Registry と互換性のある API の URL 情報です。また、Service Registry と Kafka インスタンスにアクセスするには、各インスタンスへのアクセス権限を持ったサービスアカウントが必要になります。サービスアカウントがまだ作成されていない場合には、[Create service account] ボタンをクリックしてサービスアカウントを作成し、Service Registry インスタンスの [Access] タブの画面で [Grant access] ボタンをクリックしてそのサービスアカウントにアクセス権限を付与します。以上が Red Hat OpenShift Service Registry の概要と基本的な使い方となりますが、次回は実際にクライアントアプリケーションから Service Registry にアクセスするための方法についてご紹介したいと思います。

ビッグデータ, API, OSS, アーキテクチャ, Microservices, 設計, オンプレミス