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