Swift losf

1. © 2019 NTT TechnoCross Corporation
性能改善に向けた取り組み
OpenStack Swift
2019/1/18
須田憲男

2. © 2019 NTT TechnoCross Corporation 2
サマリ
• 自己紹介
• はじめに
• Swiftの性能問題
• 性能改善Patch紹介
• PUTとGETの流れ
• どれだけ性能が改善するのか
• おわりに

3. © 2019 NTT TechnoCross Corporation 3
自己紹介
• NTTテクノクロス(株)
須田 憲男
Swiftに関する業務
これまで 2013年からSwift (Grizzly) の機能調査に参画
Tempestシナリオ拡充
Storage Policyに関するバグ改修パッチ提供
商用稼動中のプライベートクラウドの運用保守
現在は Swiftの機能調査、運用保守
社内クラウドサービスにオブジェクトストレー
ジサービスを立ち上げてトライアル実施中

4. © 2019 NTT TechnoCross Corporation 4
はじめに

5. © 2019 NTT TechnoCross Corporation 5
はじめに
• Webで「OpenStack Swift 性能」のキーワードで検
索すると・・・
• Swiftの性能面で色々苦労している事例が幾つかヒッ
トする。
• ネガティブな書き込みしかない。

6. © 2019 NTT TechnoCross Corporation 6
Swiftの性能問題

7. © 2019 NTT TechnoCross Corporation 7
Swiftの性能問題
• 性能問題を語る前に前提として
• Swiftはディスクにファイルを格納する際にOSの
ファイルシステムを利用。
• Swiftはxfsを推奨。

8. © 2019 NTT TechnoCross Corporation 8
Swiftの性能問題
• OSのファイルシステムはファイル毎にメタ情報
（inode,dentry）をキャッシュ上に保持。
• キャッシュ上のメタ情報を読み込むことで高速に処
理。
• しかし、ファイル数が増大すると・・・

9. © 2019 NTT TechnoCross Corporation 9
Swiftの性能問題
• メタ情報がキャッシュ上に乗り切らず、溢れたメタ
情報はディスクへ書き込まれる。
• ディスクを介してメタ情報を処理するとファイルシ
ステムの処理時間は大幅に伸びる。

10. © 2019 NTT TechnoCross Corporation 10
Swiftの性能問題

11. © 2019 NTT TechnoCross Corporation 11
Swiftの性能問題
• また、xfsの場合はxfsaildがメモリ上にキャッシュし
たメタ情報をある程度溜まる度にジャーナルログを
用いて非同期にディスクに書き出す。
• ファイル数の増加に伴ってinode構造（B-tree）が
巨大化、複雑化すると、このxfsaild実行時にI/O負
荷が高まる。
• SwiftのI/Oに影響を及ぼす。

12. © 2019 NTT TechnoCross Corporation 12
Swiftの性能問題
• 数KB～数10KB程度の小さなファイルを大量にアッ
プロードした場合、Swiftの書込み性能が充填率0%
の時と比べて最終的には約10分の1まで低下する。

13. © 2019 NTT TechnoCross Corporation 13
性能改善Patch

14. © 2019 NTT TechnoCross Corporation 14
性能改善Patch
• OSのファイルシステム上のファイル数が増加するこ
とでディスクI/O性能が低下する。
• そこでSwift経由でファイルの数を減らす仕組みとし
て改善パッチ LOSF(Lots of small files)が考案され
た。

15. © 2019 NTT TechnoCross Corporation 15
性能改善Patch
• 仏 OVH 社 の Alexandre Lecuyer が 考 案 し 、
OpenStack wikiに仕組みを掲載してソースコードも
準備している。

16. © 2019 NTT TechnoCross Corporation 16
性能改善Patch
• ファイル数を減らす仕組みは単純。
• 各Storageノードのディスク毎に、アップロードし
たファイルとそのメタデータを１つのファイル
（Volumeと呼ぶ）にどんどん追記する。

17. © 2019 NTT TechnoCross Corporation 17
性能改善Patch

18. © 2019 NTT TechnoCross Corporation 18
性能改善Patch
• Facebookの写真共有ストレージ「Haystack」と似
た仕組み。
• 「 Haystack 」 で は 書 き 込 む フ ァ イ ル を 「 Store
File」と呼んでいる。

19. © 2019 NTT TechnoCross Corporation 19
PUTとGETの流れ

20. © 2019 NTT TechnoCross Corporation 20
PUTの流れ
• ディスクにファイルを書き込む際、アップロードし
たファイルとそのメタデータが１つのVolumeに書き
込まれる。

21. © 2019 NTT TechnoCross Corporation 21
PUTの流れ
• 次に同じディスク配下に異なるファイルが書き込ま
れる場合も、先程のVolumeにファイルとメタデータ
が追記される。

22. © 2019 NTT TechnoCross Corporation 22
PUTの流れ
• Volumeに書き込む際にロックをかけるため、もし他
のリクエストによりVolumeが捕まれていたら、別な
Volumeを生成してそちらに書き込む。

23. © 2019 NTT TechnoCross Corporation 23
PUTの流れ
• 各Storageノード上に新たに用意したIndex Server
に、書き込んだVolumeと位置情報をkey/value形式
で保持する。

24. © 2019 NTT TechnoCross Corporation 24
GETの流れ
• Index Serverからダウンロード対象のデータが書き
込まれているVolumeと位置情報を取得する。

25. © 2019 NTT TechnoCross Corporation 25
GETの流れ
• 目的のVolumeからファイルの中身を読み取ってクラ
イアントに返却する。

26. © 2019 NTT TechnoCross Corporation 26
【補足】従来の方式との違い

27. © 2019 NTT TechnoCross Corporation 27
どれだけ性能が改善するのか

28. © 2019 NTT TechnoCross Corporation 28
どれだけ性能が改善するのか
• PUT
• 0個→400万個
• 400万個→800万個
改善前 改善後
minutes 3360 2540
PUT/s 19.8 26.2
改善前 改善後
minutes 3900 1700
PUT/s 17 39.2
1.3倍
2.3倍

29. © 2019 NTT TechnoCross Corporation 29
どれだけ性能が改善するのか
• GET
• 800万個のファイルを格納した状態
改善前 改善後
minutes - -
GET/s 39.0 93.02.4倍

30. © 2019 NTT TechnoCross Corporation 30
おわりに

31. © 2019 NTT TechnoCross Corporation 31
おわりに
• 引き続きスループット測定やリソース(CPU使用率、
memory使用量)への影響調査、リバランスの性能測
定なども実施する予定。