累計5000万DLサービスの裏側 – LINEマンガのKotlinで挑む大規模 Server-side ETLの最適化

「Kotlin Fest 2025」の登壇資料です。
https://2025.kotlinfest.dev/

Transcript

1. 累計5000万DLサービスの裏側 – LINEマンガのKotlinで挑む大規模 Server-side ETLの最適化 2025.11.01 LM Server Dev1 / Ono Akito (@omelette_alpaca) © LINE Digital Frontier Corporation
2. “ LINEマンガは累計5000万ダウンロードを超え、日々多くのユーザー にレコメンデーションを提供しています。 一見シンプルなバッチ処 理も、この規模になると、億単位のデータを高速に連携する必要が あるなど、全く別の課題が生まれます。 私たちは、これらの大規模 データ処理を、Kotlinで実装したETLバッチパイプラインで支えてい ます。 本セッションでは、この大規模ETLシステムの構築で直面している課 題と、改善に向けたリアルな試行錯誤を共有します。 本セッションのポイント: - 大規模データ処理における現実的な課題 - Kotlin Coroutines/Channel/Flowを用いた様々なトライ&エラー - 失敗と成功から得られた実践的な指針 実サービスの試行錯誤を通じて見えてきた、Kotlinによる大規模デー タETLのリアルをお伝えします。” Proposal (Re)
3. This Session’s TL;DR ETL x Coroutine x Flow は最高
4. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Try 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Try 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Try 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 2.3 Result 3.3 Result 06. Conclusion 6.1 Summary 4.2 Result 5.3 Result A 5.4 Try B 5.5 Result B
5. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Try 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Try 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Try 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 2.3 Result 3.3 Result 06. Conclusion 6.1 Summary 4.3 Result 5.3 Result A 5.4 Try B 5.5 Result B
6. 1. Introduction
7. • 電子コミックアプリ • 累計 5000 5500 万DLを突破 • 2025年第1四半期&第2四半期のアプリ収益ランキング1位 • **Server-side Kotlin**を採用 About LINE MANGA
8. • ユーザーにパーソナライズした作品を薦める仕組み • サービスの色々な箇所で利用されている • 提供までの時間が重要 About Recommendation
9. • ETL style batch How to recommend ?
10. What is the problem? (1) X000万ユーザー * N パターン = “億”単位のレコード
11. What is the problem? (2) どうやってデータを全部取り出せば… 現実的な実行時間に収まる? Batchマシンのリソースも
12. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Try 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Try 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 3.3 Result 06. Conclusion 6.1 Summary 4.3 Result 5.3 Result A 5.4 Try B 5.5 Result B 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Try 2.3 Result
13. 2. ”分ける“ – Trino queryにおけるdata segmentation
14. • 1 Queryでは取り出せない • LIMIT OFFSETのページングでは難しい Problem
15. • hashとmoduloで分割 Try (1)
16. • ユニークなIDカラムに対してhashを計算する • Hashのmod Nを計算する • mod N の結果単位で分割してデータを取得 Try (2)
17. • 実際のクエリ Try (3)
18. • データを全て取り出せた • ほぼ均等に分割できた • Nで任意のサイズに調整可能 Result
19. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Try 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Try 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 2.3 Result 06. Conclusion 6.1 Summary 4.3 Result 5.3 Result A 5.4 Try B 5.5 Result B 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Try 3.3 Result
20. 3. ”流す“ - Streamによるmemoryの効率化
21. • メモリに乗り切らない • Batchは他のJobとの共用なので可能な限り削減したい Problem
22. • データをStreamで処理する Try (1)
23. • JDBCのストリーミング処理を利用 • SpringのJDBC TemplateでStream<Record>に Try (2)
24. • 全データの処理がMemory 32GBのVMに収まった • 既存のメモリ使用量にあまり影響を与えず処理できた • CPUもちょっと重いJob程度 Result
25. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Try 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Try 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 2.3 Result 3.3 Result 06. Conclusion 6.1 Summary 5.3 Result A 5.4 Try B 5.5 Result B 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Try 4.3 Result
26. 4. “重ねる” - CoroutineによるTrino queryの並列化
27. • Trinoクエリに時間がかかる Problem
28. • Coroutineでクエリ自体を並列化する Try (1)
29. • Coroutine • Kotlinの非同期処理機構 • I/Oに強い(= non blocking) 軽量スレッド Try (2)
30. Try (3)
31. • クエリの実行時間が短縮された • 実行時間と並列数がほぼ線形になった Result
32. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Action 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Action 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Action Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 2.2 Result 3.3 Result 4.2 Result 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A 5.3 Result A 5.4 Try B 5.5 Result B 06. Conclusion 6.1 Summary
33. 5. “整える” - Flowによる全体の並列制御
34. • Extract(Trino)とLoad(Redis)を個別に並列処理で最適化したい • 一方でBatch全体で協調したい Problem
35. • Channel(kotlinx.coroutines.channel)を利用する • Go言語のGoroutine + Channelから着想 Try A (1)
36. Try A (2)
37. Try A (3)
38. • 失敗 • 実装自体はできたものの色々つらい • Channelの低レイヤーな操作がやや煩雑 • 処理コードが手続的になる Result A
39. • Flowを利用する Try B (1)
40. • Flow • 複数の非同期処理(suspend)を組み合わせる • Coroutineベース • Bufferという仕組みがある • （Coroutine + Channel) x N のチェーンを内部的に自動で構成 • ※ channel sizeとしてのbufferとは別 Try B (2)
41. Try B (3)
42. Try B (4)
43. Try B (5)
44. Try B (6)
45. Try B (7)
46. Try B (8)
47. • 成功 • 約 1000万 record / 15 min (=現行の3~7倍) を達成 • コードも宣言的にまとまって良い Result B
48. 01. Introduction 1.1 About LINE MANGA 1.2 About Recommendation 04. “重ねる” - CoroutineによるTrino queryの並列化 4.1 Problem 4.2 Try 02. “分ける” - Trinoにおけるdata segmentation 2.1 Problem 2.2 Try 03. “流す” - Streamによるmemoryの効率化 3.1 Problem 3.2 Try 05. “整える” - Flowによる全体の並列制御 5.1 Problem 5.2 Try A Agenda 1.3 How to recommend ? 1.3 What is the Problem ? 2.3 Result 3.3 Result 4.3 Result 5.3 Result A 5.4 Try B 5.5 Result B 06. Conclusion 6.1 Summary
49. 6. Conclusion
50. Summary (1) “流す” - Streamによるmemoryの効率化 ” 分ける” - Trinoにおけるdata segmentation Problem: データサイズが大きすぎる Solution: Hash + moduloで分割 Problem: メモリ使用量を削減したい Solution: Streamで処理 “整える” - Flowによる全体の並列制御 “重ねる” - CoroutineによるTrino queryの並列化 Problem: クエリに時間がかかる Solution: Coroutineで並列化 Problem: 個別最適化しつつ全体協調したい Solution: Flowで制御
51. Summary (2) 1000万 record / 15 minを達成
52. This Session’s TL;DR (again) ETL x Coroutine x Flow は最高
53. We Are *Strongly* Hiring !! [PR] Company Deck Jobs
54. End Of doc.