Quarkus 対 Spring Boot

現代のアプリケーション開発とアーキテクチャにおいては、製品に必要なあらゆる機能を備えたモノリシックな大規模アプリケーションから、特定の目的を持つ多数の小規模サービスへと大きな転換が起こっています。この流れを受けて、マイクロサービスフレームワーク（マイクロフレームワーク）の時代が到来し、このパラダイムにおけるアプリケーションのプロトタイプ作成、構築、設計が容易になりました。

Quarkus と Spring Boot を比較すると、それぞれがマイクロサービス アプリケーション開発者としての目標を達成するのに役立つ独自の強みを備えていますが、どちらを選択すべきでしょうか。

Quarkus と Spring Boot: 違いは何ですか?

QuarkusとSpring Bootのどちらを選ぶか迷っているなら、結局のところは、何を構築し、どこで実行するかが重要です。Quarkusはクラウドネイティブ環境向けに構築されており、起動時間が短く、メモリ使用量が少なく、Kubernetesとのスムーズな統合が可能です。Spring Bootは、エンタープライズアプリ開発において実績のある頼れる存在です。豊富な機能と強力なコミュニティサポートに加え、既にSpringエコシステムを利用している場合には、導入も容易です。

Quarkusとは何ですか？

クォークス は、GraalVM と HotSpot 向けに調整された Kubernetes ネイティブ Java フレームワークであり、最高の Java ライブラリと標準から作成されています。 Quarkus の目標は、Java を主要なプラットフォームにすることです。 Kubernetes サーバーレス環境にも対応しています。また、開発者には、より幅広い分散アプリケーションアーキテクチャに最適に対応する、統合されたリアクティブ型および命令型プログラミングモデルも提供されます。

Quarkus の注目すべき機能には次のようなものがあります。

1. ライブコーディングQuarkusはライブコーディングを可能にする開発モードを提供しており、開発者はアプリケーションを再起動することなく、コードを変更して即座に結果を確認できます。この機能により、開発プロセスが大幅にスピードアップします。
2. 統一された構成Quarkus は集中化された構成システムを提供し、アプリケーション全体の構成プロパティの管理と整理を容易にします。
3. リアクティブプログラミング: Quarkus は、高性能なイベント駆動型アプリケーションを構築するためのツールキットである Vert.x によるリアクティブ プログラミングをサポートしています。 この機能により、開発者は大量の同時接続を処理できる応答性と回復力のあるシステムを作成できます。
4. 高い拡張性: Quarkus には拡張機能の広大なエコシステムがあり、RESTEasy、Hibernate、Apache Camel などのさまざまなテクノロジー、ライブラリ、フレームワークと簡単に統合できます。
5. ネイティブ イメージの生成Quarkus は GraalVM を使用したネイティブ実行可能ファイルの生成をサポートしており、従来の Java アプリケーションと比較して起動時間が短縮され、メモリ使用量が削減されます。

Quarkusを使い始める

Quarkus の新しいサービスを立ち上げるのは驚くほど速かったです。Spring Boot のスキャフォールディングやそれに付随する配線に苦労したことがある人にとっては、これは良い気分転換になるでしょう。

CLIとWebベースのプロジェクトジェネレーターを使えば、簡単に使い始めることができます。必要な拡張機能（Kafka、REST、Hibernateなど）のチェックボックスをいくつかオンにするだけで、すぐに使えるスタータープロジェクトが完成します。./mvnw quarkus:dev で実行すると、ライブリロードが組み込まれた開発モードになります。ファイルを編集して保存すれば、すぐに反映されます。再起動も待ち時間もありません。

定型的なコードはほとんどなく、「Hello, world」とだけ出力するために、設定ファイルに埋もれる必要もありません。また、軽量で最初からコンテナ向けに設計されているため、Kubernetes上でヘルスチェックとメトリクスを実装して、予想よりも早く稼働させることができました。

学習曲線？それほど急ではありません。Javaに慣れていて、CDIを触ったことがあるなら、ほとんどの部分は自然に感じられます。初心者でも、ゆっくりと慣れていけば大丈夫です。Quarkusは、必要がない限り、リアクティブプログラミングを強制することはありません。

Spring Bootとは何ですか？

春のブーツ マイクロサービスを構築するためのオープンソースのJavaベースのフレームワークです。Pivotalチームによって開発され、スタンドアロンおよび本番環境対応のSpringアプリケーションの構築に使用されています。マイクロサービスアーキテクチャにおいて、よく選ばれるアプリケーションフレームワークです。

以下に、Spring Boot の注目すべき機能をいくつか示します。

1. 自動構成: Spring Boot は、含める依存関係に基づいてアプリケーションを自動的に構成し、必要な手動構成の量を減らします。 この機能により、開発プロセスが合理化され、開発者は構成ファイルの処理ではなく、コードの記述に集中できます。
2. 組み込みサーバー: Spring Boot アプリケーションは、Tomcat、Jetty、Undertow などの組み込み Web サーバーでパッケージ化できるため、アプリケーションを外部サーバーにデプロイする必要がなくなります。 この機能により、展開プロセスが簡素化され、自己完結型アプリケーションの作成が容易になります。
3. スターターの依存関係: Spring Boot は、開発者が Web サービス、データ アクセス、セキュリティなどの一般的な機能をすばやく追加して構成できるようにする、事前構成済みの「スターター」依存関係のセットを提供します。 これらのスターター依存関係は、ボイラープレート コードを削減し、プロジェクト間で一貫した構成を確保するのに役立ちます。
4. アクチュエータ： Spring Boot Actuator モジュールは、ヘルスチェック、メトリクス、アプリケーション情報などの組み込みの本番対応機能を提供し、本番環境でのアプリケーションの監視と管理を容易にします。
5. YAML 構成: 従来の Java プロパティ ファイルに加えて、Spring Boot は YAML ベースの構成ファイルをサポートします。 この機能は、アプリケーションを構成するためのより人間が読める簡潔な構文を提供します。

コミュニティと標準

フレームワークを選択するときに、コミュニティや標準が常に最初に考慮されるわけではありませんが、6 か月後 (または 6 年後) にそのサービスを保守する側になると、それらは重要になります。

Quarkus には、この分野で 2 つの大きな利点があります。

まず、Red Hatの支援を受けているため、一時的なオープンソースプロジェクトではなく、本格的なサポートとロードマップの計画が裏付けされています。次に、Eclipse MicroProfileをベースに構築されているため、Javaエコシステムに既に存在する多くのツールや標準規格とスムーズに連携します。

コミュニティも驚くほど堅実です。ドキュメントは有用で、スケジューラの遅延が設定できないといったエッジケースが発生した場合でも、機能リクエストは2週間以内に修正されることが知られています。このような迅速な対応は、Quarkusが単に安定しているだけでなく、今後も正しい方向へ進化し続けていくという大きな自信につながります。

Spring から移行してきた方は、まだそれほど大規模なコミュニティではないことに気付くでしょうが、そこに存在するのは集中的で、アクティブで、熱心な人たちです。

LogicMonitorマイクロサービステクノロジースタック

LogicMonitorのメトリックパイプライン（環境内でQuarkusの概念実証を構築した場所）は、次のテクノロジスタックに展開されます。

• Java 11（corretto、cuzライセンス）
• Kafka（AWS MSKで管理） 
• Kubernetes 
• Nginx（Kubernetes内の入力コントローラー）

なぜSpringBootからQuarkusに移行するのですか？

私たちのレガシーパイプラインはSpringとTomcatに基づいていました。 このフレームワークの選択について、メンテナンスとデプロイメントを継承したときに気に入らなかったことがいくつかありました。

• メモリとCPUの消費：実行されている操作のために、SpringとTomcatのフレームワークによって、アプリケーションの主な目的の外で膨大な量のリソースが使用されていました。
• ウォームアップ時間：Springアプリケーションの起動には10〜20秒かかる場合があり、その時点でアプリケーションのウォームアップが開始されます。
• コードの削減：開発者として、私たちは皆定型コードを嫌います。 「ヌフは言った。
• テスト：Quarkusを使えば、ユニットテストと統合テストの両方を簡単に書くことができます。@QuarkusTestアノテーションを追加するだけで、アプリケーション全体が起動し、テストが実行されます。
• スケールアウト (水平) 対 スケールアップ (垂直): 各アプリケーションが (リソースの面で) 小さくなるほど、追加できるものが多くなり、水平方向のスケーラビリティが勝ります。
• 学習曲線：Quarkusのオンラインドキュメントは非常に単純で、吸収しやすいものでした。

他のJavaマイクロフレームワークよりもQuarkusをどのように選択しましたか？

Quarkus に加えて、Helidon.io と MicroNaut という 2 つの Java マイクロフレームワークも調査しました。

マイクロノート

MicronautはおそらくQuarkusに最も類似しているでしょう。フレームワークの宣言的な性質は非常に似ており、私たちが頻繁に使用する技術をすぐにサポートしていました。 

• カフカ
• ドッカー / Kubernetes
• API
• リレーショナルデータベースと非リレーショナルデータベース
• 受け台

Micronautを使用しなかった主な理由は、それがEclipseマイクロプロファイルフレームワークに基づいていたのではなく、自家製のものであったためです。 QuarkusはRedhatに支えられており、マイクロプロファイルに基づいているため、コミュニティのサポートとドキュメントに関してより良い状況にあると感じました。

ヘリドンアイオ

Micronaut を採用しなかった主な理由は、Eclipse のマイクロプロファイルフレームワークではなく、自社開発のものだったからです。Quarkus は Redhat の支援を受けており、マイクロプロファイルをベースとしていたため、コミュニティのサポートとドキュメント面でより優れていると感じました。

私たちが学んだこと

パイプライン内のアプリケーションのXNUMXつのPOCの構築に着手したとき、成功基準をレイアウトする内部ドキュメントを設定しました。

APIの設計と実装は非常に簡単でした。 Quarkusと一緒に行きました 簡単な実装 RFCに準拠しており、インフラ内の他のアプリケーションで既に使い慣れているJERSEYフレームワークに類似していることが分かりました。しかし、既存アプリケーションのリクエスト認証方法（自社開発のリクエストヘッダートークンに基づく）との後方互換性の問題により、JERSEYの組み込み認証実装は使用できませんでした。

Kubernetesサポート

Quarkusフレームワークで特に気に入った点の一つは、KubernetesのLiveness/Readinessプローブの設定が簡単だったことです。依存関係（smallrye-health）を追加し、 の監視で、KafkaのLiveness/Readinessプローブが準備完了です。アプリケーションが正しく設定されていることを確認するための独自のヘルスチェックを追加するのは、クラスにアノテーションを付けてシンプルなインターフェースを実装するだけで簡単でした。その後、プローブは「/health」（LivenessとReadinessの両方のチェック結果を取得）、「health/live」、「health/ready」エンドポイントで利用できるようになりました。

CDIBeanインジェクション

プローブに加えて、私たちはまた本当に好きでした CDIBeanインジェクションこれはSpringのDI実装よりも概念化が容易で、通常よりもはるかに迅速に開発できることがわかりました。ただし、メトリクスを公開するには、Bean定義アノテーションを持つクラスから公開する必要があることに注意してください。これはMicroProfileの仕組みの一部です。メトリクスについては後ほど詳しく説明します。

　

構成に関して、Quarkusはプロファイルと構成をサポートしています。 複数の情報源。 LogicMonitorでは、中央構成サービスを使用しているため、最終的にはに基づいてシステムプロパティを設定しました。 熱心にインスタンス化されたBean そのサービスの構成設定をポーリングしました。 @ConfigPropertyアノテーションの大きなユースケースはありませんでした。これは、ほとんどの構成を実行時に簡単に変更できるようにするためであり、通常、これらはBeanのインスタンス変数で定義されます。 POCアプリのほとんどのBeanは@ApplicationScopedであったため、構成値を静的にする必要がありました。

QuarkusKafkaの制限

QuarkusはSmallRye Reactive Messagingフレームワークを通じてKafkaをサポートしています。このフレームワークはKafka Producerでは良好な結果が得られましたが、Kafka Consumerアプリケーションではうまくいきませんでした。Kafka Producerは、命令型での使用向けにセットアップするのが非常に簡単です。 このガイドプロデューサーのデフォルトの構成値に関して、いくつか注意すべき点があります。この値によって、私たちは多くの問題（そして数時間のトラブルシューティングの頭痛）に悩まされました。

• オーバーフロー戦略: デフォルトでは、プロデューサーのオーバーフロー戦略は小さなメモリバッファを使用するものです。Kafkaエミッターは、Kafkaコンシューマー（リアクティブメッセージング）からのシグナルを待機し、指定されたメッセージが正しく処理されるかどうかを確認します。しかし、Kafkaコンシューマーが別のアプリケーションに存在し、エミッターにシグナルを送信できない場合、これは好ましくありません。そのため、この戦略をNONEに設定します。この場合のリスクは、アプリケーション内にKafkaコンシューマーが処理に対応しているかどうかを知る手段が何もないことです。しかし、監視ソリューションでKafkaクライアントのJMXメトリクスを直接使用することで、この問題を解決しました。

• WaitForWriteCompletion: デフォルトでは、プロデューサーはKafkaからの確認応答を待ってメッセージを正しく完全に受け入れていました。 たとえ acks が 0 に設定された場合でも同様です。 デフォルトではこの構成値は true なので、処理するデータの量に対応するために false に設定する必要がありました。

Kafka Consumer に関しては、主に次の 2 つの領域でかなりの問題に遭遇しました。

• 自動コミット: デフォルトでは、Quarkus コンシューマーはすべてのメッセージを受信した後に Kafka にコミットし、コンシューマー ラグの大きな蓄積を引き起こしていました。 
• シングルスレッドの消費者: これにより、実際に メトリック処理にQuarkusKafkaコンシューマーを使用しないでください長時間のトラブルシューティングと頭を悩ませた末、チームはKafkaがシングルスレッドであるだけでなく、メッセージをシリアル処理していることを発見しました。このままでは処理量に対応しきれなかったため、Apache Kafka Java SDKをベースにしたKafkaコンシューマーを構築し、アプリケーションコンテナごとに複数のコンシューマースレッドを用意しました。ただし、QuarkusのKafkaコンシューマーは、メッセージ量がはるかに少ない別のユースケースのために残しておきました。設定が簡単だったからです。

• QuarkusKafkaコンシューマーに関するその他の「落とし穴」は次のとおりです。
  • あなたは非常に注意して返す必要があります 完了した将来; そうしないと、リアクティブフレームワークが各メッセージを処理するのに時間がかかりすぎ、場合によっては無期限にハングすることがわかりました。 
  • @Incoming メソッドでスローされた例外も適切に処理されません (コンシューマーが停止します) ので、ここでも注意してください。
  • リアクティブ メッセージング フレームワークのチャネル実装では、パターンに基づいてトピックを消費することはできません (つまり、チャネルごとに 1 つのトピックしか消費できません)。

Quarkus は、JMX 経由の既存の Java モニタリングと非常にスムーズに連携しました（ガベージコレクション、ヒープ、スレッド、稼働時間などのすべてのデータソースが適用され、データが自動的に収集されました）。また、独自のアプリケーションメトリクスを簡単に定義することもできました。個人的には、このアプリの最大のメリットの一つは、マイクロプロファイルメトリクスを使用できることでした。シンプルなアノテーションを追加するだけで、操作の時間と回数を計測でき、これらのメトリクスを「/metrics/application」エンドポイントから即座に利用できるようになりました。

@Timedアノテーションは、最小値、最大値、平均値、スループット、パーセンタイルなど、膨大な情報を提供します。このスクリーンショットには、 フォールトトレランス機能 （ちなみに、独自の指標を公開しています）。それに加えて、 スケジュールされたタスクを発見できたのは嬉しい驚きでした（余談ですが、スケジューラの初期遅延は設定できないことがわかったので、機能リクエストを提出したところ、2週間以内に修正されました！）。さて、メトリクスに戻りましょう。

ゲージとカウンターも超簡単です:

Quarkusでのログ記録はJBoss経由で行われ、logging.propertiesファイルを追加すると、 物事を調整する 問題ありません。

Quarkusのパフォーマンス：大幅な改善

• CPUデプロイ後、Quarkus は以前の Spring/Tomcat ソリューションの約 15% の CPU を使用していることがわかりました。Kubernetes における POC アプリケーションのリソース要求/制限の 200 つを大幅に削減することができました（インフラストラクチャの Kubernetes ワーカーノード全体で約 XNUMX コア相当）。
• メモリまた、Quarkus が以前のメモリの約 12% を使用していることもわかったので、ここでも大幅にスケールダウンすることができました (このアプリケーションだけでインフラストラクチャ全体で約 500 GB のメモリ削減)
• スタートアップ: 以前は15秒だったのが、今では平均85秒短縮され、以前よりXNUMX%も速くなりました。

Quarkus と Spring Boot はどちらも確実な選択肢ですが、どちらが適切かは状況によって異なります。

クラウドネイティブのコンテナ化環境で、起動速度、リソース使用量の削減、Kubernetesとの緊密な統合を重視するなら、Quarkusはまさに画期的なソリューションです。起動速度は85%高速化し、CPU使用率は従来の15%、メモリ使用量は12%削減と、大規模な環境でも大幅な節約を実現しました。

一方、Spring Bootは、特にSpringエコシステムに精通しているエンタープライズアプリに最適です。成熟度が高く、強力で、豊富な統合機能を備えているため、複雑で従来型のデプロイメントに最適です。

Quarkusは私たちにとってまさに理想的なプラットフォームでした。軽量で高速、そして私たちが運用するマイクロサービス向けに構築されているからです。完璧ではありませんが（Kafkaにはいくつか癖がありました）、そのトレードオフは十分に価値がありました。

クラウド向けに構築していて、肥大化のないパフォーマンスを求める場合は、Quarkus を真剣に検討する価値があります。