ファイルとディレクトリの合計数：カタログ化するオブジェクトの総数は、コンピューティングとストレージの要件を決定する主要因です。オブジェクト数が増えるほど、メモリ、CPU、ストレージの必要量も比例して増加します。

ディレクトリ構造：リソースの使用量は、ディレクトリのネストの深さや、ファイルが共有やボリュームにどのように分散されているかによって異なります。深くネストされた構造や高度に断片化された構造は、よりフラットな階層構造で同じファイル数の場合よりも多くのリソースを必要とする可能性があります。

必要なスキャン処理能力：初期カタログの完了速度は、CPUとメモリ割り当てに直接関係します。推奨サイズを下回るプロビジョニングを行うと、スループットが低下し、初期スキャンウィンドウが長くなります。

ストレージ パフォーマンス：ハイパフォーマンス ストレージを強く推奨します。メタデータのインデックス作成とイベント処理には、展開規模に比例した持続的な IOPS とスループットが必要です。

初期カタログ期間の延長：計算処理能力の低下により、1日あたりのスキャン対象オブジェクト数が減少します。例えば、30億個のオブジェクトを対象とするデプロイメントでも、より小さなサイズでプロビジョニングされた場合、目標の3～4日よりも大幅に時間がかかる可能性があります。

継続的な取り込みスループットの低下：継続的な負荷がかかると、新しいファイルイベントと増分スキャン更新の処理速度が低下します。

ストレージ容量リスク：オブジェクトの総数に対してストレージ容量が不足すると、メタデータインデックスが容量のしきい値に近づく可能性があります。通常、この問題はシステム全体の再デプロイを行わずに、ストレージ容量を拡張することで解決できます。

ホストVM上のvCPU、メモリ、またはストレージを増やしてください。

クラスターの再構成や再インストールは不要です。

AIDE Lite はハイパフォーマンスや水平方向のスケールアウトをサポートしていません。環境内のファイル数が常に30億を超える場合、または高可用性と耐障害性が必要な場合は、代わりに"AIDE Enterprise"を導入してください。

ファイルとディレクトリの合計数：オブジェクトの合計数は、ストレージとコンピューティングの要件を決定する主要な要因です。大規模な環境では、処理負荷を分散し、パフォーマンスを維持するために、追加のクラスタノードが必要になります。

高可用性レプリケーション： エンタープライズ展開では、耐障害性のために、デフォルトでノード間でのデータレプリケーションが有効になります。レプリケーションを行うと、同等のシングルノード構成と比較して、ストレージとメモリの総必要量が増加します。

ノード数とワークロードの分散：処理スループットとカタログの総容量は、クラスタ内のノード数に応じてスケールします。追加ノードは、インデックス作成のワークロードとストレージ容量の両方をクラスタ全体に分散します。

必要なスキャン処理能力：クラスタ全体のCPUとメモリの割り当てによって、1日のスキャン速度と初期カタログの完了速度が決まります。

ノードごとのストレージ性能：各ノードには高性能ストレージを強く推奨します。クラスタ全体の容量はノード数に比例して増加します。

初期カタログ期間の延長：ノード数が少ない、またはノードあたりのリソースが少ないとスループットが低下し、初期カタログ期間が比例して延長されます。

ピーク負荷時の処理遅延の増加：クラスター全体のメモリ不足により、大量のデータを取り込む期間中に処理遅延が増加する可能性があります。進行中の処理は中断されませんが、持続的なスループットは低下します。

ストレージ容量リスク：対象オブジェクト数に対してクラスタストレージが不足すると、メタデータインデックスが容量しきい値に近づく可能性があります。既存ノードのストレージを拡張する（無停止）か、専用のストレージ ノードを追加することで、この問題を解決できます。

ワーカーノードを追加して、スキャン処理とイベント取り込みに利用できるCPUとメモリを増やします。

専用ストレージ ノードを追加して、カタログの総容量を増やします。これは、事前定義された最大デプロイメント サイズを超えて環境をスケールアウトするための主要な方法です。

クラスターにノードを追加することで、60億ファイルを超える規模にも対応できます。カスタムスケールにおけるノードのサイジングに関するガイダンスについては、NetAppの担当者にお問い合わせください。

既存のエンタープライズクラスタにノードを追加しても、進行中のスキャン操作には影響しませんが、変更はアクティビティの少ない時間帯に行うようにしてください。