ioDrive+MySQL勉強会
•
14 gefällt mir•4,745 views
Crooz meet Fusion-io 【事例】CROOZ社によるFusion-io利用のきっかけ
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie ioDrive+MySQL勉強会
Mehr von takaoka susumu
ioDrive+MySQL勉強会
- 1. meet�
- 2. ioDrive2�
- 3. CROOZが提供するサービス ブログサイト ソーシャル ゲーム 通販・モール その他 ８０サイト
- 4. ちょっとインフラーチーム体制の話 ・28タイトル（最近調べ） ・売上はIR資料見てください ・ソーシャル系のサーバ（Web/DB）で90台程度 ・サーバもネットワークもストレージも自分達で選定、発注、構築、 監視、運用 ・このメンバーで別システム200台程のブログシステムをDC移 転（さすがに赤帽とか呼びまくってサービス断は4時間程度で 完了） ・アルバイト、契約社員、外注一切なし。 ・色々なことに挑戦したいが、インフラメンバー3～4人
- 5. インフラ運用（サーバ購入は至難の道） 既不人気タイトルDBの統合 企画開発からサービス 集約、スレーブはく奪 開始のお知らせ （いつも突然。その週とかもある） （マシン確保） サービス伸びてきて 新サービス用サーバ作成 スレーブ追加 • 実は2012年はソーシャル用のサーバは１台も購入していない。（ネット ワーク増強（中）やio-Drive等の投資のみ）
- 6. 前回のあらすじ
- 7. CROOZでは2011年にFusion-ioを試験的に購入。 DUOを2台構成。 しかし 当時は特段大きな恩恵を受けることができず、本格導入は見送っていた。 当時、ソーシャルゲームを20タイトル程度、月間PVは数十億 これらのアクセス、トラフィックをWeb+DB約90台で処理。 DBサーバの一部分 にSSDを適用するだけで、特段問題なかった。 基本的にはMySQLのスロークエリの根絶（開発担当者すごい）DB分割、 キャッシュ等積極的利用の運用が上手く回っていて、インフラ、サーバ台数も 適切な台数で推移。 これでDisk-io根絶 = ioDrive不要。 当時の合言葉は 「Fusion-ioいらないよね？ 使ったら負け？」 「富豪」 「ゆとり」
- 9. 「神魔×継承！ラグナブレイク」 大ヒット御礼
- 10. CROOZ meet Fusion-io その上、イベントで「一定時間体力が減らない」施策発動。 DDoS攻撃状態 （ただし、相手は会員、お客様） サーバ、ネットワーク共にお祭り状態。 その結果・・・
- 11. MySQL Master MySQL slave（約20台）
- 12. CROOZ meet Fusion-io 購入だけしてあったFusion-ioマシンを投入。 MySQLサーバ群の一部だがioDriveになり、対象機器のみ DiskI/O、slave遅延などがきれいさっぱり無くなった。 やっぱりFusion-ioはすごいかもしれない（ステマ） ioDriveがすごいんだ！（どっちでもいい） 「Fusion-ioいらないよね？ 使ったら負け？」 （謝罪して訂正） 「Fusion-io最高だ。あれがないと寝れない。 何枚かまとめて買っといて」 （by.開発チーム） 謝罪の意味も込め、ioDrive2を5枚発注
- 13. 祭りは続く ！ 最大 941.93Mbps（回線は1Gbpsです） このあたりはioDriveでは解決できず・・・。結局毎月こんな感じ。 多分、今週も・・・。
- 14. 祭りは続く（真夏の恐怖） 最大 776.51Mbps（回線は1Gbpsです） 同一スイッチ、他ポートもこんな感じ。 そして、息が止まり始める・・・・・・。 スタックやめたり（なぜか治る）、スイッチ再起動したり、その都度ぶら下がるサービス全断。
- 15. CROOZ meet Fusion-io ioDrive2編
- 17. MySQL • 構成 – バージョンは5.1.x系 – SAPはここはあまり頑張るところではない（と思っている） – 基本的にSSDのみ（が、一部io-Drive侵食） – Master（更新）-slave（参照）構成のみ • モダンな構成。ミドルウエアのチューニングやトリッ キーなプロダクトにしてしまうと運用が追いつかない。 欠点をハードで解決できるうちはなるべくシンプルな構 成に。 • slave追加で参照負荷分散（増えすぎると問題） – 追加、剥奪作業自体も楽。 • master障害時slave昇格で対応
- 18. MySQL • リリースしたてのタイトル MySQL Replication MySQL (M) (S) MySQL TABLE-a (S) MySQL TABLE-b (S) TABLE-c どのようなタイトルでもMaster×1 , Slave×３くらいでスタート。 基本的にWebで2000万PV（day）ならちょっと辛いくらいで問題なし。 DBは1CPU、SSDで統一。 スレーブが何十台も増えて、マスター分割した り、レプリケーションやWeb間通信でラックスイッチ折り返しトラフィックなどが 目立ってきたら集約したい → ここでやっとioDriveを検討。
- 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. MySQL • パーテショニングは使っていない。 MySQL MySQL ioDrive入れて Replication 優良課金ユーザ用 (M) (S) MySQL のシステム TABLE-a (S) MySQL RANGE、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. 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. 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全廃したいが もう少しキャパシティプランニングをちゃんと やりたい。
- 31. 気になった点 lspciコマンドが・・・（cent5.4） ioDrive2 # lspci | grep -i fusion 08:00.0 Mass storage controller: Fusion-io Unknown device 2001 (rev 04) ioDrive1 # lspci | grep -i fusion 0b: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も入っているので、気になるなら 入手して入れ替えてみてください。
- 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. 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. 今後の構成（検討中）
- 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. まとめ
- 38. • ioDriveが何のためにあるか考える。 – 弊社の場合、Disk ioによるリソース逼迫、レスポンスの悪 化などにioDriveが効いた。 • Disk ioが発生する要件は多々ある。 ＜解決策は色々。詳細は各所で既出なので割愛＞ – Innodb_buffer_pool_size – スロークエリの根絶。 • イベント用プログラムがリリースされるたびに生まれる。 ： • そもそも高負荷時にレプリケート遅延やネットワーク逼迫 – スロークエリなどなし、レプリケートセグメントに特段変な もの無ければ、いよいよハードで解決を検討。
- 39. • ioDrive以外での解決策 – スレーブを参照系として利用している場合、CPUのアップ グレード、メモリの増強も効く。 • 弊社の場合、スペックをそろえているので、細かいもの をちょろちょろ買うと管理がめんどくさい。 • メモリは安いので積極的に搭載するべき。 • CPUは高い。 • CPUメモリ増強案 – 弊社のDBサーバは高スペックCPU１枚なので、2CPU化 し、2ndCPU側のメモリスロットを全埋めで見積もりを取得 した所、ioDriveより少し安いって程度だった。 管理方法、汎用性などを考慮した結果、ioDriveを採用。 ・１枚単位で管理ができる。 ・ローカルSSDが不要。（OS領域残すならその分のみ）
- 40. • ioDriveのリスク – 単品で購入すると資産計上。 • しかも年１で棚卸し。サービス止めてサーバ開けろと かありえない。 – キャパシティの上限がわからない。 • Iopsとか言われてもねぇ・・・。 • 某社の事例では○台→●台になったというのはあくまで も「当社比」レベルの話。 自社の現実を直視して責任 を持って決めるしかない。 他社の集約実績は神話。 – メーカが納期をコミットしない。 – 早すぎて他のシステムとのギャップ • 例えばバックアップサーバとか・・・。
- 41. • リスクの回避 – キャパシティなんて知らなくて良い。 • ioDriveで成り立つシステムのスタンバイにSSDとかあ り得ない。 SSDでいいならioDriveは最初から不要。 – 今の所、予め余分にリソースを準備するほかない。 • ソーシャルの場合、投資回収のサイクルが早い事と、 ioDriveは単品できちんと管理できるので、リソースが 逼迫したら追加購入で問題無いと思う。 – 但し、サービス（売上）が伸びていく前提。 売上伸 びていないのにリソースが逼迫しているなら別の （ダメクエリとか）要因を疑う。
- 42. ioDriveあるある • なんか「高い」って言われるけど、大抵は障害時に「サーバ追 加して」と言う人。 • 1の頃はDUOが早いと言われたが2になったら大差ないと言 われる。 • SSDからioDriveを投入したのに、SSDマシンを返してくれな い。ioDrive１枚あたりSSDマシン３台くらい返してほしい気分。 • マスター強化したらスレーブ死んだ。（ioDriveでやるのは特 に危険） • 納期６週間と言われたのに次の週に納品。