読者です 読者をやめる 読者になる 読者になる

SANMAN

思いつきの考えを垂れ流すブログ

Microsoft BingのFPGAアクセラレーションについて学ぶ 1

FPGA

MicrosoftのBingをFPGAで高速化した件についての話。
FPGAで処理をしたことよりも、FPGA間ネットワークをイーサネットとは別に用意するシステムアーキテクチャとその運用に注目すべき。
ホモジニアスでありながら高いアクセラレーション効果を得られるように、とても良い設計&使い方をしている。

なお、FPGAを使ったハードウェアアクセラレーション自体はいわゆるスパコンの分野(HPC)等で結構チャレンジ(海外ばかりだが)されてきていて、さして新しいアプローチではない。

最初のアプローチ、集中化

Microsoftはまずサーバーのアクセラレータとして最高のものを作ろうとした。 XilinxFPGA Spartan6を1個とVertex6を6個使い、PCIeにてホストCPUと接続されたアクセラレータ「BFB Board」。なおSpartan6はPCIe接続(PLXのPCIeチップ)とVertex6群(アクセラレーション用)とのホストFPGAとして使われているようで、論文中などではアクセラレーションリソースとしてカウントされていなかった。 最高のアクセラレータをホストCPUへ繋ぐのはハードウェアアクセラレーションのアプローチとしてはきわめて普通で、これまでにも実施されてきたから「とりあえずやってみっか」と深く考えずに作ったのだろう。 プロトタイプの実際のFPGA接続関係は不明だがFPGA間はAuroraなどのシリアルインターフェースで双方向通信可能としていると思う。 6FPGAパイプライン構成だとこんなイメージだ。

f:id:tkysktmt:20141213130609p:plain

1カードが高価となるため全サーバーには搭載せず、他サーバー群が接続されているメッシュネットワーク上に接続するという使い方をMicrosoftは想定したそうだ。

しかしながら、Microsoftのやりたいことに対してこのアプローチには以下の問題がある。

・搭載FPGA数による制限
6FPGAで収まらないアプリケーションへの対応の問題。FPGAアクセラレーション可能な他サーバーを用意すれば6FPGA以上の構成は可能だが、イーサネット経由となるためこのFPGA間通信がボトルネックとなってしまう。

FPGA搭載数の制限
PCIeの電力供給は25Wである。仮にFPGA数が増えると必要な電力が増えるため、専用電源の設計(+熱設計も)が求められる。

・物理スペース制限
写真を見れば分かるようにPCIカードサイズ基板に6個以上を載せるのが困難。

f:id:tkysktmt:20141213162802p:plain

Vertex6 SX315Tのパッケージサイズは35mm角or42.5mm角+周辺回路なためPCIeカードサイズにたくさんのFPGAを収めるには小パッケージFPGAの高性能化に期待するしかない。

物理スペースの制約を外すとなると、専用のアクセラレーションサーバーとしてのラックを含めた新規設計が求められる。

・単一障害点となる
アクセラレーションサーバーに障害が発生すると、それを使う他サーバーのサービスが停止する。回避するには全サーバーにアクセラレータを搭載するか、アクセラレーションサーバー停止時はソフトウェア処理でとりあえずサービスを提供するなどがある。

・基板製造難度
歩留まり。基本的に部品点数が多い複雑な基板は製造が難しくなる。1基板あたりに発生する不良部品の遭遇率や、製造過程での不良発生率は単純な基板より高い。1つあたりの価格は非常に高価なので、不良品発生による損失はバカにできない。修理すると言ってもBGAなど簡単に付け替えたりできない部品も多い。

次のアプローチ、分散化

集中化アプローチの問題から、Microsoftのケースでは分散化が適していると判断。
レイテンシよりも、スループットの改善と耐障害性を重視しているため分散化はコスト面で期待できる。
プロトタイプでの経験も踏まえ、以下の様な要件を満たすように設計された。

・1サーバーの上昇コストは30%に収める
全サーバーに搭載するため1カードあたりが低コストである必要がある。

・1サーバーの消費電力増加は10%に収める
全サーバーに搭載するため1カードあたりの消費電力の考慮する必要がある。

・ハードウェアアクセラレータはPCIeの供給電力25W以内で動作すること
どうしても専用電源を用意する必要があるならコストをかけて集中化したほうがいい。

・現状のサーバー動作に影響を与えない
アクセラレータの搭載にあたって必要な変更は無い方が望ましい。

・サーバーネットワークの変更の必要がないこと
イーサネットの接続構成を変更する=データセンターの再設計は大変。

・既存システムより故障率を上昇させないこと
システム稼働率の低下や全体パフォーマンスが下がるような施策は無意味。

基本的に低コスト志向になった。 FPGAXilinxからAlteraになったのはよくわからん大人の事情か、Xilinxの開発ツールが使いにくいからかなんなのかは不明。 ホストCPUに温められるのもあって68℃に達するため、高温条件下に強いインダストリアルグレード品を採用。基板は16層になったそうだ。

分散化アプローチ1回目

単純に分けた。
またもやよく考えずに「とりあえず分散化してみた」って感じだ。 1サーバに1FPGAがPCIe接続されて、ラック内のサーバ間通信のためTORスイッチという装置を置いた。

f:id:tkysktmt:20141213150544p:plain

確かに分散化されてFPGAパイプライン構成の柔軟性はよくなったが、この構成ではパイプラインのためのFPGA間通信=TOR経由=CPU経由であるためFPGAの処理速度に対しFPGA間通信が遅いという状況が考えられる。どうしてもCPUを経由するため、そこがボトルネックとなりFPGAの持つ性能を活かしきれない。

分散化アプローチ2回目

TORによるサーバーネットワークとは別に、FPGA間をシリアルインターフェースで直接続してFPGAパイプラインを構成できるようにしたCatapult基板が作られた。

1FPGAはホストCPUとPCIe3.0x8で接続され、さらに他の4FPGAとSL3(Serial Lite III)で接続されている。SL3は2GB/sの双方向通信でSFF-8080 SASポートにアサイン。リング状に改造したSASケーブルで物理的に接続される。

Microsoftは1段に2サーバー挿せる24段のラックを使用しており、この計48サーバーをシステムのひとつの単位として「pod」と呼んでいる。pod間はイーサネットで接続される。 1podにある48FPGAは、6FPGAからなるトーラス状ネットワークと、別の6FPGAトーラスと接続して作る8FPGAトーラスを組み合わせたネットワーク構造を持つ。 48FPGAを障害FPGAを迂回可能なかたちで接続できれば良いので、トーラス中に含まれるFPGA数は適当に決めた思われる。(8x6でも良いし)

6x8トーラス構造と1podでの関係は以下のようになる。◯はFPGAで、赤色のラインが6FPGAトーラス緑色のラインが8FPGAトーラスとなる。実際の位置関係での8FPGAトーラス接続は全部書くとわけわかんなくなるので、1例だけにした。 見ればわかると思うが、6FPGAトーラス内で同位置関係にある他6FPGAトーラスのFPGAと繋いでいくだけだ。

f:id:tkysktmt:20141213130559p:plain

今回のデモンストレーションおよびテストでは34pod(1632FPGA)でのシステム構築。 1つあたりが単純化されたおかげか、組み上げ時に発覚した不良品発生率はCatapult基板7カード(0.4%)の不良FPGA通信3264Link(0.03%)がSASケーブルアセンブリ不良により発生した程度であり、組み上げ後数か月間の運用中に新たなハードウェア不良は出なかったとのこと。

FPGAパイプラインとそのマッピング

あるアプリケーションを、48FPGAに対してどのようにマッピングするかは重要な問題で、手作業では管理が大変。そこで、Microsoft「マッピングマネージャー」というツールを開発した。実際どういった理屈で動作するものかは今のところ不明。重要だと思うので当分は秘密のままだろう。

ハードウェア上、マッピングに強い制約は無いが、一筆書き出来るような配置が無駄のないものだろう。(通信経路のためだけのFPGAが無駄になる) Math、Physics、Comp.Vision、WebSarchの4つのアプリケーションアクセラレータをマップしたイメージは以下となる。

f:id:tkysktmt:20141213151941p:plain

図ではTORが消えているが、この例では利用されていないだけでシステム要素として存在する。構築したFPGAパイプラインに属するCPUは、どのCPUでもFPGAパイプラインに対しPCIeからアクセス可能である。CPU→PICe→FPGA(Local)→SL3→....→SL3→FPGA(パイプライン先頭)という感じだろう。1回目の分散化ようなサーバ間通信を利用しないため、FPGAパイプライングループ内のCPUはどれも高性能なアクセラレーション機能を利用できる。 ただし、FPGAパイプライングループ外のCPUは1回目の分散化と同じようなサーバ間通信でのアクセスとなる。

今回Microsoftは、デモンストレーションとしてBingサービスの一部を7+1FPGAに実装した。(1個は予備) 部分としてはRaaS部分後半ということだが、アムダールの法則のとおり重い処理をハードウェア化したのが実際だろう。

f:id:tkysktmt:20141213143455p:plain

FE→FFE→MLSの3つの処理からなるアプリケーションで、図では2つのサーバー(ホストCPU)がFPGAパイプラインにアクセスしている。スペアFPGAは平常時はデータを受けて渡すだけの機能を提供してパイプラインに組み込まれていると思われる。 各FPGAの内部リソース使用率と動作周波数は以下。

FPGA0 FPGA1 FPGA2 FPGA3 FPGA4 FPGA5 FPGA6 FPGA7
Logic使用(%) 74 86 86 20 47 47 48 10
RAM使用(%) 49 50 50 64 88 88 90 15
DSP使用(%) 12 29 29 0 0 0 1 0
動作周波数(MHz) 150 125 125 180 166 166 166 175

処理内容によってリソース使用率や動作周波数がまちまちなのは当然。 今回MicrosoftはFFE処理のために専用プロセッサを設計したので、FPGA1,2のDSP使用率が高いのはそのあらわれだ。 FPGA間通信がボトルネックとなるような1FPGA内での超効率化はあんまり意味なく、FPGA通信帯域を充分に使いかつ低周波数動作であることが電力効率が良い。

次回

長くなってきたので、ここで中断。 次回はMicrosoftFPGA内部に構築したアーキテクチャについて注目してみたり、GPGPUだったりと雑多な内容の予定。