© 2019 NTT TechnoCross Corporation
性能改善に向けた取り組み
OpenStack Swift
2019/1/18
須田憲男
© 2019 NTT TechnoCross Corporation 2
サマリ
• 自己紹介
• はじめに
• Swiftの性能問題
• 性能改善Patch紹介
• PUTとGETの流れ
• どれだけ性能が改善するのか
• おわりに
© 2019 NTT TechnoCross Corporation 3
自己紹介
• NTTテクノクロス(株)
須田 憲男
Swiftに関する業務
これまで 2013年からSwift (Grizzly) の機能調査に参画
Tempestシナリオ拡充
Storage Policyに関するバグ改修パッチ提供
商用稼動中のプライベートクラウドの運用保守
現在は Swiftの機能調査、運用保守
社内クラウドサービスにオブジェクトストレー
ジサービスを立ち上げてトライアル実施中
© 2019 NTT TechnoCross Corporation 4
はじめに
© 2019 NTT TechnoCross Corporation 5
はじめに
• Webで「OpenStack Swift 性能」のキーワードで検
索すると・・・
• Swiftの性能面で色々苦労している事例が幾つかヒッ
トする。
• ネガティブな書き込みしかない。
© 2019 NTT TechnoCross Corporation 6
Swiftの性能問題
© 2019 NTT TechnoCross Corporation 7
Swiftの性能問題
• 性能問題を語る前に前提として
• Swiftはディスクにファイルを格納する際にOSの
ファイルシステムを利用。
• Swiftはxfsを推奨。
© 2019 NTT TechnoCross Corporation 8
Swiftの性能問題
• OSのファイルシステムはファイル毎にメタ情報
(inode,dentry)をキャッシュ上に保持。
• キャッシュ上のメタ情報を読み込むことで高速に処
理。
• しかし、ファイル数が増大すると・・・
© 2019 NTT TechnoCross Corporation 9
Swiftの性能問題
• メタ情報がキャッシュ上に乗り切らず、溢れたメタ
情報はディスクへ書き込まれる。
• ディスクを介してメタ情報を処理するとファイルシ
ステムの処理時間は大幅に伸びる。
© 2019 NTT TechnoCross Corporation 10
Swiftの性能問題
© 2019 NTT TechnoCross Corporation 11
Swiftの性能問題
• また、xfsの場合はxfsaildがメモリ上にキャッシュし
たメタ情報をある程度溜まる度にジャーナルログを
用いて非同期にディスクに書き出す。
• ファイル数の増加に伴ってinode構造(B-tree)が
巨大化、複雑化すると、このxfsaild実行時にI/O負
荷が高まる。
• SwiftのI/Oに影響を及ぼす。
© 2019 NTT TechnoCross Corporation 12
Swiftの性能問題
• 数KB~数10KB程度の小さなファイルを大量にアッ
プロードした場合、Swiftの書込み性能が充填率0%
の時と比べて最終的には約10分の1まで低下する。
© 2019 NTT TechnoCross Corporation 13
性能改善Patch
© 2019 NTT TechnoCross Corporation 14
性能改善Patch
• OSのファイルシステム上のファイル数が増加するこ
とでディスクI/O性能が低下する。
• そこでSwift経由でファイルの数を減らす仕組みとし
て改善パッチ LOSF(Lots of small files)が考案され
た。
© 2019 NTT TechnoCross Corporation 15
性能改善Patch
• 仏 OVH 社 の Alexandre Lecuyer が 考 案 し 、
OpenStack wikiに仕組みを掲載してソースコードも
準備している。
© 2019 NTT TechnoCross Corporation 16
性能改善Patch
• ファイル数を減らす仕組みは単純。
• 各Storageノードのディスク毎に、アップロードし
たファイルとそのメタデータを1つのファイル
(Volumeと呼ぶ)にどんどん追記する。
© 2019 NTT TechnoCross Corporation 17
性能改善Patch
© 2019 NTT TechnoCross Corporation 18
性能改善Patch
• Facebookの写真共有ストレージ「Haystack」と似
た仕組み。
• 「 Haystack 」 で は 書 き 込 む フ ァ イ ル を 「 Store
File」と呼んでいる。
© 2019 NTT TechnoCross Corporation 19
PUTとGETの流れ
© 2019 NTT TechnoCross Corporation 20
PUTの流れ
• ディスクにファイルを書き込む際、アップロードし
たファイルとそのメタデータが1つのVolumeに書き
込まれる。
© 2019 NTT TechnoCross Corporation 21
PUTの流れ
• 次に同じディスク配下に異なるファイルが書き込ま
れる場合も、先程のVolumeにファイルとメタデータ
が追記される。
© 2019 NTT TechnoCross Corporation 22
PUTの流れ
• Volumeに書き込む際にロックをかけるため、もし他
のリクエストによりVolumeが捕まれていたら、別な
Volumeを生成してそちらに書き込む。
© 2019 NTT TechnoCross Corporation 23
PUTの流れ
• 各Storageノード上に新たに用意したIndex Server
に、書き込んだVolumeと位置情報をkey/value形式
で保持する。
© 2019 NTT TechnoCross Corporation 24
GETの流れ
• Index Serverからダウンロード対象のデータが書き
込まれているVolumeと位置情報を取得する。
© 2019 NTT TechnoCross Corporation 25
GETの流れ
• 目的のVolumeからファイルの中身を読み取ってクラ
イアントに返却する。
© 2019 NTT TechnoCross Corporation 26
【補足】従来の方式との違い
© 2019 NTT TechnoCross Corporation 27
どれだけ性能が改善するのか
© 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倍
© 2019 NTT TechnoCross Corporation 29
どれだけ性能が改善するのか
• GET
• 800万個のファイルを格納した状態
改善前 改善後
minutes - -
GET/s 39.0 93.02.4倍
© 2019 NTT TechnoCross Corporation 30
おわりに
© 2019 NTT TechnoCross Corporation 31
おわりに
• 引き続きスループット測定やリソース(CPU使用率、
memory使用量)への影響調査、リバランスの性能測
定なども実施する予定。

Swift losf

  • 1.
    © 2019 NTTTechnoCross Corporation 性能改善に向けた取り組み OpenStack Swift 2019/1/18 須田憲男
  • 2.
    © 2019 NTTTechnoCross Corporation 2 サマリ • 自己紹介 • はじめに • Swiftの性能問題 • 性能改善Patch紹介 • PUTとGETの流れ • どれだけ性能が改善するのか • おわりに
  • 3.
    © 2019 NTTTechnoCross Corporation 3 自己紹介 • NTTテクノクロス(株) 須田 憲男 Swiftに関する業務 これまで 2013年からSwift (Grizzly) の機能調査に参画 Tempestシナリオ拡充 Storage Policyに関するバグ改修パッチ提供 商用稼動中のプライベートクラウドの運用保守 現在は Swiftの機能調査、運用保守 社内クラウドサービスにオブジェクトストレー ジサービスを立ち上げてトライアル実施中
  • 4.
    © 2019 NTTTechnoCross Corporation 4 はじめに
  • 5.
    © 2019 NTTTechnoCross Corporation 5 はじめに • Webで「OpenStack Swift 性能」のキーワードで検 索すると・・・ • Swiftの性能面で色々苦労している事例が幾つかヒッ トする。 • ネガティブな書き込みしかない。
  • 6.
    © 2019 NTTTechnoCross Corporation 6 Swiftの性能問題
  • 7.
    © 2019 NTTTechnoCross Corporation 7 Swiftの性能問題 • 性能問題を語る前に前提として • Swiftはディスクにファイルを格納する際にOSの ファイルシステムを利用。 • Swiftはxfsを推奨。
  • 8.
    © 2019 NTTTechnoCross Corporation 8 Swiftの性能問題 • OSのファイルシステムはファイル毎にメタ情報 (inode,dentry)をキャッシュ上に保持。 • キャッシュ上のメタ情報を読み込むことで高速に処 理。 • しかし、ファイル数が増大すると・・・
  • 9.
    © 2019 NTTTechnoCross Corporation 9 Swiftの性能問題 • メタ情報がキャッシュ上に乗り切らず、溢れたメタ 情報はディスクへ書き込まれる。 • ディスクを介してメタ情報を処理するとファイルシ ステムの処理時間は大幅に伸びる。
  • 10.
    © 2019 NTTTechnoCross Corporation 10 Swiftの性能問題
  • 11.
    © 2019 NTTTechnoCross Corporation 11 Swiftの性能問題 • また、xfsの場合はxfsaildがメモリ上にキャッシュし たメタ情報をある程度溜まる度にジャーナルログを 用いて非同期にディスクに書き出す。 • ファイル数の増加に伴ってinode構造(B-tree)が 巨大化、複雑化すると、このxfsaild実行時にI/O負 荷が高まる。 • SwiftのI/Oに影響を及ぼす。
  • 12.
    © 2019 NTTTechnoCross Corporation 12 Swiftの性能問題 • 数KB~数10KB程度の小さなファイルを大量にアッ プロードした場合、Swiftの書込み性能が充填率0% の時と比べて最終的には約10分の1まで低下する。
  • 13.
    © 2019 NTTTechnoCross Corporation 13 性能改善Patch
  • 14.
    © 2019 NTTTechnoCross Corporation 14 性能改善Patch • OSのファイルシステム上のファイル数が増加するこ とでディスクI/O性能が低下する。 • そこでSwift経由でファイルの数を減らす仕組みとし て改善パッチ LOSF(Lots of small files)が考案され た。
  • 15.
    © 2019 NTTTechnoCross Corporation 15 性能改善Patch • 仏 OVH 社 の Alexandre Lecuyer が 考 案 し 、 OpenStack wikiに仕組みを掲載してソースコードも 準備している。
  • 16.
    © 2019 NTTTechnoCross Corporation 16 性能改善Patch • ファイル数を減らす仕組みは単純。 • 各Storageノードのディスク毎に、アップロードし たファイルとそのメタデータを1つのファイル (Volumeと呼ぶ)にどんどん追記する。
  • 17.
    © 2019 NTTTechnoCross Corporation 17 性能改善Patch
  • 18.
    © 2019 NTTTechnoCross Corporation 18 性能改善Patch • Facebookの写真共有ストレージ「Haystack」と似 た仕組み。 • 「 Haystack 」 で は 書 き 込 む フ ァ イ ル を 「 Store File」と呼んでいる。
  • 19.
    © 2019 NTTTechnoCross Corporation 19 PUTとGETの流れ
  • 20.
    © 2019 NTTTechnoCross Corporation 20 PUTの流れ • ディスクにファイルを書き込む際、アップロードし たファイルとそのメタデータが1つのVolumeに書き 込まれる。
  • 21.
    © 2019 NTTTechnoCross Corporation 21 PUTの流れ • 次に同じディスク配下に異なるファイルが書き込ま れる場合も、先程のVolumeにファイルとメタデータ が追記される。
  • 22.
    © 2019 NTTTechnoCross Corporation 22 PUTの流れ • Volumeに書き込む際にロックをかけるため、もし他 のリクエストによりVolumeが捕まれていたら、別な Volumeを生成してそちらに書き込む。
  • 23.
    © 2019 NTTTechnoCross Corporation 23 PUTの流れ • 各Storageノード上に新たに用意したIndex Server に、書き込んだVolumeと位置情報をkey/value形式 で保持する。
  • 24.
    © 2019 NTTTechnoCross Corporation 24 GETの流れ • Index Serverからダウンロード対象のデータが書き 込まれているVolumeと位置情報を取得する。
  • 25.
    © 2019 NTTTechnoCross Corporation 25 GETの流れ • 目的のVolumeからファイルの中身を読み取ってクラ イアントに返却する。
  • 26.
    © 2019 NTTTechnoCross Corporation 26 【補足】従来の方式との違い
  • 27.
    © 2019 NTTTechnoCross Corporation 27 どれだけ性能が改善するのか
  • 28.
    © 2019 NTTTechnoCross 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 NTTTechnoCross Corporation 29 どれだけ性能が改善するのか • GET • 800万個のファイルを格納した状態 改善前 改善後 minutes - - GET/s 39.0 93.02.4倍
  • 30.
    © 2019 NTTTechnoCross Corporation 30 おわりに
  • 31.
    © 2019 NTTTechnoCross Corporation 31 おわりに • 引き続きスループット測定やリソース(CPU使用率、 memory使用量)への影響調査、リバランスの性能測 定なども実施する予定。