コールドスタート神話：イベントのためのJVM最適化

SchemaBridge Team · 2026-01-20 · Serverless, Performance, JVM, Java

なぜJavaはもはやサーバーレスに「遅すぎる」わけではないのか。スレッドプール、JITウォーミング、そして長時間稼働するコンテキストについて。

現代クラウドの「レイテンシ税」

「サーバーレス」は私たちを救うはずでした。無限のスケーリングとゼロマネジメントを約束していたのです。しかし、ユーザー向けレイテンシ（User-Facing Latency）に関して言えば、汎用的なサーバーレス関数（FaaS）には隠された欠点があります。それがコールドスタート（Cold Start）です。

しばらく実行されていなかったLambdaにリクエストが届くと、プロバイダーはコンテナを起動し、ランタイムをブートし、コードをロードしなければなりません。複雑なアプリケーションでは、これに数秒かかることもあります。現代のWebアプリケーションの世界において、2秒は永遠にも等しい時間です。それは「キビキビした」体験と「壊れた」体験の違いを生み出します。

長年、業界の常識は「Javaはサーバーレスには重すぎる。GoかNode.jsを使うべきだ」というものでした。

SchemaBridgeでは、この常識に挑戦しています。私たちはJVM（Java仮想マシン）の堅牢性に依拠しており、Javaを捨てるのではなく、その動作方法を最適化することでコールドスタート問題を解消するようにシステムを設計しています。

JVM：短距離走者ではなく、荷役獣

JVMは、一時的な関数のためではなく、長時間稼働するサーバープロセスのために設計されています。起動直後は「ウォームアップ」に時間を費やします――クラスのロード、バイトコードのインタープリタ実行、そしてホットパスの最適化（JITコンパイル）です。

Javaアプリケーションを100msで消滅する「関数」として扱うなら、それはランタイムの物理法則に逆らっていることになります。JIT最適化の恩恵を受けることなく、リクエストのたびに起動コストを支払い続けることになるのです。

活用法：長時間稼働するアプリケーションコンテキスト

SchemaBridgeは、ワークフローのステップを分離された一時的な関数として実行することはありません。代わりに、長時間稼働型ワーカーモデルを採用しています。

1. スレッドプーリング：永続的なアプリケーションコンテキスト内で、ウォーム状態のスレッドプールを維持します。イベントが到着すると、既存のウォームなスレッドがそれを処理します。OSプロセスの生成もJVMの起動も不要です。実行は即座に行われます。

2. JIT最適化：私たちのワーカーは数日から数週間にわたって稼働し続けるため、JVMのC2コンパイラはロジックをネイティブマシンコード並みの速度まで最適化する時間を持てます。実行されればされるほど、コードは実際に速くなっていきます。

3. コネクションプーリング：データベース接続の管理にはコストがかかります。FaaSモデルでは、接続の開閉が常に発生します。私たちの長時間稼働ワーカーは、DynamoDBや外部サービスへの健全なコネクションプールを維持し、1呼び出しあたり数十ミリ秒のレイテンシを削減します。

未来：GraalVMとネイティブイメージ

現在は主にウォーム状態の標準JVMに依拠していますが、私たちはGraalVM Native Imageの活用についても積極的に実験を行っています。

Native Imageを使えば、Javaアプリケーションを事前コンパイル（AOT）し、スタンドアロンのバイナリとして生成できます。これによりJVMのウォームアップフェーズが完全に排除されます。

この技術は、Javaエコシステムの生産性とGoやRustの起動速度との間のギャップを埋めるものです。GraalVMが成熟するにつれ、これは私たちのインフラの中核を担うようになり、「コールドスタート」のペナルティなしに、負荷の急増に応じて新しいワーカーを動的に立ち上げられるようになるでしょう。

ケーススタディ：高頻度広告入札

私たちは、入札リクエストを50ms未満で処理する必要があったAdTech企業と協業しました。

課題

彼らはJavaによる標準的なAWS Lambdaを使用していました。定期的に発生するコールドスタートのせいで、p99レイテンシは2秒に達していました。これは、入札機会の5%を逃していることを意味していました。

SchemaBridgeによる解決策

彼らは入札ロジックをSchemaBridgeのウォームワーカープールに移行しました。

1. ウォームスレッド：ロジックは事前にウォームアップされたスレッド上で実行されました。

2. 結果：p99レイテンシは18msまで低下しました。

3. 安定性：コンテナのプロビジョニング待ちが発生しなくなったため、レイテンシのばらつき（ジッター）は事実上消滅しました。

比較：一時的なFaaS vs. SchemaBridgeワーカー

| 項目 | 標準的なFaaS（Lambda） | SchemaBridgeウォームワーカー |

| :--- | :--- | :--- |

| コールドスタート | 200ms〜2秒 | 1ms未満（キューポーリング時間） |

| ランタイム | リクエスト時に起動 | 永続的なプロセス |

| 最適化 | なし（コードは若くして消える） | 完全なJITコンパイル |

| 接続 | 頻繁に再確立 | プールされ再利用 |

| コストモデル | リクエスト単位（単価が高い） | ワーカー時間単位（単価が低い） |

Javaパフォーマンスのためのエキスパートチェックリスト

1. リソースを再利用する：ハンドラー関数内でデータベースクライアントを作成してはいけません。一度だけ（static/グローバルとして）作成し、再利用してください。

2. ヒープをチューニングする：積極的なガベージコレクションを避けるため、コンテナに対してJVMヒープのサイズが適切に設定されていることを確認してください。

3. リフレクションを避ける：（一部の古いJSONパーサーのような）リフレクションを多用するライブラリはウォームアップが遅くなります。可能な限りコンパイル時生成を選択してください。

4. GCポーズを監視する：ガベージコレクションがワークフローにレイテンシスパイクをもたらしていないか、ツールを使って確認してください。

結論：ランタイムは重要である

「サーバーレス＝遅い」という時代は終わりました。ランタイムの背後にある物理法則を理解し、その法則を尊重するアーキテクチャを選択することで、私たちは関数特有の開発速度と、ベアメタル並みの生のパフォーマンスを両立できるのです。

第13回では「ジェネリックコネクタ」パターンについて解説しました。第14回では「コンプライアンスと監査」を取り上げ、規制当局のためにあらゆる実行をトレースする方法について見ていきます。

詳しく見る