Amazon OpenSearch Service の運用上のベストプラクティス - Amazon OpenSearch サービス
モニタリングとアラートシャード戦略安定性パフォーマンスセキュリティコスト最適化

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon OpenSearch Service の運用上のベストプラクティス

この章では、Amazon OpenSearch Service ドメインを操作するためのベストプラクティスと、多くのユースケースに適用される一般的なガイドラインについて説明します。各ワークロードは一意で、固有の特性があるため、すべてのユースケースに完全に適した一般的な推奨事項はありません。最も重要なベストプラクティスは、ドメインを連続的なサイクルでデプロイ、テスト、調整して、ワークロードに最適な設定、安定性、およびコストを見つけることです。

トピック

モニタリングとアラート

OpenSearch サービスドメインのモニタリングには、次のベストプラクティスが適用されます。

CloudWatch アラームの設定

OpenSearch サービスはパフォーマンスメトリクスを Amazon に出力します CloudWatch。クラスターとインスタンスのメトリクスを定期的に確認し、ワークロードのパフォーマンスに基づいて推奨 CloudWatch アラームを設定します。

ログの発行を有効にする

OpenSearch サービスは、Amazon CloudWatch Logs の OpenSearch エラーログ、スローログの検索、スローログのインデックス作成、監査ログを公開します。検索スローログ、インデックス作成スローログ、およびエラーログは、パフォーマンスと安定性の問題のトラブルシューティングに役立ちます。きめ細かいアクセスコントロールを有効にした場合にのみ使用できる監査ログは、ユーザーアクティビティを追跡します。詳細については、 OpenSearch ドキュメントの「ログ」を参照してください。

検索スローログとインデックス作成スローログは、検索およびインデックス作成オペレーションのパフォーマンスを理解し、トラブルシューティングするための重要なツールです。すべての本番ドメインのために、検索およびインデックスの低速ログ配信を有効にします。また、ログ記録のしきい値を設定する必要があります。そうしないと、ログはキャプチャ CloudWatch されません。

シャード戦略

Shards は、 OpenSearch サービスドメインのデータノード全体にワークロードを分散します。インデックスを適切に設定すると、ドメイン全体のパフォーマンスを向上させるのに役立ちます。

OpenSearch Service にデータを送信すると、そのデータをインデックスに送信します。インデックスはデータベーステーブルに似ています。ドキュメントが行、フィールドが列に相当します。インデックスを作成するときに、作成するプライマリシャード OpenSearch の数を指定します。プライマリシャードは、データセット全体の独立したパーティションです。 OpenSearch サービスは、インデックス内のプライマリシャード全体にデータを自動的に分散します。インデックスのレプリカを設定することもできます。各レプリカシャードは、そのインデックスのプライマリシャードのコピーの完全なセットで構成されます。

OpenSearch サービスは、クラスター内のデータノード間で各インデックスのシャードをマッピングします。これにより、インデックスのプライマリシャードとレプリカシャードが別々のデータノードに確実に存在するようになります。最初のレプリカは、インデックスにデータのコピーが確実に 2 個あるようにします。常に少なくとも 1 個のレプリカを使用する必要があります。追加のレプリカは、さらなる冗長性と読み取りキャパシティーを提供します。

OpenSearch は、インデックスに属するシャードを含むすべてのデータノードにインデックス作成リクエストを送信します。インデックス作成リクエストは、まずプライマリシャードを含むデータノードに送信され、その後にレプリカシャードを含むデータノードに送信されます。検索リクエストは、コーディネーターノードによって、インデックスに属するすべてのシャードのプライマリシャードまたはレプリカシャードにルーティングされます。

例えば、5 個のプライマリシャードと 1 個のレプリカがあるインデックスの場合、各インデックス作成リクエストは 10 個のシャードにタッチします。一方、検索リクエストは n 個のシャードに送信されます。n はプライマリシャードの数です。5 個のプライマリシャードと 1 個のレプリカがあるインデックスの場合、各検索クエリは、そのインデックスの 5 個のシャード (プライマリまたはレプリカ) にタッチします。

シャードとデータノード数を決定する

次のベストプラクティスを使用して、ドメインのシャードとデータノード数を決定します。

シャードのサイズ — ディスク上のデータのサイズは、ソースデータのサイズの直接的な結果であり、インデックスを作成するデータが増えるにつれて変化します。 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 のデータがある場合、1 個のシャードを使用するべきです。

データノードあたりのシャード — ノードが保持できるシャードの合計数は、ノードの Java 仮想マシン (JVM) ヒープメモリに比例します。ヒープメモリの GiB あたりのシャード数が 25 個以下になるように試みます。例えば、32 GiB のヒープメモリを持つノードのシャード数は 800 個以下である必要があります。シャードの分散は、ワークロードのパターンに基づいて異なる場合がありますが、シャード数はノードあたり 1,000 個という制限があります。cat/allocation APIは、データノード全体のシャードの数とシャードストレージの合計をすぐに確認できます。

シャード対CPU比 – シャードがインデックス作成または検索リクエストに関与する場合、vCPU を使用してリクエストを処理します。ベストプラクティスとして、シャードあたり 1.5 vCPU の初期スケールポイントを使用します。インスタンスタイプに 8 がある場合はvCPUs、各ノードに 6 つのシャードを超えないようにデータノード数を設定します。これは近似値であることに注意してください。必ずワークロードをテストし、それに応じてクラスターをスケールしてください。

ストレージボリューム、シャードサイズ、インスタンスタイプに関する推奨事項については、次のリソースを参照してください。

ストレージスキューを回避する

ストレージスキューは、クラスター内の 1 つ以上のノードが、1 つ以上のインデックスについて、他のノードよりも高い割合のストレージを保持している場合に発生します。ストレージスキューの兆候には、不均一なCPU使用率、断続的なレイテンシーと不均一なレイテンシー、データノード間の不均一なキューイングなどがあります。スキューの問題があるかどうかを判断するには、次のトラブルシューティング セクションを参照してください。

安定性

以下のベストプラクティスは、安定した正常な OpenSearch サービスドメインの維持に適用されます。

で最新の状態を維持する OpenSearch

サービスソフトウェア更新

OpenSearch サービスは、機能を追加したり、ドメインを改善したりするソフトウェア更新を定期的にリリースします。更新では、 OpenSearch または Elasticsearch エンジンのバージョンは変更されません。DescribeDomain API オペレーションを実行するために定期的な時間をスケジュールし、 UpdateStatus が の場合はサービスソフトウェアの更新を開始することをお勧めしますELIGIBLE。特定の時間枠 (通常 2 週間) 内にドメインを更新しない場合、 OpenSearch Service は自動的に更新を実行します。

OpenSearch バージョンアップグレード

OpenSearch サービスでは、コミュニティでメンテナンスされているバージョンの のサポートが定期的に追加されます OpenSearch。利用可能な場合は、常に OpenSearch 最新バージョンにアップグレードしてください。

OpenSearch サービスは、 OpenSearch と OpenSearch Dashboards (ドメインがレガシーエンジンを実行している場合は Elasticsearch と Kibana) の両方を同時にアップグレードします。クラスターに専用マスターノードがある場合、アップグレードはダウンタイムなしで完了します。それ以外の場合、クラスターはマスターノードを選択している間、アップグレード後数秒間応答しない可能性があります。アップグレードの一部またはすべて中に OpenSearch ダッシュボードが使用できない場合があります。

ドメインをアップグレードするには 2 つの方法があります。

使用するアップグレードプロセスにかかわらず、開発とテスト専用のドメインを維持し、本番ドメインをアップグレードする前に新しいバージョンにアップグレードすることをお勧めします。テストドメインを作成するときに、デプロイタイプのために [Development and testing] (開発とテスト) を選択します。ドメインのアップグレードの直後に、必ずすべてのクライアントを互換性のあるバージョンにアップグレードしてください。

スナップショットパフォーマンスの向上

スナップショットの処理が停止するのを防ぐには、専用マスターノードのインスタンスタイプがシャードカウントに一致する必要があります。詳細については、「専用マスターノードのインスタンスタイプの選択」を参照してください。また、各ノードの Java ヒープメモリの GiB あたりのシャード数は、推奨される 25 シャードよりも少なくしてください。詳細については、「シャード数の選択」を参照してください。

専用マスターノードを有効にする

専用のマスターノードにより、クラスターの安定性が向上します。専用マスターノードではクラスター管理タスクを実行しますが、インデックスデータは保持せず、クライアントリクエストにも応答しません。このクラスター管理タスクのオフロードにより、ドメインの安定性が向上し、一部の設定変更をダウンタイムなしで行うことができます。

3 つのアベイラビリティーゾーンにまたがるドメインの安定性を最適化するために、3 個の専用マスターノードを有効にして使用します。スタンバイが有効のマルチ AZ でデプロイすると、3 つの専用マスターノードが設定されます。インスタンスタイプの推奨事項については、「専用マスターノードのインスタンスタイプの選択」を参照してください。

複数のアベイラビリティゾーンにデプロイする

サービス中断が発生した場合にデータの損失を防ぎ、クラスターのダウンタイムを最小限に抑えるため、同じ AWS リージョン内の 2 つまたは 3 つのアベイラビリティーゾーン間にノードを分散できます。ベストプラクティスは、スタンバイが有効のマルチ AZ を使用してデプロイすることです。これにより、3 つのアベイラビリティーゾーンが設定され、2 つのゾーンがアクティブ、1 つのゾーンがスタンバイとして機能し、インデックスごとに 2 つのレプリカシャードが割り当てられます。この設定により、 OpenSearch Service は対応するプライマリシャードAZsとは異なる にレプリカシャードを分散できます。アベイラビリティーゾーン間のクラスター通信には、AZ 間のデータ転送料金はかかりません。

アベイラビリティーゾーンは、各 リージョン内の独立した場所です。2 つの AZ 設定では、1 つのアベイラビリティーゾーンを失うことは、すべてのドメインキャパシティーの半分を失うことを意味します。3 つのアベイラビリティゾーンに移行すると、1 つのアベイラビリティゾーンを失うことによる影響が軽減されます。

取り込みフローとバッファリングを制御する

_bulk APIオペレーションを使用して、全体的なリクエスト数を制限することをお勧めします。1 つのドキュメントを含む 5,000 のリクエストを送信するよりも、5,000 のドキュメントを含む 1 つの _bulk リクエストを送信する方が効率的です。

最適な運用安定性のために、インデックス作成リクエストのアップストリームフローを制限したり、一時停止したりする必要がある場合があります。インデックス作成リクエストのレートを制限することは、対処しなければクラスターで過負荷となる可能性のある、予期しないまたは時折のリクエストの急増に対処するための重要なメカニズムです。アップストリームアーキテクチャにフロー制御メカニズムを構築することを検討してください。

次の図は、ログ取り込みアーキテクチャの複数のコンポーネントオプションを示しています。急激なトラフィックの急増や短時間のドメインメンテナンスのために受信データをバッファリングするのに十分なスペースを確保できるように、集約レイヤーを設定します。

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 方法を示す方法として使用できます。インデックスを作成する前に、インデックステンプレートを設定します。その後、インデックスを作成すると、テンプレートから設定とマッピングが継承されます。1 個のインデックスに複数のテンプレートを適用できるため、1 個のテンプレートで設定を指定し、別のテンプレートでマッピングを指定できます。この戦略では、複数のインデックスにまたがる共通設定用の 1 個のテンプレートと、より具体的な設定やマッピング用の個別のテンプレートを使用できます。

次の設定は、テンプレートでの設定に役立ちます。

  • プライマリシャードとレプリカシャードの数

  • 更新間隔 (インデックスを更新して最近の変更を検索できるようにする頻度)

  • 動的マッピングコントロール

  • 明示的なフィールドマッピング

次のテンプレート例には、これらの各設定が含まれています。

{
   "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 簡単です。

Index State Management でインデックスを管理する

ログまたは時系列データを管理している場合は、インデックス状態管理 () を使用することをお勧めしますISM。ISM では、定期的なインデックスライフサイクル管理タスクを自動化できます。を使用するとISM、インデックスエイリアスロールオーバーを呼び出すポリシーを作成し、インデックススナップショットを取得し、ストレージ層間でインデックスを移動し、古いインデックスを削除できます。また、ISMロールオーバーオペレーションを代替データライフサイクル管理戦略として使用して、シャードスキューを回避することもできます。

まず、ISMポリシーを設定します。例については、「サンプルポリシー」を参照してください。その後、ポリシーを 1 つ以上のインデックスにアタッチします。ポリシーにISMテンプレートフィールドを含めると、 OpenSearch Service は指定されたパターンに一致するインデックスにポリシーを自動的に適用します。

未使用インデックスの削除

クラスター内のインデックスを定期的に確認し、使用されていないインデックスを特定します。これらのインデックスが S3 に保存されるようにスナップショットを作成してから、削除します。未使用のインデックスを削除すると、シャード数が減り、ノード全体でよりバランスの取れたストレージの分散とリソースの使用が可能になります。アイドル状態であっても、インデックスは内部的なインデックスのメンテナンス作業中に一部のリソースを消費します。

未使用のインデックスを手動で削除するのではなく、 ISMを使用して一定期間後にスナップショットを自動的に取得し、インデックスを削除できます。

高可用性を実現するために複数のドメインを使用する

複数のリージョンで 99.9% のアップタイムを超える高可用性を実現するには、2 つのドメインの使用を検討してください。小規模またはゆっくりと変化するデータセットの場合、クロスクラスターレプリケーションを設定して、アクティブ/パッシブモデルを維持できます。このモデルでは、リーダードメインのみが書き込みの対象となりますが、どちらのドメインも読み取りの対象とすることができます。データセットが大きく、データが急速に変化する場合は、すべてのデータがアクティブ-アクティブモデルの両方のドメインに独立して書き込まれるように、取り込みパイプラインで二重配信を設定します。

フェイルオーバーを念頭に置いて、アップストリームとダウンストリームのアプリケーションを設計します。フェイルオーバープロセスは、他のディザスタリカバリプロセスと一緒にテストしてください。

パフォーマンス

次のベストプラクティスは、最適なパフォーマンスを実現するために、ドメインの調整に適用されます。

一括リクエストのサイズと圧縮を最適化する

一括サイズ設定は、データ、分析、およびクラスター設定によって異なりますが、適切な開始点は一括リクエストあたり 3～5 MiB です。

gzip 圧縮を使用してリクエストとレスポンスのペイロードサイズを小さくすることで、 OpenSearch ドメインからリクエストを送信し、レスポンスを受信します。OpenSearch Python クライアント で gzip 圧縮を使用するか、クライアント側から次のヘッダーを含めることができます。

  • 'Accept-Encoding': 'gzip'

  • 'Content-Encoding': 'gzip'

一括リクエストのサイズを最適化するには、3 MiB の一括リクエストサイズから始めます。その後、インデックス作成のパフォーマンスが改善しなくなるまで、リクエストサイズを徐々に大きくします。

注記

Elasticsearch バージョン 6.x を実行しているドメインで gzip 圧縮を有効にするには、クラスターレベルで http_compression.enabled を設定する必要があります。この設定は、Elasticsearch バージョン 7.x およびすべてのバージョンの でデフォルトで適用されます OpenSearch。

一括リクエストのレスポンスのサイズを小さくする

OpenSearch レスポンスのサイズを減らすには、 filter_pathパラメータで不要なフィールドを除外します。失敗したリクエストを識別または再試行するために必要なフィールドを除外しないようにしてください。詳細な説明と例については、「レスポンスサイズの削減」を参照してください。

更新間隔を調整する

OpenSearch インデックスには最終的な読み取り整合性があります。更新オペレーションにより、インデックスに対して実行されたすべての更新が検索可能になります。デフォルトの更新間隔は 1 秒です。つまり、 はインデックスが書き込まれる間、1 秒ごとに更新 OpenSearch を実行します。

インデックスの更新頻度が低い (更新間隔が長い) ほど、インデックス作成の全体的なパフォーマンスが向上します。更新間隔を長くすることのトレードオフは、インデックスが更新されてから新しいデータが検索可能になるまでの時間が長くなることです。全体的なパフォーマンスを向上させるには、更新間隔を許容できる限り長く設定します。

すべてのインデックスの refresh_interval パラメータを 30 秒以上に設定することをお勧めします。

Auto-Tune を有効にする

Auto-Tune は OpenSearch 、クラスターのパフォーマンスと使用状況のメトリクスを使用して、ノードのキューサイズ、キャッシュサイズ、Java 仮想マシン (JVM) 設定の変更を提案します。これらのオプションの変更により、クラスターの速度と安定性が向上します。いつでもデフォルトの OpenSearch サービス設定に戻すことができます。Auto-Tune は、明示的に無効にしない限り、新しいドメインでデフォルトで有効になります。

すべてのドメインで Auto-Tune を有効にし、定期的なメンテナンスウィンドウを設定するか、定期的に推奨事項を確認することをお勧めします。

セキュリティ

ドメインのセキュリティ保護には、次のベストプラクティスが適用されます。

きめ細かなアクセスコントロールを有効にする

きめ細かなアクセスコントロールにより、 OpenSearch サービスドメイン内の特定のデータにアクセスできるユーザーを制御できます。一般化されたアクセスコントロールと比較して、きめ細かいアクセスコントロールでは、各クラスター、インデックス、ドキュメント、およびフィールドに、独自の指定アクセスポリシーが設定されます。アクセス基準は、アクセスをリクエストする人の役割や、データに対して実行しようとしているアクションなど、さまざまな要因に基づくことができます。例えば、あるユーザーにはインデックスへの書き込みアクセスを許可し、別のユーザーには変更を加えずにインデックスのデータを読み取るためだけのアクセスを許可する場合があります。

きめ細かなアクセスコントロールは、セキュリティやコンプライアンスの問題を生じさせずに、アクセス要件の異なるデータが同じストレージスペースに存在できるようにします。

ドメインできめ細かいアクセスコントロールを有効にすることをお勧めします。

内にドメインをデプロイする VPC

OpenSearch サービスドメインを仮想プライベートクラウド (VPC) に配置すると、インターネットゲートウェイ、NATデバイス、またはVPN接続を必要とVPCせずに、 OpenSearch 内のサービスと他のサービス間の安全な通信が可能になります。すべてのトラフィックは AWS クラウド内に安全に保持されます。論理的な分離により、 内に存在するドメインVPCは、パブリックエンドポイントを使用するドメインよりもセキュリティレイヤーが強化されます。

内にドメインを作成するVPCことをお勧めします。

制限的なアクセスポリシーを適用する

ドメインが 内にデプロイされていてもVPC、レイヤーにセキュリティを実装することがベストプラクティスです。現在のアクセスポリシーの設定を確認してください。

制限的なリソースベースのアクセスポリシーをドメインに適用し、設定APIと OpenSearch APIオペレーションへのアクセスを許可するときは、最小権限の原則に従います。原則として、アクセスポリシーで匿名ユーザープリンシパル "Principal": {"AWS": "*" } を使用することは避けてください。

ただし、きめ細かなアクセスコントロールを有効にする場合など、オープンアクセスポリシーの使用が許容される状況もあります。オープンアクセスポリシーを使用すると、特定のクライアントやツールなど、リクエストの署名が困難または不可能な場合にもドメインにアクセスできます。

保管中の暗号化を有効にする

OpenSearch サービスドメインは、保管中のデータの暗号化を提供し、データへの不正アクセスを防止します。保管時の暗号化では、暗号化キーの保存と管理に AWS Key Management Service （AWS KMS) を使用し、暗号化を実行するには 256 ビットキー (AES-256) を使用する Advanced Encryption Standard アルゴリズムを使用します。

ドメインに機密データが保存されている場合、保管中のデータの暗号化を有効にします。

暗号化を有効にする node-to-node

Node-to-node 暗号化は、 OpenSearch Service 内のデフォルトのセキュリティ機能に加えて、追加のセキュリティレイヤーを提供します。内にプロビジョニングされているノード間のすべての通信に Transport Layer Security (TLS) を実装します OpenSearch。 Node-to-node 暗号化。 を介して OpenSearch Service ドメインに送信されたデータは、ノード間で分散およびレプリケートされている間、転送中に暗号化されたHTTPSままになります。

ドメインに機密データが保存されている場合は、暗号化 を有効にします node-to-node。

でモニタリングする AWS Security Hub

を使用して、セキュリティのベストプラクティスに関連する OpenSearch サービスの使用状況をモニタリングしますAWS Security Hub。Security Hub は、セキュリティコントロールを使用してリソース設定とセキュリティ標準を評価し、お客様がさまざまなコンプライアンスフレームワークに準拠できるようサポートします。Security Hub を使用して OpenSearch サービスリソースを評価する方法の詳細については、 ユーザーガイドのAmazon OpenSearch Service 「 コントロール」を参照してください。 AWS Security Hub

コスト最適化

以下のベストプラクティスは、 OpenSearch サービスコストの最適化と節約に適用されます。

最新世代のインスタンスタイプを使用する

OpenSearch サービスは常に、低コストでより優れたパフォーマンスを提供する新しい Amazon EC2インスタンスタイプを採用しています。常に最新世代のインスタンスを使用することをお勧めします。

本番稼働用ドメインで T2 や t3.small インスタンスを使用しないようにしてください。それらは負荷の高い状態では不安定になることがあるためです。r6g.large インスタンスは、小規模な本番ワークロードのためのオプションです (データノードと専用マスターノードの両方として)。

最新の Amazon gp3 EBS ボリュームを使用する

OpenSearch データノードは、高速インデックス作成とクエリを提供するために、低レイテンシーと高スループットのストレージを必要とします。Amazon EBSgp3 ボリュームを使用すると、以前に提供された Amazon gp2 ボリュームタイプよりも 9.6% 低いコストで、より高いベースラインパフォーマンス (IOPS EBS とスループット) が得られます。gp3 を使用して、ボリュームサイズに関係なく、追加の IOPSとスループットをプロビジョニングできます。これらのボリュームはバーストクレジットを使用しないため、前世代のボリュームよりも安定性が優れています。gp3 ボリュームタイプは、 per-data-nodegp2 ボリュームタイプのボリュームサイズ制限も倍増します。これらのより大きなボリュームを使用すると、データノードあたりのストレージ容量を増やすことによって、パッシブデータのコストを削減できます。

時系列ログデータに UltraWarm とコールドストレージを使用する

ログ分析 OpenSearch に を使用している場合は、コストを削減するためにデータを UltraWarm またはコールドストレージに移動してください。Index State Management (ISM) を使用して、ストレージ層間でデータを移行し、データ保持を管理します。

UltraWarm は、大量の読み取り専用データを OpenSearch Service. UltraWarm use Amazon S3 に保存するためのコスト効率の高い方法を提供します。これは、データが不変であり、コピーが 1 つだけ必要なことを意味します。インデックス内のプライマリシャードのサイズに相当するストレージの料金のみをお支払いいただきます。 UltraWarm クエリのレイテンシーは、クエリの処理に必要な S3 データの量とともに増加します。ノードにデータがキャッシュされると、 UltraWarm インデックスへのクエリはホットインデックスへのクエリと同様に実行されます。

コールドストレージも S3 を使用します。コールドデータをクエリする必要がある場合は、既存の UltraWarm ノードに選択的にアタッチできます。コールドデータには と同じマネージドストレージコストが発生しますが UltraWarm、コールドストレージのオブジェクトは UltraWarm ノードリソースを消費しません。したがって、コールドストレージは、 UltraWarm ノードのサイズや数に影響を与えることなく、大量のストレージ容量を提供します。

UltraWarm ホットストレージから移行するデータ量が約 2.5 TiB になると、 はコスト効率が向上します。フィルレートをモニタリングし、そのデータ量に達する前にインデックスを UltraWarmに移動する計画を立てます。

リザーブドインスタンスの推奨事項を確認する

パフォーマンスとコンピューティングの消費量に関するベースラインが良好になったら、リザーブドインスタンス (RIs) の購入を検討してください。割引は、前払いなしの 1 年間の予約で約 30% から始まり、全額前払いの 3 年間の契約では最大 50% まで増加する可能性があります。

少なくとも 14 日間安定した動作を確認したら、Cost Explorer で [Reserved Instance recommendations] (リザーブドインスタンスの推奨事項) を確認します。Amazon OpenSearch Service の見出しには、特定の RI 購入のレコメンデーションと予想される節約額が表示されます。