セルフホスト型 DefectDojo Pro のハードウェアサイジング (Pro)

DefectDojo デプロイのサイジングは、突き詰めると2つの問いに集約されます。どれだけのデータを保持しているか、そして同時に何人がその中で作業しているか、です。このページでは、その両方について出発点となる目安を示します。

以下の内容は仕様ではなく、一般的なガイダンスとして扱ってください。数値は意図的に保守的に見積もっており、日常的なトリアージと定期的なスキャンインポートを並行して行うデプロイを想定しています。実際の数値は製品の使い方によって変わりますので、何かを準備する前に、表の下にある注記を読んでください。

スペックは、どのクラウドプロバイダーやオンプレミスのハードウェアにも当てはまるよう、汎用的な vCPU とメモリの数値で示しています。アプリケーションノードのガイダンスは Kubernetes を前提としています。単一ホストで Docker Compose を実行する場合は、同じ合計値を使用してください。

サイジング表#

範囲のどのあたりに位置するかは、ワークロードによって異なります。どのような場合に上位のティアが必要になるかに該当する項目がある場合は、範囲の上限側から始めてください。

5億件の行は、その上の行のパターンの延長ではなく、はるか先にある参考値です。したがって、この行と1,000万件のティアの間を補間しないでください。この2つの間に位置するデプロイは、個別にサイジングする必要があります。また5億件の行は、ハードウェアだけでは解決できない作業を前提としており、その内容は非常に大規模なデプロイで扱います。

これらの数値の読み方#

データベースの CPU よりもメモリが重要#

DefectDojo は、検出事項全体に対して集計負荷の高いクエリを実行します。これらのクエリは、作業対象データとそのインデックスがメモリから供給されている間は高速なままですが、データベースがディスクへアクセスし始めると急速に劣化します。どちらかを選ばなければならない場合は、コア数を増やすよりもメモリを増やしてください。表もこの考え方を反映しています。ティアが上がるごとにメモリはおおむね倍増しますが、CPU 数はそれよりもはるかにゆっくりとしか増えません。

アプリケーションノードは検出事項ではなくユーザー数に追従する#

表内の同時ユーザー数は、データセットが小さいほどチームも小規模である、という前提に基づいています。この前提は頻繁に崩れます。仮に検出事項が20万件でも、同時に100人が UI を使っているのであれば、アプリケーション層はそのユーザー数に合わせてサイジングし、データベースは検出事項数に応じたティアのままにしてください。この2つは独立してスケールします。

表のはるか先の部分には、1つだけ例外があります。インポートと重複排除はデータベースではなくアプリケーション層で実行されるため、データセットが十分に大きくなりこの処理が支配的になると、ノード数はユーザー数ではなく取り込み量に追従するようになります。5億件の行が、ユーザー数だけから想定されるよりもはるかに大きな値になっているのはこのためです。

ノードの構成は柔軟#

Kubernetes は、少数の大きなノードを与えても、より多くの小さなノードを与えても負荷を分散します。したがって上記のノード数は必須要件ではなく、うまく機能する構成の一例です。守っておく価値があるのは次の2点です。1つを失ってもアプリケーションが停止しないよう、少なくとも2ノードは確保すること。そして、個々の Pod が無理なくスケジュールされるよう、2 vCPU / 8 GB より小さいノードは避けることです。

ストレージ#

検出事項100万件あたり、データベースストレージは20〜30GBを見込んでください。この幅のどこに位置するかは、各検出事項にどれだけの情報を紐づけているかによります。長い説明文や多数のエンドポイントは、上限側に押し上げる要因になります。検出事項の行データそのものは、このうちのごく一部にすぎません。大部分の容量はインデックスと、各検出事項に紐づく関連テーブルが占めるため、行データだけからサイジングすると大幅に不足します。

1,000万件までのすべてのティアは、汎用 SSD 数百GBの範囲に収まります。ストレージが不足した場合のコストに比べれば、ストレージ自体は安価です。したがって、現在の状態ではなく、1年後に想定される状態に合わせてプロビジョニングしてください。プロバイダーがストレージのオートスケーリングを提供している場合は、有効にしておきましょう。

5億件の行は 2.5TB でサイジングしています。この数値は、稼働中のデータセットが積極的に管理されており、古い検出事項が無期限に蓄積されるのではなくホットパスからアーカイブされていることを前提としています。上記の100万件あたりの比率をそのまま単純に当てはめると、管理されていない5億件規模のデプロイでは、その数倍の値になってしまいます。このスケールを目指している場合は、アーカイブ戦略を後回しにするのではなく、サイジング作業の一部として扱ってください。

このスケールのストレージでは、容量だけでなくスループットにも注意が必要です。作業対象データがメモリに収まらなくなると、汎用ボリュームのデフォルトのベースライン IOPS が、容量よりもかなり先に制約となります。

メディアストレージは別枠であり、通常ははるかに小さくて済みます。スクリーンショットやリスク受容ドキュメントなどのアップロードされた成果物を保持するものなので、自分たちのアップロード習慣に基づいてサイジングしてください。

どのような場合に上位のティアが必要になるか#

検出事項の件数は代表的な指標ですが、件数だけから想定されるよりも早く上位のティアが必要になる要因がいくつかあります。

• インポートの量と頻度。 大規模なスキャンが頻繁に、特に複数同時に届くと、データベースと非同期ワーカーの両方に持続的な負荷がかかります。ビルドのたびにインポートを行う CI パイプラインが典型的な原因です。
• 重複排除。 重複排除は、受信した検出事項を既存の保有データと比較します。保有している検出事項が多く、重複排除の設定範囲が広いほど、インポートのたびに行われる処理は増えます。
• レポートとダッシュボード。 メトリクスビューや大規模なレポート生成は読み取り負荷が高く、日常的なトリアージよりも強くデータベースに負荷をかけます。
• API トラフィック。 ポーリングを行ったり大きな結果セットを取得したりするインテグレーションは、対話的なユーザー数には決して現れない同時負荷を追加します。
• 保持期間。 すべてを永久に保持するデプロイは、予定どおり次のティアへと成長していきます。古いデータをアーカイブまたは削除することで、現在のティアにより長くとどまることができます。

非常に大規模なデプロイ#

1,000万件のティアを超えると、ハードウェアだけでは答えにならなくなります。変化する点は2つです。

支配的な制約が読み取りから書き込みへと移ります。重複排除は、受信した各検出事項を既存の保有データと比較するため、インポートのコストは背後にあるデータセットのサイズとともに増大します。表の最上位では、通常これが、ユーザーが UI 上で気づく何かよりも先に直面する問題になります。それだけ大規模なデータセットを作り上げたインポート量は、一般的に今も継続して発生しているため、そのコストは一度きりではなく継続的に支払うことになります。

メモリの数値は、ホットセットが小さいままであることを前提としています。デプロイでは通常、最近の検出事項を扱い、古いものにはほとんど手を触れません。これによって、データベースはメモリよりもはるかに多くのデータを保持しながら、良好なパフォーマンスを維持できます。もしアクセスパターンが実際にデータセット全体にまんべんなく広がっているのであれば、表に記載した以上のメモリが必要になり、ある時点を過ぎると単一インスタンスでは足りなくなります。

この2つはどちらも、同じ作業の必要性を示しています。このスケールでは、パーティショニングを行い、コールドな検出事項を稼働中のデータセットからアーカイブすることのほうが、vCPU をさらに増やすことよりも重要であり、負荷の高いレポート処理はプライマリではなくリードレプリカで行うべきです。これはハードウェアの手当ての後ではなく、並行して計画してください。そして、プロビジョニングする前にぜひご相談ください。

迷ったら切り上げる#

ここに示した数値はすでに保守的に見積もられており、1段階大きすぎることのコストは、1段階小さすぎることのコストよりもはるかに小さく済みます。特にデータベースのメモリ逼迫は、緩やかには劣化しません。パフォーマンスは、問題が起きるその瞬間まで問題なく保たれます。

アプリケーションの容量を後から追加するのは、ノードを足すだけなので簡単です。一方、データベースのリサイズには通常ダウンタイムが伴うため、最初にきちんと見積もっておく価値があるのはこちらです。

ご質問やサポートについて#

これらはあくまで出発点であり、上限ではありません。デプロイが表の最上位に位置する場合や、ワークロードがここでの前提と異なる場合は、プロビジョニングする前にぜひご相談ください。担当のアカウント担当者、またはまでご連絡ください。