OpenShift上のアプリケーションのデプロイにQuarkusがどのように使用されたか。

数年前から、私はKubernetesのプロジェクトに参加しています。

これらの目標に加えて、アプリケーションがテナントごとにデプロイされるという事実に関連した制約がありました（つまり、規制に関連した理由もありますが、マルチテナントではありません）。アプリケーションによっては、数十のテナントが存在する可能性があり、その場合、テナントごとにアプリケーションを1回デプロイすることになります（つまり、あるアプリケーションに10のテナントがあった場合、本番では10のプロセスが実行されることになります）。しかし、物理的にプロセスを分離する必要がある場合は、異なるビジネスルールに基づいて、一部のテナント、IT環境、地理的ゾーンの間で、設定の一部を共有することができます。高度に単純化、因数分解された構成部分は、開発チームにとっては真の意味での単純さの源となり、デプロイメントプロセスにとっては真の意味での複雑さの源となります。

プロジェクト終了時には、さまざまなクラスターで10,000個のポッドが含まれているという予測もありました。

その複雑さを考慮して、私たちは設定とデプロイのための独自のツールを作成しました。最初のバージョンはAnsibleをベースにしたもので、Towerのワークフローに対応していました。さまざまな理由から、1年前にJavaで書き直すことにしました。主な理由は:

しかし、一つ気になったのは、メモリ消費量、CPU使用率、起動時間でした。というのも、あるアプリケーションでは、各テナントがそれぞれのデプロイメントプロセスで独立してデプロイされるからです。というのも、アプリケーションフレームワークは生産性や標準化の面では優れていますが、抽象化の面ではリソースコストがかかるからです。そのため、プログラムはプレーンなJavaで書かれており、サイズもユースケースも十分に小さかったので、クリーンなコードのためにいくつかのパターン（例：コンストラクタベースのインジェクションを手作業で行う）に頼ることを条件に、それで済ませることができました。このプログラムは ocpdeploy といいます。

Tower からの移行に伴い、Tekton パイプラインのタスクとして _ocpdeploy_を実行することで、Kubernetes インフラストラクチャを活用することにしました。これにより、再現性が得られ、異なるアプリケーションや、同じアプリケーションの異なるテナントを異なる _ocpdeploy_バージョンでデプロイすることができました。java (他のハイレベル言語でも可) を使用することで、設定処理のための複雑なアルゴリズムを実装することができる一方で、高いレベルの生産性と保守可能なコードを提供し、広範なリグレッション・テスト・スイートのおかげで _ocpdeploy_のリリースの品質レベルが向上しました。

全てが順調だったのは、複数のテナントを同時にデプロイしたり、異なるアプリケーションをデプロイするようになるまでです。 _ocpdeploy_コンテナのサイズは 200 millicores 、RAMは 280 Mb でした。いくつかのアプリケーションでは、約30のテナントがあり、それらはすべて並行してデプロイされます。これは30ポッドを意味し、 6 cores と 8 Gb のRAMを占めていました。しかし、デプロイは多くの場合、営業時間後の午後7時から8時の間に行われることが多いのです。また、起動時にクラスタに負担をかけるSpringBootやWildFlyのアプリケーションに加えて、複数のデプロイを並行して実行する場合、 _ocpdeploy_自体が受ける影響を心配し始めました。

1年前、私たちは _Ocpdeploy_でQuarkusのPOCを開始することにしました。その目的は、QuarkusをGraalVMの実行可能ファイルとしてデプロイすることでした。遭遇した主な課題は、使用していたいくつかのライブラリでGraalVMがサポートされていないことに関連していました。FreeMarker、 SMBJ（Server Message Block SMB2およびSMB3プロトコルを実装したJavaクライアントライブラリ）、Fabric8 OpenShiftクライアント（OpenShift固有のCRDをインスタンス化する際）、そして独自の集中型ログシステムにログを送信する自作のJavaエージェントです。

幸いなことに、コマンドモードアプリケーションのサポート、restクライアント、Vaultエクステンション、Fabric8 Kubernetes Clientのサポートなど、他の部分はすでにQuarkusに存在しており、コアに追加された新しいOpenShift Clientエクステンションのベースとなりました。Kubernetes Clientエクステンションだけでも、プロジェクトにとって大きな後押しとなりました。というのも、スタート時にはArgoが利用できなかったので、 apply_と _prune を自分たちで実装しなければならなかったからです。

FreeMarkerについては、 ppalagaと carlosthe19916の作業に大きく影響されたコードで、Quarkiverseに新しいエクステンションを導入しました。SMBJについては、社内のQuarkiverseでエクステンションを作成しました。また、ロギングクライアントについては、 quarkus-logging-gelf のエクステンションからヒントを得て、追加の社内エクステンションを作成しました。

ライブラリをネイティブで動作させるには、Quarkusプロジェクトから提供される非常に優れたドキュメントと、フレームワークでのサポート（ _プロセッサ_や _レコーダー_など）が役立ちました。 Quarkusのエクステンションでネイティブをサポートする。

ちょっとした問題が発生したとき（SMBJは思ったよりも厄介だった）、 GraalVMのトレースエージェントから助けを得ました。

時々使用していたエクステンションのリストは以下の通りです。 cdi, config-yaml, freemarker, hibernate-validator, kubernetes-client, openshift-client, rest-client, restclient-jackson, vault (加えて、SMBJと私たちの内部集中型ログシステムのための内部エクステンション)。

最終的には、必要なライブラリがすべてネイティブモードで動作するようになったので、アプリケーションを _本物の_Quarkusアプリケーションのように移行する作業に切り替えることができました。

これにより、Kubernetesのyaml生成、 snapshot、様々な状況での _replay_を通じた広範なテストが可能となり、すべての設定を _MP config_に準拠したものに変換することができました。

そして、いくつかのベンチマークを実行し、旧バージョンと比較してリソース消費量を評価しました。起動時間についてはあまり気にしていませんでした。非常に優れていることはわかっていましたから。起動時間が数秒以内に収まっていれば（プレーンなJavaバージョンで経験していたことですが）、問題ありませんでした。しかし、メモリとCPUの消費は別の話でした。この試みは、実際に何らかの利益が得られることを期待して行われました。

プレーンなJavaバージョンでは、 180 Mb までコンテナを絞り込むことができました（それ以下では、 _OOM_になるか、 _GC_がパフォーマンスを殺してしまいます）。また、ネイティブ版では、 50 Mb まで下げることができました。

そして、さまざまな構成（ plain Java 180 Mb 、 Quarkus native 180 Mb 、 Quarkus jvm 180 Mb 、 Quarkus native 50 Mb 、 50 millicores request=limit から始めて、 100 、 150 、 …​）で数回の実行を行いました。

50 millicores では、 Quarkus native 180 Mb が 20 秒、 Quarkus native 50 Mb が 60 秒、その他の 2 つが 300 秒で実行されます。つまり、 180 Mb を ocpdeploy に許可すれば、300秒から20秒になるということです。 _15_倍の改善です。

250 millicores では、 Quarkus native 180 Mb が5秒以下、 Quarkus native 50 Mb が10秒、その他の2つが40秒前後でした。

また、デプロイメントを60秒以下にするために、どれだけのCPUが必要かを調べました。

Quarkus native 50 Mb では 50 millicores 、 plain Java 180 Mb と Quarkus jvm 180 Mb では 240 millicores でした（ Quarkus native 180 Mb は、最初のテストで説明したように「最悪」の結果が 20 秒だったため、対象外となりました）。つまり、時間に制約がある場合は、 240 millicores から 50 millicores へ、また、 180 Mb から 50 Mb へは、Quarkus native へ移行することで対応できるということです。

Quarkus native 180 Mb と 50 Mb の比較も興味深いものでした。というのも、メモリと CPU のノブを上げ下げすることで、ユースケースの実行時間を調整できることがわかったからです。実行時間とリソース消費の間のスイートスポットをどこに設定するかは、私たち次第です。

最後に興味深い観察結果として、 plain Java 180 Mb の結果が Quarkus jvm 180 Mb とほぼ同じだったことが挙げられます。これは、保守性と生産性を提供するアプリケーションフレームワークのコストが、私たちのケースでは0だったということです。ケーキを食べているようなものですね。私たちの場合、メモリとCPUを大幅に節約できるのであれば、実行速度が遅くても構わないと考えていましたが、それが実現できました。

Program execution in seconds for different limits (in millicores)

GraalVMでアドホック・ライブラリを動作させる上での課題以外にも、予期せぬ動作やちょっとした問題点がいくつかありました。

これはかなりの量に見えますが、実際にはこれらの箇条書きはどれも大きな問題ではなく、回避できないものでもありませんでした。いくつかの問題は設定に関するものでしたが、これはプログラムがTektonタスクとして実行されていたためで、Tektonではオプションのパラメータを定義する際の柔軟性が限られています。ここに挙げたのは、回避しなければならなかった点のみです。多くの問題や質問は、Google Groupでの回答や実際の修正により、進行中に解決されました。

もう一つの課題は、ネイティブビルドの時間と、その間のメモリとCPUの使用量に関するものでした。そこで私たちがとった方法は、マスターでのみネイティブ実行可能ファイルを生成し、フィーチャーブランチではjvmモードでテストを実行するというものでした。必要であれば、特定のフィーチャーブランチでネイティブテストを行うという選択肢もあります。しかし、新しいライブラリを統合するのでなければ、jvmテストを通過させることで、ネイティブでも同様の動作をするという十分な自信を持つことができました。

もう一つの工夫は、新しいビルドが開始されたときに、 _マスター_の現在のビルドをキャンセルすることでした。理論的には、別のコミットが行われたためにビルドがキャンセルされるのはフラストレーションがたまるかもしれません。実際には、PRが _master_にマージされる割合は低いままだったので、この問題はありませんでした。

しかし、社内で開発するQuarkusアプリケーションの数を増やしたいと考えた場合、ビルドインフラのサイズには疑問が残ります。

オリジナルのソリューションと比較した場合の唯一の欠点は、リグレッションテストスイートの実行が遅くなったことです。 _MPconfig_を使用していたので、異なるコンフィグをテストするたびに、新しいQuarkusコンテキストを起動する必要がありました。幸いなことに、新しいコンテキストの起動はQuarkusでは非常に高速ですが、それでも元々のプレーンなJavaソリューションに比べればかなり遅いです。

Vault、FreeMarker、OpenShift Clientのエクステンションの作業の他に、Quarkus内外でいくつかのPRに貢献し始めました。これは、以下のような改善を得るためのプロセスをスピードアップすることを期待しています。

特筆すべきは、Quarkusのコミュニティが成功の大きな要因になっていることです:

移行に要した期間はわずか数ヶ月で、昨年末にはQuarkusを搭載した _ocpdeploy_で最初のOpenShiftアプリケーションのデプロイを開始しました。それ以来、何百ものデプロイメントを実行するために使用されました。限られた労力で新しいリリースのペースを追うことができました。バグはほとんど発生せず、通常は次のリリースに間に合うように修正されました。Quarkusが提供するアプリケーションフレームワークにより、コードの構造化が進み、保守性が向上し、モック機能やテストプロファイルを使ったテストが容易になりました。 _ocpdeploy_の開発は、Quarkusの開発者ではなく、Javaの専門家でもないチームメンバーによって行われたことも興味深い点です。これは、フレームワークが、全体的な構造（例：コンポーネント、テスト、構成、ci）が整ってしまえば、それを忘れることができるほど軽量であることを示しています。

私たちのプログラムは、それが動作しなければビジネスが止まらないという意味で、ビジネスクリティカルではありませんでした。しかし、OpenShiftのマイクロサービスをすべてデプロイするには、このプログラムしかありません。 _ocpdeploy_は明らかに超高度なものではなく、Quarkusでできることの表面をなぞっただけでしたが、それでも私たちのために動いてくれたので、さまざまなユースケースに取り組めることがわかりました。

結論として、Quarkusの強力なセールスポイントは以下の通りだと思います。

10年前、15年前のアプリストアと同じように、私が考える今後の主な課題は、エクステンションのエコシステムが、品質を犠牲にすることなく量的に成長するようにすることです。あるいは、少なくともエクステンションを評価する方法を提供して、ビジネスクリティカルなアプリケーションを構築する人々が、テクノロジーへの投資が適切であることを保証できるようにすることです。言い換えれば、"広く広く "に加えて "深く "ということです。私が考えるもう一つの課題は、企業の準備状況のギャップを徐々に埋めていくことです。例えば、今日、部分的に開発されているソリューションを完成させ、最も一般的なユースケースに対して明確で成熟したソリューションを提供できるようにすることです。

それが、Quarkusがエンタープライズに勝つ方法です。そして、これが動き出しているのがわかります。

このプロジェクトにはとても期待しています。早くユースケースを広げたいですね。