高可用性(High Availability)とは ・Neo4jのHAクラスタ―(High Availviaity Cluster)とは ・Neo4jの大規模分散クラスタ―(Causal Cluster）とは 本スライドでは、かなりインフラ寄りの内容を誰でも理解できるように解説しています。

1. Neo4j 高可用性クラスタ―
vs 大規模分散クラスタ―の解説
李 昌桓(LEE CHANGHWAN)

2. 自己紹介
• 李 昌桓 (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

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

4. • 高可用性(High Availbility)とは
• Neo4jのHAクラスタ―(High Availbility
Cluster)とは
• Neo4jの大規模分散クラスタ―(Causal
Cluster)とは
• まとめ
3

5. 高可用性（High Availbility）とは
簡単に言えば、スペアタイヤーを装備している構
成が原型です。タイヤ―がパンクしたら、さっさと
交換して走る続けることを想定しています。
4

6. コールドスタンバイ構成
（予備機）
Neo4jユーザ―グループ 5
予備機稼働機 稼働機
バックアップ リストア

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

8. ホットスタンバイ構成
（アクティブスタンバイ）
Neo4jユーザ―グループ 7
スレーブマスター ↑マスター
データだよ
病気？！
さよなら
元気かい

9. このタイプの構成だと、1本なら
パンクしても、タイヤー交換なしで、安全
な場所まで移動することができます
8

10. 負荷分散構成
（HAクラスタ―）
9
• 基本的に3台以上の奇数で構成する(3~9台）
• SLA応じて障害時の稼働台数を調整し、サー
ビス停止は0近く保つ
• writeリクエストとreadリクエストを区別して分
散できる
• クロスで死活監視を行う
プライマリー
セカンダリ セカンダリ
データ同期
元気？
元気？ 元気？

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

12. ディザスターリカバリ構成
11
プライマリー
セカンダリ
セカンダリ
地震など広域災害時にもサービスを続けられる
ように地理的な離れたデータセンターにレプリカ
を配置する
東京リージョン シンガポール
リージョン

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

14. HAクラスタ―の最大のメリットは、
許容範囲内の障害であれば、自律的にデー
タの安全性を確保しつつ、稼働を続けられ
るということです
13

15. 3台構成（1台死んでいいよ）
Neo4jユーザ―グループ 14
ノード１ ノード2 ノード3 サービス
◎ 〇 × 継続
◎ × 〇 継続
× ◎ 〇 継続
× 〇 ◎ 継続
◎⇒プライマリー(リーダー、マスター）
〇⇒セカンダリ（スレーブ、メンバー）
× ⇒故障

16. 5台構成（２台死んでいいよ）
Neo4jユーザ―グループ 15
ノード１ ノード2 ノード3 ノード4 ノード5 サービス
◎ 〇 〇 × × 継続
◎ 〇 × 〇 × 継続
◎ × 〇 × 〇 継続
× 〇 ◎ 〇 × 継続
× × ◎ 〇 〇 継続
〇 〇 × ◎ 〇 継続
〇 × 〇 × ◎ 継続
◎⇒プライマリー(リーダー、マスター）
〇⇒セカンダリ（スレーブ、メンバー）
× ⇒故障

17. 7台構成（３台死んでいいよ）
Neo4jユーザ―グループ 16
ノード１ ノード2 ノード3 ノード4 ノード5 ノード6 ノード7 サービ
ス
◎ 〇 〇 〇 × × × 継続
◎ 〇 〇 × × × 〇 継続
◎ 〇 × × × 〇 〇 継続
◎ × × × 〇 〇 〇 継続
・・・中略・・・ 継続
× 〇 × 〇 × ◎ 〇 継続
◎⇒プライマリー(リーダー、マスター）
〇⇒セカンダリ（スレーブ、メンバー）
× ⇒故障

18. 9台構成（４台死んでいいよ）
Neo4jユーザ―グループ 17
ノード
１
ノード
2
ノード
3
ノード
4
ノード
5
ノード
6
ノード
7
ード
8
ノード
9
サービ
ス
◎ 〇 〇 〇 〇 × × × × 継続
× 〇 ◎ × × 〇 〇 × 〇 継続
× 〇 × × 〇 ◎ 〇 × 〇 継続
× × 〇 × 〇 × ◎ 〇 〇 継続
・・・中略・・・ 継続
× 〇 × 〇 × 〇 〇 × ◎ 継続
◎⇒プライマリー(リーダー、マスター）
〇⇒セカンダリ（スレーブ、メンバー）
× ⇒故障

19. Neo4jユーザ―グループ 18
如何なる壊れ型をしても、お互いに連絡が
取れる者が過半数いれば、そのグループ
（クォーラム）のなかで、新しいマスター
を選出し、正常な稼働を続けます

20. なぜ、過半数なのか？
ネットワークを経由でデータのやり取りし
ている、という特性から過半数の連絡が取
れるということは、データの信頼性が最も
高いグループだと認めます
19

21. なぜ、マスター選出が重要なのか
何台のHAクラスタ―構成でも書き込みをコミット
する権限は、1台のマスターのみが持ち、追加し
が出来ないログを記録することで
データの一貫性を守るためです
20

22. 複数のネットワーク分断が起きた
とか、過半数以上のノードが死ん
だ場合はどうなるのか
21

23. 通常、残りのノードはReadOnly状態に
陥て書き込みはできません
人間が介在して復旧する必要があります
22

24. このような「からくり」は「Raftプロトコール
(分散合意アルゴリズム）」を参考に作られていま
す。興味ある方は、下記を参照してください。
CONSENSUS: BRIDGING THEORY AND PRACTICE
https://ramcloud.stanford.edu/~ongaro/thesis.pdf
Raftについて(日本語）
https://gist.github.com/sile/ad435262c17eb79f133d
23

25. さて、どのような「からくり」な
んでしょうか。マスター選出に関
する真実を簡略に紹介します
24

26. マスターは、
生き残った過半数以上の人達による投票
(Vote)で決めるんだから民主的でいいね
25

27. 実は、Raftプロトコールによるマ
スター選出は、どうみても、王権
争いに近いです
26

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

29. 初代の王の擁立は、
神様(人間）の意思が強く働きます。
例えば、神様が与えた順位とか
結構、いい加減かも・・・
28

30. 王様は、王国で起きた重大な事柄を追加のみ
が許される「王の巻物」に記録します。これ
は、王の使命であり、王権の象徴です
29
トランザクション・ログ

31. 王は、「王の巻物」の記録追加を次々と
王継承者達に伝えることで、自分が健在で
あることをアピールします
30

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

33. これで、何もなければ、
平和が続きます
32

34. ただし、王継承者達は、虎視眈眈、王位を
狙っています。お互いを監視しながら、王
様の隙を狙い続けます（ping)
33

35. 王位継承者達は王国に分裂が起きると、
連絡が取れる、遠慮なく、我先に自分
が王に相応しいと、宣言します
34

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

37. 王になれる権利とは
通常、「王の巻物」の最新記録を持ってい
ることです。
同等の場合は、既定の神様からの
優先順位で決まります
36

38. ここまで、高可用性(High Availbility)構成の
説明と、背景にある設計思想の説明でした
37

39. • 高可用性クラスタ―
• 負荷分散クラスタ―
• トランザクションの伝播(今のところNeo4jのみ）
• シンプルなコンフィグレーション
Neo4jのHAクラスタとは
38

40. Neo4jのHAクラスタ―の基本構成
39
HAプロクシ
[現在のマスター]
トランザクションの伝播
クラスタ―を起動するとマス
ターを自律的に選出します
トランザクションの伝播
HAプロクシは、リクエストを
各ノードに均等に割り当てます
GET/PUT/POST/DELETE
クライアント側ではク
ラスタ―へ接続するた
めに何もしなくても良
いです
マスター
セカンダリ
セカンダリ
xxx.xxx.xxx.xxx
セカンダリが「書き込みリクエ
ストを受けたら、マスターに引
き渡します

41. トランザクションの伝播とは
40
HAプロクシ
[現在のマスター]
マスターのみがコミット権限をもっています
トランザクションの伝播
更新系のリクエスト
PUT/POST/DELETE
①更新系のリクエストです
③差分データコピーします
②コミットしたよ
検索処理は、普通に
行われます(GET)
[セカンダリ][セカンダリ]

42. • トランザクションのコミットがセカンダリに伝播されている場合
 データ流失は起きません
 データを受け取ったセカンダリがマスターに昇格し、セカンダリが同期を取ります
• トランザクションのコミットがセカンダリに伝播されていない場合
 データ流失のが起きます
 新マスターが誕生し、新しいトランザクションをコミットしたら、セカンダリは同期を取り
はじめ、ブランチしている旧マスターのデータはリカバリできません
トランザクション伝播と障害：
リクエストを受け取ったマスター壊れた場合
41
ただし、これは理論的な可能性を言っているものであり、現実的に、このような事故が起き
る確率はどのぐらいなのでしょうか
 一瞬にしてDBが全然機能しなくなるような障害が起きる確率は?
 なお、障害が起きた瞬間、ミリ秒の間をすり抜けて受け渡しができなくなるような不運な
データが発生する確率は?

43. • トランザクションのリクエストがマスターに伝播されている場合
 データ流失は起きません
 マスターがコミットし、セカンダリが同期を取ります
• トランザクションのリクエストがマスターに伝播されていない場合
 データ流失が起きます
 マスターが他のトランザクションをコミットすると、セカンダリが同期を取りはじ
め、ブランチしているデータはリカバリできません
トランザクション伝播と障害：
リクエストを受け取ったセカンダリが壊れた場合
42
ただし、これは理論的な可能性を言っているものであり、現実的に、このような事故が起き
る確率はどのぐらいなのでしょうか
 一瞬にしてDBが全然機能しなくなるような障害が起きる確率は?
 なお、障害が起きた瞬間、ミリ秒の間をすり抜けて受け渡しができなくなるような不運な
データが発生する確率は?

44. conf/neo4j.conf
ha.server_id = 1
ha.initial_hosts =
server1:5001,server2:5001, server3:5001
dbms.mode=HA
HAクラスタ―の設定::1台目
43

45. conf/neo4j.conf
ha.server_id = 2
ha.initial_hosts =
server1:5001,server2:5001, server3:5001
dbms.mode=HA
HAクラスタ―の設定::2台目
44

46. conf/neo4j.conf
ha.server_id = 3
ha.initial_hosts =
server1:5001,server2:5001, server3:5001
dbms.mode=HA
HAクラスタ―の設定::3台目
45

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

48. Causalという言葉は、コンピューターサイエンス
から取ってきた言葉であり、既にCausal system,
Causal consistency, Causal clusteringとかとい
うふうに使われています。とちらも、分散処理に
関わるある種の概念を表す言葉で、Neo4jの発明
品ではありません。
Causal Cluster(大規模分散クラスタ―）
47

49. • 大規模のHAクラスタ―
• 大規模のリードレプリカ
• ディザスターリカバリ
Causal Clusterとは
48
より少ない
リソースで

50. • コアは、HAクラスタ―を踏襲しています
• リードレプリカは、コアから同期を取ります
• マスター争奪争いには参加しません
Causal Clusterのアーキテクチャー
49
更新系
コア
リードレプリカ
アプリケーション
差分コピー

51. 更新系のクエリーのみを受け入れる構成で
より少ないパワーで大量のスループットを
処理することができます
コアサーバー群
50
PUT/POST/DELETE
コア

52. コアから独立しており、
一定間隔でコアから最新のトランザクションログを
コピーして来て同期を取ります
コアに殆ど負荷をかけません
レプリカサーバー群
51
コア
ログの差分コピー

53. まとめると、こんなイメージになります
Causal Clusterのユースケース
データウェアハウス?!
52
HAプロクシ
アプリケーション
サーバ コア
リードレプリカ
オペレーション系DB
レポート系DB
HAプロクシ
分析サーバー

54. neo4j.conf
dbms.mode=CORE
causal_clustering.expected_core_cluster_size=3
causal_clustering.initial_discovery_members=
server1:5000, server2:5000, server3:5000
コアの設定
53

55. neo4j.conf
dbms.mode=READ_REPLICA
causal_clustering.initial_discovery_members=r
server1:5000, server2:5000, server3:5000
リードレプリカ構成
54
リードレプリカ構成で重要なことは、自分のミッションを認識し、コアサー
バーの誰からデータを持って来るのかを教えることです。
リードレプリカの他の仲間を意識する必要は全くありません。

56. まとめ
55
区分 HAクラスター Causal Cluster
高可用性 • 同等 • 同等
拡張性 • 小規模
• 9ノードぐらい
• 中・大規模
• 数十台規模のリードレプリカ
ただし、用途に応じては、小規模でも・・・
DR構成 • 現実的ではない • リードレプリカをデータセンター間で分散

57. THE END
56