ある会社は、Amazon FSx for Lustre の Persistent 2 ファイルシステム上で解析ジョブを実行しています。扱うファイルの数は 6,000 万件から 3 億件へ増えましたが、データの総量と読み書きのスループットはほとんど変わっていません。ファイル数が増えたあとは、ファイルの一覧を取得する処理と新しいファイルを作る処理だけが目立って遅くなりました。ジョブの処理内容と実行環境は変えていません。 ソリューションアーキテクトは、この問題を解決するためにどのアクションを実行すべきですか。
ファイル数の急増で遅くなったファイルシステムについて、どの性能の軸を引き上げるかを選ぶ
ファイルを、より多くのディレクトリへ分けて配置する。
1 つのディレクトリに入るファイルの数を減らすと、そのディレクトリの一覧を取得する処理は軽くなります。AWS も Persistent 2 のファイルシステムでは 1 ディレクトリあたり 10 万件未満に抑えることを推奨しており、親ディレクトリのロックを取得する時間が短くなる効果があります。
ただしプロビジョニングされているメタデータ IOPS の上限はディレクトリの分け方では変わらず、ジョブ全体で必要な操作の数も変わらないため同じ上限に突き当たります。すでに置かれている 3 億件のファイルを配置し直す作業そのものも、大がかりになります。
解析ジョブを実行するクライアントインスタンスの台数を増やす。
Amazon FSx for Lustre は多数のクライアントから並行して読み書きされることを前提にした並列ファイルシステムで、クライアントを増やせば全体の読み書きの並列度は上がります。計算側が処理のボトルネックになっている場面では正しい対処です。
しかしファイルの作成や一覧取得を受け付ける能力にはファイルシステム側で決まっている上限があり、要求を出す側を増やしてもこの上限が変わりません。台数を増やすほど同じ上限に要求が集中し、待ち時間はかえって伸びます。
メタデータ IOPS をユーザープロビジョニングモードで引き上げる。
Amazon FSx for Lustre では、ファイルの中身を置くオブジェクトストレージターゲット (OST) と、ファイル名やディレクトリの情報を置くメタデータターゲット (MDT) が分かれています。メタデータ IOPS は 1 秒あたりに作成・一覧取得・読み取り・削除できるファイルとディレクトリの数を決める値で、読み書きのスループットとは別の軸です。
データの総量がほぼ変わらないままファイルを扱う操作だけが遅くなっているので、不足しているのはこの値です。Persistent 2 ではメタデータ IOPS をストレージ容量とは独立してプロビジョニングでき、自動モードからユーザープロビジョニングモードへ切り替えれば、ファイルシステムを作り直さずに引き上げられます。
クライアント側でディレクトリの一覧結果をキャッシュする設定を有効にする。
同じディレクトリを何度も参照する処理では、一度取得した一覧をクライアント側に保持して再利用する設定が効きます。読み取りが繰り返される場面では、要求の回数そのものを減らせます。
ただし本問ではファイルの作成も遅くなっており、まだ存在しないファイルの作成は保持した一覧を使っても速くなりません。要求を出す側の工夫では、受け付けられる回数の上限そのものが変わりません。
共有ファイルストレージが遅いときは「どの軸が足りないか」で切り分けます。
・スループット不足 — 大きなファイルの読み書きに時間がかかる。ディスク側の帯域やクライアント側の並列度が効きます。
・ファイル操作の処理能力の不足 — 作成・削除・一覧取得が遅い。データ量ではなくファイルの数が桁違いに増えたときに現れます。
Amazon FSx for Lustre はファイルの中身と、ファイル名やディレクトリの情報を別々の場所で管理する構造で、この 2 つの軸が独立しています。
後者を担うのがメタデータ IOPSで、Persistent 2 では自動モードからユーザープロビジョニングモードへ切り替えて引き上げられます。ただしメタデータ構成を指定して作成したファイルシステムに限られ、値は上げる方向にしか変えられません。
『データの総量はほとんど増えていないのにファイル数だけ桁違いに増えた』が合図です。