使用 AWS 進行擴展和性能優化

以下是各種檔案類型掃瞄所需時間的一些估計。TrendAI™透過將個別樣本檔案上傳至與掃瞄器位於同一區域的S3儲存桶中來收集這些資料。

如果大量掃描請求同時到達檔案儲存安全性，將會啟動多個 ScannerLambda 實例來並行處理這些請求。

確切的掃瞄時間取決於Lambda函數的AWS併發設置，以及您在AWS帳戶中同時運行的其他Lambda數量。

Lambda 並發設置數量不僅包括文件存儲安全性使用的 Lambda，還包括同一 AWS 帳戶中使用的所有其他 Lambda。您可以將此設置保留為默認值（由 AWS 設定），並確保此 AWS 帳戶中的 Lambda 並發數量足以進行文件存儲安全掃瞄。

以下是掃瞄所需時間和不同數量的壓縮 10 MB 檔案所使用的並發量的一些估計。表中的資料是在同一地區有一個存儲堆疊和一個掃瞄器的部署中收集的。

當共享或保留的並發數低於所需的並發數時，可能會因為限制而導致延遲。

此外，在掃瞄過程中會調用三個 Lambda 並發，分別是 BucketListener、Scanner 和 PostScanActionTag Lambda 並發。當在具有一個 S3 存儲桶和一個掃瞄器的架構中發生流量突增時，BucketListener Lambda 需要更多的並發。

AWS Lambda 服務的預設設定為允許 1000 個同時執行的總數，且 File Storage Security 的 ScannerLambda 函數遵循此配置。

ScannerLambda 透過設定事件來源對應至 SQS ScannerQueue 來接收掃瞄訊息。事件來源對應可以同時處理的批次數量上限為 1000，而 ScannerLambda 的批次大小為 1。換句話說，ScannerLambda 最多可以同時從 SQS ScannerQueue 輪詢 1000 個掃瞄訊息，即使仍有允許的並行執行。輪詢延遲決定了實際可以同時處理的掃瞄訊息數量。如果延遲為 1 秒，則 1 秒內最多可以處理 1000 個掃瞄訊息。當檔案上傳速度高於該數量時，掃瞄訊息會排隊至 SQS ScannerQueue。

檔案識別資訊也會由雲端中的TrendAI™全球主動雲端截毒技術伺服器進行掃描。（詳情請參閱架構和流程。）此伺服器設置為處理來自全球的大量負載，絕不會造成效能瓶頸。