期待のネット新技術

低いコストとレイテンシーでHPC向けの分散型構成に活路を見出す

【InfiniBandの現在】

 「InfiniBandの現在」では、規格としての歴史と現状、今後の動向をまとめて紹介している。大半の読者にとっては「InfiniBandって何?」というところだろうが、僚誌クラウドWatchをご覧になっておられる読者の中には「何で今さら」という方も居られるかもしれない。

 そう、InfiniBandという規格は、1999年に作業が始まり、2000年に最初の規格策定が行われたという「えらく古い」規格なのである。

「InfiniBandの現在」記事一覧

規格がオープンのInfiniBand、IntelがHPC向けに活路

 ということで、サーバー向けバックボーンという梯子を外されてしまったInfiniBandだが、そのIntel自身がまだInfiniBandそのものを捨てなかったのはちょっと興味深い。

 捨てなかった、とはいっても自社でのハードウェア製造は完全に放棄したわけだが、InfiniBandは規格がオープンであるが故に、複数のエコシステムパートナーがハードウェア製造を手掛けており、Intelはこうしたパートナーと組んでシステムを提供するという姿勢を見せた。

 1993年11月にオレゴン州ポートランドで開催されたSC(Supercomputing Conference)93で、Intelはパートナーと組み、192プロセッサ構成のHPC向けマシンのデモを行っている。HPCは以前ならHPCC(High Performance Computing Cluster)とされていたが、Clusterがごく一般的になったためか、最近はこれを省いたHigh Performance Computingと呼ぶ方が多いが、これは、複数のマシンを束ねて処理を行う、いわゆる大規模分散型のシステムである。

デモでは、64プロセッサのラックと128プロセッサのラックの間を、MelanoxのL1スイッチ「MTS2400」と、VoltaireのL2スイッチ「ISR9600」で繋ぐ構成。2ソケットのXeon DP Workstationには、MelalnoxのHCAが搭載されていた。出典はMellanoxの"Intel Architecture Based InfiniBand Cluster"(PDF)

分散型構成ではms単位の遅延が問題に

 クラウドの出現で変わってきたものの、HPCの最初の時期は科学技術計算が主体だった。ただ、この点はInfiniBandとはあまり関係がない。分散型システムと言っても、実際にはさまざまな形態があるが、InfiniBandで当初想定していたのは、以下の図1のよう使い方である。この場合、処理1~4を順次行うかたちになるが、このうち作業負荷が大きく、その一方で分割しやすいものが処理2と処理4だとする。その際に、処理負荷が大きい2・4のみ他のマシンも使って処理を分割すれば、トータルでの処理時間が減る可能性が高い。

 この例で言えば、まず処理1で処理2に必要なパラメーターなどを計算し、その結果をマシン1からマシン2・3に送り出して3台で並列処理を行う。それぞれの処理が終わったら、その結果をマシン1に返して処理3で後処理を行い、その結果をもとに、再び処理4を分散して行う、という具合だ。

 このケースでは、特にマシンの数が膨大になってくると、馬鹿にならないのがマシン1~3の通信に要する時間である。こうしたケースでEthernetとTCP/IPを用いると、例えば処理2の完了の際に、データ受信において以下のような面倒な処理が発生する。

  • (マシン2)処理2完了→データをまとめる→TCPフレームを作る→IPアドレスの解決を行ってヘッダーに付加する→Ethernetのパケットを作る→Ethernet経由で送り出す
  • (L2スイッチ)Ethernetパケットを受け取る→宛先を確認してパケットを送り出す
  • (マシン1)Ethernetのパケットを受け取り、TCP/IPのパケットを取り出す→TCPパケットからデータを取り出す→処理3へ

 おまけに、L2スイッチ以外の全ての処理は、マシン1なりマシン2のCPUが行っている。比喩ではなく、何も考えずにTCP/IPのSocketプログラミングでこれを実装すると、ms単位と、かなりの時間が掛かる。

 このms単位というのは、コンピューターの世界で言えば“物凄く長い”時間で、せっかく処理速度を向上させるために分散型の構成を取っても、性能が向上した分が通信時間の増加で相殺されかねない。厄介なのは、この通信時間(要するにレイテンシーで、最初にデータをマシン2上のプログラムが送り始めようとしてから、それをマシン1上のプログラムが受け取り始めるまでの時間)は、速度を引き上げても解決しないことだ。

他のインターコネクトと比べ、低いコストとレイテンシーを実現

 Ethernetは基本的にスループット、つまり単位時間あたりの転送速度を引き上げる方向でどんどん高速化が進んでいる。この当時なら1000BASE-Tの普及期にあたり、1Gbpsの転送速度が非常に安価に利用可能になっていた。一方、サーバー間の接続には10GbEが少しづつ登場し始めていた。2002年にIEEE 802.11aeの標準化が完了し、データセンター内のサーバー間接続には、10GBASE-SR/10GBASE-LR/10GBASE-ER/10GBASE-LX4といった光ファイバーを利用した接続が可能となっていた。

 ただし、どの規格も主眼はスループットを引き上げることであって、レイテンシーを引き下げることを目標とした規格は存在していない。現実問題として、最もレイテンシーが少ないのは10GBASE-SR/10GBASE-LRか、もしくは10GBASE-LX4であるが、これらもプロトコルなどでレイテンシーを減らしたというわけではなく、ハードウェアが一番シンプルで余分な処理が入らない、というだけの理由に過ぎない(64b/66bエンコードの10GBASE-SR/10GBASE-LRと、8b/10bエンコード+4:1のMUXが入る10GBASE-LX4のどちらがレイテンシーが少ないかは微妙なところだ)。

 実際には、このようなms単位でのレイテンシーがあれば使い物にはならない。なので、HPCの構成には当然別の手段が必要となる。長らくこの分野で使われていたのが米QuadricsのQsNetで、元は英Meiko Scientificという会社が開発したスーパーコンピューター向けのインターコネクトである「Elan-Elite」というネットワークがあり、これを改称した「QsNet I」と、その改良型の「QsNet II」が1990年台前半から広く利用されていた。QSNet IIの場合、実測データで912MB/secというスループットと、1.26μsというレイテンシーを記録している[*1]

[*1]……ただ、これはLow Levelレイテンシーの話で、大規模なHPC構成となればずっと増える

 同社は、さらにスループットを引き上げた「QsNet III」を開発して2009年に投入する予定だったが、その前に破綻している。他にも米Myricom(同社は2013年にCSPに買収され、そのCSPは2016年にGoogleに買収された)の「Myrinet」や、米Giganet(同社は2000年にEmulexに買収された)の「Giganet」、米Dolphin Interconnect Solutionsの「SCI(Scalable Coherent Interface)」、米Tandem Computer(その後Compaqに買収され、現在はHPEの一部)の「ServerNet」など、さまざまな独自のインターコネクトが提供されていた。

 ただ、いずれもかなりコストが高く、その割に性能が低い(レイテンシーはともかくとして、スループットが十分ではない、という話がしばしば挙がっていた)という問題を抱えていた。特に、きちんと予算が付いた大規模なHPCシステムはともかく、研究用に小規模なHPCシステムを作ろうとしても、このインターコネクト周りの価格が高すぎてシステムが組めない、といった話もあった。

 そのため、通常のEthernetのハードウェアを使いつつも、TCP/IPは通さず、MPI専用にするといった使い方をするところも出てきた(ただし、そのためにはメーカーの提供する標準デバイスドライバーが使えず、ユーザー自身がドライバーを書く作業を強いられることになったようだ)。

 InfiniBandが商機を見出したのは、まさにこうしたマーケットである。こちらに、Mellanoxが2003年の段階で、InfiniBandと、MyrinetやQuadrics(おそらくQsNet II)、それとEthernetを比較した表がある。

 これを見ると、InfiniBandは競合製品と比較して同等以上のスループットと同等以下のレイテンシー、低いCPU負荷などを実現しながらも、相対的に低コストであるとされている。この実現には、早くからMPI対応を進めていたことと、RDMAの存在がカギとなった。

「InfiniBandの現在」記事一覧

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/