[アップデート] AWS Lambda の SnapStart が ARM をサポートしたので、過去に x86 でデプロイしていた Java 関数を ARM に変更してみた

いわさです。

AWS Lambda で Java を実行する場合、コールドスタート対策として SnapStart という機能を使うことが出来ます。
無料で利用出来るかつパフォーマンス改善出来るケースが多く、私の周りでも利用されるシーンが増えています。
しかし、この SnapStart はいくつかの注意点がありまして、プロビジョニング同時実行や EFS のマウント、あるいは ARM アーキテクチャが採用出来ないなどの制限がありました。

今朝のアップデートでこのうちの ARM アーキテクチャに関する制限がなくなり、x86 以外でも SnapStart が利用可能になりました。

https://aws.amazon.com/about-aws/whats-new/2024/07/aws-lambda-snapstart-java-functions-arm64-architecture/

AWS Lambda は x86 よりも ARM のほうがメモリサイズに応じた実行時間あたりの利用料金が若干低いため、ARM に移行出来ると AWS 利用料金の削減が出来る場合があります。

https://aws.amazon.com/jp/lambda/pricing/

変更してみる

今回は事前に x86 で SnapStart を有効化してデプロイ済みの Java Lambda 関数をデプロイ済みです。

こちらは API Gateway に統合されています。
HTTP リクエストを送信してみましょう。

% curl "https://32m1t9nwjd.execute-api.ap-northeast-1.amazonaws.com/hoge/"
Hello from Lambda!

これを x86 → ARM に変更してみます...変更出来るのか？

ランタイム設定を編集

関数のランタイム編集から、既存関数のアーキテクチャの変更が可能です。
ただし、言語あるいはランタイムサイズによってはアーキテクチャ変更時にコードソースの再アップロードが必要になります。
試したところ、Java は再アップロードが必要でした。コード無しでのアーキテクチャ変更を行おうとするとエラーに。

なお、既存のコードは関数の概要画面の「ダウンロード」 -> 「ファンクションコード .zip をダウンロード」からダウンロードすることが出来ます。
もしアーキテクチャに依存したコードやモジュールが含まれている場合はアップロードファイルの用意からやり直したほうが良いと思いますが、今回（固定レスポンス返すだけ）はそのままいけました。

アーキテクチャ変更後、SnapStart は有効化されているのでそのまま新しいバージョンを発行しましょう。
SnapStart は LATEST 関数では動作しません。SnapStart を有効化した上でバージョン発行が必要となります。

関数バージョンが変わったので、API Gateway 側の統合先も変更しました。
ついでに API のステージも x86 と別のものを発行しました。

ARM 版のバージョンを参照する API にリクエストを送信してみましょう。

% curl https://32m1t9nwjd.execute-api.ap-northeast-1.amazonaws.com/hoge2/
Hello from Lambda!

動作していますね。
そして関数のログも確認してみます。

新しい関数バージョンは ARM なのですが、SnapStart の動作であるコールドスタート時のリストアが実行されていることが確認出来ますね。

さいごに

本日は AWS Lambda の Java SnapStart が ARM をサポートしたので、過去に x86 でデプロイしていた関数を ARM に変更してみました。

デプロイ済み関数のアーキテクチャ変更ってそもそもしたことなかったなと思いやってみましたが出来ました。
コスト削減などの観点で ARM 採用は検討すること多いと思いますが、Java SnapStart がサポートされておらず過去に見送っていた方はこの機に再検討されてみては如何でしょうか。