IBM Enterprise Build of Quarkusとは?
IBM Enterprise Build of Quarkus は、OSSの Quarkus をベースに IBMがエンタープライズ向けに製品化したディストリビューションです。
community版が最新機能の追従を重視しているのに対し、本ディストリビューションは長期サポート(LTS)、セキュリティ修正、検証済み構成の提供といった、安定運用に重点を置いています。また、OpenShift環境での利用を前提として最適化されている点も特徴です。
言い換えると、「最新性」よりも「安定性・サポート」を重視したQuarkusといえます。
非コンテナ環境でも得られるメリット
Quarkusはコンテナ環境での利用を前提に設計されていますが、その特徴である「高速起動」「低メモリ消費」「軽量プロセス」といったメリットは、非コンテナ環境(ローカル実行や従来のVM環境)でも十分に享受することができます。
実際、Quarkus公式でも、以下のように明記されています。
“Quarkus applications are optimised for low memory usage and fast startup times.”
“These optimizations are not only advantageous in containers.”
https://quarkus.io/container-first/
特にNativeモード(詳細は後述)では、以下のような効果があります:
- 起動時間の大幅な短縮(ミリ秒オーダー)
- JVMを介さないことによるメモリ使用量の削減
- 軽量な単一プロセスとしての実行
そのため、コンテナを前提としない環境であっても、従来のSpring BootなどのJavaアプリケーションと比較した際の、性能やリソース効率の違いを体感できます。
本記事の対象読者・位置づけ
本記事は以下のような方を対象としています:
- コンテナ/Kubernetesを本格導入していないが、Quarkusを試したい方
- Quarkusの実行モデル(JVM / Native)の違いを理解したい方
- Spring Bootなど従来のJavaアプリケーションからの移行を検討している方
Quarkusは本番ではコンテナ環境での利用が一般的ですが、
本記事ではローカルや非コンテナ環境での理解・検証にフォーカスし、以下の2つの実行方式を整理します。
- JVMモード(従来通りJVM上で実行)
- Nativeモード(ネイティブ実行ファイルとして実行)
JVMモード
最もシンプルな実行方法で、従来のJavaと同様にJVM上で動作します。
柔軟性や互換性が高く、既存のJavaエコシステムをそのまま利用可能です。一方で、起動時間やメモリ使用量はNativeと比較すると大きくなる傾向があります。
特徴
- ビルドが高速
- クロスプラットフォームで実行可能(OS非依存)
- Nativeより起動時間とメモリ効率は劣る
前提条件
- Apache Maven
- 公式ドキュメントではV3.9.9以上を推奨
- JDK 17 または 21
- 詳細なサポート範囲はIBM公式ページを参照
ビルド
mvn clean package -Dquarkus.package.jar.type=fast-jar
補足:パッケージ形式設定
-Dquarkus.package.jar.typeにより、JAR形式を指定できます。
- fast-jar(デフォルト):Quarkus最適化済み。起動が速くメモリ使用量も改善
- legacy-jar:従来形式(非推奨)
- mutable-jar:Nativeコンテナビルド用
- uber-jar:依存関係を含んだ単一JAR
通常は fast-jar の使用が推奨されます。
実行方法
java -jar target/*.jar
Nativeモード
アプリケーションを事前にネイティブ実行ファイルへコンパイルし、JVMを介さずに直接OS上で動作させる方式です。
起動が非常に高速でメモリ使用量も小さくなりますが、ビルドや対応ライブラリに制約があります。
特徴
- 起動が非常に高速(ミリ秒オーダー)
- 実行時のメモリ使用量が小さい
- ビルド時間が長い(数分レベル)
- ビルド時に大量のメモリを消費(目安8GB以上)
- 最大スループットはJVMモードに劣る場合がある
公式サポート上の注意(重要)
- Red Hat Build of Quarkus Native builder image (quarkus/mandrel-for-jdk-21-rhel8)を指定した、Podman/DockerなどのOpen Container Initiative(OCI)互換のコンテナランタイムを経由したビルド方式がサポートされている
- 実行形式はOS・CPUアーキテクチャに依存し、IBM Enterprise Build of Quarkusでは
主に Linux 向けの ELF バイナリ(x86-64 / AArch64)での利用が想定されている- 詳細なサポート範囲はIBM公式ドキュメントを参照
前提条件
- Apache Maven
- 公式ドキュメントではV3.9.9以上を推奨
- PodmanやDockerなどのOCI互換のコンテナランタイム
- Red Hat Build of Quarkus Native builder image (quarkus/mandrel-for-jdk-21-rhel8)
有効化方法
pom.xmlファイルを開き、プロジェクトにnativeプロファイルを追加
<profiles>
<profile>
<id>native</id>
<activation>
<property>
<name>native</name>
</property>
</activation>
<properties>
<skipITs>false</skipITs>
<quarkus.native.enabled>true</quarkus.native.enabled>
</properties>
</profile>
</profiles>
ビルド:コンテナベースのNativeビルド(サポート対象・本番利用で推奨)
Podman環境を前提とし、サポート対象であるRed Hat Build of Quarkus Native builder imageを明示的に指定します。
また、デプロイ先環境で実行可能なバイナリを生成するため、コンテナのプラットフォームもデプロイ先と同一のアーキテクチャに指定します(本記事では amd64 を使用します)。
プロジェクトディレクトリで以下のコマンドを実行。
mvn package \
-Dnative \
-Dquarkus.native.container-build=true \
-Dquarkus.native.builder-image=registry.access.redhat.com/quarkus/mandrel-for-jdk-21-rhel8:23.1-42.1777859703 \
-Dquarkus.native.container-runtime=podman \
-Dquarkus.native.container-runtime-options="--platform=linux/amd64"
実行方法
./target/*-runner
補足:Javaバージョン互換
Java 17に基づいてソースコードが記述され、Java 18~21の機能が使用されていないアプリケーションでも、サポート対象であるJava 21ベースのMandrel 23.1ベースイメージ(Red Hat Build of Quarkus Native builder image (quarkus/mandrel-for-jdk-21-rhel8))を使用することで、そのアプリケーションのネイティブ実行可能ファイルをコンパイルできる。
Applications whose source is written based on 17, with no Java 18 - 21 features used, can still compile a native executable of that application by using the Java 21-based Mandrel 23.1 base image.
https://www.ibm.com/docs/en/quarkus/3.27.x?topic=applications-compile-native-executables#building-a-native-executable-with-ibm-enterprise-build-of-quarkus-covers
補足:コンテナランタイムを使用しないビルド方法(IBMサポート対象外)
▶ 前提条件
- Apache Maven
- 公式ドキュメントではV3.9.9が明記
- Graal VMディストリビューションのどれか
▶ 事前準備
export GRAALVM_HOME=/path/to/graalvm
export JAVA_HOME=$GRAALVM_HOME
export PATH=$GRAALVM_HOME/bin:$PATH
gu install native-image
▶ ビルド
mvn clean package -Pnative
▶ 実行
./target/*-runner
JVM vs Native の比較
| 観点 | JVMモード | Nativeモード |
|---|---|---|
| 起動速度 | Nativeより遅い。 数百ms〜秒単位 |
非常に高速。 ミリ秒オーダー |
| メモリ使用量 | 多め | 少ない |
| ビルド時間 | 短い | 長い |
| スループット | 長時間稼働ではJIT最適化により有利な場合がある | JVMより低い場合がある |
| 実行環境の柔軟性 | 高い(クロスプラットフォーム) | 制約あり(OS/CPU依存。Linux環境での利用が中心) |
| 開発効率 | 高い。従来のJava開発に近い | 調整が必要な場合がある。 ライブラリ互換性、リフレクション、ビルド環境に注意 |
Nativeモードは、起動時間やメモリ使用量が重要なワークロード、特にサーバーレス、短命なコンテナ、スケールアウト頻度の高いマイクロサービスなどで有効です。
一方で、長時間稼働し高スループットを求めるアプリケーションでは、JVMモードの方が適する場合もあり、実測に基づく判断が重要です。
まとめ
Quarkusを利用する際、最初からNativeモードを選択する必要はありません。
Quarkusは「すべてをネイティブ化すること」を目的としたフレームワークではなく、用途に応じて最適な実行モデルを選択できる柔軟性に価値があります。
まずはJVMモードで開発・動作確認を行い、その後は要件に応じてNative化を検討するのが現実的です。
本記事では、非コンテナ環境におけるIBM Enterprise Build of QuarkusのJVMモードとNativeモードの違いについて整理しました。
少しでも理解の一助となれば幸いです。
最後までお読みいただき、ありがとうございました。