fat JAR問題を解決する - HubSpotの例

Spring Boot 1.4とDropwizard 1.0が7月末，いずれもfat JARベースでリリースされた。このようなフレームワークやマイクロサービスでの採用が増えていることで，fat JARはデプロイ機構として一般に普及しつつある。

fat JARは，Javaアプリケーション実行に必要なすべての依存対象を，単一のファイルにバンドルするテクニックであり，Spring BootやDropwizardなど，多くのJavaマイクロサービスフレームワークで利用されている。Fat JAR Eclipse Plug-Inといったものでさえ存在する。

マイクロサービスを多用していない企業ならば，fat JARの使用する帯域はほとんど気にならないが，何千というマイクロサービスを使用するようになると，その帯域消費が問題になる可能性がある。

今年の初夏，HubSpotは，maven-shade-pluginでのエクスペリエンス上の問題や，100,000以上の小さなファイルをJARにパッケージングする際の効率問題の原因として，デプロイ技術としてのfat JARの問題を報告した。その中で同社は，ビルドとデプロイを定常的に実施している1,000以上の自社アプリケーションが発する，依存関係JARの大規模な重複問題にも言及している。

肥大化を抑制するため，同社ではmaven-dependency-pluginを試したが，生成されるビルド結果のサイズを減少することはできなかった。

fat JARの問題を解消するため，HubSpotでは，特定のプロジェクトクラスのみを含んだアーティファクトを生成するSlimFast plugin for Mavenを開発した。このプラグインはデプロイフェーズにピギーバックして，アプリケーションのすべての依存物を個別に，Amazon Simple Storage Service (S3)にアップロードする。HubSpotの報告によると，同社では，このプラグインを使用することによって，ビルド時間の60%の高速化とストレージ容量の99%の増加を実現した。

下のグラフは，SimFastを使うことによるビルドの高速化を示している。

HubSpotのfat JAR問題に関する詳細を知るため，InfoQでは，同社のソフトウェアエンジニアスタッフであるJonathan Haber氏にインタビューした。

InfoQ: 御社の経験したfat JARの問題は，継続的インテグレーションとデプロイメントに関係するものが中心だったのですか？

Jonathan Haber: そうです。私たちの突き当たった問題の大きな原因は，当社の開発スタイルにあったのだと思います。当社ではたくさんの小さなチームが，１日に100回以上，コードのプッシュやビルド，デプロイを行っています。ビルド単位が小さいため，コードのコンパイルやテストを実際に行なう時間に比べて，JARファイルの生成やアップロードに多くの時間を要することが少なくありません。ビルトに20分以上を要するようなモノリシックなアプリケーションならば，fat JARのオーバーヘッドもここまで顕著ではなかったかも知れませんが，このような高速で軽量なデプロイメントスタイルに移行することで，同じ問題に突き当たる企業はたくさんあると思います。

InfoQ: Spring BootやDropwizardなどのフレームワークは，SimFastが提供するような他のテクニックを採用するべきだと思いますか？

Haber: SimFastのアプローチにはビルトおよびデプロイシステムとの統合が必要なので，Spring BootやDropwizardのようなものに組み込むには少し癖が強過ぎるような気がします。ですが，この問題を扱う手段のひとつとして，SimFastプラグインを記述したMavenプロファイルを環境変数でアクティベートする方法もあります。こうしておけばビルドシステムで(環境変数を設定して)この機能をサポートするように指示するか，あるいはフォールバックしてfat JARを使用することができます。

InfoQ: クラウドプロバイダ(HerokuやCloudFoundryなど)が同じようなテクニックを使用して，アプリケーション間のJARの重複を削減することが可能ならば，ネットワークの費用を大幅に抑制できるでしょうか？

Haber: 削減できるという確信はありませんが，同じような戦略を取ることは可能だと思います。ですが，私たちにとっては，すべてのアプリが同じバージョンのサードパーティ製ライブラリを使用することの方が，はるかにメリットが大きいのです。クラウドプロバイダの場合は，ユーザが利用するライブラリが幅広く，バージョンもさまざまですから，すべてをアプリケーションサーバにキャッシュするには膨大なスペースが必要になります。ですが，そうしなければ，今度は速度と帯域の節約はほとんどできません。まったく節約できない訳ではないにせよ，私たちのアプローチよりももっと高度な方法が必要になるでしょう。しかも，これらのクラウドバイダでは，一般的にユーザの用意したPOMを使用してMavenを実行しますから，プロバイダ側からビルドライフサイクルを管理することはほとんどできません。彼らにとっては，これも問題のひとつになります。

InfoQ: fat JARアプリケーションに関して実施されるべき改善点は，他にも何かありますか？

Haber: Java 9のリストに載っているか分かりませんが，JavaがネストしたJARを扱えるようになれば，fat JARのビルドや実行はずっと簡単になるでしょう。Spring BootやOne-JARといったツールはこの制限をうまく回避していますが，その分複雑ですし，完全にトランスペアレントではありません。