FAAS における JAVA 起動時間の比較 AWS / AZURE / GCP JJUG CCC 2023 Spring 2023/06/04 tacck (Kihara, Takuya) JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 1

JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 2 木原 卓也 Kihara, Takuya / @tacck 生活協同組合コープさっぽろ デジタル推進本部システム部 Amplify Japan User Group 運営メンバー ゆるWeb勉強会@札幌 主催 AWS Community Builder Since Q2 2021 / Category: Front-end Web and Mobile 好きなフィギュアスケートの技 スプレッド・イーグル

きっかけ - 前職で、 AWS Lambda に Java を採用したプロジェクトがあった。 - 依頼元の技術スタックの関係から、 Java 8 が指定されていた。 - Cold Start の遅さに遭遇。 - FaaS で Java は人類には早かったことを痛感 それから2〜3年。 - AWS Lambda SnapStart の速さに驚愕！ JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 3

きっかけ JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 4 Javaユーザーグループ北海道（Java Do）での発表 Cloud上での高速化は、みんな注目しているっぽい。

きっかけ JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 5 タイミングよく流れてくる 寺田さんのFacebook投稿 他のクラウドプロバイダーだと、 どういう高速化方法があるんだろう？ →というのをCfPで応募 →今に至る

今回お話しすること - クラウドプロバイダーごとに提供している FaaS (Function as a Service) で、 Java を実行してみたらどのくらい時間がかかるのか？ - 今回は AWS 、 Azure 、 GCP で計測。 - 各プロバイダーごとのFaaSの高速化技術によって、 それぞれどの程度の効果が得られるのか？ コードや実行環境の詳細は割愛させていただきます JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 6

FaaS の処理概要 - 各プロバイダーとも基本的な考え方は同じ - 準備 (Cold Start でのみ必要) - インスタンス(VM/コンテナ)起動 - ランタイム準備 - プログラムコードのロード - ファンクションの初期処理実行 - 実行 (Warm Start はここから) - ファンクションのハンドラ実行 JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 7

Cold Start に与える影響 - 各プロバイダーとも基本的な考え方は同じ - 準備 (Cold Start でのみ必要) - インスタンス(VM/コンテナ)起動 - ランタイム準備 - プログラムコードのロード - ファンクションの初期処理実行 - 実行 (Warm Start はここから) - ファンクションのハンドラ実行 JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 8 ランタイム問わず共通 ランタイムによる プログラムによる

Java で考えると - 各プロバイダーとも基本的な考え方は同じ - 準備 (Cold Start でのみ必要) - インスタンス(VM/コンテナ)起動 - ランタイム準備 - プログラムコードのロード - ファンクションの初期処理実行 - 実行 (Warm Start はここから) - ファンクションのハンドラ実行 JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 9 ここで時間がかかる • JVMの起動を伴うため • プログラム(JAR)が大きくなりがち ランタイム問わず共通 ランタイムによる プログラムによる

Cold Start の時間を減らすために - 方針は大きく二つ - 準備を早くするための仕組み (パターンA) - AWS: SnapStart - GCP: 起動時の CPU ブースト - そもそも Cold Start させない仕組み (パターンB) - AWS: Provisioned Concurrency - Azure: Functions Premium JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 10

確認してみる - 各サービスで、設定なし、設定あり、で測定。 - アプリケーション - Spring Cloud Function リポジトリの Sample を利用。 - 計測方法 - Cold Start (相当)の確認では、20分ごとにアクセス、10回確認。 - Warm Start (相当)の確認では、1分ごとにアクセス、10数回アクセスし直近10回を確認。 - 実行時間の取得方法 - AWS は CloudWatch Logs の出力結果から実行時間を取得。 - Azure は Insight の出力結果から実行時間を取得。 - GCP は、ログから取得できなかったため、手元のPCから time + curl コマンドで計測。 - 計測結果の平均値で、設定の効果を確認。 プロバイダ間の計測条件が異なるので、プロバイダ間の数字の比較は行いません。 JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 11

パターンA 準備を早くするための仕組み - AWS: SnapStart - GCP: 起動時の CPU ブースト JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 12

AWS: SnapStart JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 13 起動パターン 設定なし(ms) 設定あり (ms) 短縮率 Cold Start 4227.77 676.91 16.01% Warm Start 2.66 2.71 101.92% Spring Cloud Function v3.2.10 のサンプルを利用 Java 11 ランタイムを利用 その他: 追加料金無しで設定可能。 Arm64で使えないなど一部制限あるので、利用できる構成であれば利用推奨。 「初期化処理実行済み」のコンテナイメージを作成し、それを起動させることで高速化。

GCP: 起動時の CPU ブースト JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 14 起動パターン 設定なし(ms) 設定あり (ms) 短縮率 Cold Start 15646.40 2646.80 16.92% Warm Start 157.00 151.90 96.75% Spring Cloud Function v4.0.2 のサンプルを利用 Java 17 ランタイムを利用 その他: 費用は追加となる可能性があるが、今回のテストで試した程度では体感できなかった。 (CPUリソースを5個分割り当てて起動時間が1/5になるなら、実質料金が変わらない？) 設定はデフォルトでONになっている。 Cold Start 中のCPU割り当てを、設定以上に自動で割り当てることで高速化。

パターンB そもそも Cold Start させない仕組み - AWS: Provisioned Concurrency - Azure: Functions Premium JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 15

AWS: Provisioned Concurrency JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 16 起動パターン 設定なし(ms) 設定あり (ms) 短縮率 Cold Start 4227.77 129.48 3.06% Warm Start 2.66 2.68 100.75% Spring Cloud Function v3.2.10 のサンプルを利用 Java 11 ランタイムを利用 その他: 設定中に、月で+$7目安とコンソール上表示される。 設定ありの場合に、ログには準備実行が記録されても、 呼び出し側には待ち時間としては現れなかった。 動き続けるコンテナが切り替わりながら維持されているように見える。 同時実行数を予約(provisioned)して、事前リソースを確保することで高速化を実現。

Azure: Functions Premium JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 17 起動パターン 設定なし(ms) 設定あり (ms) 短縮率 Cold Start 2740.00 34.13 1.25% Warm Start 63.88 38.77 60.69% Spring Cloud Function v4.0.2 のサンプルを利用 Java 17 ランタイムを利用 その他: 常時コンテナが稼働するため、効果は高いが費用も高くなる可能性がある。 常時コンテナを稼働することで、高速化を実現。

全体比較 JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 18 パターン プロバイダー Java 起動パターン 設定なし(ms) 設定あり (ms) 短縮率 A 準備時間 短縮 AWS SnapStart 11 Cold Start 4227.77 676.91 16.01% Warm Start 2.66 2.71 101.92% GCP 起動時の CPU ブースト 17 Cold Start 15646.40 2646.80 16.92% Warm Start 157.00 151.90 96.75% B Cold Start なくす AWS Provisioned Concurrency 11 Cold Start 4227.77 129.48 3.06% Warm Start 2.66 2.68 100.75% Azure Functions Premium 17 Cold Start 2740.00 34.13 1.25% Warm Start 63.88 38.77 60.69%

まとめ - 各プロバイダーごとに手法がそれぞれあり、 いずれも高い効果が確認できた。 - 特に「Cold Start をなくす」パターンは劇的な改善。 - 今回はシンプルなアクセス方法での計測。 ある程度負荷を与える形で計測した場合に、待ち時間のパーセンタイルが どのようにでてくるかも、今後確認してみた。 JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 19

END JJUG CCC 2023 Spring #jjug_ccc #jjug_ccc_d 20