規模調整 - AWS 方案指引
儲存節點和執行個體類型的數目決定索引策略和碎片計數CPU 使用率執行個體類型

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

規模調整

調整大小可協助您判斷正確的執行個體類型、資料節點數量，以及目標環境的儲存需求。我們建議您先依儲存體調整大小，再依 CPUs調整大小。如果您已經在使用 Elasticsearch 或 OpenSearch，大小通常保持不變。不過，您需要識別等同於您目前環境的執行個體類型。為了協助判斷正確的大小，建議使用下列準則。

儲存

調整叢集的大小從定義儲存需求開始。識別叢集所需的原始儲存體。這取決於評估來源系統產生的資料 （例如產生日誌的伺服器或產品目錄原始大小）。識別您有多少原始資料後，請使用下列公式來計算儲存需求。然後，您可以使用結果做為 PoC 的起點。

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

公式會考量下列事項：

  • 索引的磁碟上大小會有所不同，但通常比來源資料大 10%。

  • Linux 保留 5% 的作業系統額外負荷進行系統復原，並防止磁碟重組問題。

  • OpenSearch 保留每個執行個體 20% 的儲存空間，用於區段合併、日誌和其他內部操作。

  • 我們建議保留 10% 的額外儲存空間，以協助將節點故障和可用區域中斷的影響降至最低。

合併後，這些額外負荷和保留需要 45% 的額外空間，以來源中的實際原始資料為基礎。因此，請將來源資料乘以 1.45。接下來，將此乘以資料副本的數量 （例如，一個主要加上您將使用的複本數量）。複本計數取決於您的彈性和輸送量需求。對於平均使用案例，您可以從一個主要和一個複本開始。最後，再乘以您想要在熱儲存層中保留資料的天數。

Amazon OpenSearch Service 提供熱儲存、暖儲存和冷儲存層。暖儲存層使用 UltraWarm 儲存。UltraWarm 提供經濟有效的方法，可在 Amazon OpenSearch Service 上儲存大量唯讀資料。標準資料節點使用熱儲存，其採用連接到每個節點的執行個體存放區或 Amazon Elastic Block Store (Amazon EBS) 磁碟區的形式。熱儲存可盡可能提供最快速的效能，以編製索引和搜尋新資料。UltraWarm 節點使用 Amazon Simple Storage Service (Amazon S3) 作為儲存體，並使用複雜的快取解決方案來改善效能。對於您未主動寫入或查詢頻率較低的索引，以及沒有相同效能需求的索引，UltraWarm 可大幅降低每 GiB 資料的成本。如需 UltraWarm 的詳細資訊，請參閱 AWS 文件。

當您建立 OpenSearch Service 網域並使用熱儲存時，您可能需要定義 EBS 磁碟區大小。這取決於您選擇的資料節點執行個體類型。您可以使用相同的儲存需求公式來判斷 Amazon EBS 支援執行個體的磁碟區大小。我們建議將 gp3 磁碟區用於最新一代的 T3, R5, R6G, M5, M5g, C5和 C6g 執行個體系列。使用 Amazon EBS gp3 磁碟區，您可以佈建與儲存容量無關的效能。Amazon EBS gp3 磁碟區也提供更好的基準效能，與 OpenSearch Service 上現有的 gp2 磁碟區相比，每 GB 的成本低 9.6%。透過 gp3，您還可以在 R5, R6g, M5 和 M6g 執行個體系列中取得更密集的儲存體，這可協助您進一步最佳化成本。您最多可以建立支援配額的 EBS 磁碟區。如需配額的詳細資訊，請參閱 Amazon OpenSearch Service 配額。

對於具有 NVM Express (NVMe) 磁碟機的資料節點，例如 i3 和 r6gd 執行個體，磁碟區大小是固定的，因此 EBS 磁碟區不是選項。

節點和執行個體類型的數目

節點數量是根據操作工作負載所需的 CPUs 數量。CPUs 數量是以碎片計數為基礎。OpenSearch 中的索引由多個碎片組成。建立索引時，您可以指定索引的碎片數量。因此，您需要執行下列動作：

  1. 計算您要存放在網域中的碎片總數。

  2. 判斷 CPU。

  3. 尋找最具成本效益的節點類型和計數，為您提供所需的 CPUs和儲存體數量。

這通常是起點。執行測試以判斷預估大小是否符合您的功能和非功能需求。

決定索引策略和碎片計數

了解儲存需求後，您可以決定需要多少索引，並識別每個索引的碎片計數。一般而言，搜尋使用案例有一或幾個索引，每個索引代表可搜尋的實體或目錄。對於日誌分析使用案例，索引可以代表每日或每週日誌檔案。在您決定多少索引之後，請從下列擴展指引開始，並判斷適當的碎片計數：

  • 搜尋使用案例 – 10–30 GB/碎片

  • 日誌分析使用案例 – 50 GB/碎片

您可以將單一索引中的資料總量除以您在使用案例中瞄準的碎片大小。這將為您提供索引的碎片數量。識別碎片總數可協助您找到適合您工作負載的正確執行個體類型。碎片不應太大或太多。大型碎片可能會讓 OpenSearch 難以從故障中復原，但由於每個碎片使用一定數量的 CPU 和記憶體，因此有太多小碎片可能會導致效能問題和out-of-memory錯誤。此外，對資料節點的碎片配置不平衡可能會導致擺動。當您具有包含多個碎片的索引時，嘗試使碎片計數為資料節點計數的偶數倍。這有助於確保碎片在資料節點之間均勻分佈，並防止熱節點。例如，如果您有 12 個主要碎片，則資料節點計數應為 2、3、4、6 或 12。但是，碎片計數不若碎片大小重要 – 如果您有 5 GiB 的資料，則仍應使用單一碎片。在可用區域中平均平衡複本碎片計數也有助於改善彈性。

CPU 使用率

下一個步驟是識別工作負載所需的 CPUs數量。我們建議從作用中碎片的 CPU 計數 1.5 倍開始。作用中碎片是接收大量寫入之索引的任何碎片。使用主要碎片計數來判斷接收大量讀取或寫入請求之索引的作用中碎片。對於日誌分析，只有目前的索引通常處於作用中狀態。對於搜尋使用案例，所有主要碎片都會被視為作用中碎片。雖然我們建議每個作用中碎片使用 1.5 個 CPU，但這與工作負載高度相依。請務必測試和監控 CPU 使用率，並相應地擴展。

維護 CPU 使用率的最佳實務是確保 OpenSearch 服務網域有足夠的資源來執行其任務。持續具有高 CPU 使用率的叢集可能會降低叢集穩定性。當您的叢集超載時，OpenSearch Service 會封鎖傳入的請求，這會導致請求拒絕。這是為了保護網域免於失敗。CPU 使用率的一般準則約為平均 60%，CPU 使用率上限 80%。偶爾 100% 的峰值仍然可以接受，而且可能不需要擴展或重新設定。

執行個體類型

Amazon OpenSearch Service 為您提供多種執行個體類型的選擇。您可以選擇最符合您使用案例的執行個體類型。Amazon OpenSearch Service 支援 R、C、M、T 和 I 執行個體系列。您可以根據工作負載選擇執行個體系列：記憶體最佳化、運算最佳化或混合。識別執行個體系列之後，請選擇最新一代的執行個體類型。一般而言，我們建議使用 Graviton 和更新世代，因為與上一代執行個體相比，它們旨在以更低的成本提供更好的效能。

根據針對日誌分析和搜尋使用案例執行的各種測試，我們建議下列事項：

  • 對於日誌分析使用案例 ，一般準則是從資料節點的 R 系列 Graviton 執行個體開始。我們建議您執行測試、建立符合您需求的基準，以及識別工作負載的適當執行個體大小。

  • 對於搜尋使用案例，我們建議將 R 和 C 系列 Graviton 執行個體用於資料節點，因為相較於日誌分析使用案例，搜尋使用案例需要更多 CPU。對於較小的工作負載，您可以使用 M 系列 Graviton 執行個體進行搜尋和日誌。我的系列執行個體提供 NVMe 磁碟機，並由具有快速索引和低延遲搜尋需求的客戶使用。

叢集由資料節點和叢集管理員節點組成。雖然專用主節點不會處理搜尋和查詢請求，但其大小與他們可以管理的執行個體大小和執行個體數量、索引和碎片高度相關。AWS 文件提供建議最低專用叢集管理員執行個體類型的矩陣。

AWS 為採用 AWS Graviton2 處理器的 Amazon OpenSearch Service 7.9 版或更新版本提供一般用途 (M6g)、運算最佳化 (C6g) 和記憶體最佳化 (R6g 和 R6gd)。這些執行個體是使用 Amazon 設計的自訂晶片建置而成。它們是 Amazon 設計的硬體和軟體創新，可透過隔離的多租用戶、私有聯網和快速本機儲存，實現高效、靈活且安全的雲端服務。

與 OpenSearch Service (M5、C5, R5) 中可用的上一代 Intel 型執行個體相比，Graviton2 執行個體系列可將索引延遲降低高達 50%，並將查詢效能提升高達 30%。