次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション

Copyright©2018 NTT Corp. All Rights Reserved.
次世代の高速メモリストレージ利用に向けた
ソフトウェアのモダナイゼーション
2018年 7月 25日
NTT ソフトウェアイノベーションセンタ(SIC)
分散処理基盤技術プロジェクト
石崎晃朗

2
• オープンソースソフトウェア(OSS)を中心とした,
基盤ソフトウェア(OS・仮想化技術)に関する研究開発
• Linux, KVMなどがこれまでの主な活動領域
• 過去には, NTTグループ事業会社のクラウドサービス立上げに携わる
• 近年はデータストア系のOSSを中心として, 研究活動実施
• 2014年頃から, 次世代のメモリストレージ関連の動向に着目(本日お話する内容)
自己紹介

3
• ムーアの法則の終焉
• CPUへ過度に頼った現在のコンピューティングモデル
• CPUに依存しない新たなコンピューティングモデルの必要性
研究取り組み背景
現在のコンピューティングモデル
Memory
StorageNetwork
CPU
すべての処理にCPUが介在
Memory
StorageNetwork
CPU
FPGA GPU
Infiniband
(RDMA)
SCM
コンピューティングモデルの変更
特定の処理に特化した
ハードウェアを活用

4
メモリドリブンコンピューティングも着想は似ている

5
• DRAM並みの低遅延性
• HDD/SSDと同様の永続性
• メモリとしてアクセス可能
• SSDを上回る耐久性
• 「物理素子によっては」SSD並みの大容量性を持つ
ストレージクラスメモリ(SCM)
DRAM
SCM
SSD HDD
PCM ReRAM STT-MRAM
読出し遅延 60 ns 50 ns 100 ns 20 ns 25 μs 10 ms
書き込み遅延 60 ns 150 ns 100 ns 20 ns 300 μs 10 ms
永続性 × ○ ○ ○ ○ ○
アドレス指定方法 Byte Byte Byte Byte Block Block
書き込み回数上限 > 1016 1010 108 1015 105 > 1016
参照元: J. Arulraj, A. Pavlo, and S. R. Dulloor, "Let's Talk About Storage & Recovery Methods for Non-Volatile Memory Database
Systems," in Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data, 2015, pp. 707-722
Memory
StorageNetwork
CPU
SCM

6
AI/IoTなどの大規模データ分析の高度化
• 低遅延性を活かして高速化
• データ仲介役としての, Kafka等のメッセージ処理基盤
• データ蓄積役としての, RDBMS(特にOLTP)やKVSなどのデータストア製品
SCM導入が効果的なユースケース
AIIoT
分析精度向上即時性の向上
GW
センサデータ Apache Kafka
APサーバ
RDBMS等
分析者(定型)
分析者(試行錯誤)
●IoT基盤システムの構成例

7
• HPE Persistent Memory(NVDIMM-N)
• DRAM+SSDをDIMMモジュールに搭載. 通常時はDRAMで動作
• 電源断時には, 外部バッテリーからの給電を利用して
DRAMからSSDへデータ退避
• HPE Scalable Persisitent Memory
• NVDIMMと同等機能をサーバ筐体内の
DRAM+PCIeSSD+バッテリーで実現
• Intel Optane DC Persistent Memory
• SCMに分類される不揮発メモリ製品
SCMの製品化動向
画像引用元:
https://community.hpe.com/t5/Behind-the-scenes-Labs/How-HPE-Persistent-Memory-Furthers-Our-Vision-of-Memory-Driven/ba-p/6994205#.Wx-uEIouDmE
https://store.hp.com/us/en/pdp/hp-proliant-dl380-g10-2u-rack-server-2-x-intel-xeon-gold-6132-tetradeca-core-(14-core)-260-ghz-64-gb-installed-ddr4-sdram
https://newsroom.intel.com/?attachment_id=80258
早期にサーバ側のサポートを含めて利用可能な製品であったため, 2016年から利用

8
• SCMの効果的な利用のための機能
• SCM利用のための機能に関して「単純適用」
• SCMの性能を引き出す「新たなソフトウェア実装」
本日ご紹介する内容
無意識に常識として行っていた実装方法からの脱却
⇒ ソフトウェアのモダナイゼーション

9
• 従来の重厚なI/Oスタック構成では高速性を損ねてしまう
①ファイルシステムのDRAM上のキャッシュ階層(Page Cache)を減らした
DAXファイルシステムがOS機能として既に提供
②OSを介さずにメモリとして直接SCMへアクセスするための
ユーザライブラリがOSSとして提供
SCMの効果的な利用方法
Application
NVDIMM Block Device Driver
Storage Class Memory (SCM)
Traditional Filesystem DAX Filesystem(ext4 or xfs) memory-mapping
Virtual File System (VFS)
Persistent Memory
Development Kit
Page Cache(DRAM)
user
kernel
read/write
memcpy
read/write
ここに着目
①
②

10
• OSを介さずSCM領域へメモリとして直接アクセスために
必要な処理を抽象化
• Intel社が主導して開発
• https://github.com/pmem/pmdk/
• PMDK利用前後で比較して2.5倍へ書き込み性能が改善
Persistent Memory Development Kit(PMDK)
Hardware HPE Proliant DL360G9
CPU E5-2667 v4 x 2 (8 cores per node)
DRAM [Node0/1] 32 GiB each
PMEM (NVDIMM-N) [Node0] 64 GiB (HPE 8GB NVDIMM x 8)
NVMe SSD Intel SSD DC P3600 400GB
HDD HP 1TB 6GB SATA 7.2Krpm(MM100GFJTE)
Software
Distro Ubuntu 17.10
Linux kernel 4.16
PMDK 1.4
Filesystem ext4 (DAX available)
HDD NVMe SSD NVDIMM
(DAX FS)
NVDIMM
(DAX FS+PMDK)
約13000倍約29倍約2.5倍
Throughput[MB/sec]
約12.4GB/s
(約600nsec/req)
約5.0GB/s
(約1.5μsec/req)
8KiB synchronous write
NVDIMM
(Non DAX)
約10.3倍
約1.2GB/s約440MB/s約1MB/s

11
•まずはPostgreSQLに対して適用することとした
• アプリケーションに占めるI/O処理の比率が高そう
• OSSでありTCO削減へ貢献できる
• NTTグループで広く利用されている
• NTTグループ内に有識者が多くサポート体制が組める
PMDK適用アプリケーションの選定

12
Copyright©2018 NTT Corp. All Rights Reserved.HDD/SSD HDD/SSD
• ディスクI/O負荷の高い箇所へ適用
①変更リクエスト実行履歴情報 (WAL)
②表データの変更差分情報の書き出し(Checkpoint)
• 既存のread/write命令をmemcpyへ「単純に置き換え」
PostgreSQLへのPMDK適用検討
op: insert
id:4
name:emi
login:9:05
logout:17:00 ID name login logout
1 hanako 9:31 17:58
2 taro 9:29 17:55
3 jiro 10:30 20:00
リクエスト
Log
表データ
DRAM
①WAL書き込み
②Checkpoint書き込み
open mmap munmap close
DAX FSとPMDK
DAX FSのみ
オフセット
計算 seek
オフセット
計算
バリア
fsync
…
…open closewrite
メモリ
コピー
CPU命令
システムコール
同期I/Oの場合

13
• ディスクI/O負荷の高い箇所へ適用
①変更リクエスト実行履歴情報 (WAL)
②表データの変更差分情報の書き出し(Checkpoint)
• 既存のread/write命令をmemcpyへ「単純に置き換え」
PostgreSQLへのPMDK適用検討
op: insert
id:4
name:emi
login:9:05
logout:17:00 ID name login logout
1 hanako 9:31 17:58
2 taro 9:29 17:55
3 jiro 10:30 20:00
リクエスト
Log
表データ
DRAM
①WAL書き込み
②Checkpoint書き込み
NVDIMM NVDIMM
open mmap munmap close
DAX FSとPMDK
DAX FSのみ
オフセット
計算 seek
オフセット
計算
バリア
fsync
…
…open closewrite
メモリ
コピー
CPU命令
システムコール
同期I/Oの場合

14
• 「単純な置き換え」では想定していたほど改善効果が見られなかった
• WAL書き込み処理部は10%の性能向上
• Checkpoint書き込み処理部は30%の処理時間短縮
PostgreSQLへのPMDK適用結果
① WAL書き込み部の変更効果(1KiBの挿入処理のみ実行) ②Checkpoint書き込み部の変更効果(約7.35GB書き込み)
トランザクション数[kTPS]
所要時間[sec]
約1.1倍
85kTPS
93.2kTPS
約30%削減
2.65秒
3.75秒
NVDIMM
(DAX FS)
NVDIMM
(DAX FS+PMDK)
NVDIMM
(DAX FS)
NVDIMM
(DAX FS+PMDK)

15
アプリケーション(AP)設計をSCM前提で見直す必要がある
特に下記のような従来の設計・実装は性能に大きな影響がある
• AP独自のキャッシュ構造
• 低速ディスクを前提とした非同期I/O処理機構
• 従来のスピンドルディスクを前提としたシリアライズ処理
• 無意識に実行するメモリコピー
• 抽象化ライブラリ内でのバッファコピー
• 処理受け渡し時のメモリコピー
• ロック箇所の削減(一般的な話として)
• … 他にもたくさんあります
PMDKの「単純な適用」だけで十分？

16
• データ本体について, OS内のキャッシュ構造(PageCache)を介さず
書き込みを行うDAXファイルシステムの適用で約4.2倍の性能差
• AP独自のキャッシュ構造を排除した場合に, 単純に同じ結果が得られると
は限らないが, 高速化へ寄与する可能性は高い(詳細は【参考1】)
AP独自のキャッシュ構造に関する設計変更の必要性
Application
NVDIMM Block Device Driver
NVDIMM
Traditional Filesystem DAX Filesystem(ext4 or xfs)
Virtual File System (VFS)
Page Cache(DRAM)
NVDIMM
(DAX FS)
約5.0GB/s
8KiB synchronous write(再掲)
NVDIMM
(Non DAX)
約4.2倍
約1.2GB/s
キャッシュ構造以外にも性能差の要因があるため、
参考情報だが、DAXファイルシステムにより約4.2倍
Throughput[MB/sec]
NVDIMM
(Non DAX)
NVDIMM
(DAX FS)

17
• 既存APの実装を見ると意外と無駄なコピー処理が散見
• I/O処理までのコピー処理をどう削減するかが重要
「無意識に実行するメモリコピー」の回数削減が重要
●処理受け渡し毎にコピーする悪い例(メモリコピー5回)
●改善例1(メモリコピー3回) ●改善例2(メモリコピー3回)
データの実体
ポインタ参照
ポインタ渡し
メモリコピー
関数(処理単位)
無駄なコピー処理
(数十～数百nsec)
無駄なコピー処理
(数十～数百nsec)

18
主要なベンダ製品のSCM適用が急速に進みつつある
• Microsoft SQL Server 2016
• SAP HANA
商用製品の動向
Microsoft SQL Server 2016
utilizes NVDIMM-N for Tail-of-Log [1]
SAP HANA is leveraging
PMEM for Main Store [2]
[1] https://www.snia.org/sites/default/files/PM-Summit/2017/presentations/Tom_Talpey_Persistent_Memory_in_Windows_Server_2016.pdf
[2] https://www.snia.org/sites/default/files/PM-Summit/2017/presentations/Zora_Caklovic_Bringing_Persistent_Memory_Technology_to_SAP_HANA.pdf

19
• 高速な次世代メモリストレージの登場により
従来のソフトウェア設計・実装の常識が変わる
• 新たなコンピューティングモデルに向けた
ソフトウェア開発への投資が重要な鍵となる
• ハードウェアの高速性を活用できないソフトウェアは淘汰される可能性も
• 高速メモリストレージの次は「高速fabric」
• システムのボトルネック箇所がネットワークへ
• 高速fabricに最適なソフトウェアモデルの再検討も必要？
• 次世代のバス技術であるGen-Zの採用を目指す
The Machine についても有力なプラットフォームの
1つとして注視したい
ソフトウェアのモダナイゼーションが今後加速する

20
• 日本HPE様から取り上げていただいた事例紹介ページ
• https://h50146.www5.hpe.com/products/servers/news/casestudy/ntt/
• Introducing PMDK into PostgreSQL(PGCon 2018)
• 投稿中のWALのI/O処理へのPMDK適用パッチ
• https://www.pgcon.org/2018/schedule/events/1154.en.html
• PMDK main source repo
• https://github.com/pmem/pmdk
• Memory Driven Computing Explained
• https://news.hpe.com/memory-driven-computing-explained/
関連ページ

21
• 独自キャッシュ構造を持つメリットが少ない
• SCMはDRAM並みに高速かつランダムアクセスに強いため応答時間改善効果が少ない
• DRAMを介さないとSCM上へ永続化できないため, 永続化までの時間が延びる
【参考1】独自キャッシュ構造を持つAPへのNVDIMM適用考察
①DRAMへためる
(nsec)
②結果を返す
③まとめて書く
(msec)
①DRAMへためる
(nsec)
②結果を返す
③まとめて書く
(nsec)
①SCMへ直接書く
(nsec)
②結果を返す
データ
DRAMを介さず直接書き込み
処理階層を削減して高速化
データデータ
単純にSCMへ置き換え
応答時間の高速化やシリアライズ化
のためバッファリングした時点で返却
SCMへ書いてから②の結果を返しても
劇的な応答時間の改善は見込めない

22
• NUMAの影響が大きい
• 今回の試験環境でも3割程度性能が落ちる
• OS機能を有効に使わないと意外と速くならない
• Hugepage機能
• CPU命令の差で性能傾向が大きく異なる
• memcpyの実体である, mov命令の種類によってCPU Cache利用の仕方が異なる
• テストプログラムの厳密性
• 計測区間を厳密に決める必要がある
• テストプログラムの再現性
• CPU Cacheの状態を意識する必要がある
• CPU Cache上へ配置されているかどうかで性能が全く違う
• Page Tableの状態を意識する必要がある
• pagefaultが結構重い
• 従来のリソース監視手法が適用できない
• OSを経由せずにI/O実行するためThroughputなどOSのカウンタ値が利用できない
【参考2】検討を進める上でハマったこと

次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション

Similar to 次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション (20)

More from NTT Software Innovation Center

More from NTT Software Innovation Center (20)

次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション