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

by LINEヤフーTech (LY Corporation Tech)

Embed

Start on current slide

Slide 1

Slide 1 text

LINE Messenger の次世代ストレージ選定 LINE ヤフー株式会社鶴原翔夢 1

Slide 2

Slide 2 text

Agenda LINE Messenger を支えるデータベースの概要と課題課題解決のための技術選定 YugabyteDB の強み 2

Slide 3

Slide 3 text

自己紹介 2013 年 LINE 株式会社入社 LINE 開発SBU メッセージングPF 開発SBU Messenger サービスのバックエンドエンジニア 3

Slide 4

Slide 4 text

LINE Messenger メッセンジャーサービスグローバルに利用可能国内月間利用者数1 億人突破 1 日数百億単位のメッセージを処理 4

Slide 5

Slide 5 text

Messenger のBackend ユーザーデータはHBase とRedis にストアされる暗号化済みメッセージもサーバー側に保存する( 直近2 週間分) 5

Slide 6

Slide 6 text

HBase とは Apache HBase HDFS(Hadoop File System) 上で動作する分散型NoSQL データベース (Key -> Value) というシンプルなデータモデルノードを追加することで水平方向にスケールすることができる Messenger の裏側では数百台規模のクラスターが複数稼働中 6

Slide 7

Slide 7 text

現状の課題トランザクションが使えないため、アプリケーション側のロジックが複雑化アプリケーションサイドでセカンダリーインデックスの構築など不整合の発生が不可避 HBase のユニークなAPI による開発者への負担アンチパターンを踏むと全体障害に発展することもある地理的に離れた場所への同期的なレプリケーションが実質不可能 7

Slide 8

Slide 8 text

HBase のレプリケーション内部的にはHDFS レイヤーでのチェインレプリケーション複数地域にまたがる場合は可用性を考慮すると使えないクラスタ間のレプリケーションは非同期のみサポート Destination 側にはデータが遅れて到達するのでStandby クラスタとして運用することになる Failover 時にわずかにデータロスが発生 8

Slide 9

Slide 9 text

Active-Standby 構成の問題 Active 側で障害が発生した時にFailover のステップを確実に行うための定期的な訓練の実施が必要 Standby 側は普段はアイドル状態になるので、Active 側と同じ規模の設備をおくのがコストになる Standby 側では機能を絞ることになるため、アプリケーションサーバーは縮退モードを実装することになるコードが複雑化 9

Slide 10

Slide 10 text

課題: Disaster Recovery のための環境維持が困難 10

Slide 11

Slide 11 text

Active-Active にしたい 11

Slide 12

Slide 12 text

Active-Active にするためには非同期レプリケーションでActive-Active を実現するにはアプリケーション側で、primary-secondary の厳密な制御が必要になる上に有事の際のデータロスが避けられないため、データがなくなる場合を考慮したアプリケーションの設計が必要になり難易度が非常に高いリージョンをまたがる同期レプリケーションが必要 12

Slide 13

Slide 13 text

同期レプリケーションにするとどうなるか 13

Slide 14

Slide 14 text

同期レプリケーションにするとどうなるか 14

Slide 15

Slide 15 text

同期レプリケーションにするとどうなるか 15

Slide 16

Slide 16 text

同期レプリケーションにするとどうなるか単純な同期レプリケーションでは可用性を下げてしまう WAN ネットワークの品質がDB のパフォーマンスに直結 16

Slide 17

Slide 17 text

Google のアプローチ Shard ごとに分散合意アルゴリズムPaxos を使ってレプリケーション Megastore (2011) Spanner (2012) 17

Slide 18

Slide 18 text

Spanner を使おう？ Vendor ロックインは避けたいコアテクノロジーのブラックボックス化を避けたいオンプレミス環境の資源を活用したい 18

Slide 19

Slide 19 text

Spanner Inspired なOSS 分散合意アルゴリズムRaft の発明によりSpanner クローンと呼ばれる OSS 製品が登場 TiDB YugabyteDB CockroachDB ライセンス変更によりOSS ではなくなった 19

Slide 20

Slide 20 text

技術選定 YugabyteDB TiDB CockroachDB Vitess MongoDB FoundatonDB etc, etc .... 20

Slide 21

Slide 21 text

評価基準機能セットレジリエンシーパフォーマンス ( レイテンシー・スループット) 21

Slide 22

Slide 22 text

機能セット地理分散のサポート水平スケールオンラインスキーマ変更セカンダリインデックスのサポート既存システムとの相互運用性などなど 22

Slide 23

Slide 23 text

レジリエンシー評価単一ノード障害からの復旧、単一リージョン障害からの復旧両方のシナリオにおいてYugabyteDB は迅速に回復可能 YugabyteDB はコントロールプレーンのノードが障害になったとしてもダウンタイムが発生しない 23

Slide 24

Slide 24 text

パフォーマンス評価 Messenger サービスのSLO を違反しないことが必須要件 2 種類の評価手法ベンチマークツール (YCSB) 本番トラフィックのリプレイ (Replayer) 24

Slide 25

Slide 25 text

試験環境 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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

本番トラフィックのリプレイ 27

Slide 28

Slide 28 text

Table1 SELECT median latency 28

Slide 29

Slide 29 text

Table1 INSERT median latency 29

Slide 30

Slide 30 text

Table2 SELECT median latency 30

Slide 31

Slide 31 text

Table2 UPDATE median latency 31

Slide 32

Slide 32 text

TiDB とYugabyteDB のパフォーマンスの違いテーブルによって得意不得意がある書き込みはTiDB が高速なケースが多いとくにセカンダリインデックスがあるテーブルへの更新は差が大きいおそらくTiDB のAsync Commit のおかげ 32

Slide 33

Slide 33 text

地理分散のパフォーマンスへの影響 33

Slide 34

Slide 34 text

地理分散のパフォーマンスへの影響 34

Slide 35

Slide 35 text

YugabyteDB のyb-master をリモートに移動してみる 35

Slide 36

Slide 36 text

TiDB のPD Leader をリモートに移動してみる ※ PD (PlacementDriver) = TiDB におけるControl Plane Node 36

Slide 37

Slide 37 text

TiDB のPD Leader をリモートに移動してみる 37

Slide 38

Slide 38 text

Why? TiDB はトランザクションタイムスタンプを取得するために PD (= control plane leader) にアクセスする必要がある。 https://docs.pingcap.com/tidb /stable/optimistic- transaction/ 38

Slide 39

Slide 39 text

トランザクションの順序付けの実装 TiDB: TimeStamp Oracle 方式を採用ほぼすべてのトランザクションがPD Leader にアクセスする必要があるため地理分散環境ではボトルネックが生じる YugabyteDB: Hybrid Logical Clock を採用 TimeStamp Oracle のような中央集権的なコンポーネントは存在しないノード間が通信するときにインクリメントする論理クロックと物理時計の時刻を組み合わせて因果関係を保ったまま順序付けを行う 39

Slide 40

Slide 40 text

パフォーマンスまとめ 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

Slide 41

Slide 41 text

YugabyteDB の強み地理分散環境下で同期レプリケーションを可能にしてくれる Hybrid Logical Clock を使うことにより、地理分散環境においてどの地域でも同等のパフォーマンスを発揮できるアプリケーションをActive-Active マルチデータセンター構成にするための要素技術となる OSS である 41

Slide 42

Slide 42 text

まとめ Disaster Recovery 環境維持のコスト効率改善のため地理分散同期レプリケーションが可能な技術の選定を行った YugabyteDB はActive-Active multi-DC 環境を実現するにあたって良い選択肢の一つであることを確認した 42

Slide 43

Slide 43 text

We're hiring!! https://www.lycorp.co.jp/ja/recruit/career/job- categories/ly00093/ 43