Adventarの6日目の記事です。Javaこんにちはid:dhigashiです。今年もServerless盛り上がっていましたね。体験が凄く良かったです。今では、ちょっとした事ならコードを書く必要は殆ど無く、サーバーサイドで必要なロジックは関数としてデプロイしておき必要な時にだけ利用する、といった事ができる環境が整ってきていますね。Jar)JVMの初期起動時間が長いメモリの消費量が多いといったイメージがあり、ユースケースによっては他のランタイムが利用されているように思います。Imageを利用すると、これらの問題を解決することができるのではないでしょうか。Imageを利用しパフォーマンスが改善できるか検証を行います。おけるJavaについて、こちらのスライドがとても参考になりました。Japanwww.slideshare.net是非ご覧下さい。関数を開発するためにFnとDockerを導入します。serverを利用する事ができません。Debian系では問題は無いので、以降はUbuntuで検証を行います。Documentationに従い、FnとDockerを導入します。検証を行った環境は次の通りです。今回検証に用いた関数はこちらにあります。github.com今回検証する関数は次の三種類です。指定し、組み込まれているランタイム以外の関数テンプレートを利用することができます。Image関数を作成しました。Imageを含めたデプロイ用のイメージの作成を行っていることが分かります。Image、go関数を比較していきます。imagesでDockerイメージのサイズを確認すると、次の結果となりました。Image関数がGo関数より若干大きいが、Java関数と比較すると1/10程度に削減出来ています。実行時間Fn関数は呼び出されると、Dockerコンテナとして起動しリクエストを処理します。関数は30秒(デフォルト値)後続のリクエストを待ち、リクエストが無ければシャットダウンします。この初回起動をCold、リクエストを待ち受けている状態をWarmとし、それぞれの状態での実行時間を計測し比較します。実行する関数は次の通りです。}}@FnConfigurationアノテーションが付与されたsetUp()メソッドは初回起動時に一度だけ呼び出されるので、ここでRuntimeMXBean#getUptimeでJVM自体の起動時間を計測します。0m0.010s...関数が立ち上がっていないCold状態からの呼び出し、関数が待ち受けているWarm状態での呼び出しでそれぞれ10回ずつ計測して平均すると次の結果となりました。Image関数とJava関数を比較するとCold状態からの実行時間がJVMの起動時間分早くなっています。Image関数はgo関数と同等の時間となっています。「ホット」な関数Cold状態では差が見られましたが、Warm状態では先ほど図で示した様に差はみられませんでした。これは、関数がシャットダウンされず後続のリクエストを待ち受けているとき、イメージのプルやコンテナ、JVMの起動といった関数の立ち上げ処理を行う必要が無いためです。利用すれば開発者は意識すること無く簡単に実現することができます。statsでメモリの使用量を確認すると次の結果となりました。Image関数はGo関数と同程度で、Java関数と比較すると1/10程度となっています。Functionsへデプロイし比較を行います。Functionsは共に東京リージョンを利用しました。関数のメモリーは初期設定の128MBです。Image関数の起動時間が大きく改善されていることがわかります。Image関数はgo関数と同等の時間となりました。コールドスタートWarm状態ではローカル実行時と同様に実行時間に差はありません。Imageの機能を利用し、Serverless環境におけるJavaアプリケーションのコールドスタート時のパフォーマンスの改善について検証を行いました。今回検証に用いたアプリケーションは現実のシナリオを反映したものでは無いので必ずしも有用とは限りませんが、検討してみてはいかがでしょうか。(ココがこの記事で一番大事)明日の記事もお楽しみに。