Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Java ランタイムからカスタムランタイムに行き着くまで
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Sho
February 19, 2026
Technology
550
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Java ランタイムからカスタムランタイムに行き着くまで
TECH BATON in 東京 〜今 Lamdbaどうやって使ってる? 〜
Sho
February 19, 2026
More Decks by Sho
See All by Sho
チームでリファクタリングを進めるために
ririru0325
0
140
AWS歴6年のSaaS企業が直面する低凝集マイクロサービスの課題とその解決アプローチ
ririru0325
0
42
エムオーテックスの現場_-_SaaSプロダクトのアーキテクチャ変革と技術負債解消の道のり
ririru0325
0
79
できたこと・やっていきたいこと
ririru0325
0
65
jq を駆使して aws cli の運用を最適化
ririru0325
1
190
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
ririru0325
0
430
サーバーレスアプリケーションの観測を適正化し、運用負荷を減らしていってる話
ririru0325
0
77
Lambdaのこと
ririru0325
0
110
Other Decks in Technology
See All in Technology
現場で使える AWS DevOps Agent 活用ノウハウ - Release Management 機能の検証結果を添えて / AWS DevOps Agent Release Management and Know-How
kinunori
3
110
コンテナ・K8s研修【MIXI 26新卒技術研修】
mixi_engineers
PRO
1
280
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
AI時代におけるテストの基礎の再定義 / Rethinking the Fundamentals of Testing in the AI Era
mineo_matsuya
15
5.7k
20260720_クラウド女子会×PyLadiesTokyoコラボ Amazon Bedrock ハンズオン用資料
yuuka51
2
120
AI研修(Day1)【MIXI 26新卒技術研修】
mixi_engineers
PRO
1
1.3k
データベース研修【MIXI 26新卒技術研修】
mixi_engineers
PRO
1
340
AIコード生成×サプライチェーン攻撃 — PHPが直面する“二重の信頼問題
shinyasaita
0
490
現場との対話から始める “作る前に問い直す”業務改善
mochico50
2
310
伝票作成AIエージェントを支える、LLMOpsとインフラの選択肢 / AICon2026_takeda
rakus_dev
0
300
歴史から理解するクラウドインフラのしくみ
kizawa2020
0
170
探索・可視化・自動化を一本化 Amazon Quickでデータ活用スピードを上げる方法
koheiyoshikawa
0
210
Featured
See All Featured
The agentic SEO stack - context over prompts
schlessera
0
850
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
200
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.4k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
570
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
350
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
180
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
57k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
160
How to Ace a Technical Interview
jacobian
281
24k
Site-Speed That Sticks
csswizardry
13
1.4k
Transcript
Java ランタイムからカスタムランタイムに行き着くまで 2026.02.20 TECH BATON 桑名 翔 1
自己紹介 名前:桑名 翔(くわな しょう) 所属:エムオーテックス株式会社 サービス開発1部 関心:サーバーレス、CI/CD、生産性向上 趣味:スノーボード / ゲーム(APEXプレデター・Valorantイモータル)
2
アーキテクチャ概要 Lambdaを中心としたサーバーレス構成 トリガー: API Gateway / SQS 処理: Lambda(Scala) ストレージ:
DynamoDB / S3 サービス間はイベントバス(pub-sub)で非同期連携 Lambda:約1000個運用 3
課題 コールドスタートが遅い + コストが高い コールドスタートが遅い Lambdaのコンテナ準備 + JVMのクラスロード+JITコンパイルが初回に集中して 走るため LambdaはメモリとCPUが比例するため、性能のために多くメモリを割り当てる必要
がある → コストに直結 知ってた解決策: Provisioned Concurrency でも… コストがさらに増える 予約数を超えたら結局コールドスタートが発生する 4
調査を始めた 観点は2つ 性能改善:コールドスタートを速くしたい コスト最適化:メモリ割り当てを減らしたい 選択肢が複数見つかった 階層型コンパイル(環境変数) SnapStart カスタムランタイム 言語変更 5
まずは手軽なやつから:階層型コンパイルの調整 JVMが実行時にコードを最適化する処理のレベルを下げて、起動を速くする設定 JAVA_TOOL_OPTIONS: -XX:+TieredCompilation -XX:TieredStopAtLevel=1 環境変数の追加のみ・実装変更なし → 全体に適用(※ Java 17以降のランタイムはデフォ
ルトで有効) Before After init 3955ms 2260ms duration 193ms 142ms 合計 4148ms 2402ms サンプルでの検証結果 参考: https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-customization.html 6
次のステップを考えた カスタムランタイムを調べると... コールドスタートがさらに速くなる メモリも大幅に削減できる ただし実装コストが高い → いきなり全部は無理 7
まずは1つだけ試す 対象: 月10億回以上呼ばれてる関数 呼び出し回数が多い → メモリ削減の効果が金額に直結 試算した結果、コスト削減効果が大きいと判断 目的: コスト削減 GraalVM
Native Imageでネイティブバイナリ化 8
大変だった ビルド編 GraalVM Native Imageのビルドを通すのが難しい リフレクションの設定(reflect-config.json) ビルド時間が長い → 試行錯誤のコストが高い Lambda編
Runtime APIを直接扱う必要がある(今まで意識したことがなかった) カスタムランタイム特有の仕組みを一から理解 初めてだらけで時間がかかった 9
どうなったか 試行錯誤を繰り返してなんとか実装できた Before After コールドスタート 5000ms 800ms 実行時間 140ms 45ms
メモリ 1536MB 256MB 結果として、1つのLambdaだけで 年間 $30,000以上 のコスト削減 メモリ最適化によるコスト削減だけじゃなく コールドスタートも大きく改善 → 実装方法もわかった。モデルケースができた 10
言語変更という選択肢 カスタムランタイムの学習コスト vs 別言語習得コスト、どちらが現実的か考えた Node.js / Python などのマネージドランタイムであれば、JVMのようなコスト・性能 問題が起きにくい カスタムランタイムの深い知識も不要
でも… チームはScala中心 JVM知識が前提 開発文化もScala 結論:言語を変えるより、カスタムランタイムを扱える組織にする 11
まとめ 知見ゼロの状態から ↓ 手軽な改善(環境変数)で成果を出しつつ ↓ 1つのLambdaでカスタムランタイムを検証 ↓ モデルケースをもとに横展開中(API用のLambdaに順次適用) コールドスタート改善 =
レスポンス速度の改善 12
最後に カスタムランタイムを選んだ理由 最速だから → ✗ 最先端だから → ✗ 組織として一番現実的だったから 13
ありがとうございました! X(旧Twitter): @sho987_25 14