InfoTalk springbreak_2012

分散型 KVS 「okuyama」の活用事例

InfoTalk Spring Break 2012（NoSQL）

株式会社リンク
ディベロッパーサポート部
文屋宏

講演内容

・自己紹介＆会社紹介
・ okuyama とは
・ at+link の活用事例（キャッシュサーバ）
・ at+link の活用事例（画像ストレージ）
・神戸デジタル・ラボの活用事例

自己紹介

○氏名
文屋宏（ぶんやひろし）
Twitter：bun_hiroshi

○所属
株式会社リンク at+link 事業部ディベロッパーサポート部
Twitter：@appliplatform（ハッシュタグ：#appliplatform）

○担当業務
プロジェクトマネジメント，広報活動，営業活動，ユーザサポート，
他社との協業，たまに現地作業，面白いネタ探し

○活動
日本 Red5 ユーザー会メンバー, tokyoLinuxStudy 企画

at+link とは

ディベロッパーサポート
◇開発者のためのサービス開発
at+link の営業窓口
◇開発者の悩み相談
◇新しい技術・面白い技術の
研究・サービス化

データセンター常駐マシン製造
現場担当 24/365 サポート

ノベルティ

「あっとりんく」じゃありません（笑）

okuyama とは

○ 神戸デジタル・ラボ岩瀬氏が Java で開発

○ NoSQL の１つ（分散 KVS）

○ オープンソース版 2010年1月リリース
商用版 2011年9月リリース

○ 最新バージョン 0.9.3

CAP 定理
Availability
可用性Ａ
CA AP
リレーショナル型キー・バリュー型カラム指向
RDBMS
Dynamo Cassandra
Aster Data
Voldermote
Creenplum
Tokyo Cabinet ドキュメント指向
KAI
カラム指向２つを選択 okuyama
SimpleDB
CouchDB
Vertica Riack

Partition Tolerance
C
Consistency
P 分割耐性

一貫性カラム指向
CP キー・バリュー型
ドキュメント指向
BigTable Scalaris
MongoDB
Hypertable BerkeleyDB
Terrastore
HBase MemcacheDB
Redis

CAP 定理
Availability
可用性Ａ
CA AP
リレーショナル型キー・バリュー型カラム指向
RDBMS
Dynamo Cassandra
Aster Data
Voldermote
Creenplum
Tokyo Cabinet ドキュメント指向
KAI
カラム指向２つを選択 okuyama
SimpleDB
CouchDB
Vertica Riack
一貫性レベルの
選択で補強！！
Partition Tolerance
C
Consistency
P 分割耐性

一貫性カラム指向
CP キー・バリュー型
ドキュメント指向 okuyama では
BigTable Scalaris 一貫性のレベルを
MongoDB
Hypertable BerkeleyDB ３段階選択可能！
Terrastore
HBase MemcacheDB
Redis

okuyama の構成イメージ

Data Node Data Node Data Node

Master Node Data Node Data Node Data Node
Client

Client
Master Node Data Node Data Node Data Node

Client

Client → Master Node → Data Node(×3)
（以降 okuyama 関連資料
神戸デジタル・ラボ岩瀬高博氏提供）

okuyama クライアント

Client

okuyamaへの問い合わせを実現 Client

専用クライアントはJavaと、PHPを実装
Client

okuyama マスターノード

・クライアントからのI/F ・データノード管理

・サポートプロトコル >データ入出力
>オリジナルサポート分散アルゴリズム
Master Node
>Memcached 1. Mod
・set ・get ・add
2. ConsistentHash
・delete Master Node
>生存監視
・gets ・cas
起動時のデータリカバリ
>HTTP
・制限台数なしに冗長化可能
・GET

okuyama データノード


・データの保存を実現
・データ保存方式を選択可能 Data Node Data Node Data Node

・最大3ノードにデータを保存
・アクセスバランシング Data Node Data Node Data Node

・連鎖的ダウンの予防


データ保存方式の選択

1.全てのデータをメモリに保存
>非永続型（key=メモリ、value=メモリ）

２.データ操作履歴のみファイルに保存
>永続型（key=メモリ、value=メモリ）＋操作記録 =ファイル

3.データ本体をファイルに保存
>永続型（key=メモリ、value=ファイル）＋操作記録 =ファイル

4.全てをファイルに保存
>永続型（key=ファイル、value=ファイル）＋操作記録 =ファイル

データの一貫性について

複数のノードに同一の値を保持していると、
データに異なる時間が発生する

データ保存保存保存未保存
DataNode DataNode DataNode

データ取得 != データ取得

データ一貫性レベルの選択

1.弱一貫性
>全てのデータノードにランダムにアクセス

２.中一貫性
>常に最後に保存したデータノードからアクセス

3.強一貫性
>データノードの値を検証

okuyama に単一障害点は無い！

データノード障害発生
もう一つのノードから取得

データ保持
ノード割り出し Data Ndoe DataNode

MasterNode Data Node DataNode
データ取得
Client


Data Node DataNode

okuyama に単一障害点は無い！

マスターノード障害発生

障害発生!! Data Ndoe DataNode

データ取得
Client


別のマスターノードに Data Node DataNode

再接続して処理続行

参考文献

○ 岩瀬氏ブログ
http://d.hatena.ne.jp/okuyamaoo/

○ 岩瀬氏 Slideshare
http://sliwww.slideshare.net/okuyamaoo

○ Think IT 連載記事
http://thinkit.co.jp/story/2011/02/03/1990（全４回）
http://thinkit.co.jp/story/2011/10/12/2303（全３回）

○ WEB+DB PRESS Vol.65 ～Vol.67（全３回）

okuyama キャッシュサーバ

ターゲット

・ DB の負荷が高くキャッシュを有効活用したい人
・メモリが欲しいだけなのに、専用のサーバを
用意するのは嫌だという人
・ memcached ・TokyoTyrant を使っているけど
障害が不安な人
・ memcached・TokyoTyrant を使っているけど
分散させたい人
・キャッシュの拡張性が欲しい人

okuyama キャッシュの構成イメージ

クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス

データノードデータノード
クライアント
アクセス
メイン
VIP LVS マスターノードデータノードデータノード

LVS マスターノードデータノードデータノード

スタンバイ
マスターノードはロードバランシング
高負荷時はスケールアウト

データノードで分散多重保存
容量不足・高負荷時はスケールアウト



クライアント
アクセス
メイン
障害！


スタンバイ





障害対応
クライアント
アクセス


メイン


okuyama キャッシュ実際の構成
クライアントアクセス

メインスタンバイ
LVS LVS

VIP:192.168.1.1

L2 スイッチ L2 スイッチ

マスターノードデータノードデータノードマスターノードデータノードデータノード

マスターノード：8GB メモリ搭載×２台
データノード：16GB メモリ搭載×４台
完全二重化構成
実効メモリ容量：32GB

データノード設定のツボ



フロントエンドバックエンドフロントエンドバックエンド

KeyManagerJob1.memoryMode=false
KeyManagerJob1.dataMemory=true データノード（バックエンド）の
KeyManagerJob1.keyMemory=true 「DataNode.properties」で指定
KeyManagerJob1.keySize=5000000
KeyManagerJob1.memoryLimitSize=95

データの圧縮
DataSaveMapType=serialize
SerializerClassName=okuyama.imdst.util.serializemap.ObjectStreamSerializer
フロントエンドがメモリいっぱいになってもバックエンドは生き残る

データノード設定のツボ

ただし、データ登録時に圧縮、データ取り出し時に解凍するので遅くなる

LoadBalanceMode=true マスターノードの
BalanceRatio=8:2 「MasterNode.properties」で指定

フロントエンドとバックエンドのアクセス比率を 8：2 に設定

okuyama キャッシュ LVS障害発生時

障害！
LVS LVS

VIP:192.168.1.1




障害機メイン
LVS LVS

VIP:192.168.1.1




障害機メイン
LVS LVS

VIP:192.168.1.1



なぜか切り替わりに、どうしても数秒かかってしまう・・・


障害機メイン
LVS LVS

VIP:192.168.1.1 VIP:192.168.1.1



L2 スイッチのキャッシュ？こんな状態？？

okuyama キャッシュ LVS運用のツボ

障害機メイン
LVS LVS

VIP:192.168.1.1



okuyama キャッシュ LVS運用のツボ

障害機メイン
LVS LVS

VIP:192.168.1.1

192.168.1.10 にログイン

arping L2 スイッチ L2 スイッチ


192.168.1.10
192.168.1.1 で実行
ssh -i /root/.ssh/id_rsa_10 root@192.168.1.10 "arping -c 10 192.168.1.1"

192.168.1.1 までの経路上の arp キャッシュをクリア！

okuyama キャッシュの事例

・ソーシャルアプリ
ピーク時秒間1,000～3,000アクセスのアプリ複数

ピーク時トータル秒間約10,000アクセス

ターゲット

・消せない画像がどんどん増えて困っている人
・ディスク容量が欲しいだけなのに、わざわざ
サーバを借りるのは嫌だという人

・アプリと画像データのネットワークを分けたい人
・ okuyama を使ってみたい人

旧画像ストレージ実際の構成

ロードバランサロードバランサ
LVS


Web アプリ Web アプリ Web アプリ Web アプリ

マスターノードマスターノードマスターノードマスターノード

データノードデータノードデータノードデータノード

API を受け付ける Web アプリ、マスターノード、データノードを
全て１台にまとめる
LB でクライアントからのアクセスをロード場ランシング

実際に起こった障害
について語ります

悩みどころ

・データを分割保存するチャンクサイズ
・メモリ容量の確保
・バックアップの取り方
・リカバリの仕方
・物理的なマシン設置の仕方
・コストとの兼ね合い

教訓

・チャンクサイズの設計をしっかり
・ユーザ側のサービスの性質によって
環境を分けよう
・マスターノードとデータノードは物理的に
分けよう
・データノードは三重化しよう
（更新は１号機、２号機のみ、参照は３台に）
・独立した２つの環境を用意しよう
（万が一のときに、影響範囲を少なくする）
・コストとの兼ね合い

新画像ストレージ構想
ロードバランサロードバランサ
LVS


Web アプリ Web アプリ Web アプリ Web アプリ Web アプリ Web アプリ

マスターノード A マスターノード B マスターノード C マスターノード D マスターノード E マスターノード F


データノード A データノード B データノード C データノード D データノード E データノード F

データノード A’ データノード B’ データノード C’ データノード D’ データノード E’ データノード F’

データノード D’’ データノード E’’ データノード F’’ データノード A’’ データノード B’’ データノード C’’

画像ストレージの事例

・ブログサービス

・写真共有サービス

・広告配信サービス

・ EC サイト

・短期キャンペーンサイト

デモンストレーション

okuyama 画像ストレージのデモ①

ブラウザで体感！
okuyama v.s. Apache

デモ環境

アプリプラットフォーム

okuyama v.s. Apache！ okuyama
http://demo.at-link.ad.jp

demo.at-link.ad.jp

okuyama 画像ストレージ
Apache サーバ
それぞれから画像を Apache
300枚読み込む
（ファイルサイズ：60KB弱）

okuyama 画像ストレージのデモ②

画像ストレージを操作してみよう

開発中サービス

・ログストレージ

・大容量データストレージ

・ KDL 岩瀬氏開発 CEP（Complex Event
Processing）エンジン「Setsuna」と連携した
サーバのリアルタイム監視サービス

コミュニティ

○ 公式サイト
http://okuyama-project.com/

○ SourceForge
http://sourceforge.jp/projects/okuyama/

○ facebook アカウント Okuyama-日本語
http://www.facebook.com/#!/okuyama.jp

オープンソース版 okuyama
ぜひ使ってみてください！

ご清聴ありがとうございました！

InfoTalk springbreak_2012

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (11)

Similar to InfoTalk springbreak_2012

Similar to InfoTalk springbreak_2012 (20)

More from Hiroshi Bunya

More from Hiroshi Bunya (10)

InfoTalk springbreak_2012