SatchanPお酒ばっかり飲んで過ごした連休もいよいよ終わりです。(これ書き始めたのが連休中)まともな休みになった連休は数年ぶりな気もします。Chainerという将棋ソフトのインフラ構築をやることになりました。長いので以下Ponanza。結果からいうと優勝目標で二位という結果でした。将棋のいろいろ恐ろしいものの片りんを味わった気がします。ちなみに自分は大会の3日前にハム将棋を初めて、当初は10枚堕ちでボロ負けしてたのが、当日にはハンデありで互角に戦えるくらいにはなりました。(しょぼ)今回のインフラ構築作業をするまでは自分の中でコンピュータ将棋というと、スペックのいいパソコンを1、2台会場にもっていってスタンドアロンで動かすという印象があったため、最初は「なんぞ?」と思いつつ着手しました。実際Ponanzaも手を付けるまでは数台の規模でしたし、最初はノートパソコンで動いてたとか?他の仕事も忙しかったのでながら作業となりましたが、作業を進める中で山本さんとの会話でコンピュートリソースの殴り合いが始まり数個のプロセッサでは勝つのが難しい状況になっていることを知り、社内で余剰のサーバや部材をかき集めてPonanzaクラスタを動かすことが目的ということをしりました。Ponanza用の計算クラスタということは言い換えれば自作のスパコンです。結果的にPonanzaのためのHPCのインフラを社内からかき集め、限られたリソースで最大限パフォーマンスを発揮できる状態にすることが自分の仕事になりました。クラスタはただたくさん並べてつなげばいいというわけではありません。CPU1台でやっていた計算を複数台でやるわけですから、CPU間の通信が最大のボトルネックとなります。これをインターコネクトといいます。コンピュータ間で通信できればいい訳ですから、種類は様々でイーサネットやInfinibandや高度なシステムになると独自規格専用設計だったりします。このインターコネクトにはCPUへの命令やその結果、共有メモリなど大量の通信が流れます。昨今GPUによりFLOPS単体の性能は劇的に上がりましたが、あくまでも単体の性能の話でクラスタを構成する場合、システム全体でどの程度の性能(スループット)が出るかは、インターコネクトが大きく影響します。FLOPSだけ見てGPUが地球シミュレーターの性能を超えたとかいうのは、そうゆう見方もありだとは思いますがナンセンスだと思いますし、用途がまるっきりちがいます。脱線しましたが、今回のPonanzaのインターコネクトは1Gイーサです。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来年もぜひとも挑戦したいと思います。コンピュータ将棋でインフラエンジニアが必要な時代になったんですねえ...。コメントをキャンセルメールアドレスが公開されることはありません。*About:SatchanTwitter@SatchanPへっぽこインフラ屋ネットワーク、サーバ、言語問わず手広く浅く見てます。