mixiの可用性の主管部門
負荷対策
障害対応
ミドルウェアの管理
その他いろいろ
システム本部の紹介
mixi.jpのインフラについて
mixi.jpのシステム構成
運用のお話
システム本部(システム全体の部署)
技術部
たんぽぽG
研究開発G
運用部
アプリ運用G(ミドルウェア以上の運用)
インフラG
バックオフィスG
mixiサービス概要
ユーザー数は全国民の5分の1
月間PV
217.8億pv(モバイルガラケー)
37.2億pv(pc)
14.0億pv(スマホ)
スマホの伸びが良い(普及しているから)
mixiのインフラについて
標準化
4000台サーバがあるから設計は無理
タイプ別で標準化
アプリケーション = CPU重視
キャッシュ/データベース = メモリ重視
コンテンツ = ストレージ重視
標準化(ラッキング)
同じタイプのサーバを数ラック単位の「ユニット」というまとまりでラッキン
グ
標準化(ネットワーク)
どこのデータセンタを見ても同じように
使えるようにネットワークを設定
インフラについて
ラックなどは納期が数ヶ月かかることも
必要になりそうなものを前もって準備
何が必要かを考える
サービスによって何が必要かを細かく考えてラックを仕入れる
DB、サーバなど
クラウド
クラウドや外部ホスティングは使用していない
CDN(画像とか動画とか重いものを扱うサーバ、ネットワーク)は外部(CDNの使
用料は高い)
データセンタ
(数ヶ所を契約)
フロア単位で占有契約
サーバ
サーバは消耗品
壊れたものはすぐに捨てる(すぐベンダーとのやりとり、
修理のコストとかがかかるため)
運用コストを極力抑える
運用コスト > 金銭コスト
データセンター間のインフラ
web+db press vol.64にて
サーバファーム
コアスイッチとエッジスイッチ
スイッチを複数用意する
キャパ
上位回線10G*n
コア10G*n
エッジ1G*n
設計哲学
普通
目的指向
遮二無二新しいものを導入しない
シンプル・透明
欠点があっても、どうなっているか、何が起きているか
を重視(フェイルオーバー)
解析困難な冗長化はしない
誰でも
現地オペレータが一次対応しやすいもの(指示しやすくする)
社員がいつもいるわけではない
自由
その時々で最適な製品を選ぶ(常に最新のものは選ばないようにする)
独自プロトコル等でメーカーロックインされたくない(Apache,MySQL)
インフラについて(将来)
今後のネットワークデザインの試行中
広帯域化
スイッチバッファコリジョンへの対応
ロードバランサの効率利用
メンテナンス性の向上
設備リソースのプロビジョニンウ
IPv6
スイッチバッファコリジョンについては
web+db press 63から
mixiのシステム構成(サーバ)
サーバをタイプ毎の大別して使用
アプリケーション
キャッシュ/データベース
スケールアウト
データベース拡散&ユーザ分散(量)
スケールアップ
金で解決(質)(ムーアの法則)
Apache900
MySQL1000
memcached100(きゃっしゅさーば)
画像ストレージ400
etc...
8名で運用している
システム構成(リバースプロキシ)
インターネット
mod_proxy apache(リバースプロキシ)
mod_perl(アプリサーバ)
DB memcached API
webサービスの基本構造
日々増え続ける負荷に対し、
スケールする構成
各サーバからのやりとり
サーバ追加、故障サーバの入れ替えが容易
運用コストを至上とし、金銭コストは二の次
運用のお話
組織
本番(プロダクション)用サーバにログインできるのは
運用者のみ
システム構成DBのスキーマ等についてレビューを行う
(mixi.jpの運用だけではなく、可用性の責任も負う)
サーバの管理運用
障害について
アプリのバグ
サーバの障害
アプリサーバの追加交換
スケールアウト(高スペックサーバへの入れ替え、追加)
ある程度の予備をラックについでセットアップしている
20分程度で増強可能(数百台ある)
DBサーバの追加
監視の課題
アクセスは夜に多い
イベント(正月、試合、ラピュタ)のときに負荷がかかりやすい
サーバの4分の1は予備
故障率は思ったほど少ない
週1で壊れれば多いほう月2、3くらい
メインとバックアップでデータセンターを
使い分ける
アプリケーションレイヤーでのデータセンターは使い分ける必要がない
