• Like
RiakCSとmixiプライベートクラウド環境
Upcoming SlideShare
Loading in...5
×

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

  • 3,949 views
Uploaded on

Riak Meetup Tokyo #3 の資料です。 …

Riak Meetup Tokyo #3 の資料です。

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,949
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
28
Comments
0
Likes
25

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 • 障害時に取れる3つの選択肢 • そのままリバランシング • • ノードを複数まとめて追加して、データ移動 • • 予備のホスト等が存在しなかったり、対応するのが面倒な時 コマンド一発叩いて睡眠に戻れる どうせリバランシングするならノードを複数まとめて追加して、 データ移動 壊れたノードの変わりに新しい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