USENIX NSDI17 Memory Disaggregation
•
1 like•808 views
第2回 システム系輪講会での報告 https://connpass.com/event/52323/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to USENIX NSDI17 Memory Disaggregation
Similar to USENIX NSDI17 Memory Disaggregation (20)
More from Kuniyasu Suzaki
More from Kuniyasu Suzaki (20)
Recently uploaded
Recently uploaded (16)
USENIX NSDI17 Memory Disaggregation
- 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%は割り当てて使われない。これを利用できないか？
- 12. System Overview • Disk(非同期書き込み)とRDMA(同期書き込み)の併用 • Fault Tolerant の確保 • Control Plane(Daemon)とData Plane(RDMA)の分離 • Daemonが領域管理を行う。
- 13. 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に近い性能を 達成。