Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

netfilterを利用したDSP監視

10,412 views

Published on

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

Published in: Technology
  • Be the first to comment

netfilterを利用したDSP監視

  1. 1. netfilterを利用したDSP監視 手軽にできるL4監視 おおかわ かずひと Kauli, Inc.
  2. 2. なぜDSPを監視する必要があるか ● DSPへのビッドリクエストが詰まる、大量にタイムアウトする ● RTBの処理に時間がかかるとbusy processが増える ● やがて上限に達してフロントのnginxからのリクエストに応答できなくなる ↓ 配信事故になりかねない
  3. 3. 黎明期の対策方法 ● SSPのレスポンスタイムを監視して閾値を越えたらアラートを上げる ● エラーログから問題のあるDSPを特定する ● 設定ファイルを手で書き換えて問題のDSPへのリクエストを減らす 設定ファイルを書き換えて本番にデプロイできる人しか対応できない アラートがあがった時点で配信が不安定な状態寸前
  4. 4. 現在の対策方法 ● 全てのRTBリクエストをさばいているvyattaの通信状態を監視 ● 異常なTCPステータスの上昇を検知したらアラートをあげる ● アラートの内容、エラーログを確認して異常なDSPを特定する ● 問題のあるDSPの配信レートを操作する
  5. 5. ステータスの監視方法 ● これにnetfilterのconntrack tableを活用 ● conntrack tableにはvyattaを通過するすべての通信がリアルタイムで動的に保持 される ● conntrack tableは多いときで10万近いリストになることも ● conntrack tableを活用した監視方法はiptables(ip masquarede)をつかっている 副産物
  6. 6. netfilterとは ● 安川情報システムじゃないよ(学校向けフィルタリングソフト) ● カーネルのパケット処理をhookしてユーザランドで制御できるようにしたものなので、 ユーザ側で操作、参照しやすい形態 ● iptablesが有名だけどコンポーネントの一つ、他にもいくつかある ● conntrack, ulogd, ip6tables, arptables, ebtables等 ● netfilterプロジェクトの一つがiptablesなだけ、支援パッチも多数存在 http://en.wikipedia.org/wiki/Netfilter http://www.netfilter.org/
  7. 7. conntrack table ● connection tracking(追跡)の略ですべての通信がリアルタイムに記録される ● TCPの通信が終了した場合でも、設定されたタイムアウトまで蓄積される ● タイムアウトするとconntrack tableから破棄される ● つまりリアルタイムの通信以外の情報もconntrack tableには記録されている ● 監視する場合は上記の要素を排除しないといけない ● conntrack entry(中身)で見分けることが可能 ● src dst IPとPortのtupleをhash化して高速に処理している(hash table)
  8. 8. conntrack table entry ● [ASSURED] [UNREPLIED] のconntrack statusで有効なconntrackなのか判別す る ● [ASSURED]は破棄されず、[UNREPLIED]はtimeoutか上限数に達すると破棄され る ● conntrackのprotocol status、TCPなら SYN_SENT, ESTABLISHED, CLOSE_WAIT, TIME_WAITなど
  9. 9. conntrack entryのみかた ● cat /proc/net/nf_conntrack でも見れるけど時代的には古い ● 最新のカーネルだとprocfs自体から消えていたりする ● conntrack-toolsを使う、catより10倍以上早いしオプションも豊富 ● cat /proc/net/nf_conntrack(6sec) → conntrack -L(0.5sec)
  10. 10. 判定ロジック その1 ● [ASSURED] + SYN_SENTが増える(SYN_ACKが帰ってこない) ● HALF-ASSUREDが増える([ASSURED][UNREPLIED]に遷移しない]) ↓ コネクション要求に失敗している
  11. 11. その1をグラフでみると SYN_SENTが増加 コネクション要求は通るけ ど、応答が戻ってこない 状態 SYN_SENTだけは通る ので、ロードバランサーや その先のリアルサーバの 問題の可能性
  12. 12. その1をグラフでみると HALF-ASSUREDが増加 コネクションオープンまたは、クローズの 要求に応答が戻ってこない状態 NW的に疎通不可能か、レスポンスが極 端に低下している状態
  13. 13. 判定ロジック その2 ● [ASSURED] + ESTABLISHEDが増える(終了しない通信が増える) ↓ コネクションは確立しているがレスポンスがない
  14. 14. その2をグラフでみると CLOSEが増加 コネクションは確立したけど、 レスポンスがないため開きっ ぱなしのコネクションが増加 リアルサーバからレスポンス がなく通信がFINへ遷移しな いコネクションが増加している 状態 逆SYN flood状態
  15. 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. 16. まとめ ● netfilterを利用することによりL4の通信がリアルタイムで可視化できる ● conntrack-toolsにより可視化のリソースコストが激減 ● ASICと比べると遅いけどユーザランドなので柔軟性が高い ● netfilterのソースを読めばなにをしているかわかる
  17. 17. おわり フランちゃんウフフなインフラエンジニアかもしれないよ

×