流転工房

クラウドエンジニアの時流見聞

情シス記録 DMM.com開発(WEB+DB PRESS vol.78)再読その3

引き続きDMM.comのインフラチームに学びます。

「100Gbpsを超えるトラフィックをさばく秘訣」と銘打ったパフォーマンス改善編。

 

まずは画像配信の負荷対策。

画像を扱う際のボトルネック要素は、ストレージとトラフィック

 

ディスクI/Oとトラフィック分散の解消には、やはりCDN。キャッシュ保持期間の運用の苦労はあったそうだけど、複数配信サーバ+共有NFSストレージよりはいい。

さらなる性能・コスト改善は、ioDrive/GlusterFSという自社配信に切り替え、海外配信にはエッジを分散したCDNの使い分け。

ioDriveは10Gbps対応のNIC性能を引き出せる、、HW性能を引き出す為の技術選定も必要と。

 

次はデータベース。

クエリを治すという必要性は当然ながら、スケールアップ、シャーディングによるデータ分散、スケールアウトやmemcachedによるオフロードなど。

DB負荷の問題はスパイク発生時によく起きていたということ。運用側の判断フローとして、性能問題発生時はまず増強、それからアプリチームによるチューニングという流れにしていると。確かに冷静な判断期間をつくるために必要な発想。

 

そして、DBインフラの粋はやはりキャッシュによる高速応答。

MySQLSQL_CACHE指定や、PHPによるクエリ結果データのキャッシュをmemcacheに格納、その他、APIレベルでのクエリ結果のキャッシュ。

これはAPIサーバ問い合わせ結果の中間加工データを数十秒キャッシュするという運用。ヒット率はどんなだろう。

ただ、これ以前はHTMLキャッシュ(ユーザー固有情報部以外)を使っていて効果が高かったけど、ロジック部分に手をいれる保守コストが大変だったそう。

このため、ロジック部分のAPI化→この問い合わせ結果のキャッシュという仕組みにしたと。ただAPIコールのため、テーブル更新状況が不明のため短時間保持としてるらしい。

とにもかくにも、DBはディスクを読んだら終わりということ。

 

さて、構築段階での知見の投入はハイレベルだけど、本番運用で大切なのはボトルネックを発見する仕組み。こちらにも言及されているのは素晴らしい。

 

学んだ結果はその4にて。