分散Key/Valueストア Kai事例紹介

1. 分散 Key/Value ストア Kai
事例紹介 ～ goo ホーム～
20
0 9年 7月 2日
t-hashi @nttr. co j p
.
1

2. 自己紹介
 橋本智哉 ( はしもと ともや )
 goo の仕事を始めたのは 2001 年
 主にシステムの設計とか環境構築を担
当
 今まで関わったサービス
◦ goo ホーム・ブックマーク・あしあと ( 現
)
◦ goo トップ ( 現 )
◦ goo ブログ
◦ goo 音楽・映画・ゲーム
◦ etc… 2

3. 本日の内容
 Kai について紹介
 goo での Kai 利用事例紹介
 goo で Erlang の適用を検討中
 まとめ
3

4. Kai の紹介
 分散型 Key/Value ストア
 Amazon Dynamo のオープンソース実装
 当然、 Erlang で書かれています
4

5. Kai の紹介
 memcached プロトコル互換
◦ get/set/stats/version/delete をサポート
 P2P アーキテクチャによるクラスタ
◦ マスターノードがいない
◦ ノードを増減設しても勝手に再配置
 Consistent Hashing
5

6. Kai について
 本日の主催者井上さんらを中心に鋭意開
発中
http://kai.sf.net/
 井上さん・幾田さん・橋本で gihyo.jp
に寄稿いたしました
http://gihyo.jp/dev/feature/01/kai
6

7. goo ホームについて
 サービス開始から 1.5
年
◦ 2007 年１ 0 月に開始
 オープンな SNS
◦ 招待状不要の登録制
◦ 未登録ユーザでも参照
は可能
7

8. goo ホームについて
 OpenSocial v0.8.1 に対応
◦ ガジェットが使えます
 外部サービスを更新情報として取り込みま
す
◦ goo 以外の多数のサービスにも対応
 デザインテンプレート
◦ 好みのデザインに着せ替えることができます
8

9. OpenSocial 対応
 OpenSocial v0.8.1 に対応
◦ 日本のサービスでここまでサポートするのは初
◦ デベロッパーの皆さんを募集中です
goo ホームサンドボックス http://sandbox.home.goo.ne.jp/
9

10. 外部サービスの取り込み
 goo 以外のサービスも積極的に取り込みま
す
◦ スタート時点で２９のサービスに対応
◦ 要望を聞きながらさらに追加予定
10

11. アクティビティストリーム
 更新情報を見やすく一覧表示
◦ 外部サービスの更新を表示
◦ ガジェットからも追加可能
◦ マイページでは友達の更新情報
を表示
◦ プロフィールでは自分の更新情
報のみを表示
11

12. goo ホームでの Kai の利用
 2009 年 5 月に商用サービスで利用開始
◦ たぶん Kai の商用環境初デビュー
 システムの一部に試験的に導入
◦ Activity のみを Kai に格納
◦ それ以外のデータは MySQL に格納
12

13. goo ホームでの Kai の利用
 3 ノードの最小構成
◦ dets を利用して HDD に格納
◦ Xeon 5148 @ 2.33GHz × 2
◦ 4GByte メモリ
 150 万件 /3GByte のデータを格納
◦ 今のところ大きなトラブルはなし
13

14. goo ホームでの Kai の利用
 PHP 5.2 + PECL memcache 2.2.5 から利
用
◦ PECL memcached ではない
http://pecl.php.net/package/memcache
 memcached と組み合わせて使用
◦ Kai の出力は memcached にキャッシュ
14

15. 実運用を始めてみて
 ファイルディスクリプタ数の変更が漏れ
た
◦ 運用を始めたとたん、ファイルがオープンで
きなくてノードが落ちた
◦ 一定の負荷をかけないと見つからないので注
意しましょう
$ cat /etc/security/limits.conf
t-hashi soft nofile 49152
t-hashi hard nofile 49152
15

16. 実運用を始めてみて
 ノードの復帰手順をミスして問題発生
◦ Write/Write Conflict が大量発生してエラー
頻発
 Write/Write Conflict
◦ 同じキーを持つデータがクラウド上の複数存
在してしまう状態
16

17. Write/Write Conflict はこうして
起きた
② 脱落していたこ
とに気付かず set す
A’ る
node5 node5
A A
① 脱落
node4 node4
node3 node3
node2 node2
node1 node1
17

18. Write/Write Conflict はこうして
起きた
③ そのまま復帰さ
せてしまった ◦ この状態で A を get
A
A’ すると A と A’ が両
node5 node4
方とも返ってくる
◦ memcached クライア
node2
node3 ントによって見え
方が変わる
node1
18

19. 課題
 Write/Write Conflict への対応
◦ アプリ側で対処したくても対応しているクラ
イアントがない
 パッケージング
◦ apt とか rpm とか気の利いたことが手つかず
19

20. 感想
 ノードの管理はそれなりに必要
◦ 死活監視だけでは不十分
◦ 仲間はずれがいないか常に見てあげる必要あ
り
 それでも運用は簡単
◦ RDB に比べればチューニングポイントがない
◦ 足りなくなったら足すだけ
20

21. 感想
 おすすめします
◦ 永続的な Key/Value ストアを考えている人は
検討に加えてみてください
◦ パッケージングなどはそのうち解決すると思
われます
◦ 負荷テストは必ずやってみてください
21

22. ご静聴ありがとうございまし
た
22