netfilterのconntrack tableを利用した、L4レイヤーのリアルタイムステータス監視について

1. netfilterを利用したDSP監視
手軽にできるL4監視
おおかわ かずひと
Kauli, Inc.

2. なぜDSPを監視する必要があるか
●
DSPへのビッドリクエストが詰まる、大量にタイムアウトする
●
RTBの処理に時間がかかるとbusy processが増える
●
やがて上限に達してフロントのnginxからのリクエストに応答できなくなる
↓
配信事故になりかねない

3. 黎明期の対策方法
●
SSPのレスポンスタイムを監視して閾値を越えたらアラートを上げる
●
エラーログから問題のあるDSPを特定する
●
設定ファイルを手で書き換えて問題のDSPへのリクエストを減らす
設定ファイルを書き換えて本番にデプロイできる人しか対応できない
アラートがあがった時点で配信が不安定な状態寸前

4. 現在の対策方法
●
全てのRTBリクエストをさばいているvyattaの通信状態を監視
●
異常なTCPステータスの上昇を検知したらアラートをあげる
●
アラートの内容、エラーログを確認して異常なDSPを特定する
●
問題のあるDSPの配信レートを操作する

5. ステータスの監視方法
●
これにnetfilterのconntrack tableを活用
●
conntrack tableにはvyattaを通過するすべての通信がリアルタイムで動的に保持
される
●
conntrack tableは多いときで10万近いリストになることも
●
conntrack tableを活用した監視方法はiptables(ip masquarede)をつかっている
副産物

6. netfilterとは
●
安川情報システムじゃないよ(学校向けフィルタリングソフト)
●
カーネルのパケット処理をhookしてユーザランドで制御できるようにしたものなので、
ユーザ側で操作、参照しやすい形態
●
iptablesが有名だけどコンポーネントの一つ、他にもいくつかある
●
conntrack, ulogd, ip6tables, arptables, ebtables等
●
netfilterプロジェクトの一つがiptablesなだけ、支援パッチも多数存在
http://en.wikipedia.org/wiki/Netfilter
http://www.netfilter.org/

7. conntrack table
●
connection tracking(追跡)の略ですべての通信がリアルタイムに記録される
●
TCPの通信が終了した場合でも、設定されたタイムアウトまで蓄積される
●
タイムアウトするとconntrack tableから破棄される
●
つまりリアルタイムの通信以外の情報もconntrack tableには記録されている
●
監視する場合は上記の要素を排除しないといけない
●
conntrack entry(中身)で見分けることが可能
●
src dst IPとPortのtupleをhash化して高速に処理している(hash table)

8. conntrack table entry
●
[ASSURED] [UNREPLIED] のconntrack statusで有効なconntrackなのか判別す
る
●
[ASSURED]は破棄されず、[UNREPLIED]はtimeoutか上限数に達すると破棄され
る
●
conntrackのprotocol status、TCPなら SYN_SENT, ESTABLISHED,
CLOSE_WAIT, TIME_WAITなど

9. conntrack entryのみかた
●
cat /proc/net/nf_conntrack でも見れるけど時代的には古い
●
最新のカーネルだとprocfs自体から消えていたりする
●
conntrack-toolsを使う、catより10倍以上早いしオプションも豊富
●
cat /proc/net/nf_conntrack(6sec) → conntrack -L(0.5sec)

10. 判定ロジック その1
●
[ASSURED] + SYN_SENTが増える(SYN_ACKが帰ってこない)
●
HALF-ASSUREDが増える([ASSURED][UNREPLIED]に遷移しない])
↓
コネクション要求に失敗している

11. その1をグラフでみると
SYN_SENTが増加
コネクション要求は通るけ
ど、応答が戻ってこない
状態
SYN_SENTだけは通る
ので、ロードバランサーや
その先のリアルサーバの
問題の可能性

12. その1をグラフでみると
HALF-ASSUREDが増加
コネクションオープンまたは、クローズの
要求に応答が戻ってこない状態
NW的に疎通不可能か、レスポンスが極
端に低下している状態

13. 判定ロジック その2
●
[ASSURED] + ESTABLISHEDが増える(終了しない通信が増える)
↓
コネクションは確立しているがレスポンスがない

14. その2をグラフでみると
CLOSEが増加
コネクションは確立したけど、
レスポンスがないため開きっ
ぱなしのコネクションが増加
リアルサーバからレスポンス
がなく通信がFINへ遷移しな
いコネクションが増加している
状態
逆SYN flood状態

15. 値の取得方法
●
vyattaのconntrack tableをperlスクリプトでパース
tcp_ss:68 tcp_sr:0 tcp_e:1035 tcp_fw:1638 tcp_cw:2736 tcp_la:225 tcp_tw:30220 tcp_c:5163 tcp_a:33064 tcp_u:5273 tcp_ha:12 tcp_tot:38349 udp_a:91 udp_u:2 udp_ha:4844
udp_tot:4937 icmp_u:0 icmp_ha:1 icmp_tot:1 igmp_u:0 igmp_ha:0 igmp_tot:0 other_a:0 other_u:7 other_ha:0 other_tot:7 tot_a:33155 tot_u:5282 tot_ha:4857 tot:43294
●
http://forums.cacti.net/post-187384.html cacti forumのpluginを利用
●
パースした値をsnmp経由で監視サーバが取得
●
自作nagios pluginで閾値監視、cactiでグラフ化

16. まとめ
●
netfilterを利用することによりL4の通信がリアルタイムで可視化できる
●
conntrack-toolsにより可視化のリソースコストが激減
●
ASICと比べると遅いけどユーザランドなので柔軟性が高い
●
netfilterのソースを読めばなにをしているかわかる

17. おわり
フランちゃんウフフなインフラエンジニアかもしれないよ