PresentationPDF Available

ストレージコネクタspark-ceph-connectorの書き込み性能の改善

Authors:

Abstract

Presentation slide for "情報処理学会 第176回ハイパフォーマンスコンピューティング研究発表会". This is the presentation slide for the corresponding paper: https://www.researchgate.net/publication/344350943_sutorejikonekuta_spark-ceph-connector_noshukirumixingnengnogaishan
ストレージコネクタ
spark-ceph-connector
書き込み性能の改善
2020/09/25(Fri.) 176 HPC研究発表会
高橋 宗史 1) 建部 修見 2)
1) 筑波大学 大学院 システム情報工学研究科
コンピュータサイエンス専攻 HPCS研究室
2) 筑波大学 計算科学研究センター
1
発表の構成
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
2
研究の背景
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
3
研究の背景: Apache Spark
Apache Spark (Zaharia et al., 2012, USENIX NSDI '12)[1][2]
● Hadoopが苦手とする反復的な処理が高速
機械学習を含む充実した標準ライブラリ
データ解析の広い分野で人気
● spark-operatorKubeflowに対応し、Kubernetesを含む幅
広いプラットフォームに対応
4
MLlib
[1] Spark: Cluster Computing with Working Sets |
USENIX HotCloud '10 - Usenix
https://www.usenix.org/conference/hotcloud-10/spark
-cluster-computing-working-sets
[2] Apache Spark™ - Unified Analytics Engine for Big
Data - https://spark.apache.org/
研究の背景: 分散オブジェクトストレージ Ceph
Ceph (Sage A. Weil, 2006, USENIX OSDI '06) [3]
Linux Foundation 傘下の Ceph Foundation RedHat
を中心に活発に開発が行われているオープンソースの分散
オブジェクトストレージ
特徴: メタデータサーバーが不要なRADOSをベースとし、高
いスケーラビリティを持つ
5
[3] Ceph: a scalable, high-performance distributed file
system, Weil, Sage A. et al. OSDI '06
DOI: 10.5555/1298455.1298485
研究の背景: 分散オブジェクトストレージ Ceph
Ceph (Sage A. Weil, 2006, USENIX OSDI '06) [4]
利用例: CERN, Yahoo などでの10 - 100 PB級の大規模な
データの格納など[4][5]
最新版で完全にコンテナ化され、Rookを利用した
Kubernetesクラスター上でのストレージクラスタの自動構築
が可能 [6]
6
[4] Storage for Open Infrastructure. Dan Van Der Ster |
CERN IT Storage Group
https://indico.cern.ch/event/860733/contributions/3
625111/attachments/1938852/3214034/2019-intro-
ceph.pdf
[5] Yahoo Cloud Object Store - Object Storage at
Exabyte Scale | Yahoo Engineering
https://yahooeng.tumblr.com/post/116391291701/y
ahoo-cloud-object-store-object-storage-at
[6] Rook: Open-Source, Cloud-Native Storage for
Kubernetes - https://rook.io/
研究の背景: Ceph のインターフェイス
■ Cephは主に4種類のインターフェイスを提供
仮想ブロックデバイス (RBD)
S3 互換 REST API (RADOS Gateway)
CephFS (POSIX API)
RADOS ネイティブオブジェクト (librados)
最もオーバーヘッドが少ない
RADOS
librados CephFS
RBD
Block
Device
RADOS
Gateway
librados
ライブラリ
S3互換
REST API POSIX
API
http://docs.ceph.com/docs/mimic/ar
chitecture/ を元に作成
7
課題と研究の目的
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
8
課題と研究の目的: spark-ceph-connectorの開発 9
■ Cephの大規模データをApache Sparkから有効に活用するこ
とを目的にCephを有効に活用できるストレージコネクタ
spark-ceph-connectorを設計・実装した [7]
spark-ceph-connector
[7] 高橋 宗史, 建部 修見: “分散オブジェクトストレージ Ceph のための Spark スト
レージコネクタの設計, 情報処理学会 171 HPC 研究会報告 (HPC171),
Vol. 2019-HPC-171, No. 1, Sep. 2019.
課題と研究の目的: spark-ceph-connector
10
ストレージコネクタspark-
ceph-connector
従来: Ceph RADOS Gateway +
S3オブジェクトへの変換
■ libradosを直接利用することで変
換のオーバーヘッドを回避 spark-ceph-
connector
RADOS
librados CephFS
RBD RADOS
Gateway
RADOS Gateway
での変換を回避
RADOS
Object
課題と研究の目的: 書き込み性能極めて低い問題
改善前のspark-ceph-connectorに対する読み込みと書き込み
の性能測定の結果[7]
読み込み性能はベース性能に性能を発揮
書き込み性能が極めて低い (< 1 MiB/s)
11
課題と研究の目的: 本研究の目的 12
書き込み性能が極めて低い原因について、CephApache Spark
特有の性質の分析・対処
ストレージコネクタspark-ceph-connectorの書き込み性能の改
善方法の提案
spark-ceph-connector
提案手法
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
13
提案手法: 概要 14
提案手法の概要
1. Cephreplication factorと、Committerのアルゴリズムの
変更による改善
2. ストレージコネクタspark-ceph-connectorの内部バッファサイ
ズ変更による改善
3. 書き込みデータのSpark上のシリアライズ方法の変更による
改善
spark-ceph-connector
提案手法: replicationCommitterの変更による改善
Cephのレプリケーションファクターの変更
デフォルト: 3 1
一時データの複製を回避
FileOutputCommitter のコミット方法
デフォルト: アルゴリズム v1 アルゴリズム v2
2回のrename()1回に半減
15
提案手法: Cephreplication factor
16
Original
Object Replica
#1
自動的なレプリ
ケーション
Cephのレプリケーション
CephがベースとするRADOSでは、オブジェクトのレプリケー
ションが自動的に実行される
一時データの複製が書き込み性能に影響
osd #1 osd #2 osd #3 osd #4
Replica
#2
提案手法: FileOutputCommitterのコミットステップ
3つのコミットステップが実行される
(1) attemptTask() write() メソッド
(2) commitTask() rename() メソッド
(3) commitJob() rename() メソッド
17
提案手法: FileOutputCommitterのコミットステップ
rename() メソッド
HDFSなどのファイルシステム
ファイル名を変更するメタデータ操作だけの軽量な操作
18
提案手法: FileOutputCommitterのコミットステップ 19
parent/
tempdir/
file-X
parent/
file-Y
rename()
データ移動
rename() メソッド
Cephはオブジェクト配置アルゴリズム RADOS がベース
Ceph の設計上、rename により、オブジェクト全体の保存
場所の変更が必須
○ → オブジェクト全体の複製が発生
osd #1 osd #2 osd #3 osd #4
提案手法: オブジェクト形式の利用とバッファ拡張
転送データチャンクサイズが小さい問題
データの書き込みメソッドの変更
Javaネイティブのオブジェクト形式で保存
spark-ceph-connector の内部バッファのサイズ拡張
4 KiB 4 MiB に拡張
バッファサイズの不足に対処
20
提案手法: FileOutputCommitter のコミット方法
1. Spark Executor Committer の処理
Spark Executor:
データ処理によって生成されたデータI/Oの命令を発行
する
21
Internal Buffer
提案手法: FileOutputCommitter のコミット方法
2. Committer コネクタの処理
Committer:
ストレージコネクタに対してデータを渡して書き込み処理
を依頼
22
Internal Buffer
提案手法: FileOutputCommitter のコミット方法
3. コネクタ ストレージの処理
コネクタがlibradosを使用してデータI/Oの処理を実行
Cephクラスタにオブジェクトを書き込み
23
Internal Buffer
提案手法: DataFrameを使用したシリアライズの利用
DataFrameを使用したシリアライズの利用
最適な書き込みデータのシリアライズ方法を検証
シリアライズ形式
JSON形式
Apache ORC形式
Apache Parquet形式
Apache ORC, Apache Parquet
データ解析用の列指向のシリアライズフォーマット
Apache ORC: "High-Performance Columnar Storage for
Hadoop"
Apache Parquet: "efficient columnar data representation
available to any project in the Hadoop ecosystem"
24
予備実験
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
25
予備実験: 実験環境
Ceph クラスタを構成する各ノードの環境
26
CPU Intel Xeon CPU E5620 @ 2.40GHz x2
メモリ DDR3-1333 ECC 4 GB x6 (24 GB)
ネットワーク 10 Gb Ethernet
ストレージ RevoDrive 3 X2 SSD 240 GB (60GB x4)
OS Ubuntu 20.04 LTS
Linux Kernel Linux 5.4.0-42-generic (x86-64)
Ceph ceph v15.2.3 (d289bbd) octopus (stable)
予備実験: クラスタの構成
mon
osd x4
SSD
ストレージ
ノード
ストレージ
osd x4
SSD
osd x4
SSD
osd x4
SSD
Ceph クラスタを5ノードから構成
管理ノード (1ノード): mon, mgr プロセスを実行
ストレージノード (4ノード): osd プロセスを実行
mgr
クラスタ
管理ノード
27
Cephに標準で付属するRADOS Benchを使用して測定
RADOS Bench: librados を利用したRADOS オブジェクトの
直接のI/O性能を測定
シーケンシャルRead/Writeの性能を測定
Read/Writeのオブジェクトサイズを1 MiB - 1,024 MiB に変化さ
せて、実験環境のCephクラスタにおける性能を確認
予備実験: ベース性能の測定 28
読み込み性能
140 MiB/s を上回る安定した性能
予備実験: 読み込みベース性能の測定 29
書き込み性能
100 MiB/s〜約 145 MiB/sまでの性能を発揮
予備実験: 書き込みベース性能の測定 30
実験結果
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
31
実験 - 実験の方法
Apache Sparkからspark-ceph-connector経由でCephクラス
タにオブジェクトを書き込む性能を測定
オブジェクトデータの準備
● Ceph上にオブジェクトデータを準備
キャッシュ機能を利用して、Apache Spark上に書き込み
データをキャッシュ
キャッシュしたデータをspark-ceph-connector経由で Ceph
クラスタへ書き込み
生成したデータのオブジェクトサイズ
1 - 1,024 MiB
32
spark-ceph-
connector
実験1: replicationCommitterの変更による改善
ベース性能
replication factor: 3
FileOutputCommitter: アルゴリズムv1
33
replicationCommitterの変更による改善
replication factorの変更による改善
replication factor: 31
FileOutputCommitter: アルゴリズムv1
34
変更前 変更後
replicationCommitterの変更による改善
replicationとアルゴリズムの変更による改善
replication factor: 3 1
FileOutputCommitter: アルゴリズムv1 v2
35
変更前 変更後
オブジェクト形式の利用とバッファ拡張による改善
Javaネイティブオブジェクト形式の利用による改善
3.3 MiB 最大 4.4 MiB/s に改善
ストレージコネクタ内部バッファの飽和が明らかに
36
変更前 変更後
オブジェクト形式の利用とバッファ拡張による改善 37
変更前 変更後
ストレージコネクタ内部バッファの拡張
バッファサイズ: 4 KiB 4 MiB
バッファサイズが小さい影響が解消
最大で約 1.8 倍の 5.9 MiB/s に性能向上
DataFrameを使用したシリアライズによる改善
DataFrameのシリアライズ形式
JSON形式
テキスト形式だが、データチャンクが安定して 8 KiB で利用
され、効率のよい書き込みが実現された
38
変更前 変更後
DataFrameを使用したシリアライズによる改善 39
DataFrameのシリアライズ形式
DataFrameを使用したApache ORC形式
最大で約 51 MiB/s
変更前 変更後
DataFrameを使用したシリアライズによる改善
DataFrameのシリアライズ形式
Apache Parquet形式
ベース性能の約 110 倍の 66.1 MiB/s
40
変更前 変更後
まとめ
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
41
ストレージコネクタ spark-ceph-connector は十分な書き込み
性能が発揮できていなかった
本研究では
spark-ceph-connectorの書き込み性能が低い理由を分析
spark-ceph-connectorに対する改良を適用
書き込み時の適切なシリアライズ方法を検討
まとめ 42
これらの改善の結果:
128 MiBのオブジェクトサイズに対する書き込み性能
0.6 MiB/s 20.8 MiB/s
x35 の性能向上
1,024 MiBのオブジェクトサイズに対する書き込み性能
0.6 MiB/s 最大で約 66.1 MiB/s
x110 の大幅な改善
実用的な書き込み性能を発揮する方法が明らかになった
まとめ 43
関連研究
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
44
関連研究: CephFS-Hadoop プラグイン
CephFS-Hadoop プラグイン
POSIX 準拠 CephFS インターフェイスを利用
Hadoop バージョン1.1系列が必要
CephFS のオーバーヘッドが多い
Ceph : ceph/cephfs-hadoop: cephfs-hadoop
https://github.com/ceph/cephfs-hadoop
Using Hadoop with CephFS — Ceph Documentation
https://docs.ceph.com/docs/master/cephfs/hadoop/
45
CephFS-
Hadoop
RADOS
librados CephFS
RBD RADOS
Gateway
POSIX
API
関連研究: zero-rename committer
AWS S3オブジェクトストレージ向けのS3Aストレージコネクタの
ために開発されたCommitter
名前の通り、rename操作を行わないように改良されたオブジェ
クトストレージ向けのCommitter
Steve Loughran: A Zero-Rename Committer: Object-storage as a destination for
Apache Hadoop and Spark , (online), available from
https://github.com/steveloughran/zero-rename-committer (2020-08-20)
46
関連研究: ストレージコネクタStocator
zero-rename committerと同様の改善を独自のアプローチで
実装したストレージコネクタ
Amazon S3Swiftでの利用は考慮されているが、Ceph向け
には開発されておらず、Stocator用のストレージプラグインを追
加で開発する必要がある
Vernik, G., Factor, M., Kolodner, E. K., Michiardi, P., Ofer, E. and Pace, F.: Stocator:
Providing High Performance and Fault Tolerance for Apache Spark Over Object
Storage, 2018 18th IEEE / ACM International Symposium on Cluster, Cloud and
Grid Computing ( CCGRID ), IEEE, (online), DOI: 0.1109/ccgrid.2018.00073 (2018).
47
今後の課題
1. 研究の背景
2. 課題と研究の目的
3. 提案手法
4. 予備実験
5. 実験結果
6. まとめ
7. 関連研究
8. 今後の課題
48
これまで: 読み込みと書き込みの基本的な性能を評価するため
のマイクロベンチマークのみ
● →より実用的なアプリケーションに近いワークロードを用い
たベンチマークを実施し、ストレージコネクタの実用性を評
価する必要がある
Committer の改善
rename 処理に改善の余地がある
● →S3Aストレージコネクターのzero rename committerと同
等の機能を実装
今後の課題 49
ストレージコネクタは、GitHub上でApacheライセンスで公開
shuuji3/spark-ceph-connector: 🌟Spark Ceph Connector:
Implementation of Hadoop Filesystem API for Ceph
https://github.com/shuuji3/spark-ceph-connector
謝辞
本研究の一部は、筑波大学計算科学研究センターの学際共同利
用プログラム(Cygnus)、国立研究開発法人新エネルギー・産業技
術総合開発機構(NEDO)および富士通研究所との共同研究の助
成を受けたものです。
Appendix 50
Appendix 51
研究の目的 - 既存手法との比較 52
現状では S3A を利用 ()
S3A AWS のために開発
RADOS Gateway との 2
のデータ変換によるオーバ
ヘッド
本研究が提案する Ceph
コネクタ ()
librados を利用
Ceph ネイティブのオブジェク
トへのアクセスを行う
設計と実装 - コネクタ実装クラス 53
hadoop.fs.FileSystem を継
承した CephFileSystem
■ Read:
CephInputStream
CephReadChannel
■ Write:
CephOutputDataStream
CephWriteChannel
実装内部では Java New
I/O ライブラリを活用
実験と手法 - 性能劣化の原因 (1)
原因1: Apache Spark によるデータ保存時の書き込み方法
Ceph CRUSH アルゴリズムの相性の悪さ
Spark のデータ書き込みプロセス
(1) 分散タスクが attempt というファイルを書き込む
(2) データの書き込みの成功後、当該タスクごとにファイ
ルシステム上の一時ファイルに rename する
(3) すべてのタスクが成功したら、一時ファイルを最終的
な書き込み場所に移動するために rename を実行
54
attempt
Object
temp
Object Object
rename()
write() rename()
実験と手法 - 性能劣化の原因 (1)
1 MiB のオブジェクト Write 時の Ceph クラスタ内の I/O の内
(計測範囲: 0s - 100s)
Write だけでなく約 1/41/3 もの Read が含まれる
55
ResearchGate has not been able to resolve any citations for this publication.
ResearchGate has not been able to resolve any references for this publication.