なぜ手元のマネージド NFS で期待通りのパフォーマンスが出ないのか?
利用しているクラウド事業者のマネージド NFS サービスのスループットが大幅に上がったので、〇〇から移行したのだが、思ったほどパフォーマンスが出ない。
というお悩みを、今春に入ってから、数件頂いております。「〇〇」はクラウド内の VM にお客様が自前展開している nfsd であったり、CephFS など他の ReadWriteMany 共有ファイルシステムであったり、様々です。
ご相談者の運用環境は守秘を要する場合もあり、必ずしもご事情は深くは伺っておりません。 しかし、とある大手クラウド事業者が「マネージド NFS で読み書き共に最大スループットを向上させた」と発表した影響も、幾つかある理由の一つかもなど推察しています。
ともあれ、結論だけ先に申しますと、下記の一般論に行き着きます。
- ReadWriteMany 型の共有ファイルシステムは、使われ方次第では、高スループット性能を活かせない。
一般に、長文の企業ブログは読んでいただけない傾向がありますので、要点だけお知らせします。
一般論で背景を整理する
一般論1: ストレージは、転送サイズが小さいアクセスが苦手である
当サイトの他のベンチマーク記事のグラフを、いくつか眺めていただくと、判りやすいと思います。
https://www.monami-ya.jp/posts/2023/04/17/rook-ceph-benchmark-rbd-performance/ https://www.monami-ya.jp/posts/2023/04/18/rook-ceph-benchmark-cephfs-performance-1/
特に御覧いただきたいのは、折れ線グラフです。 横軸はブロックサイズで、縦軸はスループット性能です。全てのグラフで、小さなブロックサイズのとき(つまり左側)で性能が低めに出ているのが、お分かり頂けると思います。
一般論2: 共有分散ストレージにはメタデータがある
この点、背景をご理解頂くための前提知識です。ブロックデバイスとは異なり、多くの共有分散ストレージはそれ自身がファイルシステムとして動作する前提なので、ファイルを管理するためのメタデータが存在します。
メタデータという言葉にお馴染みが薄い場合には「ディレクトリ」に相当するものとご理解頂ければ概ね間違いないです。ファイルの中身はメタデータとは別に存在します。
ファイルを開く、閉じる、削除する、生成するといったとき、共有分散ストレージはメタデータを読み書きします。
メタデータは、そのストレージを共有する全てのクライアント間で一貫性が提供されなければなりません。よって、メタデータのクライアント側キャッシュによる高速化実現は、一般論としては、困難です。
一般論3: メタデータのサイズは小さい
メタデータのサイズは、ファイル本体よりも小さい場合(4kB 程度)が一般的です。
上記一般論から起こりがちなこと
ここで、前掲した、一般論1〜3が繋がります。 つまり、ファイルのオープン・クローズや生成削除等を頻繁に行う用途の場合、スループット性能低下の元凶である、メタデータのアクセスが増えます。結果もちろん、性能面で不利な状況に陥ります。
運用環境での症状は千差万別ですので、具体的な状況はさらなる調査が必要となります。しかし、全ての環境で、多かれ少なかれ上記のようなスループット性能劣化は起こります。 採用検討の際には、スループット値の実測以外にも、様々な形でのベンチマークにより、実運用時に期待できる実性能を評価することが肝要です。
高スループット型マネージド NFS の向き不向き
弊社は Rook/Ceph を推してはおりますが、お客様環境でのマネージド NFS 採用を妨げるものではありません。ご参考までに、向き不向きについて、一例を示します。
向くアプリケーション
「メタデータへのアクセスが少ない大容量データの共有」は向きます。機械学習や動画作成におけるデータのダウンロード共有などは、高スループットの恩恵を受けやすいかもしれません。ダウンロード目的でしたら、ファイルをオープンしたあとは、全てコピーが終わるまでファイルはクローズしませんので。
また Web CMS のバックエンドストレージとしての利用も、構成によっては、向きます。その際には、なるべく静的ファイルを生成する構成にしたうえでの、CDN 積極的活用が鍵となります。
向かないアプリケーション
向くアプリケーションの対極になります。データベースは一般的にはファイルのオープンとクローズ、またジャーナルの生成やコンパクションでの削除などメタデータへのアクセスが多くなりがちですので、向かない可能性が高いです。
また、広義のデータベースの一種とも言える、ソースコード管理システムも、向かないアプリケーションに分類される可能性があります。たとえば git リポジトリはディレクトリ構造ににより履歴を管理しガベージコレクション時にファイルアクセスを伴います。さらに GitLab や Gerrit のような、複数 git リポジトリを管理するよなエンタープライズ製品では、その不利が拡大する可能性があります。
ただし、これらは傾向を述べているに過ぎないことにご留意ください。各アプリケーションの、またはお客様の質要求レベルにより、マネージド NFS でも十分に質要求を満たせる可能性はあります。さらに、中長期的視点では、マネージド NFS はクラウド事業者側の OS に特別なチューニングを施せる余地があり、メタデータ関連の性能向上が見込める可能性もあります。
まとめ
高スループット型マネージドNFS における、スループット性能阻害要因について、背景となる一般論と、そこから導き出せる “向き・不向き” について概説しました。
分散共有ファイルシステムは、ブロックストレージとは性能評価ポイントが異なる面があります。パソコンやスタンドアロンのサーバではブロックストレージの利用が一般的なので、マネージド NFS 導入前性能評価では見落としてしまう項目が出がちで、結果、導入後の性能問題に繋がりがちです。
弊社は、8〜16 ノード程度の中規模 Rook/Ceph の導入検討や運用でお困りのお客様に向けて、サポートサービスを行っております。ご相談の結果、クラウドのマネージドソリューションのほうが合理的な場合には、その旨をご提案する場合もあります。
Rook/Ceph 導入という結論ありきではない、事前検討のお手伝いも承ります。ぜひお問い合わせください。