SlideShare a Scribd company logo
RiakCSと
mixi プライベートクラウド環境
Hidetaka Kojo / @hdtkkj
mixi, Inc.

1
自己紹介
•
•
•

名前:古城秀隆
twitter_id:@hdttkkj
株式会社ミクシィ

•

運用部

•

サーバの物理設置から
ミドルウェアのチューニングまで

•

主にデータ周りを触っています

•

なんだかんだでMySQL大好きです
2
agenda

•
•
•

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

3
プライベートクラウドと
RiakCS

4
プライベートクラウドとは? 
•

自社DC内に設置するサーバ設備の仮想化環境

•
•
•

OpenStack, CloudStack, Eucryptus...

libvirtやlxcの仮想化技術を使ってサーバをリソース化
よりサーバのライフサイクルを管理しやすくしたもの

5
プライベートクラウドとは? 
•

メリット

•

計算リソースが安い

•
•
•
•

(ストレージは微妙... S3, Glacier大好き!)

自社設備の有効利用
AWSへのリハビリ...

デメリット

•

AWSなどと比べて自前で用意するものも多く、
運用コストがかかる

6
なぜプライベートクラウドなの?
(以前の環境)

• 巨大な単一リポジトリのcodeを管理する開発者
• deployとミドルウェア、物理サーバを管理するops
• 飛び交うサーバ確保依頼と設定依頼

7
なぜプライベートクラウドなの?
(指向する未来)

• 小さなチームで複数のプロダクトを作成
• 開発者が好きにサーバリソースを使える環境
• もうチケット処理に追われたくない....

8
mixiのプライベードクラウド環境 1

•

OpenStack + Chef + 独自のDeployTool

•
•
•
•

GUI(horizon)からインスタンスを作成

gizmo

yamlに各サーバの構成を記載して反映
DeployToolでアプリケーション配布

社内での名前は gizmo

9
mixiのプライベードクラウド環境 2

•

インスタンスの中にデータを残さない

•
•

いつ死んでもいいようにデータを残さない

プロダクトごとに権限をわける

•
•

ログインはもちろんのこと

•

かと言って、プロダクトメンバーがログを
閲覧するのが面倒な形にはしたくない

課金情報を含むログがストレージでプロダクトを
超えてみれる状態は良くない

10
ストレージの選定
•
•

データの取得はrsyncではなくAPI経由で行いたい

•

それRiakCSで出来るよ!

出来れば、AWSとの相互移行が簡単なようにAPIは
AmazonS3に揃えたい

•
•

この流れでRiakCS(とCeph)の検証を開始
(あと、ちょうどRiakMeetup#1がいい時期にあった...)

11
RiakCSの概要 1
•
•

Riak上に作られたS3互換の分散オブジェクトストレージ
Riak+Stanchion+RiakCSという3つのプロセス

•

Riak:keyツリーの情報やファイルのメタ情報、
分割されたファイルデータの保存先

•

RiakCS:APIの提供とkeyから
ファイル情報のマッピング

•

Stanchion:ユーザ情報やバケットに関する
操作のシリアライズ

12
RiakCSの概要 2
•

実際のデータ保存はRiakが受け持っている

•
•
•

セカンダリインデックスが使えるlevelDBに
key情報を保存
bitcaskにファイルの情報を分割して保存

nodeを順番に1つずつ落としてRiakの
データディレクトリごと退避でデータの
バックアップも不可能ではない

•
•

ただしpoint-timeなスナップショットにはならない
replicaの分もデータは膨らむ
13
RiakCSの検証 1
•
•

Riak1.3当時のお話です(現在1.4.2)
5nodeで組んだRiakCSクラスタに対して2Mのファイルを
400,000個アップロードするテスト

•

単一のユーザによる単一のバケットに対する
putリクエスト

14
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
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
RiakCSの検証 4
PUT性能

•

この後、台数を追加した際、trafficがだいぶネックになる
が、性能はある程度奇麗にスケールすることは確認

•

CephのS3 API(RadosGW)は台数を増やしても
putリクエストがスケールせずに、とりあえずRiakCSを
採用することを決定

•

Cephはもう少し頑張れるところはあったかもしれないけ
れど、同じAPI実装があればあとで変更することも可能な
ので...

17
RiakCSの検証 5
検証中に気になった点

•

lsが遅い

•

keyのprefixを使ってファイルシステムのようにlsをする
とnodeをまたいでリクエストが飛ぶのでかなり遅い

•
•
•

トラフィックとread IOがかなり出る
1.4系でだいぶ改善 3min -> 15sec程度
でも遅いので、サービスから叩いたら負けだと思います

18
RiakCSの検証 6
検証中に気になった点

•

nodeごとのデータ容量の違いが許容されない

•

vnodeの分配率を個別に決められないので、
一番小さいディスクサイズがボトルネックになる

•

これは変わると嬉しいなぁと思うけど、当分難しそうな
気がする

19
mixiでのRiakCSの構成
•
•
•

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

20
RiakCSのモニタリング 1

•

Riakのstatsで見ているもの

•
•
•
•

nodeへのget/putの回数
vnodeへのget/putの回数
getされたオブジェクトのサイズ
get/putのレイテンシ

21
RiakCSのモニタリング 2

•

RiakCSのstatsで見ているもの

•

オブジェクトに対するget/put/delete/headの数と
latency(median & 95%)

•

bucketへのlistリクエストの数のlatency
(median & 95%)

22
RiakCSの死活監視

•

riak ping, stanchion ping, riak-cs ping

•
•

snmpdのextend MIBに登録

clusterのnode状態監視

•

Riakのstatsからconnected_nodesの数を監視

23
RiakCS障害時対応 1
•

Riakはnodeが落ちたとき自動でデータ移動をしない

•
•
•
•

デメリットの用だけど、悪い面だけではない
一時的な上位障害でリバランシングは怖い
データ移動が少ない復旧を取りたい場合も

riak-admin clusterコマンドのみで作業可能

24
RiakCS障害時対応 2
•

障害時に取れる3つの選択肢

•

そのままリバランシング

•
•

ノードを複数まとめて追加して、データ移動

•
•

予備のホスト等が存在しなかったり、対応するのが面倒な時
コマンド一発叩いて睡眠に戻れる

どうせリバランシングするならノードを複数まとめて追加して、
データ移動

壊れたノードの変わりに新しいnodeを移行

•

データのcopyが発生するのがreplaceされたホストだけなので、
問題は発生しづらい

25
実用例

26
プライベートクラウドとRiakCS

•

データ内容で3つのクラスタを用意

•
•
•

ログ保存用のクラスタ
サービス利用(画像アップロード)のクラスタ
バックアップ保存用のクラスタ

27
ログ保存用のクラスタ

28
既存のログ構成
•
•

ローカルにログをはいて、定期的にrsyncで移動
いろんなところでログを使うので、保存先からさらにいろ
んなところにばらまかれる

•
•

R,DrSUM,バッチサーバ,hadoop,etc...

ログを閲覧するためにサーバにログインするために、
1ステップ手順をふむ必要あり

29
新しいログ構成1

30
新しいログ構成 2
•
•
•

各roleごとに必要なconfをもったfluentd起動

•

RiakCSを使うことで各プロダクトが
各々の権限でアクセスでログにアクセスが可能

•

RiakCSのkeyはtagや日付,hostname付き

ログは全てltsv
アプリケーション内からsyslogやmsgpackを
使ってログをはいても転送

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

• コードにはToDOで記載されてるので今後に期待!
32
RiakCSとfluentd 1

•

ログはRiakCSとcapped collectionのmongodbに

•
•

kibanaインスタンスを立てればそちらにも..
fluent-plugin-forest使ってtagをs3のkeyに
埋め込んでいます

33
RiakCSとfluentd 2
•

fluent-plugin-s3を使う上で注意すること

•

新規ログファイル名のindexをheadリクエストを投げて
確認後決定する

•
•

time_slice_formatに時刻をいれたほうが無難

•

format_json trueは入れたほうが
容量的にも優しい

日付情報までだとflush_intervalが短いと
結構な数のheadリクエストが飛びます

34
ログの利用(hive)
•

各プロダクトが必要に応じてhive(hadoop)
インスタンスを立ち上げてRiakCSからload

•
•

hiveにpatchを当てて使っています
RiakCSではkeyのrenameができないため..

hiveでRiakCSを直接参照し、結果をRiakCSに
直接書き込める(ローカルにも書ける)

•

external tableを使ってパーティションごとに
RiakCSのkey構造とマッチングさせています

•

sqoopを使ってMySQLのデータをhiveにimport
バックアップをRiakCSに吐き出しとかも可能
35
ログの利用(To Do)
•

一通り動いているが、本当に大量のデータを使った
動作検証は現在継続中。

•
•
•

とりあえずこの部分がだめでもRiakCSは使う予定(笑)
今のところ、変な動きはない

ElasticSearchインスタンスにRiakCSから
bulk insertするliver pluginとか継続して試してみたい

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

37
画像ストレージ

•
•
•

特別なことは何もありません
varnishインスタンスを間に挟んで使うだけ
元のmixiの画像は2個1のnode群で
管理していたので方系壊れるとひやひや

•
•

RAID5のdiskの上で、S3にもバックアップあり。
両方壊れるとS3にアクセス。ちゃりーん

画像はある程度間隔で固めてGlacierに保存する予定..

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

39
MySQLのバックアップ 1

•

mixiではデータセンターが爆発しても大丈夫なよう
メインのDCとは別のDCに遠隔地バックアップ

•

このクラスタは壊れてもある程度すぐに戻せるので
replica数を下げている

•

権限管理が可能でAPI操作できるストレージという認識

40
MySQLのバックアップ 2

41
MySQLバックアップ 3
•

スケジューラが設定した間隔ごとに
バックアップサーバでxtrabackupを実行

•

xtrabackupに--stream=tarオプションをつけ、
tarのstreamではき、multipart uploadで
そのままRiakCSにアップロード

•

xtrabackup完了後のpositionを使って、
mysql開いているportに立ち上げ
start slave IO_THREAD;

42
Redisのsnapshot バックアップ

•

gizmo-redisコマンドがあり、各プロダクトの
redisはツールを使ってインスタンスの操作が可能

•
•

snapshotの作成やRiakCSへの保存

•

Fog最高!

RiakCSに保存されているsnapshot一覧から
すきなタイミングのものを選んでrestore可能

43
まとめ
•

当初思っていたよりRiakCSは安定している

•
•

storageにAPIでアクセスできるのは便利

•
•

1.3系から1.4系のアップデートも素晴らしかった

Fogあればたいていなんでも出来る

今後もmixiではRiakCSを
積極的に使ってみたい考えています

44

More Related Content

RiakCSとmixiプライベートクラウド環境