Firebox WSC 2020 From USENIX FAST 2014

Firebox WSC 2020のUSENIX FAST 2014の講演
FireBox: A Hardware Building Block for 2020 Warehouse-Scale Computers | USENIX
コンピュータアーキテクチャの研究って、局所的に研究するのかと思っていたらここまで幅広く研究するのかと感心したのでメモ。
大まかに言って、以下の7つがポイントかな

プログラムの生産性　　　　　(=>サービス指向アーキテクチャへ)
最遅延応答　　　　　　　　　(=>耐障害性の概念の変化、とはいえレイテンシには課題あり)
メモリ階層　　　　　　　　　(=>フラッシュメモリが入る)
セキュリティ　　　　　　　　(=>データの暗号化、どこで暗号化するか)
スケールする技術の革新　　　(=>メッセージキューイングへ)
オープンソースハードウェア　(=>ハードウェア設計言語の革新)

WSCの3世代
- 第一世代(2000年以前)
  - 商用(COTS)サーバ、スイッチ、ラックで構成
- 第二世代(2010年まで)
  - 商用(COTS)チップで、サーバ、スイッチ、ラックを構成
- 第三世代(2020年以降)
  - カスタムチップで、サーバ、スイッチ、ラックを構成
- 水平モデルであるLinux/x86から、垂直統合モデル(OS/SoC)へ
- オープンソースモデルが、各世代ごとに影響を及ぼしている。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=4
話の概要
- WSCの傾向と挑戦
  - プログラムの生産性
  - 最遅延応答
  - メモリ階層
  - セキュリティ
  - スケールする技術の革新
  - オープンソースハードウェア
- FireBox
  - 1000ソケット、100PB NVM, 4Pb/sネットワーク
- DIABLO
  - WSCをどうやって、シミュレートするか?
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=5
本屋(BookStore)をSiloで構成した場合と、SOAで構成した場合(7ページと8ページ)
サービス指向アーキテクチャ(SOA)
- ソフトウェアは、すべてサービス指向で作られるべきである。
- データは、抽象化されるべきである。(メソッドでのみアクセス)
- ネットワークでのみ通信する。
- アプリケーションは、相互操作可能であるべきである。
- 内部APIを使わない。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=6
ソフトウェア開発プロジェクトの大小と開発方法
- 大規模プロジェクトになると失敗する確率が上がる。
- 大規模プロジェクトは、サービス指向アーキテクチャおよび多数の小さいサービスにより構成すべきである。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=9
CEO:Amazon shall use SOA!(2002)
- 2002年にAmazonは、SOAで処理することを決定している。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=10
耐障害性の考え方の変遷
- かつては、耐障害性を、コモでティで実現することが重要であった。
- 近年は、応答遅延も障害に含まれるようになった。このため、応答時間も制御できる必要がある。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=11
WSCの価格性能比目標
- 従来は、性能と平均消費電力において高い価格性能比を実現すること。
- 新しくは、上記の制限に加えて、Tail Toleranceを考慮して、価格性能比を実現すること
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=12
Tail Toleranceを実現する技術
- ソフトウェア技術
  - コンポーネント種類の削減
  - さまざまな処理への対応
- ハードウェア技術
  - 早いパケット処理技術
  - パケット処理技術のオーバヘッド削減
  - 各資源が分割可能(BW, cores, caches, memories)
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=13
メモリ階層
- 従来は、メモリ、HDD、テープだった。
- 現在は、メモリ、フラッシュ、HDDとなり、テープは無くなった。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=14
不揮発メモリ(NVM)
- かつての常識、2Dフラッシュメモリが革新を続ける。
- 新しい常識、2Dフラッシュメモリは、終焉を迎える。しかし、3dフラッシュや、新世代メモリでどうなるかわからない。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=15
新しいメモリの行方(16ページから19ページ)
セキュリティ
- 従来は、WSC内での暗号化は不要であった。
- 現在は、WSC内での脅威対策で暗号化は不可欠となりつつある。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=20
ムーアの法則
- かつては、18ヶ月ごとに半導体の世代が入れ替わるのが常識だったが、現在は、3年から5年へと半導体の世代の交代が減速している。2020年には、主な半導体技術は、停滞する。(NVMや3Dメモリで革新が継続するかもしれないが)
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=21
WSCのハードウェア設計
- かつては、安い商用チップでくみ上げる。
- これからは、SOAや応答性能を考慮に入れたカスタムシステムをくみ上げる。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=22
2020年に、カスタムチップは何故必要なのか
- トランジスタの革新は無くなり、その上の改善による革新しかない。
- 100億円で、WSCをくみ上げる必要がある。
- 良いニュース：CAD技術の革新が遅くなり回収期間が長くなる。そして、ツールが安価になる。
- 新しいハードウェア設計言語が始まっている。これにより、設計の低価格化が促進されている
  - Stanford Genesis2やUCBのChisel等
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=23
ARMとx86?
- 実際的な違いは、実装品質とチップ設計の自由度の違いの2点である。
- 単に、Intelの競合として祭り上げているだけなのかもしれない。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=24
命令セット(ISA)とは?
- コンピュータシステムで一番重要なインターフェース
- サードパーティのソフトウェア開発者は、業界標準が出来ることを望んでいる。
- オープンコンピューティングの将来に、プロプラな命令セット標準が必要なのか?
- x86やARM v8は、革新的なインターフェース設計を持っているのか?
- 命令セットはオープンな業界標準であるべきである!
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=25
Berkeley RISC-V ISA
- 完全に新しく作った命令セット
- 基本命令セットは、40の整数演算しかないが、ソフトウェアツールはそろっている。
- 拡張命令セットでは、浮動小数点演算等もそろっている。
- 8つの実装がすでにある。(64bit)
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=26
オープンソースとWSC
- 第一世代　WSCにより勃興
- 第二世代　OpenComputeやOpenFlow APIを勃興
- 第三世代　オープンソースチップが始まるか?
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=27
Fireboxの概要
- 1000個のSoCと広帯域メモリ(コア数は全部で100,000)
  - 1Tbit/secの光ファイバーでSoCとスイッチを接続
- 高radixツリースイッチ群
- 1000個のNVMメモリモジュール
  - 総計100PB
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=28
Fireboxの特徴
- 運用コストを下げるため1000ソケット以上を管理
- 直接大規模インメモリをサポート
- ソフトウェアを単純化するために、大規模帯域を提供
- 低遅延を実現するために、ソフトウェア/ネットワーク/NIC/プロセッサをメッセージキューイングで接続
- データは、ファイバー間およびストレージの中では、暗号化
- 上記機能は、SoC内で実現
- オープンソースHW生成ツールで、SoCのテンプレートを作れるようにした。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=29
光スイッチ
- モノリシックなWDMの光スイッチ
- 複数のradixが1000の光スイッチをClos上に配置
- 2KのエンドポイントをSoCかNVMのモジュールとして定義できる
- ボックス内では、2ホップですべての通信がいく。
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=30
ソケット間通信
- [古い常識]共有メモリは、大規模サーバでのプログラミングを簡単化した。
- [新しい常識]メッセージパッシングは、大規模サーバでのプログラミングを簡単化する。
  - メッセージパッシングは、キャッシュコヒーレンシな共有メモリより予測しやすい。
  - 故障条件をより説明しやすくなる。
  - プログラミング抽象化の単純化(以下を統一的に扱える)
    - WSC間のメッセージパッシング
    - WSC内のクラスター間メッセージパッシング
    - WSC内のクラスター内のノード間メッセージパッシング
  - サービス指向アーキテクチャ(SOA)により合っている。
- メッセージパッシングは、この議論での勝者である。(MPI, RPC, RDMA, TCP/IP)
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=31
Fireboxの10の問いかけ
- Tail toleranceを高利用時に実現する方法はあるか?
- ボックス内の通信は何が良いか?TCP/IPへのブリッジは?
- RPC用のAPIやABIはどうすべきか?命令かライブラリか?
- 仮想化の役割は?仮想ボックスか仮想サービスか?
- 暗号化はどこで行うべきか?SoC内かそれとも、メモリ近傍か?
- どれくらいの障害が発生し復旧するのか?(コア、キャッシュ、メモリやHW)
- どうやってセキュアに100PBのNVMストレージを管理するのか?
- 本試作(設計、構築)で共同研究したい機関はあるか?
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=35
Testbed(DIABLO1)のスケール(39ページと40ページ)
- SIGCOMMでの平均規模よりサーバ数で2桁、スイッチ数で一桁上の規模
DIABLOでの(memcachedを用いた)レイテンシー(41ページから43ページ)
- ほとんどの処理は100マイクロ秒で終了するが、一部100倍以上かかる。
- スイッチを増やすと、レイテンシーが分散する。
- かといって、1Gbから10Gbに変えても2倍程度しか改善しない。ソフトウェアスタックがボトルネックになっている。
- また、カーネルの版を上げると改善する。(Linux2.6.39.3 => 3.5.7)
Fireboxの結論
- Fireboxは、2020のWSCサーバである。
  - プログラミングの抽象化まで考慮している。
  - カスタムチップ、光ファイバー、半導体メモリ
  - スーパーコンピュータ
- 学術研究では、Fireboxはかなり野心的である。共同研究機関を募集中
  - https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf#page=45