ウェブ広告のインフラについて(第2回) 基本構成

まだ二回なのであまり深く突っ込んだ話はしません。

今回は自社DCのNW構成と、その際の注意していることなどを書いていこうと思います。

下の図をご覧ください。

実際はもう少し複雑ですが、LVS-DR構成を利用したシンプルな作りになっています。
入社直後チューニングノウハウがない時期にLVS-NATで運用していましたが、いきなり負荷でLVSがつぶされた経緯があり、現在と比べてかなり小さい規模でしたが思い切ってLVS-DRに切り替えました。
今でもその流れを継いでいます。

このように外から入ってくるギガ線のトラフィックをすべてLVSで受けて、内部のLVSでnginxから各APサーバに分散し、DRでデフォルトゲートウェイのVyattaから投げ返しています。

LVS-DRを表のLBに使ってるとかマジキチと自分でも思うんですが、使い始めると案外なんとかなってしまうもので、高い箱物をアテにしていないので、予算とか読めない事業予測にとらわれないスケーラブル()なインフラが結果的にできてしまいました。
CPUはいい仕事してくれます。

FWどうしてんだよ!とかは次回以降で!

しかしLVS-DR構成もデメリットとまでは言いませんが、運用に工夫が必要です。

スイッチの配置と挙動を考慮する

何も考えずに配線すると簡単にUnicastがFloodingします。
こちらのエントリーを参考にしてください。
2ラックでサーバを両ラックに分割して配置など特に要注意です。
結局スイッチまたぎの問題は解決できず、pingを定期的に実行するサーバを運用しています。

また以下の図のようにスイッチ間のトラフィックも偏りがでないように、実際はL2コアスイッチ的なものを一台はさんで配置しています。

ブロードキャストドメインの制限がある

LVS-DRはブロードキャストドメインの制限のために、スケールに限界があります。
現在は1ブロードキャストドメインにおとなしく納まる台数ですが、今後はもう1セットLVSを用意してDNSで分散するか、LVS-DRを多段にするか、そもそもLVS-DRを捨てるか等考えている最中です。
L2 over L3。。。おっと誰かきたようだ。

リアルサーバでVIPを受けるためにループバックインターフェイスを使っている

リアルサーバでVIPの通信でするためにiptablesを使っている場合が多いと思いますが、数多くある配信サーバでconntrack tableの管理をしたくないため、ループバックインターフェイスを使っています。
うっかりarp_ignore等重要な設定を忘れたりしないために、puppetで管理をしています。
manifestはgithubで公開しているので参考にしてください。

目次の前に書いてある内容程度ですが今日はこの辺で。
細々とやるのが長く続ける秘訣ですね。

次回はLVSとVyattaのチューニングについて書こうと思います。

ウェブ広告のインフラについて(第1回) まずはじめに

最初から技術的なことをぎっちり書くのもどうかなと思い、まずは背景などを書いていこうと思います。

自社の主力はSSPです。

ご存知の通りSSPは売り上げの大半が媒体への報酬に充てられるため、DSPとは異なり利率が低いです。
また障害で配信が停止してしまうと、サイトの読み込みが遅くなる、報酬が下がるなど即クレームにつながってしまいます。
ネットワーク管理者の自分がこう言ってしまうのはなんですが、残念ながら世の中にはインターネットは完全無停止なシステムであると思っている人はかなり多いです。
もっとも長時間の配信停止は話になりませんけどね。

大手のDSP参入が相次ぐ中、SSPが増えない理由はこのあたりのせいです。
手間もかかるし儲からない商売始めたら株主様に激怒されてしまいますからね。

さらにでかい媒体に広告枠が掲載されたら、突然トラフィックが1.5倍とかになったりもします。

つまり、安価で大量のショートパケットを安定して常にかなりのキャパシティを残しつつ高速で処理することが要求されます。

自社は独立系ベンチャーで100%内製のため、親会社の資金力頼りに札束で殴りあうことも、余ってる大量の人員でなんとかすることもできません。
真のエンジニアリングを発揮しなければ会社はこの先生き残れません。

リクエスト数とかインプレッション数とかいくらでも作れる数字を出して宣伝記事を出してる所が多いですが、自分のインフラは現在ピークで外からの通信を上り下り合計で秒間500,000パケットくらいを安定して処理しています。
もちろんまだまだキャパも残しています。

使っている箱物はスイッチだけです。
ファイヤウォール、IDS、ロードバランサなどすべてLinuxです。

では次回からいよいよ具体的な内容を書いていこうと思います。

ゆっくりまっていてね!

ウェブ広告のインフラについてまとめエントリーを始めます

タイトルの通りです。

これからいつまで続くかわかりませんが月1~2回で、自社インフラのナレッジや苦労話、笑い話(w)を深く掘り下げて出していきます。
スクリプトやプラグインも公開します。

限られたリソースの中で “パケロス = 最低200msの遅延” を回避するためのインフラノウハウを遠慮なく出していきます。

リクルーティングとか売名とか目的ではなく、最近方々でこの手の話す機会が増えたのでブロードキャストしてしまえというコンセプトです。
だらだら書いていきます。

pvcreateで “device-mapper: ioctl: error adding target to table

例によって中古ディスクの使いまわしで発生した問題です。
既存のパーティションを削除した後、新たにlvmパーティションを作成し、pvcreateでエラーがでました。

パーティション作り直しでもディスクのメタ情報は消えないようです。

# /sbin/dmsetup  status

pdc_bgbaijhjgc: 0 3906898080 linear ←これ
VolGroup00-LogVol00: 0 972357632 linear
# /sbin/dmsetup info pdc_bgbaijhjgc
Name:              pdc_bgbaijhjgc
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 2
Number of targets: 1
UUID: DMRAID-pdc_bgbaijhjgc

Google先生仰せのままに解決しました。

# /sbin/dmsetup remove_all

# /sbin/dmsetup  status
VolGroup00-LogVol01: 0 4194304 linear 
VolGroup00-LogVol00: 0 972357632 linear 

# /usr/sbin/pvcreate /dev/sdc1 
Physical volume "/dev/sdc1" successfully created