情シス記録 DMM.com開発（WEB+DB PRESS vol.78）再読その３
引き続きDMM.comのインフラチームに学びます。
「100Gbpsを超えるトラフィックをさばく秘訣」と銘打ったパフォーマンス改善編。
まずは画像配信の負荷対策。
画像を扱う際のボトルネック要素は、ストレージとトラフィック。
ディスクI/Oとトラフィック分散の解消には、やはりCDN。キャッシュ保持期間の運用の苦労はあったそうだけど、複数配信サーバ＋共有NFSストレージよりはいい。
さらなる性能・コスト改善は、ioDrive/GlusterFSという自社配信に切り替え、海外配信にはエッジを分散したCDNの使い分け。
ioDriveは10Gbps対応のNIC性能を引き出せる、、HW性能を引き出す為の技術選定も必要と。
次はデータベース。
クエリを治すという必要性は当然ながら、スケールアップ、シャーディングによるデータ分散、スケールアウトやmemcachedによるオフロードなど。
DB負荷の問題はスパイク発生時によく起きていたということ。運用側の判断フローとして、性能問題発生時はまず増強、それからアプリチームによるチューニングという流れにしていると。確かに冷静な判断期間をつくるために必要な発想。
そして、DBインフラの粋はやはりキャッシュによる高速応答。
MySQLのSQL_CACHE指定や、PHPによるクエリ結果データのキャッシュをmemcacheに格納、その他、APIレベルでのクエリ結果のキャッシュ。
これはAPIサーバ問い合わせ結果の中間加工データを数十秒キャッシュするという運用。ヒット率はどんなだろう。
ただ、これ以前はHTMLキャッシュ（ユーザー固有情報部以外）を使っていて効果が高かったけど、ロジック部分に手をいれる保守コストが大変だったそう。
このため、ロジック部分のAPI化→この問い合わせ結果のキャッシュという仕組みにしたと。ただAPIコールのため、テーブル更新状況が不明のため短時間保持としてるらしい。
とにもかくにも、DBはディスクを読んだら終わりということ。
さて、構築段階での知見の投入はハイレベルだけど、本番運用で大切なのはボトルネックを発見する仕組み。こちらにも言及されているのは素晴らしい。
学んだ結果はその４にて。
