20101220 pixiv tech_meeting
Post on 24-May-2015
7.222 Views
Preview:
TRANSCRIPT
6GbpsをさばくオレオレCDN構築術
1.自己紹介
2.はじめに
3.システムの構成
4.やったらおどろいた
5.終わりに
アジェンダ
自己紹介
・ 飯田祐基 (いいだゆうき)・ まいんど (だーいー)・ 2009年8月 入社・ 前職は某ISPで3年ほど
ピクシブでは主にネットワークまわり、広告配信システム、データセンタの構築を担当
はじめに
pixivのメインコンテンツ
それは...
はじめに
イラスト
はじめに
イラスト(画像)にたくさんのアクセスが来ます↓
画像を保存してるサーバ(オリジン)だけでは捌けません!
↓他のサーバにもキャッシュ(同じデータを持たせて)して助けてもらいましょう!
はじめに
CDN(Contents Delivery Network)とは?
はじめに
要はコンテンツの配信を良い感じに手伝ったり、肩代わりしてくれるもの
専門的にやってる業者がいる → akamai, IIJ, etc
Webコンテンツをインターネット経由で配信するために最適化されたネットワークのことである
by wikipedia
はじめに
ということで、データセンタ借りて画像配信用キャッシュクラスタ(オレオレCDN)を作ってみましたよ!というお話
はじめに
はじめに
・時間がなかった(データセンタの選定も含め2,3ヶ月?)・データセンタ作業経験者が自分だけだった・ネットワークの見直し(L3スイッチ導入)も同時並行でしてた・ちょうどハテブのホッテントリにnginxを使ったクラスタの話が ※ただし、配信してみたタグはついてなかった (参考にしたエントリはこちら → http://p.tl/2vYq)
データセンタを借りることに
・初夏にかけて徐々にサイトが重い状態 (トラフィックが頭打ち)・キャパ的に拡張余地がなかった (建物、プロバイダetc)・以前の構成はかなり酷かった (無茶しやがって...)
はじめに
kamipo先生「イメージ配信クラスタ略してイメクラですね!!」
自分「*・゜゚・*:.。..。.:*・゜(n‘ ‘)η∀ ゚・*:.。. .。.:*・゜゚・」
はじめに
結論
はじめに
システム構成
システム構成
フロントA(nginx)
オリジン オリジン
フロントB(nginx)
フロントC(nginx)
フロントD(nginx)
旧社屋
キャッシュA(squid)
キャッシュB(squid)
キャッシュC(squid)
キャッシュD(squid)
ディスパッチャ(nginx)
ディスパッチャ(nginx)
ディスパッチャ(nginx)
ディスパッチャ(nginx)
ユーザーのアクセス
6Gbps占有でDNS RR
Consistent Hashing
ローカルのnginxに再度
データセンタ
システム構成
・構成が均一(各サーバのconfigが一緒!)なので管理が楽!・スケールアウト(台数を増やしての拡張)が楽! そんなふうに考えていた時期が俺にもありました...・なんか工夫してるっぽくてカッコいい・正直やってみたかった、反省はしてない
メリット
オレオレCDN
やったらおどろいた!!
オレオレCDN やったらおどろいた
其の一
オレオレCDN やったらおどろいた
入れ過ぎるな危険
オレオレCDN やったらおどろいた
フロントA(nginx)
フロントB(nginx)
フロントC(nginx)
フロントD(nginx)
ユーザーのアクセス
6Gbps占有でDNS RR データセンタ
DNSラウンドロビンにたくさんアドレスを登録
DNSサーバの返答が512byteを超える(TCPに切り替わる)
クライアント側が対応していない → 見られない
オレオレCDN やったらおどろいた
解決方法
登録してる台数を減らした
オレオレCDN やったらおどろいた
其の二
オレオレCDN やったらおどろいた
偏る
オレオレCDN やったらおどろいた
フロント(nginx)
キャッシュA(squid)
キャッシュB(squid)
キャッシュC(squid)
キャッシュD(squid)
Consistent Hashing
ハッシュによるキャッシュへのリクエストが偏る(多いとこ、少ないとこで10倍くらいの差が)
特定のサーバの負荷が高くなる
オレオレCDN やったらおどろいた
解決方法
weightをいじって調節
upstream cache_server { consistent_hash $host$request_uri;
server 192.168.32.2:8080 weight=100; server 192.168.32.6:8080 weight=110; server 192.168.32.7:8080 weight=106; server 192.168.32.8:8080 weight=110; server 192.168.32.9:8080 weight=160; …}
オレオレCDN やったらおどろいた
其の三
オレオレCDN やったらおどろいた
バッファロー限界説
オレオレCDN やったらおどろいた
フロント
キャッシュホストA
L3 Switch ↔ Switch 700Mbps
フロント
キャッシュホストB
フロント
キャッシュホストD
SwitchSwitch
フロント
キャッシュホストC
L3 Switch
リクエスト
過負荷
(L3 Switchを経由する場合)Nginxが大量のconnection timeoutを吐くように
オレオレCDN やったらおどろいた
解決方法
timeout値を上げた(とりあえず)
proxy_connect_timeout 4;
オレオレCDN やったらおどろいた
フロント
キャッシュホストA
特定種類の画像を同じSwitch内のホストにのみ任せる
フロント
キャッシュホストB
フロント
キャッシュホストD
SwitchSwitch
フロント
キャッシュホストC
L3 Switch
リクエスト ×
所属してるSwitchごとにconfigを変える必要性
オレオレCDN やったらおどろいた
upstream cache_server_switch_a { consistent_hash $host$request_uri;
server 192.168.32.3:8080 weight=100; ... }
upstream cache_server_wtich_b { consistent_hash $host$request_uri;
server 192.168.32.13:8080 weight=100; ... }
・ホストA、B → cache_server_switch_a・ホストC、D → cache_server_switch_b
終わりに
終わりに
・ やったからこそわかる事がある・ varnishとかに変えてみたい・ 局所的にアクセスの多い部分を分割・ 詳しいことは懇親会で・ 弊社ではこんなのやってる!ってのも是非・ みんなも真似できる構成
top related