本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 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)。