目次

Smart Check サイジングガイドライン

このページでは、 Smart Check クラスタのサイジングに関するガイダンスを示します。Smart Check は、垂直方向(CPUとメモリを追加する場合)または水平方向(クラスタにワーカーノードを追加する場合)に拡張できます。

まとめと推奨事項

テストの結果、垂直方向のスケーリングは水平方向のスケーリングよりも高速です。たとえば、m5a-xlargeインスタンスの4つのワーカーノードを使用して Deep Security Smart Check を配置した場合、m5-largeインスタンスの8つのワーカーノードを使用した場合よりも検索速度が速くなりました。

1ドルあたりのパフォーマンスを最適化するには、CPUまたはメモリの使用率が高くなるまでポッドをスケーリングすることをお勧めします(「 Scale Smart Check ポッド」を参照)。Podスケーリングの結果に示すように、CPU使用率がメモリよりも先に制限されることがわかったため、m5-largeからm5a-xlargeにアップグレードするだけでなく(CPUとメモリの両方を増やす)、カスタムEC2インスタンスのCPUを増やすことを検討してください。

Smart Check をAmazon RDSでテストし、 Smart Check がデータベースリソースに与える影響を特定しました。テストの結果、検索時にRDSデータベースに大きな影響はありませんでした。

これらの結論に達した方法の詳細を以下に示します。

詳細

このセクションでは、「概要と推奨事項」セクションでどのようにして結論に達したかについて詳しく説明します。

テスト環境

クラスタ設定

テストには次のクラスタ設定を使用しました。

クラスタ設定 クラスタ名 ノード インスタンスの種類 クラスタ内の合計vCPU クラスタの合計メモリ
ベースライン設定 sc-d-4 4 m5-large(2CPU、8GB) 8 32 GB
水平スケーリング sc-d-8 8 m5-large(2CPU、8GB) 16 64 GB
垂直スケーリング sc-xl-4 4 m5a-xlarge(4CPU、16GB) 16 64 GB
水平および垂直スケーリング sc-xl-8 8 m5a-xlarge(4CPU、16GB) 32 128 GB

AWSインスタンスの種類は時間の経過に伴って変化する可能性があるため、テスト時のm5-largeインスタンスとm5a-xlargeインスタンスの仕様を次に示します。

仕様書 m5-large m5a-xlarge
プロセッサの種類 第1または第2世代Intel Xeon Platinum 8000シリーズ AMD EPYC 7000シリーズ
クロック速度 ターボクロック速度最大3.1 GHz 最大2.5 GHzのターボクロック速度
Advanced Vector Extensionのサポート はい。512(AVX-512)命令セットm4インスタンスに比べてコアあたり2倍のFLOPS。 いいえ
メモリ 8 GB 16 GB
インスタンスストレージ EBSのみ EBSのみ
ネットワーク帯域幅 最大10Gbps 最大10Gbps
EBS帯域幅 最大4750Mbps 最大2880Mbps

レジストリ設定

テストには次のレジストリ設定を使用しました。

レジストリサイズ 画像総数 平均画像サイズ
11.949 GB 43 284.5 MB

データベース設定

EKSインスタンスごとにt2.small RDSインスタンスを使用しましたが、テストでは、検索中にRDSデータベースに大きな影響はないことが判明しました。

Amazon RDSのタイプは時間の経過とともに変化する可能性があるため、テスト時のt2.smallインスタンスの仕様を次に示します。

  • コア: 1
  • ** vCPU:** 1
  • ** CPUクレジット/時間:** 12
  • メモリ: 2GB
  • ネットワークパフォーマンス(Gbps): 低〜中

クラスタリソースの使用率

クラスタの平均CPU使用率を示すグラフ

クラスタの平均CPU使用率を示すグラフ

Smart Check ポッドのスケーリング

Overrides.yamlファイルを使用して、各ポッドの複製数を指定できます。

  1. overrides.yaml ファイルに次のスニペットを追加します。

    replicas:
        malwareScan: 5
        scan: 5
        imageScan: 5
        vulnerabilityScan: 5
        contentScan: 5
  2. 次に、ターミナルで次のコマンドを実行します。

    helm upgrade --values /path/to/overrides.yaml <release-name> /path/to/smartcheck-helm/

初期設定(4ノードのm5.large)では、各ポッドの複製数を5にスケーリングすると、平均CPU使用率は約72%になります。つまり、5を超える数のレプリカを設定する可能性があります。

画像に通常含まれるコンテンツの検出結果の種類がわからない場合は、ポッドを線形にスケーリングする(すべてのカウントが異なる数ではなく5とカウントする)ことをお勧めします。ただし、たとえば、コンテンツの検出結果の大部分が不正プログラムである場合は、不正プログラムポッドの複製数を増やすこともできます。

脆弱性検索ポッドが削除された場合、通常はディスクに十分な空き容量がないためです。より多くのスペースを割り当てるには、overrides.yamlに次の行を追加します。
vulnerabilityScan:
  workVolume:
    ## The amount of space to request for the vulnerability scan working volume
    ##
    ## Default value: 3Gi
    sizeLimit: 4Gi

ポッドのスケーリング結果

このセクションでは、キャッシュを無効にした場合のテスト結果について説明します。 Smart Checkでは初期設定でキャッシュが有効になっているため、ほとんどの環境で実際のパフォーマンスはこれより高くなります。

次の結果では、R1、R2、R3が複製数です。

各検索は10回プッシュされました(1時間の中断で10回の反復)。結果は次のとおりです。

  • sc-d-4: R3の検索速度はR1より130%速く、R5はR1より152%高速。
  • sc-d-8: R3の検索速度はR1より135%速く、R5はR1より237%高速。
  • sc-xl-4: R3の検索速度はR1より82%速く、R5はR1より144%高速。
  • sc-xl-8: R3の検索速度はR1より90%速く、R5はR1より161%高速。

平均検索速度の比較を示すグラフ

平均メモリ使用量の比較を示すグラフ

平均CPU使用率の比較を示すグラフ

改善量を比較したグラフ

R1(複製数1)がベースライン(つまり、複製数を複製数1と比較すると1:1)であるとします。

  • R3にスケーリングすると、R1に比べて少なくとも1.82倍から2.3に向上します。
  • R5にスケーリングすると、R1と比較して2.44〜3.37以上の改善が見られます。

同じクラスタ設定内のポッド複製数を増やすと、追加リソース(CPUとメモリ)をほとんど使用せずに、検索速度が大幅に向上しました。