AWS LambdaをはじめとするFaaS（Function as a Service）は、サーバー管理が不要な大変便利なサービスですが、特有の課題として「コールドスタート時のレイテンシ（起動遅延）」があります。特に、店舗の売上集計や複数ファイルのコンパクション処理（データ軽量化）といった高負荷で実行時間の長い処理をFaaSで行う際、ランタイムのオーバーヘッドは大きなボトルネックになります。
当サービス「StoreMenu」の売上集計バッチシステム（sales-aggregator-rust）では、このパフォーマンス問題とコストを解決するために、従来のNode.jsやPythonではなく、静的型付け言語である Rust を採用しました。今回は、RustをLambdaで動かす具体的なメリットと、ビルドサイズを最小化するためのチューニング技法について解説します。
Javaや.NET Core、さらにはNode.jsといったランタイムは、起動時に仮想マシン（VM）や大きなインタープリタのロード、および依存モジュールのインポートが必要なため、起動までに数秒かかることがあります。一方で、Rustはコンパイル時にネイティブバイナリを生成するため、ランタイム（カスタム実行環境 provided.al2023 など）がコンテナを起動した瞬間に動作を開始します。起動時間はわずか数ミリ秒〜数十ミリ秒であり、実質的にコールドスタートを意識する必要が無くなります。
Lambdaの課金モデルは「割り当てたメモリ量 × 実行時間」です。Node.jsやPythonでは最低でも 256MB や 512MB のメモリを割り当てないと動作が遅くなったりメモリ不足（OOM）で落ちたりしますが、Rustで書かれたバイナリはわずか 15MB〜30MB 程度のメモリで軽快に動作します。これにより、Lambdaの設定メモリを最小の 128MB に抑えることができ、同一処理を行う際の大幅なコスト削減に直結します。
売上集計や決済データの集計処理は、1円のズレも許されないクリティカルなシステムです。Rustのコンパイラは非常に厳格であり、メモリ安全性やスレッド安全性がコンパイル時に保証されます。また、例外（Exception）ではなく Result 型による明示的なエラーハンドリングが強制されるため、実行時の予期せぬヌルポインタ参照やバグによるクラッシュを大幅に抑制できます。
Rust製バイナリをLambdaへデプロイする際、さらなるパフォーマンス向上とアップロード容量の削減のために、StoreMenuプロジェクトでは以下の最適化プロセスを自動化しています。
cargo build --release --target aarch64-unknown-linux-gnu を実行します。x86よりもGravitonの方がCPUコストパフォーマンスが高いためです。strip bootstrap コマンドを実行してこれらの不要なデータをバイナリから完全に削除します。上記の最適化を行った結果、StoreMenuの集計Lambda関数のバイナリサイズは最終的に数メガバイトにまで縮小されました。毎夜間実行される売上集計バッチは、ミリ秒単位で完了し、毎月のランタイム維持コストは実質的にほぼゼロドルを維持しています。
AWS LambdaにおけるRustの活用は、「インフラコストを最小限に抑えたい」かつ「高速で信頼性の高いバックエンド処理を実現したい」という個人開発者・SaaS開発者に極めて強力な選択肢を提供します。特に売上集計や大規模データ加工のようにCPUバウンドになりがちなバッチ処理には、Rustの採用が最高の解決策となるでしょう。
← ホームへ戻る