20101220 pixiv tech_meeting

6GbpsをさばくオレオレCDN構築術

1.自己紹介

2.はじめに

3.システムの構成

4.やったらおどろいた

5.終わりに

アジェンダ

自己紹介

・飯田祐基 (いいだゆうき)・まいんど (だーいー)・ 2009年8月入社・前職は某ISPで3年ほど

ピクシブでは主にネットワークまわり、広告配信システム、データセンタの構築を担当

はじめに

pixivのメインコンテンツ

それは...

はじめに

イラスト

はじめに

イラスト(画像)にたくさんのアクセスが来ます↓

画像を保存してるサーバ(オリジン)だけでは捌けません！

↓他のサーバにもキャッシュ(同じデータを持たせて)して助けてもらいましょう！

はじめに

CDN(Contents Delivery Network)とは？

はじめに

要はコンテンツの配信を良い感じに手伝ったり、肩代わりしてくれるもの

専門的にやってる業者がいる → akamai, IIJ, etc

Webコンテンツをインターネット経由で配信するために最適化されたネットワークのことである

ｂｙ　ｗｉｋｉｐｅｄｉａ

はじめに

ということで、データセンタ借りて画像配信用キャッシュクラスタ(オレオレCDN)を作ってみましたよ！というお話

はじめに

はじめに

・時間がなかった（データセンタの選定も含め２，３ヶ月？）・データセンタ作業経験者が自分だけだった・ネットワークの見直し(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)




ユーザーのアクセス

6Gbps占有でDNS RR

Consistent Hashing

ローカルのnginxに再度

データセンタ

システム構成

・構成が均一（各サーバのconfigが一緒！）なので管理が楽！・スケールアウト（台数を増やしての拡張）が楽！そんなふうに考えていた時期が俺にもありました...・なんか工夫してるっぽくてカッコいい・正直やってみたかった、反省はしてない

メリット

オレオレＣＤＮ

やったらおどろいた！！

オレオレCDN やったらおどろいた

其の一


入れ過ぎるな危険


フロントA(nginx)

フロントB(nginx)

フロントC(nginx)

フロントD(nginx)

ユーザーのアクセス

6Gbps占有でDNS RR データセンタ

DNSラウンドロビンにたくさんアドレスを登録

DNSサーバの返答が512byteを超える（TCPに切り替わる）

クライアント側が対応していない → 見られない


解決方法

登録してる台数を減らした


其の二


偏る


フロント(nginx)

キャッシュA(squid)

キャッシュB(squid)

キャッシュC(squid)

キャッシュD(squid)

Consistent Hashing

ハッシュによるキャッシュへのリクエストが偏る(多いとこ、少ないとこで10倍くらいの差が)

特定のサーバの負荷が高くなる


解決方法

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; …}


其の三


バッファロー限界説


フロント

キャッシュホストＡ

L3 Switch ↔ Switch 700Mbps

フロント

キャッシュホストB

フロント

キャッシュホストD

SwitchSwitch

フロント

キャッシュホストC

L3 Switch

リクエスト

過負荷

(L3 Switchを経由する場合)Nginxが大量のconnection timeoutを吐くように


解決方法

timeout値を上げた(とりあえず)

proxy_connect_timeout 4;


フロント

キャッシュホストＡ

特定種類の画像を同じSwitch内のホストにのみ任せる

フロント

キャッシュホストB

フロント

キャッシュホストD

SwitchSwitch

フロント

キャッシュホストC

L3 Switch

リクエスト ×

所属してるSwitchごとにconfigを変える必要性


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; ... }

・ホストＡ、Ｂ → cache_server_switch_a・ホストC、D → cache_server_switch_b

終わりに

終わりに

・やったからこそわかる事がある・ varnishとかに変えてみたい・局所的にアクセスの多い部分を分割・詳しいことは懇親会で・弊社ではこんなのやってる！ってのも是非・みんなも真似できる構成

20101220 pixiv tech_meeting

Technology