Amazon OpenSearch Service のコスト最適化手法

OpenSearch は、取り込まれたすべてのドキュメントを 2 回保存します。1 回は _sourceフィールド (raw ドキュメント) に、もう 1 回は検索用のインデックス付きフィールドとして保存します。

_source フィールド単独では、大量のストレージ領域を消費する可能性があります。多くの場合、インデックスストレージ全体の 30～50% です。

派生ソースでは、保存をスキップ_sourceし、必要に応じてインデックス付きフィールドから動的に再構築します (検索、取得、mget、再インデックス、または更新オペレーション中）。

これはオプトインであり、複合インデックス設定を使用してインデックスの作成時に有効になります。

OpenSearch 3.1 以降がサポートされているすべてのリージョンで使用できます。

OR2: OR1 よりもインデックス作成スループットが最大 26% 高く、R7g インスタンスよりも 70% 高くなります。

OM2: OR1 よりもインデックス作成スループットが最大 15% 高く、M7g インスタンスよりも 66% 高くなります。

どちらも同じアーキテクチャを使用しています。プライマリストレージにはローカル EBS、耐久性には S3 です。

レプリカストレージコストを排除 - 高価な EBS ボリュームの代わりに S3 に保存されるレプリカ (耐久性 9 分の 11)。

前世代のインスタンスと比較して、最大 30% の価格パフォーマンスの向上。

浅いスナップショット v2 をサポート — I/O オーバーヘッドのないほぼ即時のスナップショット。

IoT/センサーデータ: 最近の期間、1 秒あたりのデータをホットストレージに保持します。古いデータについては、時間単位または日単位の概要にロールアップします。

システムメトリクス: 過去 30 日間の詳細なメトリクスを保持し、古いデータを時間単位または日単位の概要に集約します。

ログデータ: アクティブなトラブルシューティングウィンドウ (1 週間など) の完全な詳細を保持し、古い期間に要約されたエラーパターンを維持します。

ISM ポリシーと組み合わせて、単一のライフサイクルポリシーでロールアップと階層の移行を自動化します。

数秒から数時間への集計では、数秒から数分への集計よりも大幅な削減が可能です。

インデックスを自動的に移行する: 年齢、サイズ、ドキュメント数に基づいて、ホットから UltraWarm へ、コールドから削除へ。

階層が移行する前にロールアップをトリガーして、データ量を減らします。

ロールオーバーポリシー (インデックスが 50 GB に達した場合や 30 日が経過した場合など) を設定して、インデックスの増加を制御します。

読み取り専用インデックスの強制マージを自動化して、削除されたドキュメントからストレージを再利用します。

ロールアップと組み合わせることで、大規模な時系列データセットの節約を最大化できます。

前払いなし、一部前払い、または全額前払いの支払いオプションを含む 1 年間または 3 年間のコミットメント期間。

ホット階層データノードと、継続的に実行される専用マスターノードに最適です。

AWS 料金計算ツールを使用して、コミット前に削減額を見積もります。

リザーブドインスタンスは、オンデマンドインスタンスに適用される請求割引であり、インフラストラクチャの変更は必要ありません。

常に最新世代のインスタンスを使用してください (例えば、Graviton3 インスタンスは Graviton2-basedインスタンスよりもパフォーマンスが最大 25% 向上します）。

gp2 の代わりに gp3 EBS ボリュームを使用する — 追加料金なしで低コストでパフォーマンスが向上します。

インスタンスタイプをワークロードに一致: 検索量が多い場合はメモリ最適化、インデックス作成量が多い場合はコンピューティング最適化。

専用クラスターマネージャーノードを評価する: 3 つ以上のデータノードにのみ必要です。マスターノードサイズの過剰プロビジョニングは避けてください。

CloudWatch メトリクスをモニタリングしてオーバープロビジョニングを検出します。持続的な CPU が 40% 未満、JVM が 50% 未満、ストレージが 50% 未満の場合は、無駄の兆候です。

最適な範囲: CPU 60～80%、JVM 65～85%、持続的なワークロードのストレージ 70～85%。

推奨されるシャードサイズ: ワークロードに応じて、シャードあたり 10～50 GiB。

Java ヒープの GiB あたり 25 個以下のシャード、データノードあたり 1,000 個以下のシャード。

ISM ロールオーバーポリシーを使用してインデックスの増加を制御し、無制限のシャードの拡散を回避します。

耐久性が許容されるレプリカ数を減らします (OR1/OR2 インスタンスはレプリカを完全に不要にします）。

読み取り専用インデックスで強制マージを使用して、セグメント数を減らし、ストレージを再利用します。

取り込みコストなし — データは S3 に残ります。

アーカイブデータのホット階層ストレージコストはかかりません。

Pay-per-queryコンピューティングモデル。

視覚化のために OpenSearch Dashboards をサポートします。

秒または分のレイテンシーは許容されます。リアルタイムのユースケースでは許容されません。

サンプリング: 大量のログストリームの代表的なサブセットのみを取り込みます (デバッグログの 10% など）。

インデックス圧縮: 最適な圧縮コーデックを有効にして、ストレージフットプリントを削減します。

フィールドフィルタリング: インデックス作成の前に高カーディナリティ、低値フィールドを削除します (古いログの raw スタックトレースなど）。

保持ポリシー: コンプライアンス要件に合わせて最大保持期間を定義します。データを無期限に保存しないでください。

サポートされていない古いバージョンにとどまると、インスタンスコストに加えて追加料金が発生します。

延長サポート料金が発生しないように、現在サポートされているバージョンにアップグレードします。

OpenSearch ドメインにコスト配分タグを適用して、チームまたはワークロードごとの詳細なコスト追跡を行います。

ストレージ使用率、JVM プレッシャー、CPU の CloudWatch アラームを設定して、オーバープロビジョニングを早期に検出します。

一貫して使用率が低いドメインを識別するには、 AWS Cost Explorer を使用します。

自動調整の評価 — JVM ヒープサイズやその他の設定を自動的に調整して、パフォーマンスを向上させ、リソースの無駄を削減します。

標準 (in_memory) モードでは、完全な HNSW グラフが RAM にロードされます。RAM は大規模に非常に高価になります。

on_disk モードでは、圧縮 (量子化) ベクトルのみが候補生成のためにメモリに保持されます。全精度ベクトルは、最終的な再スコアリングフェーズ (2 フェーズ検索) でのみディスクから取得されます。

これにより、高い検索品質を維持しながら RAM 要件が大幅に削減されます。

デフォルトon_diskモードでは 32 倍のバイナリ量子化が使用されるため、メモリ内モードと比較してメモリ要件が 97% 削減されます。

圧縮レベルをサポート: 2x (FP16)、4x (バイト）、8x、16x、32x (バイナリ）。

100～200 ミリ秒の範囲の P90 レイテンシー — 1 桁ミリ秒の応答時間を必要としないワークロードに適しています。

最適化に関する推奨事項を 1 時間未満で提供します。

ベクトル取り込みパイプラインと統合されています。

数十億規模のベクトルデータベースの GPU アクセラレーションインデックス作成と組み合わせることができます。

CPU のみのインデックス作成と比較して、インデックスの構築時間が 6.4 倍から 13.8 倍短縮されました。

書き込みが多いベクトルワークロードのインデックス作成 OCU コストを最大 75% 削減します。

GPUsは動的にアタッチされます。GPU アクセラレーションがアクティブな場合にのみ OCUs に対して料金が発生します。

1 時間以内に 10 億規模のベクトルデータベースを構築できます。

Vector Acceleration OCUs。

アカウントレベル: 最大 1,700 OCUs (16 の倍数に制限されません）。

コレクショングループ: 1、2、4、8、16、および 16～1,696 OCUs。

インデックスまたはインデックスパターンごとに保持期間を 24 時間から 3,650 日に設定します。

Amazon OpenSearch Service Serverless は、ベストエフォートベース (通常は 48 時間以内、または保持期間の 10% 以内) でデータを自動的に削除します。

ルールは、コレクションレベル、インデックスパターンレベル、または個々のインデックスレベルで適用できます。より具体的なルールが優先されます。

1 TiB/日取り込み、保持期間が 30 日 = 約 1 TiB のホットデータ = インデックス作成の場合は 20 OCUs、検索の場合は 20 OCUs。

7 日間の保持期間に短縮 = 約 233 GiB のホットデータ = インデックス作成の場合は約 4 OCUs、検索の場合は 4 OCUs。

取り込み時にフィールドをフィルタリングする: パイプラインを使用して、コレクションに到達する前に低値のフィールドを削除します。

重複データや冗長データを取り込まないでください: パイプラインレベルで重複排除します。

適切なインデックスマッピングを使用する: 保存されているが検索されていないフィールドでインデックス作成を無効にします ("index": false)。

検索コレクションの場合: 検索値なしでストレージを膨張させる大きなバイナリ BLOB や未加工テキストを保存しないでください。

以前は、各一意の KMS キーには専用 OCUs が必要でした。これにより、テナントあたりの分離コストが大幅に高まりました。

コレクショングループを使用すると、個別の暗号化キーを持つテナントは OCU 容量を共有できます。

多数の小規模なテナントワークロードで最大 90% のコスト削減。

最小 OCUs (保証されたベースライン、コールドスタートなし) と最大 OCUs (コスト上限) の両方をサポートします。

異なるネットワークアクセスタイプ (パブリックと VPC) のコレクションは、同じグループに共存できます。

CloudWatch メトリクスは、リソースの消費量とレイテンシーをグループごとに可視化します。