本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 最佳實務設計模式：最佳化 Amazon S3 效能
您的應用程式從 Amazon S3 上傳和擷取儲存體時，可輕鬆達到請求中每秒數千筆交易的效能。Amazon S3 會自動調高請求率。例如，您的應用程式可以達成每個分割的 Amazon S3 字首每秒至少 3,500 個 PUT/COPY/POST/DELETE 和 5,500 個 GET/HEAD 請求。在儲存貯體中的字首數不受限制。您可以使用並行化提升讀取或寫入的效能。例如，如果您在 Amazon S3 儲存貯體裡建立 10 個字首，平行讀取，您可以縮放讀取效能至每秒 55,000 讀取要求。同樣，您可以透過寫入多個前綴來縮放寫入操作。在讀取和寫入操作中，擴展會逐漸發生，而不會立即發生，而且實際效能會根據您的特定工作負載特性、使用模式和系統組態而有所不同。Amazon S3 不斷地擴展到新的更高請求率時，您可能會看到一些 503 (減慢) 錯誤。擴展完成時，這些錯誤會消失。如需有關建立和使用字首的詳細資訊，請參閱 [使用字首整理物件](using-prefixes.md)。
例如，Amazon S3 上的部分資料湖應用程式在查詢超過數 PB 資料時，可能掃描數百萬或數十億個物件。這些資料湖應用程式實現單一執行個體傳輸率，讓 [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html) 執行個體充分利用網路介面，在單一執行個體上最高可達到 100 Gb/s。然後，這些應用程式會彙總多個執行個體之間的傳輸量，以取得每秒多個 TB。
其他應用程式為對延遲敏感的應用程式，例如社交媒體簡訊應用程式。這些應用程式可以實現一致的小型物件延遲 (以及適用於大型物的第一個位元組輸出延遲)，大約 100–200 毫秒。
AWS 其他服務也有助於加速不同應用程式架構的效能。例如，如果您想要單一 HTTP 連線有更高的傳輸速率或低於十毫秒的延遲，請使用 [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) 或 [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html)，以搭配 Amazon S3 進行快取。
此外，如果您希望在相距遙遠的用戶端與 S3 儲存貯體之間快速傳輸資料，請使用 [使用 Amazon S3 Transfer Acceleration 設定快速安全的檔案傳輸](transfer-acceleration.md)。Transfer Acceleration 使用 CloudFront 中遍佈全球的節點，加速地理距離的資料傳輸。如果您的 Amazon S3 工作負載搭配 伺服器端加密使用 AWS KMS，請參閱《 AWS Key Management Service 開發人員指南》中的[AWS KMS 限制](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)，以取得您的使用案例所支援請求率的相關資訊。
下列主題針對使用 Amazon S3 的應用程式，說明最佳化效能的最佳實務指導方針和設計模式。請參閱 [Amazon S3 的效能準則](optimizing-performance-guidelines.md)和 [Amazon S3 的效能設計模式](optimizing-performance-design-patterns.md)，以取得 Amazon S3 效能最佳化的最新資訊。
**注意**
如需將 Amazon S3 Express One Zone 儲存類別與目錄儲存貯體搭配使用的詳細資訊，請參閱 [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone) 和 [使用目錄儲存貯體](directory-buckets-overview.md)。
**Topics**
+ [Amazon S3 的效能準則](optimizing-performance-guidelines.md)
+ [Amazon S3 的效能設計模式](optimizing-performance-design-patterns.md)
# Amazon S3 的效能準則
建置從 Amazon S3 上傳和擷取物件的應用程式時，請依照我們的最佳實務指導方針來最佳化效能。我們還提供更詳細的[Amazon S3 的效能設計模式 ](optimizing-performance-design-patterns.md)。
為了讓您在 Amazon S3 上的應用程式獲得最佳效能，建議採用下列指導方針。
**Topics**
+ [測量效能](#optimizing-performance-guidelines-measure)
+ [水平擴展儲存體連線](#optimizing-performance-guidelines-scale)
+ [使用位元組範圍擷取](#optimizing-performance-guidelines-get-range)
+ [對延遲敏感的應用程式重試請求](#optimizing-performance-guidelines-retry)
+ [在相同的 中結合 Amazon S3 （儲存） 和 Amazon EC2 （運算） AWS 區域](#optimizing-performance-guidelines-combine)
+ [使用 Amazon S3 Transfer Acceleration 將距離造成的延遲降到最低](#optimizing-performance-guidelines-acceleration)
+ [使用最新版本的 AWS SDKs](#optimizing-performance-guidelines-sdk)
## 測量效能
最佳化效能時，請查看網路傳輸量、CPU 和 DRAM 要求。根據這些不同資源的混合需求，可能值得評估不同的 [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html) 執行個體類型。如需詳細資訊，請參閱《Amazon EC2 使用者指南》**中的[執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。
測量效能時，使用 HTTP 分析工具來查看 DNS 查閱時間、延遲和資料傳輸速度也很有幫助。
若要了解效能需求並最佳化您應用程式的效能，您也可以監控收到的 503 錯誤回應。監控某些效能指標可能會產生額外費用。如需詳細資訊，請參閱 [Simple Storage Service (Amazon S3) 定價](https://aws.amazon.com/s3/pricing/)。
### 監控 503 (減慢) 狀態錯誤回應的數目
若要監控您取得的 503 狀態錯誤回應數目，您可以使用下列其中一個選項：
+ 使用 Amazon S3 的 Amazon CloudWatch 請求指標。CloudWatch 請求指標包含 5xx 狀態回應的指標。如需 CloudWatch 請求指標的詳細資訊，請參閱 [使用 Amazon CloudWatch 監控指標](cloudwatch-monitoring.md)。
+ 使用 Amazon S3 Storage Lens 的進階指標區段中提供的 503 (服務無法使用) 錯誤計數。如需詳細資訊，請參閱[使用 S3 Storage Lens 指標來改善效能](storage-lens-detailed-status-code.md)。
+ 使用 Amazon S3 伺服器存取記錄 使用伺服器存取記錄，您可以篩選並檢閱接收 503 (內部錯誤) 回應的所有請求。您也可以使用 Amazon Athena 來剖析日誌。如需伺服器存取記錄日誌的詳細資訊，請參閱「[使用伺服器存取記錄記錄要求](ServerLogs.md)」。
透過監控 HTTP 503 狀態錯誤碼的數量，您通常可以獲得寶貴的洞見，了解哪些字首、金鑰或儲存貯體得到最多的限流請求。
## 水平擴展儲存體連線
跨許多連線傳播請求是常用的設計模式，藉此水平擴展效能。建置高效能應用程式時，請將 Amazon S3 視為一個非常大的分散式系統，而不是像傳統儲存伺服器那樣的單一網路端點。您可以向 Amazon S3 發出多個並行請求，以達到最佳效能。將這些請求分散到不同的連線，以從 Amazon S3 獲得最大可存取的頻寬。Amazon S3 對儲存貯體的連線數沒有任何限制。
## 使用位元組範圍擷取
您可以在 [GET 物件](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html)請求中使用 `Range` HTTP 標頭，以從物件中擷取位元組範圍，僅傳輸指定的部分。您可以對 Amazon S3 使用並行連線，從同一物件內擷取不同的位元組範圍。與單一整個物件請求相比，這可協助您實現更高的彙總傳輸量。擷取大型物件的更小範圍也可讓您的應用程式在請求中斷時改善重試時間。如需詳細資訊，請參閱[下載物件](download-objects.md)。
如果物件是使用多部件上傳的 PUT，則良好實務為以相同部件大小 (或至少與部件界限一致) GET 它們，以取得最佳效能。GET 請求可以直接處理個別組件；例如，`GET ?partNumber=N.`
## 對延遲敏感的應用程式重試請求
積極的逾時和重試可協助推動一致的延遲。由於 Amazon S3 的範圍很大，如果第一個請求很慢，則重試的請求可能會採取不同路徑且很快成功。 AWS SDKs 具有可設定的逾時和重試值，您可以根據特定應用程式的公差進行調整。
## 在相同的 中結合 Amazon S3 （儲存） 和 Amazon EC2 （運算） AWS 區域
雖然 S3 儲存貯體名稱是全域唯一，但每個儲存貯體都存放在您建立儲存貯體時選取的區域中。若要進一步了解儲存貯體命名準則，請參閱[儲存貯體概觀](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)和[儲存貯體命名規則](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)。為了最佳化效能，我們建議您 AWS 區域 盡可能從相同 中的 Amazon EC2 執行個體存取儲存貯體。這可協助減少網路延遲和資料傳輸成本。
如需資料傳輸成本的詳細資訊，請參閱 [Amazon S3 定價](https://aws.amazon.com/s3/pricing/)。
## 使用 Amazon S3 Transfer Acceleration 將距離造成的延遲降到最低
[使用 Amazon S3 Transfer Acceleration 設定快速安全的檔案傳輸](transfer-acceleration.md) 可讓用戶端與 S3 儲存貯體之間長地理距離的檔案傳輸變得迅速、簡單又安全。Transfer Acceleration 善用 [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) 中遍佈全球的節點。資料到達節點時會經由最佳化的網路路徑而路由至 Amazon S3。Transfer Acceleration 非常適合在各大洲定期傳輸數 GB 到數 TB 的資料。也有助於從世界各地上傳至集中型儲存貯體的用戶端。
您可以使用 [Amazon S3 Transfer Acceleration 速度比較工具](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html)，比較各 Amazon S3 區域的加速和非加速上傳速度。速度比較工具在使用和不使用 Amazon S3 Transfer Acceleration 的情況下，透過分段上傳，將檔案從您的瀏覽器傳送至各個 Amazon S3 區域。
## 使用最新版本的 AWS SDKs
AWS SDKs 為許多最佳化 Amazon S3 效能的建議準則提供內建支援。這些開發套件提供更簡單的 API 以方便從應用程式內善用 Amazon S3，並定期更新來遵循最新的最佳實務。例如，軟體開發套件包括在發生 HTTP 503 錯誤時自動重試請求的邏輯，並投資於程式碼以回應並適應慢速連線。
這些開發套件也提供 [Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html)，在適當情況下會使用位元組範圍請求，以自動水平擴展連線，達到每秒數千個請求。請務必使用最新版本的 AWS SDKs來取得最新的效能最佳化功能。
使用 HTTP REST API 請求時，您也可以最佳化效能。使用 REST API 時，您應該遵循屬於軟體開發套件的相同最佳實務。允許逾時和重試慢速請求，並有多個連線允許平行擷取物件資料。如需有關使用 REST API 的詳細資訊，請參閱 [Amazon Simple Storage Service API 參考](https://docs.aws.amazon.com/AmazonS3/latest/API/)。
# Amazon S3 的效能設計模式
設計應用程式以從 Amazon S3 上傳和擷取物件時，請採用我們的最佳實務設計模式，讓您的應用程式達到最佳效能。我們也提供[Amazon S3 的效能準則 ](optimizing-performance-guidelines.md)，供您在規劃應用程式架構時考量。
若要最佳化效能，您可以使用下列設計模式。
**Topics**
+ [對經常存取的內容使用快取](#optimizing-performance-caching)
+ [對延遲敏感之應用程式的逾時和重試](#optimizing-performance-timeouts-retries)
+ [水平擴展和請求並行化以實現高輸送量](#optimizing-performance-parallelization)
+ [使用 Amazon S3 Transfer Acceleration 加速異地資料傳輸](#optimizing-performance-acceleration)
+ [最佳化高請求率工作負載](#optimizing-performance-high-request-rate)
## 對經常存取的內容使用快取
許多將資料儲存在 Amazon S3 的應用程式會提供資料「工作集」，供使用者重複請求。如果工作負載對一組常用的物件傳送重複的 GET 請求，您可以使用快取，例如 [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html)、[Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) 或 [AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/index.html) 來達到最佳效能。成功採用快取可以產生低延遲和高資料傳輸率。使用快取的應用程式傳送至 Amazon S3 的直接請求也較少，有助於減少請求成本。
Amazon CloudFront 是快速的內容交付網路 (CDN)，在分散各地的大量連接點 (PoP) 之中，可直接快取來自 Amazon S3 的資料。在可能從多個區域或透過網際網路存取物件時，CloudFront 允許在存取物件的使用者附近快取資料。這樣能夠高效能傳遞熱門的 Amazon S3 內容。如需有關 CloudFront 的資訊，請參閱 [Amazon CloudFront 開發人員指南](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/)。
Amazon ElastiCache 受管的記憶體內快取。ElastiCache 可讓您佈建將物件快取在記憶體中的 Amazon EC2 執行個體。此快取會導致 GET 延遲數量級減少，以及下載傳輸量顯著增加。若要使用 ElastiCache，請修改應用程式邏輯，將熱門物件移入快取，而在向 Amazon S3 請求熱門物件之前，先檢查快取中有無這些物件。有關使用 ElastiCache 來提高 Amazon S3 GET 效能的範例，請參閱部落格文章：[使用 Amazon ElastiCache for Redis 讓 Amazon S3 效能飛快](https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/)。
AWS Elemental MediaStore 是一種快取和內容分發系統，專為 Amazon S3 的影片工作流程和媒體交付而打造。MediaStore 特別針對影片提供端對端儲存 API，建議需要高效能的影片工作負載。如需 MediaStore 的詳細資訊，請參閱《AWS Elemental MediaStore 使用者指南》[https://docs.aws.amazon.com/mediastore/latest/ug/](https://docs.aws.amazon.com/mediastore/latest/ug/)。
## 對延遲敏感之應用程式的逾時和重試
在某些情況下，應用程式會收到 Amazon S3 的回應，這表示有必要重試。Amazon S3 會將儲存貯體和物件名稱對應至相關聯的物件資料。如果應用程式產生高請求率 (通常對少數物件維持每秒超過 5,000 個請求的速率)，則它可能會收到 HTTP 503 *slowdown* 回應。如果發生這些錯誤，每個 AWS 開發套件會使用指數退避來實作自動重試邏輯。如果您未使用 AWS 開發套件，則應該在收到 HTTP 503 錯誤時實作重試邏輯。如需退避技術的資訊，請參閱《AWS SDK 和工具參考指南》**中的[重試行為](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)。
Amazon S3 會隨著持續的新請求率而自動擴展，動態地最佳化效能。當 Amazon S3 在內部針對新請求率最佳化時，您將會暫時收到 HTTP 503 請求回應，直到最佳化完成為止。在 Amazon S3 於內部針對新請求率來最佳化效能之後，通常就能處理所有請求而不必重試。
對於需要低延遲的應用程式，Amazon S3 建議追蹤並積極重試較慢的操作。當您重試請求時，我們建議對 Amazon S3 使用新連線，並執行全新的 DNS 查閱。
當您進行大量易變大小的請求 (例如，超過128 MB) 時，我們建議追蹤正要實現的傳輸量並重試最慢的 5％ 請求。當您提出更小的要求 (例如，少於 512 KB)，其中中位數延遲通常在幾十毫秒範圍內時，良好實務為 2 秒後重試 GET 或 PUT 操作。如果需要額外重試，最佳實務為退避。例如，我們建議 2 秒後發出一次重試，再過 4 秒後發出第二次重試。
如果您的應用程式對 Amazon S3 提出固定大小的請求，則這些請求的回應時間都應該會更一致。在此情況下，簡單策略為識別最慢的 1% 請求，然後重試它們。即使單次重試也常常有效地減少延遲。
如果您使用 AWS Key Management Service (AWS KMS) 進行伺服器端加密，請參閱《 *AWS Key Management Service 開發人員指南*》中的[配額](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)，以取得您的使用案例支援之請求率的相關資訊。
## 水平擴展和請求並行化以實現高輸送量
Amazon S3 是非常大的分散式系統。為了協助您善用其規模，建議您水平擴展對 Amazon S3 服務端點的並行請求。除了在 Amazon S3 內分發要求，這種擴展方法還有助於將負載分散至網路上的多個路徑。
對於高傳輸量傳輸，Amazon S3 建議使用對 GET 或 PUT 資料並行使用多個連線的應用程式。例如， AWS Java 開發套件中的 [Amazon S3 Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html) 支援此功能，而大多數其他 AWS SDKs 也提供類似的建構。對於部分應用程式，您可以實現並行連線，方法為在不同的應用程式執行緒中或在不同的應用程式執行個體中並行啟動多個請求。採取的最佳方法取決於您的應用程式，以及您正在存取的物件結構。
您可以使用 AWS SDKs直接發出 GET 和 PUT 請求，而不是使用 AWS SDK 中的傳輸管理。此方法可讓您更直接調整工作負載，同時仍能受益於軟體開發套件支援重試，以及處理任何可能發生的 HTTP 503 回應。一般而言，當您從 Amazon S3 下載大型物件時，建議您提出並行請求，以最大化網路輸送量並最佳化下載效能。您可以透過請求物件的特定位元組範圍，或同時下載分段物件的個別部分來達成此目的。這種平行下載方法有助於充分利用您的網路介面卡 (NIC) 容量。對於使用分段上傳上傳的物件，我們建議您使用相同的組件大小或將請求與原始組件界限對齊以獲得最佳效能。相較於單一整個物件請求，此並行下載方法可提供更高的彙總輸送量。
當您調整要同時發出的請求數時，測量效能很重要。我們建議從一次提出單一請求開始。測量要實現的網路頻寬，以及您的應用程式在處理資料時其他資源的使用情形。然後，您可以識別瓶頸資源 (亦即，具有最高用量的資源)，因此識別可能有用的請求數。例如，如果一次處理一個請求導致使用 25% CPU，則其建議最多只能容納四個並行請求。測量是必要的操作，且隨著請求率的增加，確認資源用量是值得的。
如果您的應用程式使用 REST API 直接向 Amazon S3 發出請求，我們建議您使用 HTTP 連線集區，並針對一系列請求重複使用每個連線。避免每個請求的連線設定可移除在每個請求上執行 TCP 緩慢啟動和 Secure Sockets Layer (SSL) 交握的需求。如需有關使用 REST API 的詳細資訊，請參閱 [Amazon Simple Storage Service API 參考](https://docs.aws.amazon.com/AmazonS3/latest/API/)。
最後，值得注意 DNS，並仔細檢查請求是否分散在廣泛的 Amazon S3 IP 位址集區。Amazon S3 的 DNS 查詢會在大量 IP 端點之中循環進行。但是快取解析程式或重複使用單一 IP 位址的應用程式碼不會受益於地址多樣性和隨之而來的負載平衡。網路公用程式工具 (例如 `netstat` 命令列工具) 可以顯示用來與 Amazon S3 通訊的 IP 位址，我們提供指導方針供 DNS 組態使用。如需這些準則的詳細資訊，請參閱 Amazon S3 API 參考**中的[提出請求](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)。
## 使用 Amazon S3 Transfer Acceleration 加速異地資料傳輸
[使用 Amazon S3 Transfer Acceleration 設定快速安全的檔案傳輸](transfer-acceleration.md)在分散全球的客戶端與使用 Amazon S3 的區域應用程式之間， 可有效盡量降低或消除地理距離所引起的延遲。Transfer Acceleration 使用 CloudFront 中遍佈全球的節點來傳輸資料。 AWS 邊緣網路在超過 50 個位置都有據點。目前用於透過 CloudFront 分發內容，並快速回應對 [Amazon Route 53](https://docs.aws.amazon.com/route53/index.html) 的 DNS 查詢。
邊緣網路也有助於加速進出 Amazon S3 的資料傳輸。它非常適合於各大洲之間傳輸資料的應用程式、具有快速網際網路連線的應用程式、使用大型物件的應用程式，或具有許多內容要上傳的應用程式。當資料到達節點時，資料會經由最佳化的網路路徑而路由至 Amazon S3。一般而言，離 Amazon S3 區域越遠，使用 Transfer Acceleration 改善速度越明顯。
您可以在新的或現有的儲存貯體上設定 Transfer Acceleration。您可以使用單獨的 Amazon S3 Transfer Acceleration 端點來使用 AWS 節點。測試 Transfer Acceleration 是否可提升用戶端請求效能的最好方式，就是使用 [Amazon S3 Transfer Acceleration 速度比較工具](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html)。網路組態和狀況會隨著時間和位置而有所不同。因此，只有在 Amazon S3 Transfer Acceleration 有可能改善上傳效能時，才會向您收取傳輸費用。如需搭配不同 AWS SDKs 使用 Transfer Acceleration 的詳細資訊，請參閱 [啟用和使用 S3 Transfer Acceleration](transfer-acceleration-examples.md)。
## 最佳化高請求率工作負載
對 Amazon S3 產生高請求率的應用程式需要特定的設計模式，才能達到最佳效能。當您的應用程式持續產生超過 3,500 個 PUT/COPY/POST/DELETE 或每秒每個字首 5,500 個 GET/HEAD 請求時，您應該實作策略來分配請求，並處理擴展行為。
Amazon S3 會自動擴展以適應更高的請求率，但此擴展是逐漸發生。在擴展過程中，您可能會收到 HTTP 503 (Slow Down) 回應。這些回應是暫時的，並指出 Amazon S3 正在針對新的請求模式將其內部系統最佳化。擴展完成後，您的請求在處理時將不受限流影響。
若要最佳化高請求率工作負載的效能，請考量下列策略：
+ **將請求分散到多個字首** – 使用隨機或循序字首模式，將請求分散到多個分割區。例如，使用隨機字首如 `log-2024-01-01.txt`，而不是使用序列式物件名稱如 `a1b2/log-2024-01-01.txt`。這有助於 Amazon S3 更有效地分配負載。
+ **針對 503 錯誤實作指數退避** – 當收到 HTTP 503 回應時，實作具有指數退避的重試邏輯。從短暫延遲開始，逐漸增加重試之間的等待時間。 AWS SDKs 包含自動處理此問題的內建重試邏輯。
+ **監控請求模式** – 使用 Amazon CloudWatch 指標來監控您的請求率和錯誤率。特別留意 5xx 錯誤指標，該指標指出您的應用程式何時接近或超過目前的擴展限制。
+ **逐漸提高請求率** – 啟動新應用程式或大幅提高請求率時，隨著時間逐漸增加流量，而不是立即跳到尖峰費率。這可讓 Amazon S3 主動擴展，並降低限流的可能性。
+ **使用多個連線** – 將您的請求分散到多個 HTTP 連線，以最大化輸送量，並降低來自任何單一連線問題的影響。
對於需要一致高效能的應用程式，請考量使用 Amazon S3 Express One Zone，該區域專為需要單一位數毫秒延遲，且每秒可支援數十萬個請求的應用程式而設計。如需詳細資訊，請參閱[S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone)。