Riak Meetup Tokyo #3 の資料です。 RiakCS自体の運用と社内のプライベートクラウドの中でどのように使っているかという内容がメインです。

1. RiakCSと
mixi プライベートクラウド環境
Hidetaka Kojo / @hdtkkj
mixi, Inc.
1

2. 自己紹介
•
•
•
名前：古城秀隆
twitter_id：@hdttkkj
株式会社ミクシィ
•
運用部
•
サーバの物理設置から
ミドルウェアのチューニングまで
•
主にデータ周りを触っています
•
なんだかんだでMySQL大好きです
2

3. agenda
•
•
•
プライベートクラウドとRiakCS
RiakCSの運用について
実際の使用例
3

4. プライベートクラウドと
RiakCS
4

5. プライベートクラウドとは?
•
自社DC内に設置するサーバ設備の仮想化環境
•
•
•
OpenStack, CloudStack, Eucryptus...
libvirtやlxcの仮想化技術を使ってサーバをリソース化
よりサーバのライフサイクルを管理しやすくしたもの
5

6. プライベートクラウドとは?
•
メリット
•
計算リソースが安い
•
•
•
•
(ストレージは微妙... S3, Glacier大好き！)
自社設備の有効利用
AWSへのリハビリ...
デメリット
•
AWSなどと比べて自前で用意するものも多く、
運用コストがかかる
6

7. なぜプライベートクラウドなの？
（以前の環境）
• 巨大な単一リポジトリのcodeを管理する開発者
• deployとミドルウェア、物理サーバを管理するops
• 飛び交うサーバ確保依頼と設定依頼
7

8. なぜプライベートクラウドなの？
（指向する未来）
• 小さなチームで複数のプロダクトを作成
• 開発者が好きにサーバリソースを使える環境
• もうチケット処理に追われたくない....
8

9. mixiのプライベードクラウド環境 1
•
OpenStack + Chef + 独自のDeployTool
•
•
•
•
GUI(horizon)からインスタンスを作成
gizmo
yamlに各サーバの構成を記載して反映
DeployToolでアプリケーション配布
社内での名前は gizmo
9

10. mixiのプライベードクラウド環境 2
•
インスタンスの中にデータを残さない
•
•
いつ死んでもいいようにデータを残さない
プロダクトごとに権限をわける
•
•
ログインはもちろんのこと
•
かと言って、プロダクトメンバーがログを
閲覧するのが面倒な形にはしたくない
課金情報を含むログがストレージでプロダクトを
超えてみれる状態は良くない
10

11. ストレージの選定
•
•
データの取得はrsyncではなくAPI経由で行いたい
•
それRiakCSで出来るよ！
出来れば、AWSとの相互移行が簡単なようにAPIは
AmazonS3に揃えたい
•
•
この流れでRiakCS(とCeph)の検証を開始
(あと、ちょうどRiakMeetup#1がいい時期にあった...)
11

12. RiakCSの概要 1
•
•
Riak上に作られたS3互換の分散オブジェクトストレージ
Riak+Stanchion+RiakCSという3つのプロセス
•
Riak：keyツリーの情報やファイルのメタ情報、
分割されたファイルデータの保存先
•
RiakCS：APIの提供とkeyから
ファイル情報のマッピング
•
Stanchion：ユーザ情報やバケットに関する
操作のシリアライズ
12

13. RiakCSの概要 2
•
実際のデータ保存はRiakが受け持っている
•
•
•
セカンダリインデックスが使えるlevelDBに
key情報を保存
bitcaskにファイルの情報を分割して保存
nodeを順番に1つずつ落としてRiakの
データディレクトリごと退避でデータの
バックアップも不可能ではない
•
•
ただしpoint-timeなスナップショットにはならない
replicaの分もデータは膨らむ
13

14. RiakCSの検証 1
•
•
Riak1.3当時のお話です(現在1.4.2)
5nodeで組んだRiakCSクラスタに対して2Mのファイルを
400,000個アップロードするテスト
•
単一のユーザによる単一のバケットに対する
putリクエスト
14

15. RiakCSの検証 2
容量（オーバーヘッド)
node
member-­‐status
実際
(理論値)
riak@192.168.164.51
18.8%
-­‐>
452G
(441G)
riak@192.168.164.52
18.8%
-­‐>
452G
(441G)
riak@192.168.164.53
18.8%
-­‐>
452G
(441G)
riak@192.168.167.34
18.8%
-­‐>
452G
(441G)
riak@192.168.167.35
25.0%
-­‐>
602G
(586G)
•
nodeに対してばらつきがあるのはvnodeの数が
16個のため
•
•
少ない追加容量でデータが格納されている
削除に関してはフラグ管理して、後ほど削除が走るので、
すぐに減らないので気をつける...
15

16. RiakCSの検証 3
PUT性能
•
DiskはSAS 15rpm x 6のRAID5
(ext4 noatime,data=writeback,barrier=0)
•
5nodeのclusterで、2Mのファイルのputを80req/sく
らいは食えていた
•
•
node側のtrafficは900M程度
CPU,io,trafficが詰まった様子はないが、403のエラ
ーがぽつぽつ出て頭打ちに...
16

17. RiakCSの検証 4
PUT性能
•
この後、台数を追加した際、trafficがだいぶネックになる
が、性能はある程度奇麗にスケールすることは確認
•
CephのS3 API(RadosGW)は台数を増やしても
putリクエストがスケールせずに、とりあえずRiakCSを
採用することを決定
•
Cephはもう少し頑張れるところはあったかもしれないけ
れど、同じAPI実装があればあとで変更することも可能な
ので...
17

18. RiakCSの検証 5
検証中に気になった点
•
lsが遅い
•
keyのprefixを使ってファイルシステムのようにlsをする
とnodeをまたいでリクエストが飛ぶのでかなり遅い
•
•
•
トラフィックとread IOがかなり出る
1.4系でだいぶ改善 3min -> 15sec程度
でも遅いので、サービスから叩いたら負けだと思います
18

19. RiakCSの検証 6
検証中に気になった点
•
nodeごとのデータ容量の違いが許容されない
•
vnodeの分配率を個別に決められないので、
一番小さいディスクサイズがボトルネックになる
•
これは変わると嬉しいなぁと思うけど、当分難しそうな
気がする
19

20. mixiでのRiakCSの構成
•
•
•
LBの下に並べてる
trafficが結構でるので10Gエッジスイッチの下に...
stanchionはシリアライズする必要があるので、vipをはっ
ている
20

21. RiakCSのモニタリング 1
•
Riakのstatsで見ているもの
•
•
•
•
nodeへのget/putの回数
vnodeへのget/putの回数
getされたオブジェクトのサイズ
get/putのレイテンシ
21

22. RiakCSのモニタリング 2
•
RiakCSのstatsで見ているもの
•
オブジェクトに対するget/put/delete/headの数と
latency(median & 95%)
•
bucketへのlistリクエストの数のlatency
(median & 95%)
22

23. RiakCSの死活監視
•
riak ping, stanchion ping, riak-cs ping
•
•
snmpdのextend MIBに登録
clusterのnode状態監視
•
Riakのstatsからconnected_nodesの数を監視
23

24. RiakCS障害時対応 1
•
Riakはnodeが落ちたとき自動でデータ移動をしない
•
•
•
•
デメリットの用だけど、悪い面だけではない
一時的な上位障害でリバランシングは怖い
データ移動が少ない復旧を取りたい場合も
riak-admin clusterコマンドのみで作業可能
24

25. RiakCS障害時対応 2
•
障害時に取れる３つの選択肢
•
そのままリバランシング
•
•
ノードを複数まとめて追加して、データ移動
•
•
予備のホスト等が存在しなかったり、対応するのが面倒な時
コマンド一発叩いて睡眠に戻れる
どうせリバランシングするならノードを複数まとめて追加して、
データ移動
壊れたノードの変わりに新しいnodeを移行
•
データのcopyが発生するのがreplaceされたホストだけなので、
問題は発生しづらい
25

26. 実用例
26

27. プライベートクラウドとRiakCS
•
データ内容で3つのクラスタを用意
•
•
•
ログ保存用のクラスタ
サービス利用(画像アップロード)のクラスタ
バックアップ保存用のクラスタ
27

28. ログ保存用のクラスタ
28

29. 既存のログ構成
•
•
ローカルにログをはいて、定期的にrsyncで移動
いろんなところでログを使うので、保存先からさらにいろ
んなところにばらまかれる
•
•
R,DrSUM,バッチサーバ,hadoop,etc...
ログを閲覧するためにサーバにログインするために、
1ステップ手順をふむ必要あり
29

30. 新しいログ構成1
30

31. 新しいログ構成 2
•
•
•
各roleごとに必要なconfをもったfluentd起動
•
RiakCSを使うことで各プロダクトが
各々の権限でアクセスでログにアクセスが可能
•
RiakCSのkeyはtagや日付,hostname付き
ログは全てltsv
アプリケーション内からsyslogやmsgpackを
使ってログをはいても転送
31

32. 新しいログ構成 3
• 複数のアカウントを管理するツールを作成
• アカウント管理,バケット操作,ACL操作etc..
• RiakCS Controlは今のところまだまだ...
• RiakCS触るならFogが便利
• 解析チームには全バケットのread権限をやりたい
• ただpolicyファイルによる特定IDに対する
権限付与はまだ未実装
• コードにはToDOで記載されてるので今後に期待!
32

33. RiakCSとfluentd 1
•
ログはRiakCSとcapped collectionのmongodbに
•
•
kibanaインスタンスを立てればそちらにも..
fluent-plugin-forest使ってtagをs3のkeyに
埋め込んでいます
33

34. RiakCSとfluentd 2
•
fluent-plugin-s3を使う上で注意すること
•
新規ログファイル名のindexをheadリクエストを投げて
確認後決定する
•
•
time_slice_formatに時刻をいれたほうが無難
•
format_json trueは入れたほうが
容量的にも優しい
日付情報までだとflush_intervalが短いと
結構な数のheadリクエストが飛びます
34

35. ログの利用(hive)
•
各プロダクトが必要に応じてhive(hadoop)
インスタンスを立ち上げてRiakCSからload
•
•
hiveにpatchを当てて使っています
RiakCSではkeyのrenameができないため..
hiveでRiakCSを直接参照し、結果をRiakCSに
直接書き込める(ローカルにも書ける)
•
external tableを使ってパーティションごとに
RiakCSのkey構造とマッチングさせています
•
sqoopを使ってMySQLのデータをhiveにimport
バックアップをRiakCSに吐き出しとかも可能
35

36. ログの利用(To Do)
•
一通り動いているが、本当に大量のデータを使った
動作検証は現在継続中。
•
•
•
とりあえずこの部分がだめでもRiakCSは使う予定(笑)
今のところ、変な動きはない
ElasticSearchインスタンスにRiakCSから
bulk insertするliver pluginとか継続して試してみたい
36

37. サービス利用(画像アップロード)の
クラスタ
37

38. 画像ストレージ
•
•
•
特別なことは何もありません
varnishインスタンスを間に挟んで使うだけ
元のmixiの画像は2個1のnode群で
管理していたので方系壊れるとひやひや
•
•
RAID5のdiskの上で、S3にもバックアップあり。
両方壊れるとS3にアクセス。ちゃりーん
画像はある程度間隔で固めてGlacierに保存する予定..
38

39. バックアップ保存用のクラスタ
39

40. MySQLのバックアップ 1
•
mixiではデータセンターが爆発しても大丈夫なよう
メインのDCとは別のDCに遠隔地バックアップ
•
このクラスタは壊れてもある程度すぐに戻せるので
replica数を下げている
•
権限管理が可能でAPI操作できるストレージという認識
40

41. MySQLのバックアップ 2
41

42. MySQLバックアップ 3
•
スケジューラが設定した間隔ごとに
バックアップサーバでxtrabackupを実行
•
xtrabackupに--stream=tarオプションをつけ、
tarのstreamではき、multipart uploadで
そのままRiakCSにアップロード
•
xtrabackup完了後のpositionを使って、
mysql開いているportに立ち上げ
start slave IO_THREAD;
42

43. Redisのsnapshot バックアップ
•
gizmo-redisコマンドがあり、各プロダクトの
redisはツールを使ってインスタンスの操作が可能
•
•
snapshotの作成やRiakCSへの保存
•
Fog最高！
RiakCSに保存されているsnapshot一覧から
すきなタイミングのものを選んでrestore可能
43

44. まとめ
•
当初思っていたよりRiakCSは安定している
•
•
storageにAPIでアクセスできるのは便利
•
•
1.3系から1.4系のアップデートも素晴らしかった
Fogあればたいていなんでも出来る
今後もmixiではRiakCSを
積極的に使ってみたい考えています
44