Cloudy会第2回 (11.8＠天神) クラウド時代のストーレジ技術

クラウド時代の

ストーレジ技術

Marat Zhanikeev [email protected]

maratishe.github.io

2014/11/08

Cloudy会第２回＠天神

PDF: bit.do/marat141108

.

maratishe.github.io

楽天が買収したViber

M.Zhanikeev -- [email protected] クラウド時代のストーレジ技術 -- bit.do/marat141108 2/47...

2/47

.

maratishe.github.io

Rakuten Conference 2014


3/47

.

maratishe.github.io

Viberのストーリーhttp://tech.rakuten.co.jp/timetable.html

7:00, 7:40(1G) 9:30(2G) 14:00(specs) 17:24(3G)

• at 7:00• at 7:40• at 9:30• at 14:00• at 17:24


4/47

http://tech.rakuten.co.jp/timetable.html

.

maratishe.github.io

Viberのストーリー

• 1G: in-memory backend• 2G: Redis frontend + MongoDB backend

◦ + custom Redis (sharding)◦ + MongoDB + alpha (cache)

• 3G: Redis + CoachDB backend


5/47

.

maratishe.github.io

Viber : Redis

• in-memory: RAM内でDBを扱う• 実際には、RAM + HDDです、もちろん、溢れたデータをHDDに書き込む

• キャッシュ技術です、使用の激しい分をRAMで保持することが目的である

• VIBERがRedisがbackendの状態で数ヶ月運用していた


6/47

.

maratishe.github.io

Viber: 1G• すごく簡単に、Redisのみのストーレジ


7/47

.

maratishe.github.io

Viber: 2G• Redis front +MongoDB backの切り分け


8/47

.

maratishe.github.io

Viber: 3G• backendでMongoDB → CouchDBのマイグレーション


9/47

.

maratishe.github.io

実用化上のストーレジ


10/47

.

maratishe.github.io

A視点 (構造): SQL - noSQL

• SQLの欠点：表ごとに構成を固定する必要がある、変えることが難しい

• noSQLにより解決：◦ データはアイテムごとに扱う◦ key-valueにばらして扱うので、構造は関係ない

• BigDataなどの世界も、もちろん、構造なし


11/47

.

maratishe.github.io

B視点 (ネットワーク): 単ノード・複数ノード

• ネットワーク上で分散するかどうか

• 現在、殆どの技術が分散型である

• 重要： LuceneなどのnoSQLの一部の単ノードの技術です


12/47

.

maratishe.github.io

C視点 (ファイル): 明確度

• 単品のコンポーネントを開発する時に明確なファイルシステムが望ましい

• MongoDBやBigDataなど、データを増えれば増えるほどファイル構造が不明になっていく


13/47

.

maratishe.github.io

実用化上のストーレジ技術

• SQL DB• SQLite (ファイルベースSQL)• Indexing (Lucene)• Key-Value store (MongoDB, CouchDB, ...)• BigData (Hadoop)


14/47

.

maratishe.github.io

クラウド上のストーレジ


15/47

.

maratishe.github.io

Key-Value → BigDataのスコープ

• key-valueとhadoopが極端なところ

• 今の技術では、途中に技術があまり存在しないのは問題です

KV Store

Hadoop (HDFS)

and MapReduce

TABID Time-Aware

Big Data (this demo)

HDFS +

Lucene Index


16/47

.

maratishe.github.io

CAP Theorem

• A: Availability = 稼働率• C: Consistency• P: Partition tolerance =分解トレランス（裕度）

• ストーレジの研究者が通常に知る定理

• 3角形の中で2つを選んで技術を決定する：3つとも不可能

• SQLを含めてほとんどの技術が乗っている


17/47

.

maratishe.github.io

Viber's CAP

• ViberのMongoDB→CouchDBのマイグレーションの理由が分かる

• 何と何のトレードオフ？• 何が良くなった？• 何が悪くなった？


18/47

.

maratishe.github.io

Heroku as the Cloudification Platform

• herokuはスケールを中心にした開発・実行環境である

• EC2上に出来ている、EC2自身はスケール無し（自分で実装しないと）

• cloudificationの定義：何らかの技術をクラウド上で使える形にする◦ ある意味で、クラウド化が出来るかどうかのテスト


19/47

.

maratishe.github.io

Cloudification: Heroku has Postgres


20/47

.

maratishe.github.io

Cloudification: Heroku has MongoDB


21/47

.

maratishe.github.io

Cloudification: Heroku has Redis


22/47

.

maratishe.github.io

Cloudification: Heroku has KVStores


23/47

.

maratishe.github.io

BigData


24/47

.

maratishe.github.io

BigData: Hadoop

.Hadoop=HDFSとは？..

.分散ストーレジ、冗長・複数化を利用した分散型ファイルシステム

.MapReduceとは？..

.Hadoop上で実行するビッグデータを処理するプロセス

• MapReduceの利用無しのHDFSは殆ど存在しないので、Hadoop=MapReduce

• 分散の簡単な理由：単ノードで保存できないからです


25/47

.

maratishe.github.io

BigData: ジョブを派遣・回収 vs データ再生型

• 大量のデータなので、効率アップの技術が大事• Hadoop最大スループット：大体60Mbps• 再生＋マルチコアの処理速度：(HDD/SSDの限定の)数Gbps - 処理の負担

One Physical Machine (1 shard)

file A file B

file C …

Hadoop Space

Manager

Hadoop Job (your code) Hadoop Job (your code) Hadoop Job (your code) Hadoop Job (your code)

many many

Name Server(s)

Client Machine

Hadoop Client

Your Code

You

Start Use

Deploy

Find Read/parse

One Physical Machine (1 shard)

Tim

elin

e Su

b-St

ore

Store

TABID Node

TABID Manager

Client Machine

TABID Client

Your Sketcher

You

Start Use

Schedule

Multicore Replay


26/47

.

maratishe.github.io

BigData = Cloud Storage

• 量の大きいデーはは、全部BigData• ただし、検索・処理などの必要性に応じて、データの単位をkey-valueの細かさまでに減らせる

KV Store

Hadoop (HDFS)

and MapReduce

TABID Time-Aware

Big Data (this demo)

HDFS +

Lucene Index


27/47

.

maratishe.github.io

ストーレジの基盤


28/47

.

maratishe.github.io

ストーレジの基盤

1.基盤◦ メモリマップ◦ Double-Linked List (DLL)◦ ハッシュ化、インデックス化◦ Bloom Filter◦ 共有メモリ

2. 基盤の次の層◦ キャッシュ化とその技術・手法◦ ネットワーク上分散◦ ...


29/47

.

maratishe.github.io

技術のピラミッド• 黒色の部分は、高性能処理に関わる手法

Other Uses

Data Streaming

Other uses Bloom Filter

Other Hashing Methods Fast Hashing A uses B

All hashing All blooming

All related technologies


30/47

.

maratishe.github.io

Hashing and Blooming

Item

1

0

1

0

1

1

1

0

Hash Keys Bloom

Filter

Bit length OR

…

1

1

1

1

0

1

0

1

Each in turn

Multiple Hash

Functions

Multiple Hash

Functions

Multiple Hash

Functions

Multiple Hash

Functions

1

0

1

0

1

1

1

0

1

0

1

0

1

1

1

0

1

0

1

0

1

1

1

0

… Replace current state


31/47

.

maratishe.github.io

Double Linked List (DLL)

Item

Item

Item

Item Item

side

prev

side

next

side

prev

prev

next sdie

next

next

prev


32/47

.

maratishe.github.io

Hashing/Bloomingの効率アップ• 大体、fast hashingか効率的bloomingの２つになる

x Item

1

0

1

0

1

1

1

0

Hash Keys Bloom

Filter

Bit length OR

…

*

*

*

*

*

*

*

*

Each in turn

Multiple Hash

Functions

Multiple Hash

Functions

Multiple Hash

Functions

Multiple Hash

Functions

1

0

1

0

1

1

1

0

1

0

1

0

1

1

1

0

1

0

1

0

1

1

1

0

… Replace current state

A non-trivial manipulation

state

…


33/47

.

maratishe.github.io

Hashing実用化の事例：o2mデータ構成• トラヒックかSNSの中で良く現れる、１人が他の数人との通信パターンを捕まえたい

No Pointer01 #001

#002

2X

PacketEntry

Entry

Hashfunction

SubentrySubentrySubentry

Digests IP addresslists

Subentry

Entry/Subentry DLLExport


34/47

.

maratishe.github.io

DLL実用化の事例：マルチコア処理

Manager

Shared memory

One thread

Create

Fork

Lifespan Stale check

Process/wrap Wrap wait

Doub

le-L

inke

d Li

st (D

LL)

Assign

Cap-ture

• マルチコア処理の際に、並列でも、ロックフリー方式が望ましい

• 共有メモリとDLLが使える• DLLの技：更新したものをDLLの頭にもってくれば、古い（除いての良い）データがDLLの尻尾に沈んでいく◦ この技でロックフリーを実現する


35/47

.

maratishe.github.io

性能ボトルネックの分析


36/47

.

maratishe.github.io

性能ボトルネック

• HDD/SSD読み・書き込む• ネットワークのスループット• データの中身そのもの（処理の負担）


37/47

.

maratishe.github.io

PetriNets：可視化の１例

Meter Merger

Analyzer

Analyzer

Analyzer

Buffer 5s Timeout 5s Sampling timeout 10s

Buffer 1s

Buffer 10s

Buffer 30s

Lower cluster Upper cluster

47kb

25kb

21kb

12kb

0.6kb

0.3kb

Per second Per buffer

10kb

7.4kb

32kb

26kb

• 少なくても２クラスに分解する（多いこともある・分類問題）

• クラスを処理負担と確率で示す

• 可視化として、自動で図を作成する


38/47

.

maratishe.github.io

クラウド技術の可視化：レンズのモデル• 手前のレンズで全てのユーザをキャッチする• focal point (集点）がある、何もしなければ、ユーザの皆さんの多人数により混雑が起こる◦ SPOF: Single Point of Failure◦ Flash Crowd: 突然・急激に人数が増えたときの混雑

• 青色：クラウドサービスの中で混雑を避けることが１つの大事な目的がある


39/47

.

maratishe.github.io

APIs: HTTP or not

• あまり考えていないところでボトルネックが生じる：ほとんどのAPIがノード内でもHTTPを使う

• 共有メモリ（ＳＨＭ）の方が絶対に効率的な方ですが、別途でソフトを開発する形になる

◦ でも、効率を増やすなら、開発しても構わないと思っている企業が沢山ある


40/47

.

maratishe.github.io

データストリーミングの見方（性能の分析）


41/47

.

maratishe.github.io

データストリーミングの基盤• データストリーミングの定義：データを保存せずに（実時間に）処理する方法

• 特徴：数学的に真面目に出ている理論、スペース効率の最適化、処理負担の効率化


42/47

.

maratishe.github.io

データストリーミングのデザイン

• 殆ど、goodput（スループット）とメモリサイズ（footprint)で記述する

• 情報理論を使って、両方の数字化が簡単に出来る


43/47

.

maratishe.github.io

Viberの性能


44/47

.

maratishe.github.io

ViberのE2E• ２つの経路： ABCとADE ... (とのその帰り） --サブ秒の厳しい性能目標


45/47

.

maratishe.github.io

Viber Problem: Discussion

• 現在のViber1. Ridus front2. CouchDB back

• どこで改善すれば？


46/47

.

maratishe.github.io

That’s all, thank you ...


47/47

Viber users

Amazon Cloud

Web Redis

x100 CouchDB

Other Webs

WebSocket

Middle Layer

Remember that Viber gave up on consistency by migrating from MongoDB to Cough DB (CAT theorem) Efficiency Trick 1: Direct WebSockets across Web VMs ‒ a possibility for efficient cache syncing and realtime Efficiency Trick 2: Middle Layer implementing a self -built sharded DB as the ultimate flexible offload (reverse VNE)

Technology

Cloudy会 第2回 (11.8＠天神) クラウド時代のストーレジ技術

Cloudy会第2回 (11.8＠天神) クラウド時代のストーレジ技術