LINE Messengerの次世代ストレージ選定

2026年2月24日に開催された「YugabyteDB Japan Meetup #7」での発表資料です。

Transcript

1. LINE Messenger の次世代ストレージ選定 LINE ヤフー株式会社 鶴原翔夢 1
2. Agenda LINE Messenger を支えるデータベースの概要と課題 課題解決のための技術選定 YugabyteDB の強み 2
3. 自己紹介 2013 年 LINE 株式会社入社 LINE 開発SBU メッセージングPF 開発SBU Messenger サービスのバックエンドエンジニア 3
4. LINE Messenger メッセンジャーサービス グローバルに利用可能 国内月間利用者数1 億人突破 1 日数百億単位のメッセージを処理 4
5. Messenger のBackend ユーザーデータはHBase とRedis にストアされる 暗号化済みメッセージもサーバー側に保存する( 直近2 週間分) 5
6. HBase とは Apache HBase HDFS(Hadoop File System) 上で動作する分散型NoSQL データベース (Key -> Value) というシンプルなデータモデル ノードを追加することで水平方向にスケールすることができる Messenger の裏側では数百台規模のクラスターが複数稼働中 6
7. 現状の課題 トランザクションが使えないため、アプリケーション側のロジック が複雑化 アプリケーションサイドでセカンダリーインデックスの構築など 不整合の発生が不可避 HBase のユニークなAPI による開発者への負担 アンチパターンを踏むと全体障害に発展することもある 地理的に離れた場所への同期的なレプリケーションが実質不可能 7
8. HBase のレプリケーション 内部的にはHDFS レイヤーでのチェイ ンレプリケーション 複数地域にまたがる場合は可用性を 考慮すると使えない クラスタ間のレプリケーションは非 同期のみサポート Destination 側にはデータが遅れて到 達するのでStandby クラスタとして運 用することになる Failover 時にわずかにデータロスが発 生 8
9. Active-Standby 構成の問題 Active 側で障害が発生した時にFailover のステップを確実に行うた めの定期的な訓練の実施が必要 Standby 側は普段はアイドル状態になるので、Active 側と同じ規模 の設備をおくのがコストになる Standby 側では機能を絞ることになるため、アプリケーションサー バーは縮退モードを実装することになる コードが複雑化 9
10. 課題: Disaster Recovery のための環境維持が困難 10
11. Active-Active にしたい 11
12. Active-Active にするためには 非同期レプリケーションでActive-Active を実現するにはアプリケー ション側で、primary-secondary の厳密な制御が必要になる上に有 事の際のデータロスが避けられないため、データがなくなる場合を 考慮したアプリケーションの設計が必要になり難易度が非常に高い リージョンをまたがる同期レプリケーションが必要 12
13. 同期レプリケーションにするとどうなるか 13
14. 同期レプリケーションにするとどうなるか 14
15. 同期レプリケーションにするとどうなるか 15
16. 同期レプリケーションにするとどうなるか 単純な同期レプリケーションでは可用性を下げてしまう WAN ネットワークの品質がDB のパフォーマンスに直結 16
17. Google のアプローチ Shard ごとに分散合意アルゴ リズムPaxos を使ってレプリ ケーション Megastore (2011) Spanner (2012) 17
18. Spanner を使おう？ Vendor ロックインは避けたい コアテクノロジーのブラックボックス化を避けたい オンプレミス環境の資源を活用したい 18
19. Spanner Inspired なOSS 分散合意アルゴリズムRaft の発明によりSpanner クローンと呼ばれる OSS 製品が登場 TiDB YugabyteDB CockroachDB ライセンス変更によりOSS ではなくなった 19
20. 技術選定 YugabyteDB TiDB CockroachDB Vitess MongoDB FoundatonDB etc, etc .... 20
21. 評価基準 機能セット レジリエンシー パフォーマンス ( レイテンシー・スループット) 21
22. 機能セット 地理分散のサポート 水平スケール オンラインスキーマ変更 セカンダリインデックスのサポート 既存システムとの相互運用性 などなど 22
23. レジリエンシー評価 単一ノード障害からの復 旧、単一リージョン障害か らの復旧両方のシナリオに おいてYugabyteDB は迅速に 回復可能 YugabyteDB はコントロール プレーンのノードが障害に なったとしてもダウンタイ ムが発生しない 23
24. パフォーマンス評価 Messenger サービスのSLO を違反しないことが必須要件 2 種類の評価手法 ベンチマークツール (YCSB) 本番トラフィックのリプレイ (Replayer) 24
25. 試験環境 Data Plane Node Spec name spec OS Rocky Linux 8.6 CPU 2.1Ghz 12 core x 2 Memory 256GB Disk NVMe-SSD 3200GB, SATA-SSD 480GB x 2 25
26. YCSB workload request type ratio data loading INSERT 100% workload "a" READ:UPDATE = 50%:50% workload "b" READ:UPDATE = 90%:10% workload "c" READ:UPDATE = 100%:0% workload "f" READ:READ-MODIFY-WRITE = 50%:50% 26
27. 本番トラフィックのリプレイ 27
28. Table1 SELECT median latency 28
29. Table1 INSERT median latency 29
30. Table2 SELECT median latency 30
31. Table2 UPDATE median latency 31
32. TiDB とYugabyteDB のパフォーマンス の違い テーブルによって得意不得意がある 書き込みはTiDB が高速なケースが多い とくにセカンダリインデックスがあるテーブルへの更新は差が大 きい おそらくTiDB のAsync Commit のおかげ 32
33. 地理分散のパフォーマンスへの影響 33
34. 地理分散のパフォーマンスへの影響 34
35. YugabyteDB のyb-master をリモートに移動してみる 35
36. TiDB のPD Leader をリモートに移動してみる ※ PD (PlacementDriver) = TiDB におけるControl Plane Node 36
37. TiDB のPD Leader をリモートに移動してみる 37
38. Why? TiDB はトランザクションタイ ムスタンプを取得するために PD (= control plane leader) に アクセスする必要がある。 https://docs.pingcap.com/tidb /stable/optimistic- transaction/ 38
39. トランザクションの順序付けの実装 TiDB: TimeStamp Oracle 方式を採用 ほぼすべてのトランザクションがPD Leader にアクセスする必要 があるため地理分散環境ではボトルネックが生じる YugabyteDB: Hybrid Logical Clock を採用 TimeStamp Oracle のような中央集権的なコンポーネントは存在 しない ノード間が通信するときにインクリメントする論理クロックと物 理時計の時刻を組み合わせて因果関係を保ったまま順序付けを行 う 39
40. パフォーマンスまとめ Max Throughput (YCSB) DB Throughput (ops/sec) YugabyteDB 90.6K (write-only) - 141.8K (read-only) TiDB 76.9K(read-modify-write) - 162.7K(read-only) Median Latency (Replayer) DB WRITE READ YugabyteDB 40.9 - 144ms 1.44 - 2.58ms TiDB 35.2 - 89.6ms 1.56 - 52.5ms 40
41. YugabyteDB の強み 地理分散環境下で同期レプリケーションを可能にしてくれる Hybrid Logical Clock を使うことにより、地理分散環境においてどの 地域でも同等のパフォーマンスを発揮できる アプリケーションをActive-Active マルチデータセンター構成にす るための要素技術となる OSS である 41
42. まとめ Disaster Recovery 環境維持のコスト効率改善のため地理分散同期レ プリケーションが可能な技術の選定を行った YugabyteDB はActive-Active multi-DC 環境を実現するにあたって良 い選択肢の一つであることを確認した 42
43. We're hiring!! https://www.lycorp.co.jp/ja/recruit/career/job- categories/ly00093/ 43