開発モードと本番アプリケーションの差異
このドキュメントでは、Quarkus の開発モードが本番アプリケーションとどのように異なるかを説明します。
アーキテクチャの差異
機能セットはさておき、開発モードで実行される Quarkus アプリケーションは、プロダクションアプリケーション (すなわち、 java -jar … を使用して実行されるもの) とはアーキテクチャ的に異なります。
開発モードでは、Quarkus は ClassLoader 階層 (詳細は こちら) を使用し、アプリケーションの再ビルドや再起動を必要とせずにユーザーコードのライブリロードを可能にしています。
本番アプリケーションでは、前述のクラスローディングのインフラは全く存在しません。目的に応じて構築された単一の ClassLoader があり、(ほぼ) すべてのクラスと依存関係をロードします。
開発モードの機能
開発者満足を提供するという信条のもと、Quarkus は開発モードを有効にすると多くの機能を提供します。最も重要な機能は以下の通りです。
ライブ・リロード
この非常に重要な機能は、紹介するまでもなく、 アーキテクチャの違い のセクションですでに述べたとおりです。
Dev UI
Quarkusは、ブラウザから /q/dev-ui でアクセスできる非常に便利な UI を提供しています。このUIにより、開発者はアプリケーションの状態を確認できるだけでなく、その状態を変更できるさまざまな操作にアクセスできます（存在するエクステンションに依存）。そのような操作の例としては、以下のようなものがあります:
-
設定値の変更
-
データベース移行スクリプトの実行
-
キャッシュの消去
-
スケジュールされたオペレーションの実行
-
コンテナのビルド
データベースインポートスクリプト
quarkus-hibernate-orm エクステンションは、Quarkus が開発モードで動作しているときに、 import.sql スクリプトを src/main/resources で実行します。詳細は こちら をご覧ください。
Dev Services
開発モードでテストまたは実行する場合、Quarkus はゼロコンフィグのデータベースをすぐに提供することができますが、これはDev Servicesと呼ばれる機能です。詳細については、こちら をご覧ください。
Swagger UI
quarkus-smallrye-openapi エクステンションは、Quarkus が開発モードで動作しているときに、Swagger UI を公開します。追加情報は こちら をご覧ください。
GraphQL UI
quarkus-smallrye-graphql エクステンションは、Quarkus が開発モードで動作しているときに GraphiQL UI を公開します。詳細は こちら をご覧ください。
Health UI
quarkus-smallrye-health エクステンションは、Quarkus が開発モードで動作しているときに Health UI を公開します。こちら のセクションでは、追加情報を提供します。
Mock mailer
quarkus-mailer エクステンションは、Quarkus が開発モードで動作しているときに、インメモリのモックメールサーバを有効にします。詳しくは こちら をご覧ください。
パフォーマンスへの影響
開発モードでは、アプリケーションの実行時フットプリントを最小化することは主な目的ではありません (ただし、Quarkus は高速に起動し、メモリをほとんど消費しません)。主な目的は、開発者満足を実現することです。そのため、ライブリロードが実行されるたびに、より多くのクラスがロードされ、ビルド時の操作も行われます。
対照的に、プロダクションアプリケーションでは、Quarkusの主な目的は、最小のメモリを消費し、最小の時間で起動することです。したがって、本番アプリケーションを実行する際には、ビルド時の操作は（定義上）実行されず、ビルド時に必要なさまざまなインフラストラクチャクラスは、実行時にはまったく存在しません。さらに、 fast-jarパッケージタイプに付属する目的に応じて構築されたClassLoaderにより、クラスの検索が可能な限り高速に行われると同時に、メモリ内のjarの量も最小限に抑えられます。
|
最適なパフォーマンスはdevモードの目的では決してないため、起動時間を改善する目的で、JVMのC2コンパイラーはdevモードでは無効になっています。 |
セキュリティへの影響
dev-modeアプリケーションを本番環境で実行してはいけない最も重要な理由は、開発モードでは (Dev-UI を介して) 機密性のある情報を読み取ることができる一方で、(本番環境のアプリケーションでは利用できないはずのエンドポイントを公開したり、Dev-UI を介して) 破壊的な操作にアクセスすることができるからです。
ネイティブ実行可能ファイル
ネイティブ実行可能ファイルを作成する場合 (詳しくは こちら)、常に 本番アプリケーションからビルドされます。
