Amazon OpenSearch 服務的操作最佳實踐 - Amazon OpenSearch 服務
監控和提醒碎片策略穩定性效能安全成本最佳化

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

Amazon OpenSearch 服務的操作最佳實踐

本章提供操作 Amazon OpenSearch 服務網域的最佳實務，並包含適用於許多使用案例的一般準則。每個工作負載都是獨一無二的，具有獨特的特性，因此沒有任何一個通用建議適合每個使用案例。最重要的最佳實務是在連續週期內部署、測試和調整網域，以找出適合您工作負載的最佳組態、穩定性和成本。

主題

監控和提醒

下列最佳作法適用於監視您的 OpenSearch 服務網域。

設定 CloudWatch 鬧鐘

OpenSearch 服務向 Amazon CloudWatch 發出性能指標。定期檢閱叢集和執行個體指標，並根據工作負載效能設定建議的 CloudWatch 警示。

啟用日誌發佈

OpenSearch 服務會在 Amazon 日誌中公開 OpenSearch 錯誤日誌、搜尋慢速日誌、編製慢速日誌索引以及稽核 CloudWatch 日誌。搜尋慢速日誌、索引慢速日誌和錯誤日誌對於疑難排解效能和穩定性問題非常有用。稽核日誌會追蹤使用者活動，只有在啟用精細存取控制時才能使用。如需詳細資訊，請參閱 OpenSearch 文件中的記錄。

搜尋慢速日誌和索引慢速日誌是了解和疑難排解搜尋和索引操作效能的重要工具。對所有生產網域啟用搜尋和索引慢速日誌傳送。您也必須設定記錄閾值 — 否則， CloudWatch 將不會擷取記錄檔。

碎片策略

碎片會將您的工作負載分配到 OpenSearch 服務網域中的資料節點。正確設定的索引有助於提升整體網域效能。

當您將資料傳送至 OpenSearch 服務時，您會將該資料傳送至索引。索引類似於資料庫的資料表，以文件作為列，欄位作為行。當您建立索引時，您會告訴您要建立多 OpenSearch 少個主要碎片。主碎片是完整數據集的獨立分區。 OpenSearch Service 會自動將您的資料分配到索引中的主要碎片。您也可以設定索引複本。每個複本都包含該索引之主要碎片的完整副本集。

OpenSearch 服務會在叢集中的資料節點之間對應每個索引的碎片。它可確保索引的主要碎片和複本碎片駐留在不同的資料節點上。第一個複本可確保索引中有兩個資料副本。您應該始終使用至少一個複本。額外的複本提供額外的備援和讀取容量。

OpenSearch 將索引請求發送到包含屬於索引的碎片的所有數據節點。它首先將索引請求傳送至包含主要碎片的資料節點，然後傳送至包含複本碎片的資料節點。搜尋請求會由協調器節點路由至屬於索引之所有碎片的主要或複本碎片。

例如，對於具有五個主要碎片和一個複本的索引，每個索引編製請求接觸 10 個碎片。相反，搜尋請求會傳送至 n 個碎片，其中 n 是主要碎片的數量。對於具有五個主要碎片和一個複本的索引，每個搜尋查詢接觸該索引中的五個碎片 (主要碎片或複本碎片)。

確定碎片和資料節點計數

請使用下列最佳實務來確定網域的碎片計數和資料節點計數。

碎片大小 - 磁碟上的資料大小是來源資料大小的直接結果，並且會隨著您編製更多資料的索引而變更。 source-to-index 比例可能會有很大的不同，從 1:10 到 10:1 或更大，但通常是 1:1.10 左右。您可以使用該比率來預測磁碟上的索引大小。您也可以為某些資料建立索引，並擷取實際索引大小，以確定工作負載的比率。掌握預測的索引大小後，設定碎片計數，以便每個碎片介於 10–30 GiB 之間 (對於搜尋工作負載)，或介於 30-50 GiB 之間 (對於日誌工作負載)。50 GiB 應該是最大值 – 確保為增長做好計劃。

碎片計數 - 資料節點的碎片分佈對網域的效能有很大影響。當您具有包含多個碎片的索引時，嘗試使碎片計數為資料節點計數的偶數倍。這有助於確保碎片在資料節點之間均勻分佈，並防止熱節點。例如，如果您有 12 個主要碎片，則資料節點計數應為 2、3、4、6 或 12。但是，碎片計數不若碎片大小重要 – 如果您有 5 GiB 的資料，則仍應使用單一碎片。

每個資料節點的碎片 - 節點可容納的碎片總數與節點的 Java 虛擬機器 (JVM) 堆積記憶體成正比。目標是每 GiB 堆積記憶體有 25 個或更少的碎片。例如，具有 32 GiB 堆積記憶體的節點應保留不超過 800 個碎片。雖然碎片分佈可能會根據您的工作負載模式而有所不同，但每個節點的碎片數限制為 1,000。cat/allocation API 可快速了解資料節點的碎片數量和碎片總體儲存。

碎片與 CPU 比率 - 當碎片涉及索引或搜尋請求時，它會使用 vCPU 來處理請求。最佳實務是使用每個碎片 1.5 vCPU 的初始縮放點。如果您的執行個體類型有 8 個 vCPU，請設定資料節點計數，讓每個節點的碎片不超過六個。請注意，這是一個近似值。請務必測試您的工作負載並相應調整叢集的規模。

如需有關儲存磁碟區、碎片大小和執行個體類型的建議，請參閱下列資源：

避免儲存扭曲

儲存扭曲是指叢集中的一個或多個節點對一個或更多索引的儲存比例高於其他節點。儲存扭曲表示包含 CPU 使用率不均、間歇性和不均勻的延遲，以及跨資料節點的佇列不均勻。若要判斷是否有扭曲問題，請參閱下列疑難排解部分：

穩定性

下列最佳作法適用於維護穩定且正常的 OpenSearch 服務網域。

保持目前的 OpenSearch

服務軟體更新

OpenSearch Service 會定期發行新增功能或改善網域的軟體更新。更新不會更改 OpenSearch 或彈性搜索引擎版本。我們建議您排定週期性執行 DescribeDomainAPI 作業的時間，並啟動服務軟體更新 (如果UpdateStatus是) ELIGIBLE。如果您未在特定時間範圍內更新網域 (通常為兩週)， OpenSearch 服務會自動執行更新。

OpenSearch 版本升級

OpenSearch 服務會定期增加對社群維護版本的 OpenSearch支援。請務必在可用時升級至最新 OpenSearch 版本。

OpenSearch 服務同時升級 OpenSearch 和 OpenSearch 儀表板（如果您的域正在運行傳統引擎，則可以同時升級 Elasticsearch 和 Kibana）。如果叢集有專用主節點，無須停機即可完成升級。否則，叢集在選取主節點時，可能會在升級後數秒內沒有回應。 OpenSearch 在部分或全部升級期間，儀表板可能無法使用。

有兩種方式可以升級網域：

  • 就地升級 – 此選項更容易，因為您保留相同的叢集。

  • 快照/還原升級 - 此選項適用於在新叢集上測試新版本或在叢集之間遷移。

無論您使用哪種升級程序，我們都建議您維護一個僅用於開發和測試的網域，並在升級您的生產網域之前先將其升級到新版本。建立測試網域時，對於部署類型，選擇 Development and testing (開發與測試)。請務必在網域升級後立即將所有用戶端升級至相容版本。

改善快照效能

為了避免快照在處理過程中卡住，專用主節點的執行個體類型應與碎片計數相符。如需詳細資訊，請參閱 選擇專用主節點的執行個體類型。此外，每個節點的 Java 堆積記憶體不應超過每 GiB 建議的 25 個碎片。如需詳細資訊，請參閱 選擇碎片數。

啟用專用主節點

專用主節點可改善叢集穩定性。專用主節點會執行叢集管理任務，但不會保留索引資料或回應用戶端請求。此叢集管理任務的卸載可增加網域的穩定性，並可在不停機的情況下進行一些組態變更。

啟用並使用三個專用主節點，以在三個可用區域中獲得最佳的網域穩定性。使用備用異地同步備份部署可為您設定三個專用主節點。如需執行個體類型建議，請參閱 選擇專用主節點的執行個體類型。

在多個可用區域中進行部署

為避免因服務中斷造成的資料遺失並盡量減少叢集停機時間，您可以在相同 AWS 區域中將節點發佈至兩個或三個可用區域。最佳做法是使用異地同步備份與待命進行部署，該備用區域會設定三個可用區域、兩個作用中區域、一個作為待命區域，以及每個索引使用兩個複本碎片。此設定可讓 OpenSearch 服務將複本碎片散發至與其對應主要碎片不同的 AZ。可用區域之間的叢集通訊無需支付跨可用區域資料傳輸費用。

可用區域是每個 區域內的隔離位置。如果使用雙可用區域組態，遺失一個可用區域表示喪失了一半的網域容量。移至三個可用區域可進一步減少遺失單個可用區域的影響。

控制擷取流量和緩衝

我們建議您使用 _bulk API 操作來限制全部請求計數。傳送一個包含 5,000 個文件的 _bulk 請求比傳送包含單個文件的 5,000 個請求更有效率。

為了獲得最佳操作穩定性，有時需要限制甚至暫停索引請求的上游流程。限制索引請求的速率是處理請求中意外或偶爾出現的峰值的一種重要機制，否則可能會拖垮叢集。考慮在您的上游架構中建置流量控制機制。

下圖顯示日誌擷取架構的多個元件選項。設定彙整層，以允許有足夠的空間來緩衝傳入資料，從而應對突然的流量峰值和短暫的網域維護。

Log ingest architecture with producers, collectors, aggregators, and dashboards components.

建立搜尋工作負載的映射

對於搜尋工作負載，請建立對應，以定義文件及其欄位的 OpenSearch 儲存和索引方式。將 dynamic 設定為 strict，防止意外新增新欄位。

PUT my-index
{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "title": { "type" : "text" },
      "author": { "type" : "integer" },
      "year": { "type" : "text" }
    }
  }
}

使用索引範本

您可以使用索引模板來告訴 OpenSearch 如何在創建索引時配置索引。在建立索引之前先設定索引範本。然後，當您建立索引時，它會繼承範本中的設定和映射。您可以將多個範本套用至單個索引，以便您可以在一個範本中指定設定，並在另一個範本中指定映射。此策略允許多個索引中的一個通用設定版本，以及針對更具體設定和映射的單獨範本。

下列設定對於在範本中進行設定很有用：

  • 主要碎片和複本碎片的數量

  • 重新整理間隔 (重新整理和對索引進行最新變更以供搜尋的頻率)

  • 動態映射控制

  • 明確欄位映射

下列範例範本包含每個設定：

{
   "index_patterns":[
      "index-*"
   ],
   "order": 0,
   "settings": {
      "index": {
         "number_of_shards": 3,
         "number_of_replicas": 1,
         "refresh_interval": "60s"
      }
   },
   "mappings": {
      "dynamic": false,
      "properties": {
         "field_name1": {
            "type": "keyword"
         }
      }
   }
}

即使它們很少變更，集中 OpenSearch 定義設定和對應也比更新多個上游用戶端更容易管理。

使用索引狀態管理功能來管理索引

如果您要管理日誌或時間序列資料，建議您使用索引狀態管理 (ISM)。ISM 可讓您自動化定期索引生命週期管理任務。使用 ISM，您可以建立政策來叫用索引別名轉換、建立索引快照、在儲存層之間移動索引，以及刪除舊索引。您甚至可以使用 ISM 轉換操作替代資料生命週期管理策略，以避免碎片扭曲。

首先，設定 ISM 政策。如需範例，請參閱 範例政策。接著，將政策連接至一個或多個索引。如果您在原則中包含 ISM 範本欄位， OpenSearch Service 會自動將原則套用至符合指定模式的任何索引。

移除未使用的索引

定期檢閱叢集中的索引，並識別任何未使用的索引。擷取這些索引的快照，以便它們儲存在 S3 中，然後刪除它們。移除未使用的索引時，您可以減少碎片計數，並可使節點之間的儲存分佈和資源使用率更平衡。即使處於閒置狀態，索引仍會在內部索引維護活動期間耗用部分資源。

您可以使用 ISM 在一段時間後自動建立快照並刪除索引，而不是手動刪除未使用的索引。

使用多個網域實現高可用性

要在多個區域實現 99.9% 執行時間以上的高可用性，請考慮使用兩個網域。對於小型或緩慢變更的資料集，您可以設定跨叢集複寫以維護主動-被動模型。在此模型中，只能寫入到領導網域，但是可以從任一網域中讀取。對於較大的資料集和快速變更的資料，請在擷取管道中設定雙重傳遞，以便將所有資料獨立寫入主動-主動模型中的兩個網域。

建構您的上游和下游應用程式，同時考量容錯移轉。請務必測試容錯移轉程序以及其他災難復原程序。

效能

以下最佳實務適用於調整您的網域以獲得最佳效能。

最佳化批量請求大小和壓縮

批量大小取決於您的資料、分析和叢集組態，但是每個批量請求的最佳起點是 3 到 5 MiB。

使用 gzip 壓縮來減少要求和回應的承載大小，從您的 OpenSearch 網域傳送請求和接收回應。您可以將 gzip 壓縮與 OpenSearch Python 用戶端搭配使用，也可以從用戶端包含下列標頭：

  • 'Accept-Encoding': 'gzip'

  • 'Content-Encoding': 'gzip'

若要優化大量請求大小，請先從 3 MiB 的大量請求大小開始。然後，慢慢增加請求大小，直到索引效能停止改善為止。

注意

若要在執行 Elasticsearch 6.x 版的網域上啟用 gzip 壓縮，您必須在叢集層級設定 http_compression.enabled。此設定在彈性搜尋版本 7.x 和所有版本中皆為真。 OpenSearch

減少批量請求回應的大小

若要減少 OpenSearch 回應的大小，請使用filter_path參數排除不必要的欄位。請確保不要排除用於識別或重試失敗請求所需的任何欄位。如需詳細資訊和範例，請參閱 縮減回應大小。

調校重新整理間隔

OpenSearch 索引具有最終讀取一致性。重新整理操作使得索引上執行的所有更新可用於搜尋。預設重新整理間隔為一秒鐘，這表示在寫入索引時，每秒 OpenSearch 會執行一次重新整理。

重新整理索引的頻率越低 (重新整理間隔越高)，整體索引效能就越好。增加重新整理間隔的折中方案是索引更新與新資料可供搜尋之間有較長的延遲時間。在您能忍受的範圍內，將重新整理間隔設定得盡可能高，以改善整體效能。

我們建議將所有索引的 refresh_interval 參數設為 30 秒或更長時間。

啟用自動調整

「自動調整」會使用 OpenSearch 叢集中的效能和使用狀況測量結果，針對節點上的佇列大小、快取大小和 Java 虛擬機器 (JVM) 設定建議變更。這些選擇性變更可提高叢集速度與穩定性。您可以隨時還原為預設的 OpenSearch 服務設定。在新網域上預設啟用自動調整，除非您明確停用它。

我們建議您在所有網域上啟用自動調整，並設定週期性維護時段或定期檢閱其建議。

安全

以下最佳實務適用於保護您的網域。

啟用精細存取控制

精細的存取控制可讓您控制哪些人可以存取 OpenSearch Service 網域中的特定資料。與一般存取控制相比，精細存取控制可為每個叢集、索引、文件和欄位提供其自己指定的存取政策。存取條件可以基於許多因素，包括請求存取之人員的角色，以及他們打算對資料執行的動作。例如，您可能會授予一位使用者寫入索引的存取權，而授予另一位使用者僅讀取索引上資料的存取權，而不能進行任何變更。

精細存取控制可讓具有不同存取需求的資料存在於相同的儲存空間中，而不會遇到安全性或合規性問題。

我們建議在您的網域中啟用精細存取控制。

在 VPC 內部署網域

將您的 OpenSearch 服務網域放置在虛擬私有雲 (VPC) 中，有助於在虛擬私人雲端 (VPC) 中啟用 OpenSearch 服務與其他服務之間的安全通訊，而不需要網際網路閘道、NAT 裝置或 VPN 連線。所有流量都安全地保留在 AWS 雲中。因為其邏輯隔離，相較於使用公有端點的網域，位於 VPC 內的網域具有額外的安全層。

我們建議您在 VPC 內建立您的網域。

套用限制性存取政策

即使您的網域部署在 VPC 中，最佳實務是分層實作安全性。確保針對您目前的存取政策檢查組態。

將限制性資源型存取原則套用至您的網域，並在授予設定 API 和 API 作業存取權時遵循最低權限原則 OpenSearch 。一般而言，請避免在存取政策中使用匿名使用者主體 "Principal": {"AWS": "*" }。

不過，在某些情況下，您可以接受使用開放存取政策，例如當您啟用精細存取控制時。開放存取政策可讓您在請求簽署困難或不可能的情況下 (例如來自特定用戶端和工具) 存取網域。

啟用靜態加密

OpenSearch 服務網域提供靜態資料的加密功能，以防止未經授權存取您的資料。靜態加密使用 AWS Key Management Service (AWS KMS) 來儲存和管理您的加密金鑰，以及使用 256 位元金鑰的進階加密標準演算法 (AES-256) 來執行加密。

如果您的網域存放了敏感資料，請啟用靜態資料加密。

啟用 node-to-node 加密

N ode-to-node 加密在 OpenSearch Service 中的預設安全性功能之上提供額外的安全性層。它會針對在其中佈建的節點之間的所有通訊實作傳輸層安全性 (TLS) OpenSearch。N ode-to-node 加密，任何透過 HTTPS 傳送至您的 OpenSearch Service 網域的資料在傳輸過程中都會保持加密狀態，而在節點之間散佈和複寫。

如果您的網域儲存敏感資料，請啟用 node-to-node加密功能。

使用監視器 AWS Security Hub

監視您使用 OpenSearch 服務的使用情況，因為它與安全性最佳做法有關AWS Security Hub。Security Hub 會透過安全控制來評估資源組態和安全標準，協助您遵守各種合規架構。如需有關使用 Security Hub 評估 OpenSearch 服務資源的詳細資訊，請參閱使用AWS Security Hub 者指南中的Amazon OpenSearch Service 控制項。

成本最佳化

以下最佳做法適用於最佳化和節省您的 OpenSearch 服務成本。

使用最新一代執行個體類型

OpenSearch 服務一直採用新的 Amazon EC2 執行個體類型，以較低的成本提供更好的效能。我們建議始終使用最新一代的執行個體。

對於生產網域，避免使用 T2 或 t3.small 執行個體，因為在持續的高負載下，它們可能會變得不穩定。r6g.large 執行個體是小型生產工作負載 (資料節點和專用主節點) 的一種選擇。

使用最新的 Amazon EBS gp3 磁碟區

OpenSearch 資料節點需要低延遲和高輸送量儲存，以提供快速的索引和查詢。透過使用 Amazon EBS gp3 磁碟區，您能夠以比之前提供的 Amazon EBS gp2 磁碟區類型低 9.6% 的成本，獲得更高的基準效能 (IOPS 和輸送量)。您可以使用 gp3 佈建額外的 IOPS 和輸送量，而不受磁碟區大小影響。這些磁碟區也比上一代磁碟區更穩定，因為它們不會使用爆量額度。gp3 磁碟區類型也使 gp2 per-data-node 磁碟區類型的磁碟區大小限制加倍。您可以使用這些更大的磁碟區，透過提高每個資料節點的儲存量來降低被動資料的成本。

使用 UltraWarm 和冷存儲時間序列日誌數據

如果您用 OpenSearch 於日誌分析，請將資料移至 UltraWarm 或冷存儲以降低成本。使用索引狀態管理 (ISM) 在儲存層之間遷移資料並管理資料保留。

UltraWarm提供在 Service 中儲存大量唯讀資料的符合成本效益的方 OpenSearch 式。 UltraWarm 使用 Amazon S3 進行儲存，這表示資料是不可變的，只需要一個副本。您只需支付相當於索引中主要碎片大小的儲存。 UltraWarm 查詢延遲會隨著服務查詢所需的 S3 資料量而增加。在節點上快取資料之後， UltraWarm 索引的查詢會執行類似於 Hot 索引的查詢。

冷儲存也由 S3 支持。當您需要查詢冷資料時，可以選擇性地將其貼附至既有 UltraWarm 節點。冷資料會產生與受管儲存體成本相同 UltraWarm，但冷存放區中的物件不會消耗 UltraWarm 節點資源。因此，冷儲存可提供大量的儲存容量，而不會影響 UltraWarm 節點大小或計數。

UltraWarm 如果您有大約 2.5 TiB 的資料要從熱儲存移轉，就會變得符合成本效益。監控您的填寫率，並計劃在達到該資料量 UltraWarm之前將索引移至。

檢閱預留執行個體的建議

在對效能和運算耗用量有了良好的基準之後，考慮購買預留執行個體 (RI)。對於無預付款的 1 年預訂，折扣從 30% 左右開始；對於所有預付款的 3 年承諾，折扣可以增加到 50%。

觀察到至少 14 天的穩定操作後，請檢閱 Cost Explorer 中的預留執行個體建議。Amazon OpenSearch 服務標題會顯示特定 RI 購買建議和預計節省成本。