はじめに

本記事はCephのBest Practiceを探る第二弾になります。今回は先日紹介した記事の続編としてCephの公式ブログで公開されているこちらの記事の内容を紹介いたします。今回も記事内容への補足や個人的なメモは青文字で加えております。

要約

Part-1に引き続き、Red Hat Ceph Storage (RHCS) 3.2でBlueStoreを利用した際のパフォーマンス検証を行った。本章では、ブロックサイズを3つのカテゴリー（Small / Medium / Large）に分け、それぞれのブロックサイズでどのようにパフォーマンスが変化するかを検証した。
Small / Mediumサイズの場合、CPUとメディアの競合により、パフォーマンスが制限された。
Largeサイズの場合、4Mサイズの時にピーク値を迎えた。クライアントのネットワーク帯域が上限に達したため、パフォーマンスが制限された。

検証内容

まず今回実施した検証内容を簡単に紹介します。

今回の検証は、Part-1の環境を引き続き利用した結果になります。検証環境については前回の記事をご覧ください。内容としては、Small / Medium / Largeという3つのブロックサイズで、それぞれパフォーマンスを比較しました。3つのブロックサイズの具体的なサイズ値は以下の通りです。

Small：4KB
Medium：8KB - 64KB
Large：1MB - 4MB

パフォーマンスの測定では、Random Read / Random Read-Write / Random Writeの場合を比較し、IOPS・Latencyなどを計測しました。なおRandom-Read-Writeは、Read：Write＝70：30の割合で行っています。

パフォーマンス計測の際、合わせてCPU使用率、メディア使用率などを測定しており、3つのブロックサイズでどの要因がボトルネックとなり、パフォーマンスに影響しているかを推定しています。

1. Small ブロックサイズ

早速ですがSmallブロックサイズの計測結果は以下のようになりました。3つのグラフは、縦軸のIOPSと横軸のIO Depthは共通ですが、それぞれ平均レイテンシ・CPU使用率・メディア使用率をプロットしています。

Graph 1：平均レイテンシ

Graph 1. small-block-size-result-01

Graph 2：CPU使用率

Graph 2. small-block-size-result-02

Graph 3：メディア使用率

Graph 3. small-block-size-result-03

上記グラフから、以下のことがわかります。

Graph 2より、Random ReadはCPUリソースの競合がボトルネックとなっています。しかしGraph 3を見ると、メディア使用率もRandom Readに強く影響していることが分かります（※1参照）。今回の検証ではCephノード（CPU/メディア）を追加していたために、Random Readがより高くスケールをした可能性があります。
Graph 2より、Random Read-Write、Random WriteはCPU使用率がボトルネックとなっていることがわかります。また一方で、この時メディアは十分余裕のあるスループットを記録したのですが、計算パワー（CPU）が足りずに使われない状態を維持していました（※2参照）。このため、Ceph OSDにより多くのCPUを集積することで、Random Write・Random Read-Writeのパフォーマンスを向上できる可能性があります。
OSDデータデバイス（今回はP4500 NVMe）の使用率は50％未満にとどまり、BlueStoreのWAL・RocksDBのメタデータをホストするデバイス（Optane P4800）は平均90％の使用率となりました。ceph.confに設定したbluestore_min_alloc_size_ssdは16KBに設定しているため、16KB以下のすべての書き込み処理は遅延されます（※3参照）。書き込み処理はまずWAL、その後非同期的にOSDへと送られます。そのため、WALデバイスがホスト上のOSDへのすべての書き込み処理を吸収しました。RocksDB/WALは高い使用率だったにもかかわらず、OSDデータデバイス上での競合の兆候は見られませんでした。しかし、これまでの経験から、WAL/RocksDB用の単一のP4800の後ろに、7つ以上のP4500 NVMeデバイスを配置することは推奨できません。
Small Blockサイズでは、他にもクライアントのSweep Testを実施しました（結果は以下のGraph 4の通り）。これはクライアントの数を20~140に徐々に増やし、その時のIOPS・レイテンシを計測するものになります。クライアント数を増やしたとき、Ceph OSDのCPU輻湊が発生するまで（およそ100クライアントまで）は線形にパフォーマンスが改善しました。100クライアント以降はシステムリソースの輻湊により、高いTail Latencyが発生しました（※4参照）。メタデータデバイスに利用したOptane P4800は、大量の並列クライアントによるレイテンシのスパイクを吸収するのに役立ち、その結果平均のレイテンシは40ms以下に収まりました。

Graph 4：Sweep Test

Graph 4

※1：Graph 2、Graph 3のCPU使用率・メディア使用率の数値を見ると、Random Readはいずれも80-90%程度の高い数値を記録しています。またCPU使用率はIO Depthが32から64に推移する際に殆ど増加していない様子も見られます。メディア使用率も同じように推移していますが、IO Depthが16→32、32→64に変化した際のグラフの傾きは、CPU使用率のほうが急激に変化しているため、CPU使用率が特に影響しているようにも見えます。

※2：Graph 2よりRandom Read-Write、Random WriteのいずれもCPU使用率が80％近くまで上昇しています。一方Graph 3ではRandom Read-Writeは50％程度、Random Writeは17％と低い使用率で頭打ちとなっています。このためCPU使用率のほうがボトルネックとなっていると言えます。

※3：16KB以下の処理はすぐに処理せず、他の処理と合わせてまとめて処理する、ということ。

※4：CPUなどの共有リソースや並列処理によるTail Latencyの発生と増幅はこちらでも指摘されています。

※参考リンク：

2. Medium ブロックサイズ

次にMediumブロックサイズの場合を見てみます。Mediumブロックサイズの結果は以下の4つのグラフの通りです（IO Depthは32で固定）。

Graph 5：平均レイテンシ

medium-block-size-result-01

Graph 6：Tailレイテンシ

medium-block-size-result-01

Graph 7：メディア使用率

medium-block-size-result-01

Graph 8：CPU使用率

medium-block-size-result-01

上記グラフより、以下のことが分かります。

Meidumブロックサイズに比べ、Smallブロックサイズのほうが、高いIOPSと低い平均レイテンシ・Tailレイテンシを記録している。
Ceph OSDノードでは、CPU使用率は80％程度、メディア使用率は90％程度まで上昇しました。そのため、Smallブロックサイズの時と同じように、Ceph OSDノードを追加することでパフォーマンスが向上する可能性があります。

※5：Graph 5、Graph 6では、ブロックサイズが増加するほどレイテンシも増加していることがわかります。ブロックサイズが増加するほど、一つのブロックの読み取りにかかる時間が増加するため、レイテンシが増加します（こちらの記事を参照）

※6：Graph 7、Graph 8を見ると、Random Read、Random Read-Writeについて、CPU使用率はブロックサイズの増加に従って減少しているのに対し、メディア使用率は常に高い値を記録しています。このことから、特にメディア使用率のほうがボトルネックとして強く影響しているようにも見ます。

※7：Graph 8において、ブロックサイズが上昇するに従いCPU使用率が減少していることがわかりますが、その理由は分かってないです。ブロックサイズが小さいときはOSDノードでの処理の呼び出し回数が増加するため？

※参考リンク：

3. Large ブロックサイズ

最後にLargeブロックサイズの検証結果です。結果は以下のグラフの通りです。

Graph 9：スループット、メディア・CPU使用率

graph9

上記グラフを見ると、ブロックサイズが4MBの場合、Random Read、Random Read-Write、Random Writeのいずれも、10.9GB/sというスループットを記録していることがわかります。このパフォーマンスのボトルネックとなっているのは、クライアントネットワークだと思われます（※8参照）。次に最も使用率の高いリソースはメディア使用率ですが、メディア使用率は上限には達しておらず、ネットワークがボトルネックにならなければより高いパフォーマンスを発揮できる余地があります。

※8：クライアントネットワークについてはPart-1にて「クライアントからCephノードへの最大スループットは~10GB/sである」という記述があり、今回の結果はそれに近しいものとなっています。

※9：LargeブロックサイズはIOPSやレイテンシでなくスループットの値を利用しています。他のブロックサイズとの比較を行うため、Small / Mediumブロックサイズでのスループットを算出（IOPS×ブロックサイズの値を利用）し比較をしてみました。Graph 9の結果を見ると、ブロックサイズが増加するに従ってスループットの値も増加すること、Random Readのスループットのほうが、Random Read-Write、Random Writeよりも高い値であることが分かります。この傾向はSmall / Mediumブロックサイズのスループット値（仮）を並べたときにも同様に見られるものでした。