SmallRye Stork meets 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.
|
What’s the problem?
現在、私たちが構築するシステムは、しばしばマイクロサービスと呼ばれる多数のアプリケーションで構成されています。システムの全体的な動作は、これらすべてのサービス間の相互作用から生まれます。つまり、あるマイクロサービスは、他のマイクロサービスを呼び出すことが多いのです。しかし、ここで問題が発生します。Kubernetesやクラウドのようなダイナミックな環境では、これらのサービスの場所は時間の経過とともに変化する可能性があります。では、マイクロサービスはどのようにして呼び出す必要のあるサービスを見つけるのでしょうか？
サービスディスカバリーは、サービスを登録して検索する仕組みを提供することで、その問題を解決します。しかし、それは別の問題を引き起こします。同じサービスのインスタンスが複数ある場合はどうなるのか？マイクロサービスはどのようにして正しいサービスを選択するのでしょうか？このシナリオは通常、複数のレプリカやバージョンが同時に利用可能な場合に発生します。そのため、サービスディスカバリーに加えて、正しいサービスを選択する方法が必要になります。
Kubernetesなどの一部の環境では、サービスの場所を発見し、トラフィックをロードバランスする方法を提供しています。そうでないものもあります。場合によっては、環境の機能がシステムのニーズに対して十分でないこともあります。
これらの問題を解決するために、私たちは 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のサービス名に設定します。クライアントの configKey が my-client である場合、Hashicorp Consul と round-robin ロードバランサーで使用するためには、以下を `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を使用する方法がステップバイステップで説明されています。
サービス選択はかなり高度なものになります。例えば、最小応答時間戦略では、サービスコールを監視し、 最速の サービスインスタンスを選択します。
| In Quarkus 2.5, the gRPC extension does not propagate statistics of the calls, such as response time or encountered errors. Therefore, a load balancer that relies on this data, such as least-response-time, will not work correctly. We are working on it and hope to have it in Quarkus 2.6. |
デモや、更に沢山！
より詳細な説明や事例については、 Quarkus Insightsの第70回目のエピソードをご覧ください。
まとめ
この記事では、SmallRye StorkとそのQuarkus統合について簡単に紹介しました。Storkは、サービスを検索して選択する方法を提供します。シンプルでカスタマイズ可能です。Storkの機能の詳細については、近日中に詳しく説明します。
新機能のアイデアをお持ちの場合やバグに直面した場合は、 GitHubのissueを作成してお知らせください。
