C22...

株式会社日立製作所情報・通信システム社

スプリットブレインになっても一貫性を保証するインメモリデータグリッド製品

ＩＴプラットフォーム事業本部開発統括本部

2013/05/30

梅田多一

db tech showcase 大阪 2013

自己紹介

DB Online http://enterprisezine.jp/dbonline/detail/3991

２０００年入社・Ｃｏｓｍｉｎｅｘｕｓ開発・Ｃｏｓｍｉｎｅｘｕｓテクニカルサポート仕事のスタイル・ＴＴＰ・ＧＮＮ

インメモリデータグリッドって何だ？

Contents

インメモリデータグリッドの要素技術

強一貫性への挑戦！

登場の背景

・発信データの爆発的増加（Big Data）

・データを扱うミドルウェアへの要件として

大量発信データの高速処理、リアルタイム分析、大量蓄積データの高速検索、、

・インメモリデータグリッド、複合イベント処理、超高速ＤＢ、、

ＢｉｇＤａｔａ

モノの発信

人の発信

電力メーター

運行情報

カーナビ

ＧＰＳ

監視映像

環境・気象データ

設備監視

物流トレース

ＩＣカード利用

診断画像・電子カルテ

データベース

メール・オフィス文書

つぶやき

ＳＮＳ

通話ログ

スマートフォン

人の移動

ネット購入

コンテンツダウンロード

動画・画像・音声

日立の取り組み

①uCosminexus Elastic Application Data store（以下EADs）（C22）

②uCosminexus Stream Data Platform（B14）

③Hitachi Advanced Data Binder プラットフォーム（D24）

現場の状況をいち早く把握問題の解決

新たな価値の提供

デー

修理

指示

売り

場へ

の指

デー

③大量蓄積データの高速検索

①大量発信データの高速処理

②大量発信データのリアルタイム分析

日立の案件

日立の案件（電力）

工場

オフィス

戸建

検針値

１日分

スマートメータ

収集サーバから出力される大量の検針値（３０分値）を、

一定期間（４０日）分DBに格納したい。

大量の検針値を高速に受信

当日分メモリ保持、日次ジョブ実行による一日分ファイル出力、一括ＤＢロード

日立の案件（通信）

メディエーション

交換機から出力される大量のRawCDRを、

課金システムや帯域制御システム向けのCDRに編集したい。

RawCDR

RawCDR：

接続開始／一定時間経過／HO発生／接続終了などのタイミングで出力される、

接続ID、接続時間、通信量などの情報。

CDR：

同一の接続に対する分割情報であるRawCDRを結合（通信量の合算など）した情報。

大量の接続情報を高速に受信

同一接続のデータ集合をイベントドリブンに編集

インメモリデータグリッドの３つの特徴

①インメモリＫＶＳである

①インメモリＫＶＳ*である

・一意に識別可能な「キー」とそれに対応する「値」

で構成されるデータを保持するインメモリストア

・レスポンス性能

* KVS: Key Value Store

Application Server インメモリＫＶＳ

Key Value

Baz A,0

②分散している

・複数サーバのメモリ上にデータを分散配置

・スループット性能と拡張性

Key Value

Baz A,0

Application Server

インメモリ分散ＫＶＳ

③実行できる

・同時に使うデータを同じ場所に格納する（Grouping*）

・ユーザロジックの分散実行（Distributed Code Execution*）

・ネットワークトラフィックの削減とCPUの活用

* JSR 347: Data Grids for the JavaTM Platform

Key Value

G1:Foo A

G1:Bar 0

G1:Baz A,0

Key Value

G2:Foo B

G2:Bar 1

G2:Baz B,1

Application Server

インメモリデータグリッド

グループ処理

ユーザロジック

まとめ

大量発信データの高速処理（レスポンス、スループット、スケールアウト）

を実現するために以下の特徴を持つもの

・インメモリＫＶＳである

・分散している

・実行できる

(分散基盤編 )

コンシステントハッシング～分散の技術～

コンシステントハッシング

・サーバは232の範囲に等分配置

・Keyのハッシュ値からマスタの保存先を決定

EADs Tool

231-1 | -231

Put Foo A

レンジ Hash(Foo)

マスタ

サーバ

レプリケーション～冗長化の技術～

レプリケーション

・多重度定義に従いデータを複製

・高速化のため非同期

EADs Tool

231-1 | -231

Put Foo A

レンジ Hash(Foo)

スレーブ１

スレーブ２

マスタ

サーバ

レプリケーション

・１サーバは複数レンジのデータを保持

EADs Tool

231-1 | -231

スレーブ１

スレーブ２

マスタ

マスタ昇格～耐障害性の技術～

マスタ昇格（障害時）

・ハートビートおよびヘルスチェックによる障害検知

・サーバを切り離しマスタを切り替える

EADs Tool

231-1 | -231

スレーブ１ →マスタ

障害

マスタ昇格（復旧時）

・運用機能によるサーバ追加

・レンジ単位にデータ転送

EADs Tool

復旧サーバ

復旧レンジ

転送速度

EADs Tool

復旧サーバ

復旧レンジ

転送速度

EADs Tool

復旧サーバ

復旧レンジ

転送速度

EADs Tool

・サーバを追加しマスタを切り替える

復旧

整合性と一貫性

整合性：マスタとスレーブの値が同じ

一貫性：すべてのクライアントから最新の値が見える

整合性と一貫性

Foo＝A

Get Foo

一貫性の３つの課題

①複製順序不正による不整合

①通信遅延⇒複製順序不正

⇒不整合⇒マスタ昇格（永久的障害時）⇒一貫性？

①Put Foo A

①Foo＝A

①Foo＝B

①Foo＝A

②Put Foo B

②Foo＝B

②Foo＝A 遅延

②複製処理失敗による不整合

②一時的障害（サーバ、ネットワーク）⇒複製処理失敗

⇒不整合⇒マスタ昇格（永久的障害時）⇒一貫性？

CAS Bar 0 1

Bar＝01

Bar＝0

失敗

成功

CAS: Compare and Swap

③スプリットブレインによる不整合

③L2スイッチの障害⇒ネットワーク分断

⇒複数マスタ⇒一貫性？

①Put Foo A

②Put Foo B

①Foo＝A

②Foo＝B

マスタはこのサーバだ！

スプリット

参考

ゴシッププロトコル～結果整合性の技術～

ゴシッププロトコル

・サーバ間で情報交換

・古いデータは新しいデータで上書き

・マスタとスレーブの値がそのうち同じ（結果整合性）

・最新の値が見えるとは限らない

リードリペア～結果整合性の技術～

リードリペア

・読み込み処理時に複数のサーバからデータを取得

・古いデータは新しいデータで上書き

・マスタとスレーブの値がそのうち同じ（結果整合性）

・最新の値が見えるとは限らない（確度を調整可能（QUORUM））

まとめ

要素技術

・コンシステントハッシング

・レプリケーション

・マスタ昇格

・ゴシッププロトコル

・リードリペア

解決へのアプローチ

分散合意アルゴリズムPaxos*の適用

* The Part-Time Parliament LESLIE LAMPORT, 1998

Paxosとは

サーバの集合が同じ処理を同じ順番で実行するためのアルゴリズム

Atomic Broadcast

1番目の処理

2番目の処理

i番目の処理

put(k1,v1)

Server1 Server2 Server3

put(k1,v1) put(k1,v1)

remove(k1) remove(k1) remove(k1)

put(k1,v2) put(k1,v2) put(k1,v2)

キーバリュー

k1 v2 整合

Paxosとは

Proposer：

1. i番目の処理を提案

Acceptor：

2. Acceptor間で過半数承認（i番目の処理を合意）

3. i番目の処理を実行

※i-1番目までの処理を実行していなければ、

i-1番目までの処理を他のAcceptorから取得して実行（FillGaps）

一貫性保証のための３つの実装

①複製順序不正による不整合の回避

Proposer：マスタを持つサーバ

Acceptor：マスタ、スレーブ１、スレーブ２を持つサーバ＋スペア*×２

実行キュー

実行スレッド

マスタ

サーバ１

スレーブ１スレーブ２

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

put(k,v)

ストア

* スペア：過半数承認用（２多重障害対応）。ストア操作なし。

レンジ用 Paxos

Proposer：i番目の処理を提案

Acceptor：Acceptor間で過半数承認（i番目の処理を合意）

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

put(k,v)

ストア

レンジ用 Paxos

Acceptor：i番目の処理を実行

”①複製順序不正による不整合”は発生しない！

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

put(k,v)

ストア

レンジ用 Paxos

サーバの集合が同じ処理を同じ順番で実行する

同じ処理ができなければ閉塞（一貫性＞可用性）

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

put(k,v)

ストア

レンジ用 Paxos

失敗

②複製処理失敗による不整合の対処

一時的障害（サーバ、ネットワーク）

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

cas(k,v1,v2)

ストア

一時的障害

レンジ用 Paxos

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

cas(k,v1,v2)

一時的障害

レンジ用 Paxos

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

cas(k,v1,v2)

一時的障害

レンジ用 Paxos

不整合

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

cas(k,v2,v3)

不整合

レンジ用 Paxos

Proposer：i+1番目の処理を提案

Acceptor：Acceptor間で過半数承認（i+1番目の処理を合意）

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

cas(k,v2,v3)

不整合

レンジ用 Paxos

Acceptor：FillGapsをおこなってからi+1番目の処理を実行

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

FillGaps

cas(k,v2,v3)

不整合

レンジ用 Paxos

不整合

永久的障害によるマスタ昇格

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタスレーブ２

マスタ

サーバ３

マスタ

サーバ４

ストア

マスタ昇格

マスタ

サーバ５

永久的障害

不整合

レンジ用 Paxos

get(k)

Acceptor：マスタ昇格後はFillGapsをおこなってからgetを受付

”②複製処理失敗による不整合”が発生しても一貫性を保証する！

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

get(k)

ストア

i FillGaps マスタ昇格

マスタ

サーバ５

永久的障害

レンジ用 Paxos

不整合

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ２

マスタ

サーバ３

マスタ

サーバ４

get(k)

ストア

FillGaps マスタ昇格

マスタ

サーバ５

永久的障害

レンジ用 Paxos

サーバの集合が同じ処理を同じ順番で実行する

同じ順番でできなければ閉塞（一貫性＞可用性）

不整合失敗

③スプリットブレインによる不整合の対処

L2スイッチの障害

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

マスタ

サーバ２

スプリット

３× ４× ５×

１× ２×

クラスタ用 Paxos

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

マスタ

サーバ２

スプリット

３× ４× ５×

１× ２×

Proposer：障害を検知したサーバ

Acceptor：すべてのサーバ

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

マスタ

サーバ２

スプリット

３× ４× ５×

１× ２×

合意

実行キュー

実行スレッド

マスタ

サーバ１

マスタ

サーバ３

マスタ

サーバ４

マスタ

サーバ５

ストア

マスタ

サーバ２

スプリット

３× ４× ５×

１× ２×

マスタ

サーバ１

マスタ

サーバ２

実行キュー

実行スレッド

マスタ

サーバ３

マスタマスタ

マスタ

サーバ４

マスタ

サーバ５

ストア

スプリット

３× ４× ５×

１× ２×

get(k)

マスタ昇格 FillGaps

不整合

複数マスタ

不整合

マスタ

サーバ１

マスタ

サーバ２

実行キュー

実行スレッド

マスタ

サーバ３

マスタマスタ

マスタ

サーバ４

マスタ

サーバ５

ストア

スプリット

３× ４× ５×

１× ２×

get(k)

マスタ昇格 FillGaps

失敗

成功

Acceptor：過半数サーバ縮退の提案が通らなければgetを拒否

”③スプリットブレインによる不整合”が発生しても一貫性を保証する！

不整合

まとめ

・サーバの集合が同じ処理を同じ順番で実行するためのアルゴリズム

お知らせ

１２年１０月から新連載がスタート！ □ 毎月、日立のデータベースの最新情報をお伝えします。

DBOnline 日立のデータベース検索

日立の国産データベースシリーズが紹介されている「国産」タブが新設！

日立の「Dr.SQL」登場！－土田正士さん日本データベース学会副会長

５０年後には、データベースはなくなっている？！

日立のデータベース開発基地に潜入開発者に突撃インタビュー

• Javaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。

• その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。

• 製品の改良により予告なく記載されている仕様が変更になることがあります。

他社商品名、商標等の引用に関する表示

株式会社日立製作所情報・通信システム社

ＩＴプラットフォーム事業本部開発統括本部

2013/05/30

梅田多一

db tech showcase 大阪 2013

C22...

Technology

TaiChi Ball Qigong

C22 peninsula

KIYOE UMEDA e ALCÍDIO ABRÃO

Desulfurare Umeda

Taichi Spada

Yang TaiChi 48

Camping Rv2009 C22

[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは？ by Taichi Umeda

Formacion Taichi

Taichi mariposa

Encarte C22 RS

C22 s14 macromoleculas

Charla Taichi Chuan

C22 KPLUS nou.pdf

Expercia C22

leaflet gw en 190521 - dotonbori.jp · OSAKA Hankyu Sanbangai Osaka Sta. Umeda Sta. Hanshin Umeda Sta. Hankyu Umeda Department Store Dai 4 Bldg. ... Namba Nankai Street Namba Parks

Taichi Chen 36

Natal Bemvinda - Taichi

Taichi & Yoga

ACCESS TEL: 0120-454-902 , 0120-874-432 line Umeda Station Nishi Umeda Station Higashi Umeda Station JR Kita-shinchi Station Kuno Clinic 14 fÈåffi z ENRIN Os ka Umeda Nishiumeda