IaaS Casual Talks #1 に参加しました

ご無沙汰しています。
BtoBになるとどこまで話していいものか判断が難しくてなかなか気軽に書けないんですよね。

さてしばらく停滞していましたが、@higebu さんが勉強会を開催されるということで、ちょうどネタもたまっていたので軽く話をさせていただきました。

ちなみに速足だったのであまり話せませんでしたが、Kauli買収直後の状況はこんな感じでした。
Capture2Captureぜんぜんめでたくないし、空中分解した現状をみて改めて↑の方々にコメントをいただきたいところですねw。
VOYAGEとか以前から恨みあったし相当嫌でしたよ。

さて、ESXiなんて貴族のハイパーバイザなんてろくに触ったことなかったんですが、半年もするとだいぶ慣れるものですね。
なにより、サポートが(ryというのもありますが、納得いくまで調べて確実にナレッジにするという基本的な行動方針おかげです。
ちょっとした内容ですが、なにかの参考になると忙しい中作った身としては幸いです。

今回は事前も当日も時間がなくて簡単な内容になってしまいましたが、期末を乗り切った次回はもうちょっとしっかり話をできたらと思います?

あと別件になってしまいますが、今扱っているNutanixについて来月の Nutanix Community Meetup #10 で実際に使った使用感を話そうと思っています。
興味がある方はぜひ参加してみてください。

 

VyOS向け低レイテンシーチューニングTips

すっかり冬模様になりましたね。
雪遊びの準備が全然できてないので、早く仕事を落ち着かせたい今日この頃です。

2015年はKauliが買収されたり、ご自慢のVOYAGEオフィスから締め出されたり、その後転職といろいろありました。
来年は落ち着いた一年になることを心から願っています。

さて久々に糞エントリーを書くのとadvent calendarということもあり、ふわっとゆるい内容でいきたいと思います。

VyOS向けとありますが、VyOS自体DebianなのでLinux全般で使えるTipsです。
低遅延になって何がうれしいかというと、VoIPで音声通話がよりリアルタイムになったり、ネットゲームで有利になったり、VyOSで超高速取引をしてる個人投資家が有利になるとかいい事尽くめです(?)

本来の目的は10Gbps 64byteのショートパケットで、ワイヤレートをだすLVSを作る予定だったんですが、VOYAGEの経営陣に取り潰されたネタです。

チューニングすべき箇所はキューやバッファですが、それぞれネットワークスタックやデバイスコンポーネントの一部として構成されています。
それらのデフォルトの設定はスループット向上や、CPU負荷低減などシステムや回線の利用効率向上に一役かっています。
しかし逆に何をしてもいいから1ナノセックでも早くパケットを処理し送り出したい、そんな要求も世の中にはあります。
今回はそんな人むけです。
なおソケットなどユーザランドは考慮しません。
あくまでルータとしてNICとカーネルまでです。

リングバッファを少なくする

リングバッファはCPUがオンデマンドで処理できない時のために、バッファ領域としてごく小さいメモリ空間として存在しています。
理想はないほうがいいし、あったとしてもメモリ空間なのでレイテンシを気にする場合は効率的に使う必要があります。
リングバッファサイズを小さくすることでヘッドポインタとテールポインタを追跡する処理やガベージコレクトのロスを減らすことができます。
レイテンシを目的とするなら最小値に設定しましょう。

RSSのキューイング先(CPUコア)を固定する

CPUのキャッシュが効率的に使えます。
ntupleとFlow Directorによって、通信条件を指定してRSSのキューイング先を指定できます。

NICのInterrupt Coalescingを無効にする

過大なCPU割り込みを軽減するために、NICはパケットを受信してもすぐ割り込みを発生させません。
特定のパケット数がたまるまで待つ設定がデフォルトでされています。
オフにすればオンデマンドで割り込みが発生し遅延しません。
ただしバーストトラフィックには注意してください。
バースト分がCPUに直撃します。

EISTとC-STATEをオフにする

CPUクロックの変化がレイテンシに悪影響を与えるため、EISTと各C-STATEをすべて無効にします。

・PCIe Link State Power Managementをオフにする

CPU同様にPCI Expressも全力で稼動させます。

NICオフロードについては未調査のため今回はスルーします。
では皆様よいお年を!
(このやっつけ感)

近状とか

ご無沙汰しています。
やっと新しい職場に入ってから3ヶ月がたって、試用期間も終わったところですが、社内のみんなそんなこと信じてくれないか忘れるくらいなじんでます。

普段あまり話さない人から、最近ブログ更新ないし何してるの?って言われたので、いい機会だから近状とかざっくり。

買収直後の辞める面談の時にVGの新経営陣から話だけはされましたが、職歴が汚れるのでVGには転籍せずにKauli所属のまま8月いっぱい有給を消化して辞めました。
引継ぎもあるし年内くらいは居た方がいいかなと思っていたんですが、新経営陣が早く追い出したがってたのでさくっとほっぽりなげて辞めました。
年内でKauliがなくなるから失業したくなければVGに移れ拾ってやる、みたいな物言いだったけど、次の行き先決まってたし。

9月からうってかわって、某ITソリューションプロバイダー()のアカウントSEに転生しました。
生まれてはじめてスーツきて仕事してます。
仕事が集まってきて大変だけど、職場の雰囲気もいいし、無理難題だらけで課題も尽きないので毎日楽しく(?)仕事してます。
むしろVGの騒いでるだけの連中みたいに仕事に派手さを求めない自分にとっては、タダ酒とかゲームできるとかどうてもよくて、落ち着いてて馬鹿が視界に入らない環境のほうが重要ですね。
一度挫折を経験するまでは、とにかく今の職場でがんばろうと思います。

そんなわけで、なにかお困り事ありましたら、こんな最低な自分が直接ご提案にいくことができるようになりました。
ちょっととがったご提案を欲してるときは、自分に声かけてください。
野良不良SEがなんか考えてもっていきます。(ひやかしはやめてね!)

というわけで復帰ついでにSE●LとGI●チームに喧嘩を売るような内容になっちゃうけどVyOSのadvent calendarネタ書かせてもらおうと思います。

Kauliを退職します

本糞ブログの更新を楽しみにしているありがたい方々がちらほらいると方々で聞いているので、お知らせします。

自社であるKauliがVOYAGE GROUPに子会社化され、辞めることにしました。
というか従業員に発表された日に、KSGと思って辞めると決めていました。

元々宗教上の理由で嫌いなVOYAGE GROUPは、買収直後からいろいろひどい話が山ほどありますが・・・、酒の席で機会があった人にはうっかり話しますw
まあ蓋が開いたら予想通りというか想像以上というか・・・。

さて、次の職場はまったくもって別の業種です。
ですので、広告系のインフラネタで書くことはもうありません。
仕事の内容的にも表に出せる内容がかなり限られると思いますが、なにか書けることがあれば細々と続けていこうと思います。
(仕事で超常現象が発生しないかぎりネタがないとも)

8月いっぱいは休みなので、酒飲みたいとか、技術的な話をして欲しいとかあったら@SatchanPまで気軽に声かけてください。

ウェブ広告のインフラについて(第5回) LinuxのTCP再送アルゴリズムとモバイルネットワークの相性の悪さ

だいぶ間が開いてしまいましたが、重い腰が上がったので5回目です。
今回はAWSなど従量制パブリッククラウドサービスを利用していて、なおかつパケ死寸前の同業他社のインフラ担当にはかなり耳寄りな話です。
内容自体は去年に社内勉強会で話したことと同じです。
その時のスライドも公開します。

さて、昨今ウェブ広告業界においてはスマホやタブレットを含むモバイルネットワークやワイヤレス通信(3G/4G/WiFi)の利用者がPCを逆転しそうなペースで増加しています。(個人的にまだ逆転したとは聞いてない)
最近では自宅でも固定回線を持たないユーザもかなり増えていますね。
固定回線で利用するPCとは異なり、特にモバイルネットワーク通信のRTTは激しく揺らぎます。
このRTTの揺らぎが、例によってLinuxのTCPスタックと激しく相性が悪く、非効率的な再送やNW機器の高負荷の原因になってしまいます。

とりあえず細かいウンチクはスライドみてください(手抜き)

雑にまとめるの以下のとおりです。

  • 移動中(電車)のユーザ数が日々の生活で眺めていてもとても多い。広告インフラ屋としてはこの人ら全員ユーザに見える
  • 都心はモバイルネットワーク網が発達している、といっても所詮ワイヤレスなためRTTの揺らぎがでかい
  • 広告配信ではRTTの揺らぎに対して、RTOの最適化が通信が短い間で終了するため補正ができない
  • 通信相手が消え去っても、多めに設定された上限値まで律儀に再送を実行する
  • キャリア側のルータの挙動が結局どうなってるのか読めない
  • 誤クリックによりユーザがBackを押した時のブラウザとOSの挙動も読めない
  • 参考だけど最低200msに設定されているのは、その下にNagleアルゴリズムがあるから

等あり、通信とサーバのコストを考慮して、再送回数を思い切って減らすことにしました。
最近はもうちょっと減らしてもいいかなと思っていたりもします。

echo 5 > sys/net/ipv4/tcp_orphan_retries

自社の場合は、当時でフロント側のnginxサーバ1台で1分間のTCP再送回数が2000回くらい減りました。
再送間隔を倍にしていった上で、5回であきらめることをどう評価するかは環境次第です。
上記の参照した値はnetstat -stで取得できる値です。
あくまでもパケット数が減るだけであって、bpsで見る総量はあまり減りませんが、確実に効果はあります。

また私事ですが、グループアワードとかやってるグループ会社が嫌で今の会社に転職したのですが、グループアワードとかやってる別のグループ会社に買収されてしまったので、広告系インフラエントリーも残り数回になるかもしれません。