dbts osaka 2014 d13 hitachikvs masakata kawanishi

© Hitachi, Ltd. 2014. All rights reserved.

日立だからこだわる。 ~一貫性を追求したインメモリ分散KVS~

株式会社日立製作所情報・通信システム社 ITプラットフォーム事業本部開発統括本部ソフトウェア開発本部第2AP基盤ソフト設計部川西正容

1


自己紹介名前：川西正容（カワニシマサカタ）会社：2012年度入社。とても大きい仕事：ミドルウェアの設計・開発著書：書いてみたい

2


一貫性ってなに？やばいの？

やばいです

説明します

3


アジェンダ

１．分散KVSとは２．分散KVSの弱点３．日立のシステム４．日立のインメモリ分散KVS

4


1.分散KVSとは

5


特徴

・負荷分散・スケーラビリティ・可用性

6


負荷分散各サーバで分散処理する

7

A aaa

write write

write

write B

write A

write C

C ccc B bbb

A aaa

C ccc B bbb

A aaa

C ccc B bbb


スケーラビリティ簡単にスケールアウトできる

8

A aaa

B bbb

C ccc

A aaa

A aaa B bbb

B bbb C ccc

C ccc

write B

write A

write C


可用性データロストしないため停止しにくい

9

A aaa

C ccc

A aaa B bbb

B bbb C ccc

C ccc

マシンが壊れても他のマシンにデータが

残ってる！

A aaa B bbb


分散KVSは

大量データを高速に処理したいときに使用されています

10


2.分散KVSの弱点

11


一貫性常に単一の最新データを取得したいが…

12

A aaa

A aaa

A aaa

get


一貫性が崩れるとき障害や遅延などで処理の順序を間違えると

13

A aaa

A aaa

1.write 2.remove

1.write A

2.remove A →ERROR 1.write A


一貫性が崩れるとき一時的に一貫性が崩れることがある

14

A aaa 1.write 2.remove

1.write A 2.remove A

2.remove A →ERROR 1.write A


A aaa

A aaa


そのデータは正しい？正しいデータを取得できない

15

A aaa

get

A aaa

A aaa データが残っている…？

？？？


分散KVSの弱点

一時的な障害や遅延で

一貫性が崩れてシステムトラブル

の可能性があります

16


3.日立のシステム

17


メッセージングメールを高速に振り分ける

18

分散KVS 携帯電話管理システム


スマートメータ電力消費量を管理する

19

電化製品電力会社分散KVS


TMS (Traffic Management Solution)

20

通信量をリアルタイムに制御する

中継地制御システム分散KVS


日立のシステム

もしも一貫性が崩れてシステムトラブルが起きたら

とんでもないことになります

21


4.日立のインメモリ分散KVS

22


日立のインメモリ分散KVS

日立のシステムに導入されているインメモリ分散KVS

EADs (uCosminexus Elastic Application Data store)

23


EADs

・インメモリ・自動分散配置・故障検知・稼動中サーバ復旧・Paxos

24


インメモリにデータを保存するため読み書きが高速

EADs2

EADs3

EADs4

EADs5

EADs1

インメモリ

25

Master Slave

Slave


データを自動で分散配置するため負荷を分散できる

EADs2

EADs3

EADs4

EADs5

EADs1

自動分散配置

26

A aaa A aaa B bbb

A aaa B bbb

B bbb

Master Master


永続的な障害が発生したサーバを自動的に離脱させシステムの停止を防ぐ

EADs2

EADs3

EADs4

EADs5

EADs1

故障検知

27

EADｓ１

delete

A aaa A aaa

A aaa

B bbb

B bbb

B bbb


EADs2

EADs3

EADs4

EADs5

EADs1

復旧時にシステムを停止させる必要が無い

稼動中サーバ復旧

28

EADｓ１

restore A aaa A aaa

A aaa

B bbb

B bbb

B bbb


・インメモリ・自動分散配置・故障検知・稼動中サーバ復旧

高速処理とか可用性のためのここらへんは当たり前ですよね

29


EADsの特徴は

一貫性保証一貫性が崩れる要因

・一時的な障害・スプリットブレイン

30


一貫性が崩れる要因


31


EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したときデータ更新中に障害が発生すると…

32

1.write A

1.write A

A aaa A aaa

A aaa

1.write A

Master

Slave

Slave


EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したとき障害中のサーバは処理できないので

33

1.write A 2.write C

1.write A 2.write C

A aaa A aaa

A aaa

C ccc C ccc

1.write A

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したときどんどん遅れていく

34

1.write A 2.write C 3.remove C


A aaa A aaa

A aaa

C ccc C ccc

1.write A

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したとき回復したときに処理を補完しようとするが

35

A aaa A aaa



A aaa

C ccc C ccc

1.write A 2.？？？ 3.？？？

Slave

Slave

Master


処理順序が崩れると…

EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したとき

36



A aaa A aaa

A aaa

C ccc C ccc

1.write A 2.remove C →ERROR

Slave

Slave

Master


処理順序が崩れると…

EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したとき

37



A aaa A aaa

A aaa

C ccc C ccc

C ccc

1.write A 2.remove C →ERROR 3.write C

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

一時的な障害が発生したとき一貫性が崩れる

38

A aaa A aaa

A aaa C ccc

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

各サーバの処理順序を常に同一にする

どうすればいいの？

39

A aaa A aaa

A aaa

1.write C 2.remove C 3.write A



Slave

Slave

Master


一貫性が崩れる要因


40


EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインのときネットワークの障害でクラスタが分断

41

A aaa A aaa

C ccc

C ccc

C ccc

A aaa


EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインのときクラスタが別々に動き出すと…

42

remove A

remove A A aaa

A aaa

A aaa

C ccc

C ccc

C ccc

Slave

Slave

Master


クラスタが別々に動き出すと…

EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインのとき

43

remove C

remove C

A aaa

A aaa

A aaa

C ccc

C ccc

C ccc Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインのとき解消されたときに…

44

A aaa

A aaa

A aaa

A aaa

C ccc

C ccc


EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインのとき一貫性が崩れる

45

全部消したはずなのに…

A aaa

A aaa

A aaa

A aaa

C ccc

C ccc


動くクラスタ1つに絞る

EADs2

EADs3

EADs4

EADs5

EADs1

どうすればいいの？

46

動けない！

動ける！

A aaa

A aaa

A aaa

C ccc

C ccc

C ccc


EADs2

EADs3

EADs4

EADs5

EADs1

どうすればいいの？解消された後は動けるクラスタに合わせる

47

おれらが正しい！おれらが

正しい！

おれらが正しい！

remove A

A aaa A aaa

A aaa C ccc

C ccc

C ccc


EADs

・インメモリ・自動分散配置・故障検知・稼動中サーバ復旧・Paxos

48


Paxos

一時的な障害でもスプリットブレインでも

同一の処理を同一の順序で配信するアルゴリズム

・過半数承認・処理補完

49


EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認過半数以上から承認されたら処理する

50

1.write A 承認！ 1.write A

するよ！

1.write A 承認！

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認一部のサーバに障害が発生しても処理は停止しない

51


するよ！

1.write A 承認！

Slave

Slave

Master


承認したサーバは承認内容を記録する

EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認

52

承認内容を記録

1.write A 承認！


するよ！ Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認承認を得たら処理を実行

53

write A write A

A aaa A aaa

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

障害中だったサーバが回復したら…

54

回復したけど仲間はずれ…

A aaa A aaa

Slave

Slave

Master


処理実行時に前回以前の抜けている処理を補完する

EADs2

EADs3

EADs4

EADs5

EADs1

処理補完

55

2.remove A 承認！

2.remove A するよ！

2.remove A承認！

だけど 1.write A

知らない！

A aaa A aaa

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完前回の承認内容を記録しているサーバは

56

A aaa A aaa

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完今回承認するサーバの中に必ず含まれる

57

承認するサーバ達

A aaa A aaa

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完誰かが前回の承認内容を知っているので…

58


A aaa A aaa

1.write A 知ってるよ！

教えて！

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完必ず補完することができる

59

A aaa A aaa

A aaa

1.write A

1.write A

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完過半数承認している限り必ず補完できるため処理順序が崩れない

60

A aaa A aaa

A aaa




Slave

Slave

Master


EADsは一時的な障害でも一貫性保証

61


過半数承認なので動けるクラスタは1つ

EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインのときは

62

処理できないクラスタ

３/５

２/５処理できるクラスタ


EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認過半数承認を行う

63

remove A




A aaa A aaa

C ccc

C ccc

C ccc

A aaa

Slave

Slave

Master


承認者が承認内容を記録する

EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認

64

A aaa A aaa

A aaa 承認内容を記録

C ccc

C ccc

C ccc




remove A

Slave

Master

Slave


過半数以上いる方は処理できる

EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認

65

remove A

remove A 処理できる！

A aaa A aaa

A aaa C ccc

C ccc

C ccc

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認過半数承認を行う

66

remove C

A aaa A aaa

A aaa C ccc

C ccc

C ccc

4.remove C 承認！

4.remove C するよ！

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

過半数承認過半数いない方は処理できない

67

処理できない…

A aaa A aaa

A aaa C ccc

C ccc

C ccc

remove C

承認内容を記録しない


EADs2

EADs3

EADs4

EADs5

EADs1

スプリットブレインが解消されたら…

68

A aaa A aaa

A aaa C ccc

C ccc

C ccc


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完処理実行時に前回以前の抜けている処理を補完する

69

A aaa A aaa

A aaa C ccc

C ccc

C ccc

5.write B 承認！

5.write B承認！

だけど

3.remove A 知らない！

5.write B するよ！

Slave

Slave

Master


前回の承認内容を記録しているサーバは

EADs2

EADs3

EADs4

EADs5

EADs1

処理補完

70

A aaa A aaa

A aaa C ccc

C ccc

C ccc

Slave

Slave

Master


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完今回承認するサーバの中に必ず含まれる

71

A aaa A aaa

A aaa C ccc

C ccc

C ccc


Slave

Slave

Master


誰かが前回の承認内容を知っているので…

EADs2

EADs3

EADs4

EADs5

EADs1


処理補完

72

A aaa A aaa

A aaa C ccc

C ccc

C ccc

3.remove A 知ってるよ！

Slave

Slave

Master

教えて！


必ず補完することができる

EADs2

EADs3

EADs4

EADs5

EADs1

処理補完

73

A aaa A aaa

C ccc

C ccc

C ccc

3.remove A

remove A

A aaa

3.remove A

Slave

Master

Slave


EADs2

EADs3

EADs4

EADs5

EADs1

処理補完過半数承認している限り必ず補完できるため処理順序が崩れない

74


2.write C

A aaa A aaa

A aaa C ccc

C ccc

C ccc 2.write C 5.write B

1.write A 2.write C

3.remove A 5.write B


5.write B B bbb

B bbb

B bbb


EADsはスプリットブレインでも一貫性保証

75


日立のこだわりは

一貫性

一貫性にこだわることによって社会インフラを支えています

76


付録


順序を守らない一貫性保証一貫性が崩れたら修正する｜結果整合性 Ex.ゴシッププロトコル・リードリペア

79

おれと一緒？

違う！

一緒！

A ccc

A ccc

A aaa


順序を守らない一貫性保証一貫性が崩れたら修正する｜結果整合性 Ex.ゴシッププロトコル・リードリペア

80

修正してやる！

repair A ccc

A ccc

A aaa


順序を守らない一貫性保証一貫性は保てるけど処理順序が狂うと古いデータが復活することがある

81

古いデータに修正してやる！

repair A old

A new

A new repair


可用性が低い一貫性保証一貫性を崩さない Ex.２PhaseCommit

82

やっちゃうぜ？

いいよー

いいよー


可用性が低い一貫性保証一貫性を崩さない Ex.２PhaseCommit

83

write

write write A aaa

A aaa

A aaa


可用性が低い一貫性保証全員が承認してくれるまで処理が進まない

84

・・・（承認してくれない）

・・・

いいよー

dbts osaka 2014 d13 hitachikvs masakata kawanishi

Technology