翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon OpenSearch Service の多層ストレージ
Amazon OpenSearch Service の多層ストレージは、さまざまなストレージ階層にわたってデータを管理することで、パフォーマンスとコストの両方を最適化するインテリジェントなデータ管理ソリューションです。このアーキテクチャにより、組織はアクセス頻度の低いデータをコスト効率の高いウォームストレージに移動しながら、アクセス頻度の高いデータを高性能ホットストレージに保持することで、パフォーマンスとコストのトレードオフを効率的にバランスさせることができます。
Amazon OpenSearch Service には、ホット/ウォームストレージ階層用の 2 つのアーキテクチャオプションがあります。
-
OpenSearch 多層ストレージアーキテクチャ
Amazon S3 をローカルインスタンスストレージと組み合わせる
OpenSearch Optimized Instances を利用
ウォーム階層での書き込みオペレーションをサポート
ホット階層とウォーム階層間のシームレスなデータ移行をサポート
OpenSearch 3.3 以降で利用可能
コールド階層をサポートしていません
-
UltraWarm ベースのアーキテクチャ
Amazon S3 をローカルインスタンスストレージと組み合わせる
UltraWarm インスタンスを使用
読み取り専用のウォーム階層ワークロード向けに最適化
Elasticsearch バージョン 6.8 以降およびすべての OpenSearch バージョンで利用可能
コールド階層をサポート
注記
このドキュメントでは、多層アーキテクチャのみに焦点を当てています。Ultrawarm ストレージアーキテクチャについては、「Ultrawarm および Cold Storage」を参照してください。
多層ストレージアーキテクチャ
主な利点
Writable Warm: ウォームインデックスの書き込みオペレーションをサポート
シームレスな移行: ストレージ層間のデータのシームレスな移動
コスト最適化: 非アクティブデータを費用対効果の高いウォームストレージに移動することで、ストレージコストを削減
パフォーマンスの向上: ホット階層内の頻繁にアクセスされるデータに対して高いパフォーマンスを維持します。
柔軟なデータ管理: ワークロード要件に最適なアーキテクチャを選択する
自動管理: ストレージ階層全体のデータライフサイクル管理を簡素化
前提条件
エンジンバージョン: OpenSearch 3.3 以降
-
インスタンスファミリー:
ホットノード: OR1, OR2, OM2、または OI2
ウォームノード: OI2
セキュリティ: Node-to-node暗号化、保管時の暗号化、HTTPS の適用
制限事項
Ultrawarm がまだ有効になっていない OpenSearch 最適化インスタンスを持つすべてのドメインで動作します
コールド階層のサポートなし
主要事項
ホットからウォームへの移行では、マルチ層アーキテクチャでの強制マージはトリガーされません。必要に応じて、ユーザーはインデックス管理ポリシーを使用して強制マージをオーケストレーションできます。
インデックス作成とは別に、ウォームノードはバックグラウンドマージオペレーションも実行するようになりました (ホットに似ています)。
ウォームインデックスに対するすべての検索リクエストはプライマリシャードにルーティングされ、レプリカはプライマリシャードがダウンしている場合にのみ読み取りを提供します。
このアーキテクチャでは、ウォームインデックスの自動スナップショットもサポートされています。
クロスクラスターレプリケーションはホットインデックスでのみサポートされています
Shrink、Split、Clone などのインデックス APIs はウォームインデックスでは機能しません。
多層ドメインの作成
ステップ 1: ドメインを作成する
aws opensearch create-domain \ --domain-name my-domain \ --engine-version OpenSearch_3.3 \ --cluster-config InstanceCount=3,InstanceType=or2.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=m6g.large.search,DedicatedMasterCount=3,WarmEnabled=true,WarmCount=3,WarmType=oi2.2xlarge.search \ --ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \ --node-to-node-encryption-options Enabled=true \ --encryption-at-rest-options Enabled=true \ --domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \ --advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"user_name","MasterUserPassword":"your_pass"}}' \ --access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":"*","Action":"es:*","Resource":"*"}]}' \ --region us-east-1
ステップ 2: ウォームノードを検証する
aws opensearch describe-domain-nodes --domain-name my-domain --region us-east-1
サンプルレスポンス (抜粋):
{ "NodeType": "Warm", "InstanceType": "oi2.large.search", "NodeStatus": "Active" }
階層移行の管理
多層ドメインは以下をサポートします。
簡素化されたエクスペリエンスのための新しい階層化 APIs
互換性のためのレガシー UltraWarm APIs
新しい階層化 APIs
インデックスをウォームに移行します。
curl -XPOST 'https://localhost:9200/index-name/_tier/warm'
レスポンス:
{"acknowledged": true}
インデックスをホットに移行します。
curl -XPOST 'https://localhost:9200/index-name/_tier/hot'
レスポンス:
{"acknowledged": true}
階層化ステータスを確認します。
curl -XGET 'https://localhost:9200/index-name/_tier'
レスポンスの例:
{ "tiering_status": { "index": "index-name", "state": "RUNNING_SHARD_RELOCATION", "source": "HOT", "target": "WARM", "start_time": 1745836500563, "shard_level_status": { "running": 0, "total": 100, "pending": 100, "succeeded": 0 } } }
詳細なシャードビュー:
curl 'https://localhost:9200/index1/_tier?detailed=true'
進行中の移行をすべて一覧表示する (テキスト):
curl 'https://localhost:9200/_tier/all'
進行中の移行 (JSON) をすべて一覧表示します。
curl 'https://localhost:9200/_tier/all?format=json'
ターゲット階層でフィルタリング:
curl 'https://localhost:9200/_tier/all?target=_warm'
互換性のためのレガシー UltraWarm APIs
ウォームに移行:
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_warm
ホットへの移行:
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_hot
ステータスを確認します。
curl -XGET localhost:9200/_ultrawarm/migration/index2/_status
セキュリティ設定
既存の Amazon OpenSearch Service ドメインで多層ストレージを有効にした場合、storage_tiering_managerロールがドメインで定義されていない可能性があります。きめ細かなアクセスコントロールを使用してドメインのウォームインデックスを管理するには、管理者以外のユーザーがこのロールにマッピングされている必要があります。storage_tiering_manager ロールを手動で作成するには、以下のステップを実行します。
-
OpenSearch Dashboards で、[セキュリティ] に進み、[許可] を選択します。
-
[アクショングループの作成] を選択し、以下のグループを設定します。
グループ名 権限 storage_tiering_cluster インデックス:admin/_tier/all storage_tiering_index_read インデックス:admin/_tier/get、インデックス:admin/get storage_tiering_index_write インデックス:admin/_tier/hot_to_warm、インデックス:admin/_tier/warm_to_hot -
[ロール]、[ロールの作成] の順に選択します。
-
ロールに
storage_tiering_managerという名前を付けます。 -
クラスターの許可 では、
storage_tiering_clusterおよびcluster_monitorを選択します。 -
[インデックス] では、
*と入力します。 -
インデックスのアクセス許可については、
storage_tiering_index_read、、storage_tiering_index_writeおよび を選択しますindices_monitor。 -
[作成] を選択します。
-
ロールを作成したら、多層インデックスを管理する任意のユーザーまたはバックエンドロールにマッピングします。
ベストプラクティス
Amazon OpenSearch Service ドメインに多層ストレージを実装するときは、次のベストプラクティスを考慮してください。
データアクセスパターンを定期的に見直して階層の割り当てを最適化する
パフォーマンスメトリクスをモニタリングして、効率的なリソース使用率を確保する
新しい階層化 APIs を使用してデータ移行をきめ細かく制御する
メトリクスのモニタリング
多層ストレージドメインは、ウォーム階層のパフォーマンスをモニタリングするための追加のメトリクスを提供します。これらのメトリクスには、既存の UltraWarm メトリクスと OpenSearch Optimized Instances アーキテクチャに固有の新しいメトリクスの両方が含まれます。
新しいメトリクス
| メトリクス名 | ノードレベルの統計 | クラスターレベルの統計 | 詳細度 |
|---|---|---|---|
| WarmIndexingLatency | 平均 | 平均 | 1 分 |
| WarmIndexingRate | 平均 | Average、Maximum、Sum | 1 分 |
| WarmThreadpoolIndexingQueue | 最大値 | 合計、最大、平均 | 1 分 |
| WarmThreadpoolIndexingRejected | 最大値 | 合計 | 1 分 |
| WarmThreadpoolIndexingThreads | 最大値 | 合計、平均 | 1 分 |