The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.

SmallRye StorkとQuarkus

先週の Quarkus Insights では、 SmallRye Storkという新しいプロジェクトとそのQuarkusへの統合についてスポットライトを当てました。今回のブログ記事では、Storkについて簡潔にご紹介したいと思います。

This post has been updated to use the quarkus. prefix when configuring stork properties. This prefix is required since Quarkus 2.8.

課題

現在、私たちが構築するシステムは、しばしばマイクロサービスと呼ばれる多数のアプリケーションで構成されています。システムの全体的な動作は、これらすべてのサービス間の相互作用から生まれます。つまり、あるマイクロサービスは、他のマイクロサービスを呼び出すことが多いのです。しかし、ここで問題が発生します。Kubernetesやクラウドのようなダイナミックな環境では、これらのサービスの場所は時間の経過とともに変化する可能性があります。では、マイクロサービスはどのようにして呼び出す必要のあるサービスを見つけるのでしょうか?

サービスディスカバリーは、サービスを登録して検索する仕組みを提供することで、その問題を解決します。しかし、それは別の問題を引き起こします。同じサービスのインスタンスが複数ある場合はどうなるのか?マイクロサービスはどのようにして正しいサービスを選択するのでしょうか?このシナリオは通常、複数のレプリカやバージョンが同時に利用可能な場合に発生します。そのため、サービスディスカバリーに加えて、正しいサービスを選択する方法が必要になります。

Kubernetesなどの一部の環境では、サービスの場所を発見し、トラフィックをロードバランスする方法を提供しています。そうでないものもあります。場合によっては、環境の機能がシステムのニーズに対して十分でないこともあります。

SmallRye Stork

これらの問題を解決するために、私たちは SmallRye Storkを作りました。Storkは両方の機能を備えています。

  • サービスディスカバリー - 呼び出す必要のあるサービスを見つけることを可能とします。

  • サービス選択 - 複数のインスタンスがある場合、適切なものを選択することを可能とします。

Storkとは?

SmallRye Storkは、 サービスディスカバリーとクライアントサイドロードバランシングのフレームワーク です。

最初からHashicorp Consul、Eureka、Kubernetesとの統合が提供されており、ラウンドロビンなどのロードバランサー(サービス選択の処理)の実装もいくつか持ち込まれています。しかし、Storkの最も大きな強みは、その拡張性です。独自のサービス発見メカニズムをプラグインしたり、独自の、おそらくビジネスに関連したサービス選択戦略を実装することができます。

StorkとQuarkus

Quarkus 2.5.0.Finalでは、Quarkus gRPCとQuarkus Reactive REST ClientがStorkを使用してサービスディスカバリーと選択を行うことができます。

あなたは、サービスをどのように探索し、選択したいかを設定するだけです。あとはクライアントが直接対応してくれます。

例えば、Storkを使ってREST Client Reactiveの実際のアドレスを決定するには、クライアントのURIのスキームを stork 、URIのホスト名をStorkのサービス名に設定します。クライアントの configKeymy-client である場合、Hashicorp Consul と round-robin ロードバランサーで使用するためには、以下を `application.properties に追加して下さい:

application.properties
quarkus.rest-client.my-client.uri=stork://hello-service

# configure the discovery and selection of the hello-service
quarkus.stork.hello-service.service-discovery.type=consul
quarkus.stork.hello-service.service-discovery.consul-host=<consul host>
quarkus.stork.hello-service.service-discovery.consul-port=<consul port>

quarkus.stork.hello-service.load-balancer.type=round-robin

プロジェクトのドキュメントでは、Consulとラウンドロビン型ロードバランサーを例に、RESTクライアントでStorkを使用する方法がステップバイステップで説明されています。

サービス選択はかなり高度なものになります。例えば、最小応答時間戦略では、サービスコールを監視し、 最速の サービスインスタンスを選択します。

Quarkus 2.5では、gRPCエクステンションは、応答時間や発生したエラーなどのコールの統計情報を伝搬しません。そのため、最小応答時間など、このデータに依存するロードバランサーは正しく動作しません。現在対応中で、Quarkus 2.6では対応できるようにしたいと考えています。

デモや、更に沢山!

より詳細な説明や事例については、 Quarkus Insightsの第70回目のエピソードをご覧ください。

このデモでは、クライアント側に このプロジェクトを使用しており、各ステップには main ブランチに対応するコミットがあります。バックエンドサービスは このプロジェクト のインスタンスであり、カスタムサービスディスカバリーサーバーの実装は こちらにあります。

結論

この記事では、SmallRye StorkとそのQuarkus統合について簡単に紹介しました。Storkは、サービスを検索して選択する方法を提供します。シンプルでカスタマイズ可能です。Storkの機能の詳細については、近日中に詳しく説明します。

新機能のアイデアをお持ちの場合やバグに直面した場合は、 GitHubのissueを作成してお知らせください。