ウェブ広告のインフラについて(第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