このページのトピック
AWSのパフォーマンスとスケーリング
パフォーマンスメトリック（検索時間）
次に、さまざまなファイルタイプの検索にかかる時間の見積もりを示します。データは、 Scannerと同じリージョンにあるS3 バケット に個々のサンプルファイルをアップロードすることによって収集されました。見積もりでは、512MBのメモリ（初期設定）が File Storage Security Scannerに割り当てられているものとします。
- 100MB未満のEXEファイル：4秒
- 100MB未満のBINファイル：4秒
- 40MB未満のJPEGファイル：3秒
- 1600MB未満のMP4ファイル：3秒
- PDFファイルが1500MB未満の場合：22秒
- 100MB未満のTXTファイル：4秒
- 100MB未満のZIPファイル：5秒
負荷の急増に対する処理大量の検索が発生した場合の検索時間と 同時実行数 の見積もり方法を教えてください。
多数の検索要求が File Storage Security に同時に到達した場合は、 ScannerLambda の複数のインスタンスが呼び出され、要求が並行して処理されます。
正確な検索時間は、 Lambda 関数の AWS 同時実行数 、およびAWSアカウントで同時に実行している他のLambdaの数によって異なります。
Lambda同時実行数 設定数には、 File Storage Security が使用するLambdaだけでなく、同じAWSアカウントで使用される他のすべてのLambdaも含まれます。この設定は初期設定（AWSで設定）のままにして、このAWSアカウントの Lambda同時実行数 が、 File Storage Security の検索に十分であることを確認できます。
次に、検索にかかる時間と、圧縮された10MBのファイルのさまざまな数について使用された同時実行数の推定値を示します。表内のデータは、同じリージョンに1つの Storage Stack と1つの Scanner が存在する環境で収集されました。
| ファイルの総数 | ScannerLambdaの使用済み 同時実行数 | 合計検索時間（秒） |
|---|---|---|
| 1000 | 53 | 40 |
| 700 | 44 | 35 |
| 300 | 26 | 23 |
| 100 | 19 | 17 |
| 10 | 5 | 6 |
共有または予約された 同時実行数 が、使用される 同時実行数の要件よりも低い場合、調整が原因で遅延が発生する可能性があります。
さらに、検索プロセスで呼び出される3つの Lambda同時実行数 、つまり、BucketListener、 Scanner、およびPostScanActionTag Lambda同時実行数があります。S3 バケット と Scannerがそれぞれ1つずつあるアーキテクチャでトラフィックのバーストが発生した場合、BucketListener Lambda にはより多くの 同時実行数が必要です。
| ファイルの総数 | バケットリスナー | Scanner | PostScanActionTag |
|---|---|---|---|
| 1000 | 137 | 53 | 11 |
| 700 | 128 | 44 | 10 |
| 300 | 193 | 26 | 8 |
| 100 | 96 | 19 | 4 |
| 10 | 10 | 5 | 5 |
同時に検索できるファイル数
AWS Lambda サービスの初期設定は、合計許容同時実行数の合計が1000で、 File Storage SecurityのScannerLambda関数はこの設定に従います。そのため、2つの File Storage Security 検索サービスが同じリージョンの同じAWSアカウントに配置されている場合、1000件の同時実行は検索サービス間で共有されます（それぞれが1000件になることはありません）。さらに、同時実行は、同じリージョン内の同じAWSアカウントにデプロイされた他のLambdaとさらに分割されます。
ScannerLambdaは、SQS ScannerQueueへのイベントソースマッピングを設定することで、検索メッセージを受信します。イベントソースマッピングで同時に処理できるバッチの最大数は1000で、ScannerLambdaのバッチサイズは1です。つまり、ScannerLambdaは、同時実行が許可されている場合でも、SQS ScannerQueueから最大1,000件の検索メッセージを同時にポーリングできます。ポーリングの待ち時間によって、同時に処理できる検索メッセージの実際の量が決まります。待ち時間が1秒の場合、1秒で処理できる検索メッセージの最大数は1000に制限されます。ファイルのアップロード速度がこの値を超えると、検索メッセージはSQS ScannerQueueのキューに入れられます。検索メッセージが1時間以上キューに入れられると、検索プロセスがタイムアウトすることがあります。この場合は、ファイルを分散して異なるバケットまたはフォルダにアップロードすることをお勧めします。バケットまたはフォルダごとに、 Scanner Stack と Storage Stack の専用セットを1つ配信します。バケット内のフォルダを検索するには、 ObjectFilterPrefix パラメータをフォルダ名にスラッシュ文字（/）を付けて設定し、 Storage Stack を配信します。
ファイル識別情報は、クラウド内のTrend Micro Global Smart Protection Server によっても検索されます。（詳細については、 アーキテクチャおよびフロー を参照してください）。このサーバは、世界中からの非常に大きな負荷を処理するように設定されており、パフォーマンスのボトルネックを引き起こすことはありません。
複数のリージョンでのパフォーマンス
File Storage Securityのパフォーマンスは、Scanner Stackが関連するStorage Stackとは異なる大陸リージョンに配置されている場合、低下します。たとえば、Scanner Stackが米国北バージニア (us-east-1) にあり、関連付けられているStorage Stackがシンガポール (ap-southeast-1) にある場合、パフォーマンスが低下します。ただし、 Scanner および Storage Stack が、バージニア州北部 (us-east-1) やオハイオ州 (us-east-2) などの同じ一般領域にある場合は、パフォーマンスは最適なままです。
パフォーマンスを向上させる方法
パフォーマンスを向上させるには、次の方法があります。
- AWS設定を変更して、より多くの同時実行を許可する。詳細については、AWSのドキュメントを参照してください： https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html.
- Lambda エイリアス
TM-FSS-MANAGEDで、 プロビジョニングされた同時実行数 を設定します。警告： Lambda エイリアスTM-FSS-MANAGEDにはルーティングを設定しないでください。これにより、管理上の問題が発生する可能性があります。 - File Storage Security ScannerLambda関数がデプロイされているAWSアカウントおよびリージョンからサードパーティのLambdaを削除します。これにより、 Scanner専用の実行機能を使用できます。
- Scanner Stack を、関連するStorage Stackと同じ大陸のリージョンに移動します。これにより、大陸間検索で発生する可能性のある速度低下を回避できます。