WCSC27のPonanza ChainerのインフラとHPCチューニングの話

お酒ばっかり飲んで過ごした連休もいよいよ終わりです。(これ書き始めたのが連休中)
まともな休みになった連休は数年ぶりな気もします。

さて、少しさかのぼりますがひょんなことからGWの連休中に開催される世界コンピュータ将棋選に参加するPonanza Chainerという将棋ソフトのインフラ構築をやることになりました。
長いので以下Ponanza。

結果からいうと優勝目標で二位という結果でした。
将棋のいろいろ恐ろしいものの片りんを味わった気がします。
ちなみに自分は大会の3日前にハム将棋を初めて、当初は10枚堕ちでボロ負けしてたのが、当日にはハンデありで互角に戦えるくらいにはなりました。(しょぼ)

今回のインフラ構築作業をするまでは自分の中でコンピュータ将棋というと、スペックのいいパソコンを1、2台会場にもっていってスタンドアロンで動かすという印象があったため、最初は「なんぞ?」と思いつつ着手しました。
実際Ponanzaも手を付けるまでは数台の規模でしたし、最初はノートパソコンで動いてたとか?

他の仕事も忙しかったのでながら作業となりましたが、作業を進める中で山本さんとの会話でコンピュートリソースの殴り合いが始まり数個のプロセッサでは勝つのが難しい状況になっていることを知り、社内で余剰のサーバや部材をかき集めてPonanzaクラスタを動かすことが目的ということをしりました。

Ponanza用の計算クラスタということは言い換えれば自作のスパコンです。
結果的にPonanzaのためのHPCのインフラを社内からかき集め、限られたリソースで最大限パフォーマンスを発揮できる状態にすることが自分の仕事になりました。

クラスタはただたくさん並べてつなげばいいというわけではありません。
CPU1台でやっていた計算を複数台でやるわけですから、CPU間の通信が最大のボトルネックとなります。
これをインターコネクトといいます。
コンピュータ間で通信できればいい訳ですから、種類は様々でイーサネットやInfinibandや高度なシステムになると独自規格専用設計だったりします。
このインターコネクトにはCPUへの命令やその結果、共有メモリなど大量の通信が流れます。

昨今GPUによりFLOPS単体の性能は劇的に上がりましたが、あくまでも単体の性能の話でクラスタを構成する場合、システム全体でどの程度の性能(スループット)が出るかは、インターコネクトが大きく影響します。
なのでFLOPSだけ見てGPUが地球シミュレーターの性能を超えたとかいうのは、そうゆう見方もありだとは思いますがナンセンスだと思いますし、用途がまるっきりちがいます。

さてちょっと脱線しましたが、今回のPonanzaのインターコネクトは1Gイーサです。(これしかなかった)
おまけにスイッチがぼろPower Connectだったため、バッファ溢れが心配でラージパケットも使いませんでした。
実際は1Gの通信で間に収まるように調整して使ってもらいました。

ではHPCクラスタにおいてのインフラ屋の仕事がサーバを積んでインターコネクトで接続して終わりかというとそうではありません。
決して終わりではありません。

大事なことだから二度いいました。

インターコネクトから入ってくる通信を、適切にアプリケーションに渡して処理してもらうまでがインフラ屋の仕事です。
つまり、インターコネクトから先(手前)のNICやドライバ、カーネル、ソケットの処理にボトルネックがあり通信を取りこぼしてしまったら、いくらインターコネクトが早くてもシステムのスループットは上がりません。
また高速なインターコネクトを使うほど、通信の処理量が増えるため取りこぼしが増えやすいです。
インフラ屋はソフトウェアエンジニアには見えない通信の部分のボトルネックを特定し、改善する必要があります。

今回のPonanzaクラスタは1Gということもあり、NICやドライバ、カーネル廻りがボトルネックになることはありませんでした。(もちろんある程度チューニングは事前に実施済み)
唯一カーネルからアプリケーションのユーザソケットに渡す部分がボトルネックになりパケットの取りこぼしが大量に発生したため、スレッド数を増やして対応してもらいました。
これにより20%~30%くらい?スループットが向上しました。

常にシステムのどこがボトルネックになるかということを意識して調べると自然と身につくと思います。(ドヤ)

またちょっと別の話になりますが、今回のPonanzaクラスタは東京と石狩の2か所の拠点で構成されています。
当初はこの拠点間を1Gbpsで通信したいという要件がありました。
東京と石狩は距離がありますが、1Gbpsで通信することは可能です。
ここは単純に通信のスループットとレイテンシの話になりますが、土管が1Gbpsでレイテンシが20msくらいなので、1Gbpsのデータが20msかかって届くという考えになります。

具体的には送信側は1秒間に130Mbyteを何も考えずに送りつづけます、受信側は受信し続ければ実現可能です。
結局この話はなくなりましたが、当初はきっちり1G使い切るTCPチューニングを考えていました。
一般的なTCPの輻輳制御アルゴリズムは衛星離島も含む広域の通信に特化しているため、安定性を優先してスループットを犠牲にしています。
雑な図をかいてみました。

この輻輳制御によって効率的に安定して通信できるわけですが、通信品質がよく安定している相手であれば、輻輳制御そのものは必要ありません。
むしろスロースタートなど輻輳制御機構によってスループットが低下します。
きっちり1Gbps使える回線という前提で、1Gbpsのウィンドウサイズで常に通信するというチューニングができます。

今回の大会に向けて実際どこをどうチューニングしたかまで書くと長くなるので、とりあえず今回はこの辺で。
気が向いたらふわっと書きます。

というわけで将棋クラスタの方々がここを見るかわかりませんが、個人的な今回の意気込みは。
技巧がAWSつかってるから、オンプレ職人の手によるチューニングの恐ろしさをみせてやるぜ!」って感じだったけど、異次元から差し込まれましたねw

来年もぜひとも挑戦したいと思います。
コンピュータ将棋でインフラエンジニアが必要な時代になったんですねえ…。

インフラ屋がシングルモードファイバを扱うときに知っておくといいこと

東京はだいぶ暖かくなりましたね。
ぼちぼち試される大地で試用される期間も3か月が過ぎ、春の到来とともに終了を迎え全力モードです。
(普通に東京勤務ですけど)

前回のWDMネタでもさらっと書きましたが、建屋間の接続は距離が長く、マルチモードファイバ(MMF)での接続は伝送損失が多すぎて不向きです。
必然的にシングルモードファイバ(SMF)になりますが、自分は今までSMFを扱った経験はベンダに言われた通りの構成で購入して、電話しながら言われた通りに接続したことしかありませんでした。
今回は自社の設備 + 自分が設計をする必要があったため、構成への不安と知識不足を感じて軽く学習しなおしました。
(物理的につなげるためだけにコネクタの形状と芯のサイズくらいしか調べた事がなかった)

SMFはMMFより扱いが難しかったり、種類が多かったり複雑ですが、要点さえ押さえてしまえばMMFとさほど変わりません。
ずらずらと書いていくのでさくっと覚えて帰って(?)いただければと思います。
※初心者のチラ裏なので間違ってるかもしれません!

出力されるレーザーは不可視で高出力
まずは安全性にかかわる重要なことです。
初期の通信用ファイバで利用されていた波長は可視光帯が利用されていました。
今でもその印象を漠然と持っている方もいると思いますが、可視光での通信は伝送損失が大きすぎるため、現在では通信用には使われていません。
波長の特性や利便性から可視光より波長が長い赤外線が利用されています。
日暮れに赤が遠くまで伝送されて夕焼けになるように、さらに長い波長の赤外線はより遠くに伝送されます。

赤外線は人間の目では見えないため、リンクアップしないからといってうっかりのぞき込むと高出力の赤外線レーザーにより眼に深刻なダメージを負うことがあります。
数百メートル~数キロのトランシーバはクラス1相当の出力が大半なため、人体に破壊的な影響を与えるものはほぼないと思いますが、扱いには気を付けましょう。
人に向けたりもしちゃだめですよ。

トランシーバモジュールの選び方
SMFで利用できる波長は技術改善により徐々に拡張されてきました。
現在では1260nmから1625nmまでが定義されています。
それぞれ利用開始時期によりバンドとして区別されています。詳細はぐぐるとすぐ出てきます。
波長が長いほど遠くまで届きやすい性質を持ちますが、その分高性能なトランシーバが必要になり価格があがります。
価格と必要とされる伝送距離のバランスで適度なモジュールを選択します。

以下は具体的な例です。

今回の自分の要件はSMF OS2ファイバで300メートルの伝送でした。
一般的にOS2ファイバの伝送損失は0.2dBm/km ~ 0.4dBm/kmくらいです。
途中パッチパネルを三か所挟むので中継の損失を多めに見て1dBm x3とします。
パッチやファイバなどの損失量についてはメーカーのカタログにのっています。

ここまでで予想される伝送損失は全体で-3.2dBm程度ですので、出力から受信まで3.2dBm減衰しても300メートル届くトランシーバモジュールを選定します。
見やすいのでJuniperのサイトから引用させてもらいます。

比較するとMMF ~300m、SMF 10km~ という自分でサンプルに選んでおいて微妙なラインナップですが、EX-XFP-10GE-LRが適正です。
スペックシートの中から重要な項目をいくつか抜き出します。

Fiber count Dual 2芯(Tx/Rx)
Transmitter wavelength 1310 nm Oバンド
Minimum launch power –8.2 dBm 動的な最低出力
Maximum launch power 1 dBm 動的な最大出力
Minimum receiver sensitivity –18 dBm 最低受信レベル
Maximum input power 0.5 dBm 最高受信レベル
Distance 10 km 最大伝送距離

このスペックシートにどう-3.2dBmを反映させるかがキモです。
赤外線の受光素子は人間の目と同様に明るすぎる光は受信できません。
最悪の場合は受光素子が壊れます。
例えるなら人の目で太陽を直視するようなものだとおもってみてください。

近年のトランシーバはこのような一方的な高出力に対して対策がされており、出力側が動的にレーザーの出力を調整します。
スペックシートを見るとわかると思いますが、最大受信可能レベルが0.5dBmに対して、最低出力が-8.2dBmとなっいます。
同一のメーカーであれば、ほぼ送信側の最低出力が受信側の最高出力をうわまらないよう設計されています。
※仮にレーザーが強すぎる場合は、アッテネータという減衰機を利用することでレベルを減衰させることができます。(トランシーバが壊れたら手遅れですが…)

今回の場合だと、出力側の-8.2dBm ~ 1dBm から 3.2dBmを引いたレベルが、受信側の-18dBm ~ 0.5dBmの範囲に収まっているので、トランシーバー間のネゴシエーションによって適切なレベルに調整され、通信できるということになります。

SMFは劣化する
SMFは主な材質として石英が使われています。
時間とともに石英ガラス中の欠陥と、ファイバの被覆等から発生する水素が反応しOH基となります。
このOH基が赤外線を吸収する特性により伝存損失が発生します。
影響される波長は場合により様々ですが、SMFで利用しているバンドは広範囲で多からず少なからず影響を受けます。
特に影響を受けるのが、Eバンド帯の1360nm ~ 1460nmです。

しかし近年ではファイバの技術革新により、水素による伝送損失の影響はほぼないと言っていいレベルまで低減されています。
ただ予想される伝送損失がシビアな場合だと、使ってる最中に僅かなながらでも経年劣化で最低受信強度を下回ってしまうかもしれません。
また古いファイバの場合、世代的に水素劣化への耐性の低いものが使われていたりするかもしれません。

またこの水素劣化の影響は波長ごとに異なるため、実際に使用する波長に対応したパワーメーター(テスター)を用意しないと、問題が発生していることが分かりません。

余談ですが赤外線が吸収や反射される特性が、赤外線分光法という解析方法に利用されています。

パワーメーターを用意する
上記でもさらっと書きましたが、トランシーバを接続したNW機器でもレベルを取得できますが、あくまでファイバーとトランシーバで利用している状態のレベルです。
ファイバ単体で特定の波長での終端同士の純粋な減衰率を計測するためにパワーメーターがあるといいでしょう。

まあ軽くまとめると。

・利用する波長の特性を理解する
・しっかり減衰率を計算する&実際に計測する
・SMFは高価なため距離が長い場合は多重化の検討を

うわ超てきとー!

40Gの延伸が案外面倒だったのとWDMが神がかってた

明けましておめでとうございます(遅
本年も糞ブログをものすごく細々と書いていこうと思ってはいます。

いきなり記事の話題が飛びますが、いろいろあって去年の12月でSEをやめました。
1月から試される大地が主戦場なインフラ屋(?)として働いてます。
雪もいっぱいあるし、食べ物もナチュラルにおいしいし、ラリー屋には最高です。
なのでいきなりこうゆうネタふりです。

さて、試される大地で自分が主に利用しているデータセンタは自社運営のため、割と自由に使うことができます。
ただし自社とはいえファシリティ的には物理的な制約は当然あり、好きに壁に穴をあけたり地面を掘ったりできないので、なにかやろうとしたら既存設備や機器の仕様を考慮しつつ、関係各部署との調整が必要になります。

サービスとして利用しているデータセンタのように、依頼したら頼んだものが出てくるとか、サービスメニューにないから無理とかはありません。
その分データセンタの通常運用から外れる部分や仕様が確定していない事項に関しては、上記問題をクリアしてなんとかする必要があります。

そしてまだ入社後間もないですが、担当しているサービスの需要を見越して、増床したスペースに新規でサーバのためのネットワークを引き回すことになりました。

使用するインターフェイスはQSFP+が4本だけですが、さすがは北の大地の平原に建つデータセンタだけあって、距離にして2次元のどんぶり勘定だけで200メートルを超えています。
QSFP+は名前の通りで10GのSFP+を4本束にしてパラレルに通信できるようにしたものです。
つまり4本(QSFP+) x4(SFP+) x2(2芯)となり、実は32本もファイバーを消費します。
200メートル x 32本なので合計6400メートルです。
6キロもファイバー買ったらエラいコストです。
地区戦のラリーだとちょうどいいSSの距離くらいですね。

またエンドトゥエンドで一本のケーブルを引くわけではなく、途中でパッチパネルを挟むので、構築もエラい手間がかかる上にオペミスも誘発しますし、減衰とQSFP+のパラレル通信によるエラーも心配です。

軽く図で書きます。

40gsfpp
まあまあ、ありえないですね。
40Gでも近場だと一本のケーブルとして意識せず使えますが、距離があくとこうなっちゃいます。

当然のごとく同じ問題を抱えている人は全世界にいるので対策もあり、光の波長を変換して少ない本数のファイバーで多重に送信するWDMを利用したり、40Gを2芯のファイバーで利用できるトランシーバーがあります。
なんと1芯で双方向通信をしつつ多重化できるWDMも存在します。(両方から青と赤に分けて照射するらしい)

あとは既存の設備(シングルなのかマルチなのか、パッチのつなぎとか距離など)で何等かの手段で多重化すれば本数が減ってすっきりして問題は解決します。

と、ここまでは現在自分の目の前にある問題ですが、これ以外の用途でもWDMさんは有能です。

光伝送装置自体は以前から存在は知っていたんですが、DC内のみの取り回ししか経験したことがなかったため、実は何に使うのかはよくわかっていませんでした。(おぃぃ)
100Gの伝送装置をDC内の他のテナントが利用しているのを見かけたこともありましたが、つなげるために必要なONUくらいのノリでなんでこんなごっついのが必要なのか深く考えた事がありませんでした。(長らくスループットよりかレイテンシ厨だったので…)

大体WDMの役割としては以下の感じでしょうか。

  • 1本のファイバーに通す波長を多重化してスループットを向上させる
  • 複数組み合わせると拠点間なんちゃってインテリジェントL2スイッチみたいに使える、常に1対1である必要はない

たとえば既設の10Gを40Gにしようとおもった場合、10Gを追加で3本敷設できないとなった場合、波長を多重化することによって既存のファイバーを利用してそのまま40Gを流すことができます。
使用例はこれだけではなく既設の設備の入り口と出口にWMDをつけるだけで倍以上のトラフィックが流せるので、バックボーンからDCやサーバルーム間まであらゆる場面で使えると思います。

データセンタが古く芯数や設備の問題で増速ができない、とお悩みの場合はぜひ波長の多重化を検討してみてください。
今は安くていいものがそこそこあるそうです。(噂話だけ聞いたのでこれから調べる)

ただレイテンシ厨としては変調がある分若干遅くなるのかな?という考えは残ります。

今までせいぜい10Gまでしか使ったことなかったし、ラック間までしかつないだことなかったしまじ北の大地鬼畜。

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

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

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

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

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

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

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

 

ウェブ広告のインフラについて(第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で見る総量はあまり減りませんが、確実に効果はあります。

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