1.
USENIX NDSI 2017報告
&
Efficient Memory Disaggregation with
Infiniswap (University of Michigan)
須崎有康
独立行政法人 産業技術総合研究所
第2回 システム系輪講会

2.
NSDI2017概要
• 14th USENIX Symposium on Networked Systems Design and
Implementation
• https://www.usenix.org/conference/nsdi17
• MARCH 27–29, 2017, BOSTON, MA
• 投稿数254本、採択46本、シングルセッション、キーノートなし。
• 主催者から発表された今年のNSDI論文で使われたキーワード
• Security、Data Center、Distributed Systems、Big Data
• Best Paper Award
• mOS: A Reusable Network stack for Flow Monitoring Middleboxes
(KAIST)
• Community Award
• Transparently Compress Hundreds of Petabytes of Image Files for a File-
Storage Service (Stanford)

3.
個人的な感想
• ネットワークがメインでない発表が多くあり、なぜNSDIで発
表するのかと思われるものが幾つかあった。
• セキュリティは全13セッション中、２セッションあり、セキュ
リティの関心の高い。
• 韓国からは4本の論文(KAIST 3本、漢陽大学校1本)が採択され
ており、存在感があった。特にKAISTはコンスタントに論文を
出している。
• SDN: Software Designed Networkに関する発表が多くあった。
• 他の会議では話題となっているzmapなどを使ったInternet全体
を対象にした調査がNSDIでは一つもなかったことが不思議

4.
Efficient Memory Disaggregation with
Infiniswap (University of Michigan)
• この論文に決めた理由

5.
Infiniswap の概要
• Motivation
• Memory Intensiveなアプリが多い。
• データセンターでのメモリ利用の偏り。
• RDMAを活用したDisaggregation Memory
• Challenge
• No application modification, Scalability, Fault-tolerance
• Swapの二重化(RDMA or DISK)
• Control Plane (各マシンのdeamon)とData Plane (RDMA)の分離。
• 4KB物理ページに対して(1GB) slabによる管理。
• decentralized slab placements and evictions.
• power of two random choice.

6.
Motivation 1
• Memory Intensive applicationが多いが、

7.
Motivation 1
• Memory Intensive applicationが多いが、

8.
Motivation 1
• アプリケーションによるMemory Over Estimationによる性能劣化

9.
Motivation 2 Memory Imbalance
• 30%は割り当てて使われない。これを利用できないか？

10.
Disaggregate Memoryのイメージ

11.
関連研究
• nbdではリモートのRAM Disk上に退避するためにCPUオーバー
ヘッドも大きい。

12.
System Overview
• Disk(非同期書き込み)とRDMA(同期書き込み)の併用
• Fault Tolerant の確保
• Control Plane(Daemon)とData Plane(RDMA)の分離
• Daemonが領域管理を行う。

13.
System Overview

14.
System Overview
• コンテナ単位？

15.
Slab構成

16.
Slab構成

17.
送り先の選択

18.
power of two random choices
• decentralized slab placements and evictionsの肝
• Michael Mitzenmacher, The Power of Two Choices in Randomized
Load Balancing, Ph.D Thesis, 2001.
• https://pdfs.semanticscholar.org/3885/812a092ff0aad3d45c0464660075e98d0231.pdf
• Michael Mitzenmacher, Andrea Richa, Ramesh Sitaraman,The Power
of Two Random Choices: A Survey of Techniques and Results, 1996.
• http://www.ic.unicamp.br/~celio/peer2peer/math/mitzenmacher-power-of-two.pdf
• Michael Mitzenmacher, The Power of Two Choices in Randomized
Load Balancing, IEEE Trans. Parallel and Distributed Systems, 2001.
• https://www.eecs.harvard.edu/~michaelm/postscripts/tpds2001.pdf

19.
パラメータ
• SlabSize=1GB
• HeadRoom=8GB
• Free Spaceの下限。これを超えるとSwap outする。
• HotSlab=20
• 一秒間のI/O Request数。不必要なslab Mappingを避ける。

20.
実装
• Linux 3.13.0 のSwapを改良。3,500 LOC。
• Loadable Moduleとして実装。
• ndbX for Mellanox https://github.com/accelio/NBDXを活用。
• Stackdb (Stacking a block device over another block device
https://github.com/OrenKishon/stackbd) を活用

21.
性能評価
• CloudLabのマシンを使う。
• InfiniSwap、通常のSwap(Disk)、nbdX on Mellanoxと比較。

22.
性能評価

23.
性能評価
• Disk
• nbdX
• Infiniswap

24.
Fault Tolerantのテスト
• VoltDB(75% memory)、SLABマシン６台のうち、1台を落とし
た場合の性能劣化。

25.
Discussion
• Application-aware Design
• アプリがremote memoryを認識(頻繁に使うHot Tableと使わないCold
Table)してプログラムしたほうが早い。
• 個人的なコメント：Linuxのmadvise()が使えないか？
• OS-Aware Design
• SwapベースにしているためContext Switchのオーバーヘッドが馬鹿に
ならない。

26.
個人的な疑問
• Remote-memoryを使うより、Memory IntensiveとCPU Intensive
のアプリを混在させるスケジューラを使ったほうが全体的に効率的
では？
• 1GB Slabにある4KB PageがランダムにSwap Inされたら効率的？
• 複数アプリの4KB Pageが1GB Slabに割り当てられるのか？
• この場合、swap inがアプリ毎に変わるが効率的？

27.
Conclusion
• ソースコードは発表時にはComing Soon でしたが、公開されて
います。
• https://github.com/Infiniswap/infiniswap
• 質疑応答
• 質問：Infiniswap はLinuxのSWAPを改良しているが、Huge
Pageは対応できるのか。たしか、LinuxのSWAPでは扱えない
はずだが。
• 回答：現在のInfiniswapでもHuge Pageは扱えない。Future
workだ。

28.
The Design, Implementation, and Deployment of a System to Transparently
Compress Hundreds of Petabytes of Image Files for a File-Storage Service (Dropbox,
Stanford University)
• Community Award Paper。JPEGファイルを保存するのにHuffman Codeから
parallelized arithmetic codeでスキャンし直して保存するファイルシステムの
Leptonの発表。圧縮率もCPU性能もよい。Lepton は2017年2月にDropBoxで
使われるようになっており、ソースコードも公開されている。
• PackJPG, MozJPG, JPEGreenなど類似に研究はあるが、JPEGの特徴を取り直
すためにHuffman Codeから別の圧縮方法でファイルシステムが対応するのは、
既存のフォーマットを残しつつシステム側で対応する新たな研究方向と思われ
る。
• また、Leptonの実装ではセキュリティを確保するのにLinuxのSECCOMを使っ
ている。また、C++のthreadで書かれているが、Deterministicを確保している
など、セキュリチィや再現性にまで言及しており、研究の質の高さを示してい
る。

29.
APUNet: Revitalizing GPU as Packet
Processing Accelerator (KAIST)
• パケット処理にGPUを使う研究(G-Opt[NSDI15])ではメモリコ
ピーの負荷がある。CPUと同じダイにあるIntegrated
GPU(AMD Accelerated Processing Unit)を使うことでアドレ
ス空間を共有し、効率的に処理するAPUNetの提案である。
APUNetはNetwork IDSにもAho-Corasickパターンマッチの高
速化に使えるとのことであった。
• GPUは普及するハードウェアであるが、メモリのコピーの課題
をAMDのAPUを使ってパケット処理と言うターゲットを絞って
活用するのは目の付け所がよい。

30.
One Key to Sign Them All Considered
Vulnerable: Evaluation of DNSSEC in the
Internet (Fraunhofer)
• 現在使われている210万個のDNSSECの鍵の脆弱性調査の発表。
190万個がRSA keyであり、このうち66％が1024bit以下。また、
共通のモジュラスや素数も見つかっている。
• モジュラスが共通だとCommon Modulus Attackが可能となる。
• この発表がインターネット全体を調査した唯一のものであった。
他の一流会議では2,3本あるのに対して、ネットワークが主眼な
会議にしては少ない。

31.
Enhancing Security and Privacy of Tor's
Ecosystem by Using Trusted Execution
Environments (KAIST)
• Torではリレーノードが改ざんされてプライバシーが守れなく
なる脆弱性がある。Intel SGXを使い、TEE: Trusted Execution
Environmentによる安全なリレーノード検出し、それらのみを
使うSGX-Torの提案。Remote Attestationで検証し、承認され
たRelayのみを使う。SGX-Tor の実装ではEnclave中にSSL
Library(OpenSSL), zlib, libevnetが含まれる。
• 性能劣化は11.9％。
• SGX-Torのソースコード
• https://github.com/KAIST-INA/SGX-Tor

32.
Opaque: An Oblivious and Encrypted
Distributed Analytics Platform, (UCB)
• SQLの処理に Hardware enclave(Intel SGX, AMD memory
encryption)を使ってもAccess pattern leakageがある。アクセ
スパターンを隠すoblivious relational operatorsを加えたSpark
SQLのOpaqueの提案である。
• OpaqueのHP。ソースコードあり
• https://github.com/ucbrise/opaque

33.
Bringing IoT to Sports Analytics, (University
of Illinois at Urbana–Champaign)
• 現在のスポーツ解説はハイスピードカメラを使って軌跡を追う
ことができるが、機材が高い。この問題を解決するために、ク
リケットのボールの中に加速度計、ジャイロ、磁力計、WiFiを
入れて軌跡を追うiballの発表。位置検出は複数のWiFiインフラ
を使う。
• 位置検出にGPSではなく、WiFiによるものが興味深い。また、
フリーフォールでは加速度計は０になるので活用できなくなる
問題あり。

34.
Clipper: A Low-Latency Online Prediction
Serving System (USB)
• 現在のMachine LearningはGoogle TensorFlowのように専用の
ハードウェアを使って性能向上を図っているが、このような専
用化は変更が難しい。汎用にする技術ためにLayered
Architectureを採用したClipperの提案。Spark, Tensor Flow,
Caffeのエンジンが抽象化されるModel Abstraction Layer とそ
れを活用するアプリを抽象化したModel selection layerで構成
される。Model Abstraction Layerは複数のエンジンを配下に置
くことができる。
• Clipperのソースは一か月後に公開されるそうだ。現在公開済み。
• https://github.com/ucbrise/clipper

35.
Gaia: Geo-Distributed Machine Learning
Approaching LAN Speeds (CMU, ETH)
• 世界中に散らばったデータセンタをMachine Learningで使える
ようにするGeo-distributed ML systemのGaiaの提案。
Parameter serverで各データセンタを調整する。レイテンシを
隠すためにデータ転送、同期などの工夫し、LANに近い性能を
達成。