Neo4j 高可用性クラスタ― vs 大規模分散クラスタ―の解説

李 昌桓(LEE CHANGHWAN)

自己紹介

• 李 昌桓 (LEE CHANGHWAN, @awk256), DBが大好きなサーバーサイドのエンジニア Informix, Oracle, Red Brick, SQL Server, Amaozn Elastic Map Redeuce,

,Apache hadoop, MySQL, Neo4j, MongoDB, AWS全般…etc

• クリエーションライン株式会社(クラウドSI, MSP, ビックデータ分析)

CloudStack, OpenStack, Azure, Softlayer, AWS, Elastic Serarch, Spark,

HahsCorp, Chef, MongoDB, Neo4j…etc

• 著書

Amazon Cloudテクニカルガイド(インプレス, 2010)

Amazon Elastic MapReduceテクニカルガイド(インプレス, 2012)

Cypherクエリー言語の事例で学ぶグラフデータベースNeo4j(インプレスR&D, 2015)

グラフ型データベース入門(共著：リックテレコム, 2016)

RDB技術者のためのNoSQLガイド(共著：秀和システム, 2016)

1

本日のテーマはNeo4jの高可用性＆拡張性に関する話しです

2

• 高可用性(High Availbility)とは

• Neo4jのHAクラスタ―(High Availbility Cluster)とは

• Neo4jの大規模分散クラスタ―(Causal Cluster)とは

• まとめ

3

高可用性（High Availbility）とは

簡単に言えば、スペアタイヤーを装備している構成が原型です。タイヤ―がパンクしたら、さっさと

交換して走る続けることを想定しています。

4

コールドスタンバイ構成 （予備機）

Neo4jユーザ―グループ 5

予備機 稼働機 稼働機

バックアップ リストア

通常、このタイプは、色んなん意味で安く済むかも知れませんが、タイヤ―の交換作業はかなり面倒そうですね

6

ホットスタンバイ構成 （アクティブスタンバイ）

Neo4jユーザ―グループ 7

スレーブ マスター ↑マスター

データだよ

病気？！ さよなら

元気かい

このタイプの構成だと、1本なら

パンクしても、タイヤー交換なしで、安全な場所まで移動することができます

8

負荷分散構成 （HAクラスタ―）

9

• 基本的に3台以上の奇数で構成する(3~9台） • SLA応じて障害時の稼働台数を調整し、サービス停止は0近く保つ

• writeリクエストとreadリクエストを区別して分散できる

• クロスで死活監視を行う

プライマリー

セカンダリ セカンダリ データ同期

元気？

元気？ 元気？

このタイプは、かなりやばい状況でも走り続けることができます。

10

ディザスターリカバリ構成

11

プライマリー

セカンダリ

セカンダリ

地震など広域災害時にもサービスを続けられるように地理的な離れたデータセンターにレプリカを配置する

東京リージョン シンガポールリージョン

もう、タイヤ―の話しではなくなりました。核セルタを作りましょう

12

HAクラスタ―の最大のメリットは、

許容範囲内の障害であれば、自律的にデータの安全性を確保しつつ、稼働を続けられ

るということです

13

3台構成（1台死んでいいよ）

Neo4jユーザ―グループ 14

ノード１ ノード2 ノード3 サービス

◎ 〇 × 継続

◎ × 〇 継続

× ◎ 〇 継続

× 〇 ◎ 継続

◎⇒プライマリー(リーダー、マスター） 〇⇒セカンダリ（スレーブ、メンバー） × ⇒故障

5台構成（２台死んでいいよ）

Neo4jユーザ―グループ 15

ノード１ ノード2 ノード3 ノード4 ノード5 サービス

◎ 〇 〇 × × 継続

◎ 〇 × 〇 × 継続

◎ × 〇 × 〇 継続

× 〇 ◎ 〇 × 継続

× × ◎ 〇 〇 継続

〇 〇 × ◎ 〇 継続

〇 × 〇 × ◎ 継続

◎⇒プライマリー(リーダー、マスター） 〇⇒セカンダリ（スレーブ、メンバー） × ⇒故障

7台構成（３台死んでいいよ）

Neo4jユーザ―グループ 16

ノード１ ノード2 ノード3 ノード4 ノード5 ノード6 ノード7 サービス

◎ 〇 〇 〇 × × × 継続

◎ 〇 〇 × × × 〇 継続

◎ 〇 × × × 〇 〇 継続

◎

× ×

×

〇 〇

〇

継続

・・・中略・・・ 継続

× 〇 × 〇 × ◎ 〇 継続

◎⇒プライマリー(リーダー、マスター） 〇⇒セカンダリ（スレーブ、メンバー） × ⇒故障

9台構成（４台死んでいいよ）

Neo4jユーザ―グループ 17

ノード１

ノード2

ノード3

ノード4

ノード5

ノード6

ノード7

ード 8

ノード 9

サービス

◎ 〇 〇 〇 〇 × × × × 継続

× 〇 ◎ × × 〇 〇 × 〇 継続

× 〇 × × 〇 ◎ 〇 × 〇 継続

×

× 〇 ×

〇 ×

◎

〇 〇 継続

・・・中略・・・ 継続

× 〇 × 〇 × 〇

〇 × ◎ 継続

◎⇒プライマリー(リーダー、マスター） 〇⇒セカンダリ（スレーブ、メンバー） × ⇒故障

Neo4jユーザ―グループ 18

如何なる壊れ型をしても、お互いに連絡が取れる者が過半数いれば、そのグループ

（クォーラム）のなかで、新しいマスターを選出し、正常な稼働を続けます

なぜ、過半数なのか？

ネットワークを経由でデータのやり取りしている、という特性から過半数の連絡が取れるということは、データの信頼性が最も

高いグループだと認めます

19

なぜ、マスター選出が重要なのか

何台のHAクラスタ―構成でも書き込みをコミットする権限は、1台のマスターのみが持ち、追加し

が出来ないログを記録することで

データの一貫性を守るためです

20

複数のネットワーク分断が起きたとか、過半数以上のノードが死ん

だ場合はどうなるのか

21

通常、残りのノードはReadOnly状態に

陥て書き込みはできません

人間が介在して復旧する必要があります

22

このような「からくり」は「Raftプロトコール(分散合意アルゴリズム）」を参考に作られています。興味ある方は、下記を参照してください。

CONSENSUS: BRIDGING THEORY AND PRACTICE

https://ramcloud.stanford.edu/~ongaro/thesis.pdf

Raftについて(日本語）

https://gist.github.com/sile/ad435262c17eb79f133d

23

さて、どのような「からくり」なんでしょうか。マスター選出に関

する真実を簡略に紹介します

24

マスターは、

生き残った過半数以上の人達による投票(Vote)で決めるんだから民主的でいいね

25

実は、Raftプロトコールによるマスター選出は、どうみても、王権

争いに近いです

26

• 神様 人間 • 法律 Raftプロトコール • 王様 マスター or プライマリ or リーダー • 王位継承者達 メンバー全員が条件さえ満たせば、誰でも王に なれる

このような世界観の王国です

27

初代の王の擁立は、

神様(人間）の意思が強く働きます。

例えば、神様が与えた順位とか

結構、いい加減かも・・・

28

王様は、王国で起きた重大な事柄を追加のみが許される「王の巻物」に記録します。これ

は、王の使命であり、王権の象徴です

29

トランザクション・ログ

王は、「王の巻物」の記録追加を次々と

王継承者達に伝えることで、自分が健在であることをアピールします

30

王位継承者達は「王の巻物」を必死に筆写してきます。もしも、王権争いの際には、最新の記録をもっている者が王になる可能

性が高いからです。

31

これで、何もなければ、

平和が続きます

32

ただし、王継承者達は、虎視眈眈、王位を狙っています。お互いを監視しながら、王

様の隙を狙い続けます（ping)

33

王位継承者達は王国に分裂が起きると、連絡が取れる、遠慮なく、我先に自分

が王に相応しいと、宣言します

34

こうなると「王様が生存していて災害でたまたま孤立」していたとしても、王国が始まった時の勇者達の過半数が集まったグループで「新王」を擁立します

35

王になれる権利とは

通常、「王の巻物」の最新記録を持っていることです。

同等の場合は、既定の神様からの

優先順位で決まります

36

ここまで、高可用性(High Availbility)構成の

説明と、背景にある設計思想の説明でした

37

• 高可用性クラスタ―

• 負荷分散クラスタ―

• トランザクションの伝播(今のところNeo4jのみ）

• シンプルなコンフィグレーション

Neo4jのHAクラスタとは

38

Neo4jのHAクラスタ―の基本構成

39

HAプロクシ

[現在のマスター]

トランザクションの伝播

クラスタ―を起動するとマスターを自律的に選出します

トランザクションの伝播

HAプロクシは、リクエストを 各ノードに均等に割り当てます

GET/PUT/POST/DELETE

クライアント側ではクラスタ―へ接続するた

めに何もしなくても良いです

マスター

セカンダリ

セカンダリ

xxx.xxx.xxx.xxx

セカンダリが「書き込みリクエストを受けたら、マスターに引き渡します

トランザクションの伝播とは

40

HAプロクシ

[現在のマスター]

マスターのみがコミット権限をもっています

トランザクションの伝播

更新系のリクエスト PUT/POST/DELETE

①更新系のリクエストです

③差分データコピーします

②コミットしたよ

検索処理は、普通に行われます(GET)

[セカンダリ] [セカンダリ]

• トランザクションのコミットがセカンダリに伝播されている場合

データ流失は起きません

データを受け取ったセカンダリがマスターに昇格し、セカンダリが同期を取ります

• トランザクションのコミットがセカンダリに伝播されていない場合

データ流失のが起きます

新マスターが誕生し、新しいトランザクションをコミットしたら、セカンダリは同期を取りはじめ、ブランチしている旧マスターのデータはリカバリできません

トランザクション伝播と障害： リクエストを受け取ったマスター壊れた場合

41

ただし、これは理論的な可能性を言っているものであり、現実的に、このような事故が起きる確率はどのぐらいなのでしょうか 一瞬にしてDBが全然機能しなくなるような障害が起きる確率は?

なお、障害が起きた瞬間、ミリ秒の間をすり抜けて受け渡しができなくなるような不運なデータが発生する確率は?

• トランザクションのリクエストがマスターに伝播されている場合

データ流失は起きません

マスターがコミットし、セカンダリが同期を取ります

• トランザクションのリクエストがマスターに伝播されていない場合

データ流失が起きます

マスターが他のトランザクションをコミットすると、セカンダリが同期を取りはじめ、ブランチしているデータはリカバリできません

トランザクション伝播と障害： リクエストを受け取ったセカンダリが壊れた場合

42

ただし、これは理論的な可能性を言っているものであり、現実的に、このような事故が起きる確率はどのぐらいなのでしょうか 一瞬にしてDBが全然機能しなくなるような障害が起きる確率は?

なお、障害が起きた瞬間、ミリ秒の間をすり抜けて受け渡しができなくなるような不運なデータが発生する確率は?

conf/neo4j.conf

ha.server_id = 1

ha.initial_hosts = server1:5001,server2:5001, server3:5001

dbms.mode=HA

HAクラスタ―の設定::1台目

43

conf/neo4j.conf

ha.server_id = 2

ha.initial_hosts = server1:5001,server2:5001, server3:5001

dbms.mode=HA

HAクラスタ―の設定::2台目

44

conf/neo4j.conf

ha.server_id = 3

ha.initial_hosts = server1:5001,server2:5001, server3:5001

dbms.mode=HA

HAクラスタ―の設定::3台目

45

ここまで、Neo4j HAクラスタ―の説明でした。

46

Causalという言葉は、コンピューターサイエンス

から取ってきた言葉であり、既にCausal system, Causal consistency, Causal clusteringとかというふうに使われています。とちらも、分散処理に関わるある種の概念を表す言葉で、Neo4jの発明品ではありません。

Causal Cluster(大規模分散クラスタ―）

47

• 大規模のHAクラスタ―

• 大規模のリードレプリカ

• ディザスターリカバリ

Causal Clusterとは

48

より少ないリソースで

• コアは、HAクラスタ―を踏襲しています

• リードレプリカは、コアから同期を取ります

• マスター争奪争いには参加しません

Causal Clusterのアーキテクチャー

49

更新系

コア

リードレプリカ

アプリケーション

差分コピー

更新系のクエリーのみを受け入れる構成で

より少ないパワーで大量のスループットを処理することができます

コアサーバー群

50

PUT/POST/DELETE

コア

コアから独立しており、

一定間隔でコアから最新のトランザクションログを

コピーして来て同期を取ります

コアに殆ど負荷をかけません

レプリカサーバー群

51

コア

ログの差分コピー

まとめると、こんなイメージになります

Causal Clusterのユースケース データウェアハウス?!

52

HAプロクシ

アプリケーションサーバ コア

リードレプリカ

オペレーション系DB レポート系DB

HAプロクシ

分析サーバー

neo4j.conf

dbms.mode=CORE

causal_clustering.expected_core_cluster_size=3

causal_clustering.initial_discovery_members=

server1:5000, server2:5000, server3:5000

コアの設定

53

neo4j.conf

dbms.mode=READ_REPLICA

causal_clustering.initial_discovery_members=rserver1:5000, server2:5000, server3:5000

リードレプリカ構成

54

リードレプリカ構成で重要なことは、自分のミッションを認識し、コアサーバーの誰からデータを持って来るのかを教えることです。 リードレプリカの他の仲間を意識する必要は全くありません。

まとめ

55

区分 HAクラスター Causal Cluster

高可用性 • 同等 • 同等

拡張性 • 小規模 • 9ノードぐらい

• 中・大規模 • 数十台規模のリードレプリカ ただし、用途に応じては、小規模でも・・・

DR構成 • 現実的ではない • リードレプリカをデータセンター間で分散

THE END

56