Successfully reported this slideshow.

ioDrive+MySQL勉強会

7,009 views

Published on

Crooz meet Fusion-io
【事例】CROOZ社によるFusion-io利用のきっかけ

ioDrive+MySQL勉強会

  1. 1. meet�
  2. 2. ioDrive2�
  3. 3. CROOZが提供するサービス ブログサイト ソーシャル ゲーム 通販・モール その他80サイト
  4. 4. ちょっとインフラーチーム体制の話 ・28タイトル(最近調べ)・売上はIR資料見てください・ソーシャル系のサーバ(Web/DB)で90台程度・サーバもネットワークもストレージも自分達で選定、発注、構築、監視、運用・このメンバーで別システム200台程のブログシステムをDC移 転(さすがに赤帽とか呼びまくってサービス断は4時間程度で 完了)・アルバイト、契約社員、外注一切なし。・色々なことに挑戦したいが、インフラメンバー3~4人
  5. 5. インフラ運用(サーバ購入は至難の道) 既不人気タイトルDBの統合 企画開発からサービス 集約、スレーブはく奪 開始のお知らせ(いつも突然。その週とかもある) (マシン確保) サービス伸びてきて 新サービス用サーバ作成 スレーブ追加 •  実は2012年はソーシャル用のサーバは1台も購入していない。(ネット ワーク増強(中)やio-Drive等の投資のみ)
  6. 6. 前回のあらすじ
  7. 7. CROOZでは2011年にFusion-ioを試験的に購入。 DUOを2台構成。 しかし当時は特段大きな恩恵を受けることができず、本格導入は見送っていた。 当時、ソーシャルゲームを20タイトル程度、月間PVは数十億 これらのアクセス、トラフィックをWeb+DB約90台で処理。 DBサーバの一部分 にSSDを適用するだけで、特段問題なかった。 基本的にはMySQLのスロークエリの根絶(開発担当者すごい)DB分割、 キャッシュ等積極的利用の運用が上手く回っていて、インフラ、サーバ台数も 適切な台数で推移。 これでDisk-io根絶 = ioDrive不要。 当時の合言葉は  「Fusion-ioいらないよね? 使ったら負け?」 「富豪」     「ゆとり」
  8. 8. しかし・・・・・2012年、これまでの自社で体験したことのないパターンが。。
  9. 9. 「神魔×継承!ラグナブレイク」 大ヒット御礼
  10. 10. CROOZ meet Fusion-ioその上、イベントで「一定時間体力が減らない」施策発動。 DDoS攻撃状態 (ただし、相手は会員、お客様) サーバ、ネットワーク共にお祭り状態。 その結果・・・
  11. 11. MySQL Master MySQL slave(約20台)
  12. 12. CROOZ meet Fusion-io 購入だけしてあったFusion-ioマシンを投入。 MySQLサーバ群の一部だがioDriveになり、対象機器のみ DiskI/O、slave遅延などがきれいさっぱり無くなった。 やっぱりFusion-ioはすごいかもしれない(ステマ) ioDriveがすごいんだ!(どっちでもいい) 「Fusion-ioいらないよね? 使ったら負け?」 (謝罪して訂正)「Fusion-io最高だ。あれがないと寝れない。 何枚かまとめて買っといて」 (by.開発チーム) 謝罪の意味も込め、ioDrive2を5枚発注
  13. 13. 祭りは続く ! 最大 941.93Mbps(回線は1Gbpsです) このあたりはioDriveでは解決できず・・・。結局毎月こんな感じ。 多分、今週も・・・。
  14. 14. 祭りは続く(真夏の恐怖) 最大 776.51Mbps(回線は1Gbpsです) 同一スイッチ、他ポートもこんな感じ。 そして、息が止まり始める・・・・・・。スタックやめたり(なぜか治る)、スイッチ再起動したり、その都度ぶら下がるサービス全断。
  15. 15. CROOZ meet Fusion-io ioDrive2編
  16. 16. ソーシャルゲームにおけるMySQL構成
  17. 17. MySQL•  構成 –  バージョンは5.1.x系 –  SAPはここはあまり頑張るところではない(と思っている) –  基本的にSSDのみ(が、一部io-Drive侵食) –  Master(更新)-slave(参照)構成のみ •  モダンな構成。ミドルウエアのチューニングやトリッ キーなプロダクトにしてしまうと運用が追いつかない。  欠点をハードで解決できるうちはなるべくシンプルな構 成に。 •  slave追加で参照負荷分散(増えすぎると問題) –  追加、剥奪作業自体も楽。  •  master障害時slave昇格で対応
  18. 18. MySQL•  リリースしたてのタイトル MySQL Replication MySQL (M) (S) MySQL TABLE-a (S) MySQL TABLE-b (S) TABLE-c どのようなタイトルでもMaster×1 , Slave×3くらいでスタート。 基本的にWebで2000万PV(day)ならちょっと辛いくらいで問題なし。DBは1CPU、SSDで統一。 スレーブが何十台も増えて、マスター分割したり、レプリケーションやWeb間通信でラックスイッチ折り返しトラフィックなどが目立ってきたら集約したい → ここでやっとioDriveを検討。
  19. 19. MySQL•  Slaveが数台増えてくるなど、なんとなく不安になってきたら Master分割 MySQL Replication MySQL (M) (S) MySQL TABLE-a (S) MySQL TABLE-b (S) MySQL Replication MySQL (M) (S) MySQL (S) MySQL TABLE-c (S)•  テーブルの分散なので効果が見えにくい時もある。(分割対 象テーブルの利用率など)
  20. 20. MySQL •  パーテショニングは使っていない。 MySQL MySQL ioDrive入れて Replication 優良課金ユーザ用 (M) (S) MySQL のシステム TABLE-a (S) MySQLRANGE、LIST、HASH、KEY TABLE-b (S)(偶数奇数、優良不良ユーザ TABLE-c などの振り分け) 無課金、休眠 MySQL MySQL 一見、お試しユーザ用 Replication (弱スペック) (M) (S) MySQL (S) MySQL ABテストシステム TABLE-a 使って広告乗せたい (S) TABLE-b くらい(違反) TABLE-c •  個人的には使いたいけど最後かな・・・。   (データバックアップなどの問題もあるし)
  21. 21. MySQL•  マスター(更新)スレーブ(参照)構成の場合、ヒットすると大 変なことになる。 Apache Apache Apache Apache Apache MySQL Replication Apache MySQL ××Apache Apache ×× Apache Apache MySQL Apache (M1) Apache (S × 9) ××99×× Apache Apache ××99×× Apache MySQL (S × 9) 99××99 TABLE-a 99× 99 MySQL ioDrive ×3 99 (S1 × 9) 9 MySQL Replication MySQL (M2) MySQL (S × × 2) (S2 9) TABLE-b MySQL Replication MySQL (M3) MySQL MySQL (S ××9) (S × 3) TABLE-c (S3 3)   これだけアクセスのあるサービスで台数が増えるとネットワーク(ラック スイッチ)かディスクIOが悲鳴。 ioDriveの出番!
  22. 22. MySQL•  ioDrive投入検証をしているサービス。。 まだ検証なので、基本的に振り分け比率など も変えず1:1で運用。 LVS SSD9台、ioDrive3台の場合、12回のアク セスのうち、3回しかioDriveが当たらない。 (検証なので・・・) Apache Apache Apache MySQL ×× Apache Apache MySQL Apache (S × 9) ××99×× Apache MySQL (S × 9) 高負荷時は先にSSD側のマシンがio遅延な 99× 99 MySQL ioDrive ×3 (S1 × 9) 9 どに見舞われる。 ioDrive5台くらいにしてSSD全廃したいが もう少しキャパシティプランニングをちゃんと やりたい。
  23. 23. MySQL Master(SSD CPU×1)
  24. 24. MySQL Slave(SSD CPU×1)
  25. 25. MySQL Slave(ioDrive1-Duo) CPU×2
  26. 26. MySQL Slave(ioDrive2-Solo(Mono?)) CPU×1
  27. 27. マスター(SSD)1CPUスレーブ(SSD)1CPUスレーブ(F-io1)Duo2CPUスレーブ(F-io2)Solo(Mono)1CPU
  28. 28. ioDriveどう?既に導入している方々すみません。
  29. 29. 導入 怖がる必要なし。 勢いで購入してもhttp://ja.community.dell.com/techcenter/b/weblog/archive/2011/12/09/fusion-io-4-iodrive.aspxが秀逸。説明はioDrive1ですが殆どこのままダウンロード対象ファイルなども読み替えれば問題無し。でもきっと長谷川さんならアップデートすると思う。
  30. 30. 安心の保証外サポート(基本、自己責任で)
  31. 31. 気になった点 lspciコマンドが・・・(cent5.4) ioDrive2# lspci | grep -i fusion08:00.0 Mass storage controller: Fusion-io Unknown device 2001 (rev 04)ioDrive1# lspci | grep -i fusion0b:00.0 Mass storage controller: Fusion-io ioDIMM3 320GB (rev 01)0c:00.0 Mass storage controller: Fusion-io ioDIMM3 320GB (rev 01)fio-status –aなどで問題なければ、pciidsファイルが古い可能性がある。未確認ですが、最新のpciidsファイルには、ioDrive2も入っているので、気になるなら入手して入れ替えてみてください。
  32. 32. ioDrive検証おきまりなことやってみました。
  33. 33. bonnie++ Version 1.03e ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP mragnarokDb0 96576M 116454 99 1310143 77 339619 26 94275 89 666215 32 47757 64
  34. 34. fio Read Bandwidth Write Bandwidth Read IOPS
 Write IOPS
 KB/s
 KB/s
  (ランダム、bs=4K、 (ランダム、bs=4K、 (ランダム、bs=1M、 (ランダム、bs=1M、 64並列) 64並列) 4並列) 4並列) HDD 78353 92.09179688 1797 1135 SSD(RAID10) 202162 203398 47294 9199 SSD(RAID0) 290073 319342 48938 14426 ioDrive(DUO) 1547878 528020 120608 43920 EC2(エクストララージ) 65419 85690 245 306 ioDrive2(SOLO) 1399500 988110 125531 65269
  35. 35. 今後の構成(検討中)
  36. 36. NoSQLの積極的な活用•  MySQLのMaster-Slaveの適切台数運用 MySQL Replication MySQL (M1) MySQL (S × 9) MySQL (S × 9) ioDrive ×3 Apache Apache Apache ×× Apache Apache Apache ××99×× Apache Apache 99××99 更新 99 Redis Redis Redis (ioDrive) (ioDrive) (ioDrive)Redis検証中。 イベントやランキングなど、季節もの・バッチものを積極的にNoSQLに。 MySQLの負担が減る事を期待!
  37. 37. まとめ
  38. 38. •  ioDriveが何のためにあるか考える。 –  弊社の場合、Disk ioによるリソース逼迫、レスポンスの悪 化などにioDriveが効いた。•  Disk ioが発生する要件は多々ある。 <解決策は色々。詳細は各所で既出なので割愛> –  Innodb_buffer_pool_size –  スロークエリの根絶。 •  イベント用プログラムがリリースされるたびに生まれる。  :•  そもそも高負荷時にレプリケート遅延やネットワーク逼迫 –  スロークエリなどなし、レプリケートセグメントに特段変な もの無ければ、いよいよハードで解決を検討。
  39. 39. •  ioDrive以外での解決策 –  スレーブを参照系として利用している場合、CPUのアップ グレード、メモリの増強も効く。 •  弊社の場合、スペックをそろえているので、細かいもの をちょろちょろ買うと管理がめんどくさい。 •  メモリは安いので積極的に搭載するべき。 •  CPUは高い。•  CPUメモリ増強案 –  弊社のDBサーバは高スペックCPU1枚なので、2CPU化 し、2ndCPU側のメモリスロットを全埋めで見積もりを取得 した所、ioDriveより少し安いって程度だった。管理方法、汎用性などを考慮した結果、ioDriveを採用。 ・1枚単位で管理ができる。 ・ローカルSSDが不要。(OS領域残すならその分のみ)
  40. 40. •  ioDriveのリスク –  単品で購入すると資産計上。 •  しかも年1で棚卸し。サービス止めてサーバ開けろと かありえない。 –  キャパシティの上限がわからない。 •  Iopsとか言われてもねぇ・・・。 •  某社の事例では○台→●台になったというのはあくまで も「当社比」レベルの話。 自社の現実を直視して責任 を持って決めるしかない。 他社の集約実績は神話。 –  メーカが納期をコミットしない。 –  早すぎて他のシステムとのギャップ •  例えばバックアップサーバとか・・・。
  41. 41. •  リスクの回避 –  キャパシティなんて知らなくて良い。 •  ioDriveで成り立つシステムのスタンバイにSSDとかあ り得ない。 SSDでいいならioDriveは最初から不要。 –  今の所、予め余分にリソースを準備するほかない。 •  ソーシャルの場合、投資回収のサイクルが早い事と、 ioDriveは単品できちんと管理できるので、リソースが 逼迫したら追加購入で問題無いと思う。 – 但し、サービス(売上)が伸びていく前提。 売上伸 びていないのにリソースが逼迫しているなら別の (ダメクエリとか)要因を疑う。
  42. 42. ioDriveあるある •  なんか「高い」って言われるけど、大抵は障害時に「サーバ追 加して」と言う人。•  1の頃はDUOが早いと言われたが2になったら大差ないと言 われる。•  SSDからioDriveを投入したのに、SSDマシンを返してくれな い。ioDrive1枚あたりSSDマシン3台くらい返してほしい気分。•  マスター強化したらスレーブ死んだ。(ioDriveでやるのは特 に危険)•  納期6週間と言われたのに次の週に納品。

×