NoSQL+ioDriveでの高速、大容量KVS実現勉強会でお話した内容デス。

1. meet�

2. 1つのサービスで�
�
1日で1億PV�
�
ピーク1時間で1000万PV�
�
に迫るシステム�

3. 懐（2009年頃）�

4. ioDrive2�

5. ioDrive勉強会で事例をお話しするのは３回目。
すっかりレギュラー化ですが、恐らく今回が最後です。
一つのソーシャルゲームが大ヒット。 それにあわせサーバ、回線、構成が変化。
今回はioDrive回りをお話します。
第一回 7/27
1日4000万PV突破でMySQLはSSD×18、ioDrive×2構成
第二回 8/23
SSD×13、ioDrive×7構成で回線が950Mbps頭打ち。
スイッチ障害多発。
第三回 今回
１億PV目前で大変。 遂にioDrive20台構成に。
（もう「富豪」でも「ゆとり」でもなんとでも呼んでください）

6. ↑ キャンペーンは多分終わってます。
インフラ残酷物語
引き続き、応援よろしくお願いします！

7. ソーシャルゲームが当たるという事（主な出来事抜粋）
月
PV/日
主な出来事
PF展開
３月
リリース！
モバゲー版リリース
４月
MySQLスレーブ追加（DELL R610/SSD） Mixi(FP)
５月
MySQLスレーブ追加（DELL R610/SSD）
６月
ラックスイッチダウン（まさかの体力無限イベント） Mixi(SP）
MySQLスレーブ追加（DELL R610/SSD） Ameba
DB分割2系統目
７月
4000万
ラックスイッチダウン Deity Wars(Android)
DB分割3系統目 PickUP
１
Memcachedが微妙に・・・
８月
5000万
ラックスイッチダウン頻発 Deity Wars(iOS)
ioDrive1を２台投入、その後追加で５台、計７台
２
プログラムリファクタリング、APCキャッシュ積極利用
９月
5800万
ラックスイッチダウン/LVS、リバプロの動きがもっさり・・・
上位回線10Gbps化(Force10/S4810)
一部ラックスイッチ10GbE(Force10/S60)投入
既存スイッチに異常な量のPAUSEフレーム発見
PickUP
Redis(SSD)投入
10月
7000万
このサービスのみラックを隔離するため、増強という名の アヴァロンの騎士
サーバ買い直し。（台数変更せずSpecUP→DELL R620/io） TV CM
新ラックのNW機器は全てForce10社のものを採用。
11月
9000万
遅延し始めるioDrive(1) PickUP
３
バックアップもioDrive♪

8. 全体構成
Internet
L7バランサ ioDrive効果
適用可能！ あり！
Front LVS (GLOBAL)
cache
etc. Service
nginx proxy (GLOBAL)
プラット
フォーム Contents Redis Memcached
Ping返答用 (picture)
(NoSQL)
Front Service LVS (GLOBAL)
BackService LVS
ioDrive効果
あり！
Web Server
DBServer
オンメモリ
上にAPC
キャッシュ
展開可能！

9. 余談ですが・・
Internet
L7バランサ
適用可能！
Front LVS (GLOBAL)
etc. Service
nginx proxy (GLOBAL)
プラット
フォーム このあたりが気軽に500Mbpsを
Ping返答用
超えてしまう。
1GbpsのNICを搭載したサーバが
Front Service LVS (GLOBAL)
２台の上長構成の場合、500Mbps
とか超えられるとたまらない。
F5の8000番台欲しい・・・。
Web Server
オンメモリ
上にAPC
キャッシュ
展開可能！

10. memcachedが微妙に・・・。
NoSQLなどの検証を全く行っていなかった時期にmemcached
が微妙に・・・・
memcachedサーバは「余っているマシン」で構築
Intel x5400（Harpertown）世代、16G程度のメモリ、SAS-HDD
・高負荷時に原因不明の「もっさり」
・気がつけば数百kのデータ（格納できない）
・接続できない。または、接続断。
当然ですが、キャッシュに異常が発生すると該当サービスはひ
どい事になるため、まずWebサーバ側にAPCキャッシュ投入。

11. Redis(SSD)投入
検証する間のないRedisをいきなり本番投入。 memcachedと
平行稼動させ、開発側で徐々に切り替えていきました。
Intel x5500（Nehalem）世代、48G程度のメモリ、SSD
最初はランキングなどから。 現時点では遂にランキングがリア
ルタイム化に成功！ Redisすごい！
現時点でもSSDです（NOT ioDriveですみません）
特に大きな問題はないのですが、時々「４秒以上かかったアク
セス」（これは監視しているものです）が「ドバッ」とでます。

12. Redis(SSD)投入
当現象がRedisのメモリからディスクへのフラッシュが発生した
タイミングだったとしたら、ioDrive化で対応かも知れません・・・。

13. 遅延し始めるioDrive(1)
プログラムリファクタリング、テーブル構成の見直し・分割、キャッシュ変更な
ど開発側はもの凄い勢いで対応してくれた。 対応したチームは本当に凄い
と思う・・・・・・が、
ついにdaily１億PV、時間ピークも1000万PV目前の頃、まさか
のioDriveに書き込み遅延が発生し始めた。
ioDrive1(duo) x 2台（DELL R610） ※こちらだけが遅延
Intel x5670（Nehalem）×2(24コア)、（確か）mem48G
ioDrive2(mono) x 18台（DELL R620) ※こちらは平気
Intel E5-2670（SundyBridge-EP）×2(32コア)、mem96G
プログラム、テーブル、マシンリソースなども熟成期だったため、ioDrive1を
撤去し全て2で統一した。

14. CPUネックを避けるためにSandyBridgeへ移行
2CPU構成
SPECint_rate
SPECfp_rate
Xeon 5600
_base2006
2006
_base2006
2006
X5670
2.93GHz/12MB/6Core
338
362
240
249
SPECint_rate
SPECfp_rate
Xeon E5-2600
_base2006
2006
_base2006
2006
1CPU単価
E5-2620
2GHz/15MB/6Core
375
393
328
336
135,000
E5-2670
★
2.6GHz/20M/8Core
618
644
469
483
400,000
E5-2690
2.9GHz/20M/8Core
666
693
491
507
526,000
R610/R620ではioDrive1（DUO)/2(mono)という差はあるもの
のCPUなどサーバのアーキテクチャが異なっている。
この辺りもioDriveの“更なる”潜在能力を引き出すと推測し「同
程度のスペック」ではなく、倍程度に引き上げた。

15. バックアップもioDrive搭載サーバで♪
やや余談ではありますが、データベースのバックアップについ
てもHDD→SSD→ioDriveと変更。
バックアップ取得の書き込み遅延がひどくなりioDrive化。
ある程度は取得データの選択や、不要レコードの削除で対応
する事はできるが、それ自体の工数や、バックアップ取得後に
分析したり、検証したりする事などを考えるくらいだったら、
ioDriveで一括取得し、用途に応じたクローンを作成した方が早
い。

16. 今後の展望
ココ数ヶ月、正に教科書とおりの「モグラたたき」に悩まされた。
Disk(SSD)io遅延(ioDrive化) → CPU能力不足(2CPU化）
→ スレーブ追加時にメモリ不足でレプリ追いつかず(96Gメモ
リ） → ネットワーク全断(10Gネットワーク、DeepBuffer搭載
ラックスイッチ） → フロントプロキシが増え続ける（F5導入検
討中） → Disk(ioDrive)io遅延（今度はチューニング）
※実際にはキャッシュ採用や、プログラム、テーブル見直しなどチューニング
もたくさんしました。

17. 今後の展望
ioDriveのチューニング
試行錯誤中ではありますが、以下のチューニングレポートの
検討に着手しました！ もし、適用、効果が見えたらFusion-ioさ
んへフィードバックします！（むしろどなたかやっていらっしゃれ
ば共有を・・・）
情報共有を・・・）