大量リクエストを低コストでさばく AWS Lambda 関数を JVM で実現

クラウドアプリのモニタリングを提供する DataDog の 2020 年の調査 によると、

• AWS ユーザーの 50% 近くが AWS Lambda を採用
• AWS 利用企業で Lambda を使っている割合は、スタートアップ～中小企業では40～55%、エンタープライズ領域では 90%

と、Lambda の高い普及率が示されております。
特に「エンタープライズ領域のほうが Lambda を使っている」というのは興味深いです。

サーバーレス関数は「一部の熱狂的ファンが使っている」という段階はとうに過ぎて、「エンタープライズを含むクラウド利用者全体に広がっている」と言えそうです。
先程紹介した「そろそろマネージド、クラウドネイティブで行こう ! サーバーレスへのチャレンジ」の事例は、その一例なのでしょう。

ところで話は変わりますが、Java およびその周辺技術がソフトウェア開発で重要な位置を占めるのは言うまでもないことでしょう。

• Java EE、Spring などのアプリケーション開発フレームワーク
• Tomcat、Jetty、GlassFish などのアプリケーションサーバー
• Hadoop、Spark、Elasticsearch などのデータの分析や検索
• Eclipse、JetBrains IDE などの統合開発環境

など、開発者は多くの場面で Java を書くか、そうでないまでも Java 周辺技術を活用しています。
実際、統計的データの上でも Java 技術のビジネス需要は高そうです。

• 開発ツールベンダー JetBrains の2020年の推計によると、Java を第 1 または第 2 開発言語としている開発者は 680 万人。これは、世界の開発者人口 2400 万人 (1 年ずれますが、ソフトウェアの市場調査会社 EDC による 2019 年の推計) の 28%。
• IT 人材紹介を手掛けるレバテックの 2020 年の調査によると、日本のソフトウェア開発の求人では Java 技術者が 35%前後で、2 位以下を大きく離す。

そんなビジネス需要の高い Java は、AWS Lambda 開発でもやはり需要が高いのでしょうか ? 実は、そうではないようです。

Lambda 関数を Java で実装した場合とそれ以外で実装した場合で、処理時間や消費メモリがどう変わるか、具体的に見ていきましょう。
すぐに試せる環境が手に入るのがクラウドのすばらしいところですね。

Lambda ランタイムとして Java より人気の高い Python、Node.js と比較します。
Python、Node.js、Java いずれも、現時点 (2021 年 9 月 20 日現在) の最新バージョンを使用します。

• Python ランタイム : Python 3.9 を使用
• Node.js ランタイム * Node.js 14.x を使用。実装言語は TypeScript 4.3 で実装し、JS に変換
• Java ランタイム : Java 11 (Amazon Corretto) を使用
  

まず比較の基準として、実質的に何も処理をしない (イベントが発生したら固定の JSON を返すだけ) 単純な Lambda 関数を作ってみます。
何もしないこの関数を Noop (no-operation) と呼びます。

Lambda での処理や初回起動にかかった時間は、CloudWatch Logs に格納される次のようなログで確認できます。

各項目は次のような意味です。

• Duration はイベントの処理にかかった時間です。
• Billed Duration は「処理時間を 1 ミリ秒単位に切り上げたもの」です。Billed Duration は使用料金の計算に使われます。
• Init Duration はランタイムやイベントハンドラ関数外の初期化にかかった時間で、Duration とは別物です。Init Duration も料金計算に使われます。Lambda 関数の新たなインスタンスが起動するときに発生します。
  

通常、箱ひげ図には中央値 (50%ile) や平均値が分かるようにしますが、今回は図を簡略にするため、省略しました。25%ile～75%ile の区間をボリュームゾーンと考え、これを比較していくことにしましょう。

Node.js ランタイムが明らかに速く、どのメモリ量でもおよそ140～160ミリ秒にボリュームゾーンが見られます。
Java と Python ランタイムでは、およそ 330～380ミリ秒程にボリュームゾーンが見られます。

全体としては、メモリ量を増やしてもボリュームゾーンはほとんど動きませんでした。
Lambda ではメモリ量に比例して CPU 性能も高まるのですが、初回起動時間については大きな影響はないようです。
したがって、Lambda ランタイムの初期化時間はメモリ量 (と CPU 性能) によらずほぼ一定と言えそうです。

次に、Node.js ランタイムが他よりも初期化時間が短い理由は何なのでしょうか。
ひとつ考えられるのは、Lambda 関数のパッケージサイズです。
関数のパッケージサイズが大きくなると、Lambda の起動時間も長くなることがあります。

今回のパッケージサイズは下表のようになりました。

Java だけサイズが突出して大きいですが、これは aws-lambda-java-core やその遷移先依存である joda-time などのライブラリが同梱されるためです。
Node.js や Python は Noop 実装では特にライブラリを必要としないので、パッケージサイズは Lambda 関数そのもののソースコードだけとなり、とても軽量です。
ただし、Node.js と Python のパッケージサイズはほぼ同じなので、今回の両者の起動時間の違いはパッケージサイズはあまり関係なさそうです。

他に考えられそうなのは、各ランタイムに含まれる組み込みライブラリの初期化です。
ただ、組み込みライブラリの起動時間のどれくらいが初期化時間なのかを Lambda 上で記録するのは難しそうです。

以上から、Node.js 14 の起動は JVM や Python よりも純粋に速い、と理解しておくことにしましょう。

どのランタイムでも、メモリを増やしていくとボリュームゾーンがやや下に改善していきます。

いずれのランタイムでも、128MB のときのボリュームゾーンの振れ幅が 256MB以降よりも大きいようです。128MB と 256MB の間になにか壁があるようです。

さきほどご紹介したように Lambda では CPU 性能はメモリ量に比例するとされていますが、直線的ではなく、128MB / 256MB のどこかで CPU 性能がガクッと変化するのかもしれません。

ただ、これら 2 つの違いは、この関数はあくまでも Noop であり本稿では重要ではないので、特に検討しないでおきます。

さて、Noop 関数だけを見ると、Node.js の起動時間は速いものの、Java ランタイムもなかなか健闘しているように見えました。
ですが、実際のアプリケーションに近い処理をさせてみるとどうなるのでしょうか ?

実際のアプリでは、何らかのデータをファイルやデータベースに書き込んだり、読み込んだりするのが常です。
そこで、KVS 型データベースである Amazon DynamoDB から、1 つのアイテム (リレーショナルデータベースでいうレコード) を読み取る Lambda 関数「GetItem」を実装してみます。

Lambda から DynamoDB などの AWS にアクセスするには、クライアントが必要です。今回は AWS 公式の AWS SDK を使用します。

処理時間の大小は、Java (1860～1950ミリ秒) ＞ Python (600～640ミリ秒) ＞Node.js (250～290ミリ秒) となりました。

なんと Java @ 128MB では、メモリ不足 (OutOfMemory) が多発し、何度か Lambda が再起動して運良く成功することがある・・・という状況でした。

これでは不安定で本番運用は難しいので、今回は Java @ 128MB の結果を除外しました。

Noop に比べて、GetItem では次のように起動時間が伸びています。

• Node.js では + 120 ミリ秒
• Java では +1500 ミリ秒
• Python では +300 ミリ秒

これはさきほど紹介した「関数のパッケージサイズが大きくなると、Lambda の起動時間も長くなることがある」との典型的な例です。

• 大きなパッケージを読み込む時間
• パッケージに含まれるライブラリやアプリの初期化時間 (何らかのオブジェクトのインスタンス作成など)

が伸びるためです。

今回、GetItem では DynamoDB クライアントライブラリが必要でした。互換ライブラリもいくつかありますが、AWS 公式の AWS SDK を使用しました。これにより、パッケージサイズは次のように増加していました。

• Java では DynamoDB 専用 SDK だけでも 10MB にもなりました。AWS SDK のコアライブラリやいくつもの HTTP クライアントなどが比較的大きいためです。他のランタイムに比べて初期化に 2 秒近くもかかってしまっていました。
• Python では、boto3 という AWS 全部入りの SDK にしました。boto3 が Java や Node.js の AWS SDK と API がほぼ共通で、Python に詳しくないぼくでもすぐ扱えるためです。おもしろいことに、boto3 は AWS 全部入りで 9 MB 近くあるにもかかわらず、初期化時間の増加は Java ほどではありません。ライブラリの初期化が少なく早く終るのかもしれません。
• TypeScript では、2021 年に正式リリースされた AWS-SDK-JS-v3 を使うことで、0.1MB と他の 100 分の 1 程度で済みました。パッケージサイズは小さく、また初期化処理も少ないとみえ、初期化時間の増加も +120 ミリ秒程度に収まりました。

AWS SDK を追加するだけでも、ランタイムによって初期化時間がずいぶん異なることが分かりました。

少し補足しますと、Python や Node.js などのランタイムでは、各言語の AWS SDK が事前にインストールされています。デフォルトの SDK で十分であれば、Lambda のパッケージから AWS SDK を除外してパッケージサイズを小さくできます。

ただし、事前インストール済み SDK のバージョンは必ずしも最新ではありません。新機能やバグ修正が含まれる新しい SDK が必要な場合は、今回の実験のように SDK を Lambda パッケージに含める必要があります。
今回の実験では「各言語の AWS SDK を明示的に追加する」という条件を揃えることにしました。

• DynamoDB への GetItem はメモリを増やしていくとある程度速くなる。AWS 間通信に関する処理が、メモリ量 ≒ CPU 性能の向上で高速化するためと考えられる。
• ただし通信に最低限かかる時間はあるので、どこかで飽和する。したがって、最短の処理時間実現に十分なメモリ量を見極めることで、コストを最適化できる
• Java は 1024MB でも 12～30 ミリ秒かかる。他のランタイムが 512MB で下限の 6 ~ 10 ミリ秒に到達しているので、Java は性能・コスパ観点で見劣りする
  

さて、残念ながら Java ランタイムにはキビシイ結果となりました。
さきほどの Datadog の Lambda ランタイム利用の調査で Python と Node.js 合わせたシェアが 85%、Java がわずか 7% になるのもムリはない気がします。

Java 技術者 / Scala 技術者でも、Lambda 開発では Python や Node.js を使えばいいのでしょうか？

ですが、開発の事情によってはそうも言えないでしょう。
弊社 Chatwork でも同様で、次のような事情がありました。

• 組織として Scala に投資しており、開発者は Java / Scala の専門家であるため、Node.js や Python のノウハウが組織にない。
• 短期間で性能や保守性よく開発する必要があり、不慣れな Node.js や Python だと不安がある。
• 開発予定の Lambda 関数はわずか 2 つで、今後 1～2 年は増やす予定はない。せっかく Node.js や Python の技術スタックを習得しても定着しない可能性が高い。
• 今後も長期的にメンテナンスするので、Java / Scala 技術が望ましい。

こうした事情がある中でも「膨大なトラフィックを省メモリ (=低コスト) で高速に処理」するという非機能要件をなんとか両立できないでしょうか。
弊社では Java でも省メモリ・高速を実現する道を探ることにしました。

Java アプリを開発してきた方なら、これまで見てきた Lambda x Java ランタイムの問題にはどこか見覚えがあるのではないでしょうか。

• JVM の起動や JIT の暖機が十分に進むまで時間がかかるため、ワークロードの変動が大きい場合にスケールアウトがもたついてしまう
• スケールアウトに余裕をもたせておくとアイドルなサーバーが増えてしまい、高コストになってしまう
• 比較的単純な Java アプリでも数百 MB 以上のメモリを必要とし、サーバーコストの最低ラインが高い

これはサーバー「フル」、つまり従来型の Java アプリケーションを物理サーバーや何らかのコンテナランタイムで起動する場合であっても、つきまとってくる問題です。

こうした課題に対して、Oracle が打ち出したのが GraalVM と総称される一連の技術です。GraalVM は 2018 年にバージョン 1.0 がリリースされ、2019 年にはプロダクションレディとうたわれるバージョンがリリースされた、比較的新しい技術です。

GraalVM にはいくつかの技術が含まれるのですが、今回重要なのは native-image と呼ばれる技術です。native-image をカンタンに説明すると「Java プログラムを事前コンパイル (AOT、Ahead-Of-Time) して、単独実行可能なネイティブバイナリを生成するツール」です。C 言語や C++ 言語などで開発したときと似ていますね。

ネイティブという言葉から想像しやすいように、native-image で生成されたネイティブバイナリは、次のメリットがあります。

• 非常に高速に起動する
• 必要なメモリが少なく済む

これはまさに、今回の実験でお見せしました Java ランタイムの課題にピッタリですね。

これまでの実験では、AWS が提供するランタイムを使用してきました。
Lambda ではさらに、AWS ユーザー自身で実装するカスタムランタイムを使うことができます。これにより、既存のランタイムで満たせないニーズを満たすことができます。

カスタムランタイムは、Lambda のインターフェース仕様を満たしていれば、どんなプログラミング言語でも開発できます。native-image で生成したネイティブバイナリももちろん使用できます。

実際に native-image を Lambda 関数に適用してみるとどうなるか、実験してみましょう。

ロジックのない Noop 関数は省略し、DynamoDB を扱う GetItem 関数と Query 関数だけを見てみます。

もともとの Java ランタイムより圧倒的に速くなり、300〜340 ミリ秒台でした。最速の Node.js ランタイムの 250〜280 ミリ秒台に肉薄しています。