OpenSearch ダッシュボードにアクセスできない VPC ドメインにアクセスできない読み取り専用状態のクラスター赤のクラスター状態黄色のクラスター状態 ClusterBlockException Multi-AZ with Standby への移行中にエラーが発生した JVM OutOfMemoryError 障害が発生したクラスターノードシャードの最大制限を超えましたドメインが処理状態でスタックしている低 EBS バーストバランス監査ログを有効にできないインデックスが閉じないクライアントライセンスのチェックリクエストのスロットリングノードに SSH 接続できない「オブジェクトのストレージクラスで有効ではない」スナップショットエラー無効なホストヘッダー無効な M3 インスタンスタイプホットクエリは有効化すると動作しなくなります。 UltraWarm アップグレード後にダウングレードできないすべての AWS リージョンのドメインの概要が必要 OpenSearch ダッシュボード使用時のブラウザエラーノードシャードとストレージスキューインデックスシャードとストレージスキュー VPC アクセス選択後の許可されていないオペレーション VPC ドメイン作成後、読み込みでスタックする API へのリクエストが拒否されました。 OpenSearch Alpine Linux から接続できない Search Backpressure のリクエストが多すぎる SDK を使用する場合の証明書のエラー

Amazon OpenSearch サービスのトラブルシューティング

このトピックでは、Amazon OpenSearch Service の一般的な問題を特定して解決する方法について説明します。AWS サポートに問い合わせる前に、このセクションの情報を参照してください。

OpenSearch ダッシュボードにアクセスできない

OpenSearch ダッシュボードエンドポイントは署名付きリクエストをサポートしていません。ドメインのアクセスコントロールポリシーで、特定の IAM ロールにのみアクセス権が付与されており、Amazon Cognito 認証を設定していない場合は、Dashboards にアクセスしようとするときに次のエラーが発生する場合があります。


"User: anonymous is not authorized to perform: es:ESHttpGet"

OpenSearch サービスドメインが VPC アクセスを使用している場合、このエラーは表示されませんが、リクエストがタイムアウトする可能性があります。この問題の修正、および利用できるさまざまな設定オプションの詳細については、「 OpenSearch Dashboards へのアクセスの制御」、「VPC ドメインのアクセスポリシーについて」、および「Amazon OpenSearch Service での Identity and Access Management」を参照してください。

VPC ドメインにアクセスできない

「VPC ドメインのアクセスポリシーについて」および「VPC ドメインをテストする」を参照してください。

読み取り専用状態のクラスター

以前のバージョンの Elasticsearch OpenSearch や Elasticsearch 7 と比較してみてください。 x はクラスターの調整に別のシステムを使用しています。この新しいシステムでは、クラスターがクォーラムを失うと、アクションを実行するまでクラスターは使用できなくなります。クォーラム損失には 2 つの形式があります。

クラスターが専用マスターノードを使用している場合は、半分以上が利用できないときにクォーラム損失が発生します。
クラスターで専用マスターノードを使用していない場合は、データノードの半分以上が利用できないときにクォーラム損失が発生します。

クォーラム損失が発生し、クラスターに複数のノードがある場合、 OpenSearch Service はクォーラムを復元し、クラスターを読み取り専用状態にします。これには 2 つのオプションがあります。

読み取り専用状態を削除し、クラスターをそのまま使用します。
スナップショットからクラスターまたは個々のインデックスを復元します。

クラスターをそのまま使用する場合は、次のリクエストを使用してクラスターの状態が緑色であることを確認します。


GET _cat/health?v

クラスターの状態が赤の場合、スナップショットからクラスターを復元することをお勧めします。トラブルシューティングのステップについては、赤のクラスター状態も合わせてお読みください。クラスターの状態が緑色の場合は、次のリクエストを使用して、予想されるすべてのインデックスが存在することを確認します。


GET _cat/indices?v

次に、いくつかの検索を実行して、予想されるデータが存在することを確認します。存在する場合は、次のリクエストを使用して読み取り専用状態を削除できます。


PUT _cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": false
  }
}

クォーラム損失が発生し、クラスターにノードが 1 つしかない場合、 OpenSearch Service はそのノードを置き換え、クラスターを読み取り専用状態にはしません。それ以外の場合、オプションは同じです。つまり、クラスターをそのまま使用するか、スナップショットから復元します。

いずれの場合でも、 OpenSearch Service はに 2 つのイベントを送信します。AWS Health Dashboard最初のステップでは、クォーラムの損失が通知されます。2 つ目は、 OpenSearch Service がクォーラムを正常に復元した後に発生します。の使用方法について詳しくは AWS Health Dashboard、『ユーザーガイド』を参照してください。AWS Health

赤のクラスター状態

赤いクラスターステータスは、少なくとも 1 つのプライマリシャードとそのレプリカがノードに割り当てられていないことを意味します。 OpenSearch サービスはインデックスの状態に関係なくすべてのインデックスの自動スナップショットを取得しようとしますが、赤色のクラスターステータスが続く間はスナップショットは失敗します。

赤色のクラスターステータスの最も一般的な原因は、クラスターノードの障害と、 OpenSearch 継続的な高負荷によるプロセスのクラッシュです。

注記

OpenSearch Service は、クラスターの状態に関係なく、自動スナップショットを 14 日間保存します。したがって、赤のクラスター状態が 2 週間を超えて続くと、最後に正常な自動スナップショットが削除され、クラスターのデータが完全に失われることになります。 OpenSearch Service Domainのクラスタステータスが赤色になった場合は、自分で問題に対処するのか、 AWS Support それともサポートチームに支援してもらいたいのかを尋ねる場合があります。 CloudWatch 赤色のクラスターステータスが発生したときに通知するようにアラームを設定できます。

最終的に、赤のシャードにより赤のクラスターが発生し、赤のインデックスにより赤のシャードが発生します。赤色のクラスター状態の原因となっているインデックスを特定するのに役立つ API がいくつかあります。 OpenSearch

GET /_cluster/allocation/explain は、見つかった最初の割り当てられていないシャードを選択し、そのシャードをノードに割り当てることができない理由について説明します。


{
    "index": "test4",
    "shard": 0,
    "primary": true,
    "current_state": "unassigned",
    "can_allocate": "no",
    "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes"
}

GET /_cat/indices?v はヘルス状態、ドキュメントの数、および各インデックスのディスク使用量を表示します。


health status index            uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   test1            30h1EiMvS5uAFr2t5CEVoQ   5   0        820            0       14mb           14mb
green  open   test2            sdIxs_WDT56afFGu5KPbFQ   1   0          0            0       233b           233b
green  open   test3            GGRZp_TBRZuSaZpAGk2pmw   1   1          2            0     14.7kb          7.3kb
red    open   test4            BJxfAErbTtu5HBjIXJV_7A   1   0
green  open   test5            _8C6MIXOSxCqVYicH3jsEA   1   0          7            0     24.3kb         24.3kb

赤のインデックスを削除することが、赤のクラスター状態を修正するための最速の方法です。赤いクラスターのステータスの理由によっては、より大きなインスタンスタイプ、より多くのインスタンス、または EBS OpenSearch ベースのストレージを使用するようにサービスドメインをスケーリングし、問題のあるインデックスを再作成してみることもできます。

問題のあるインデックスを削除することが可能でない場合、スナップショットを復元する、インデックスからドキュメントを削除する、インデックスの設定を変更する、レプリカの数を減らす、または他のインデックスを削除してディスク領域を解放することができます。重要なステップは、サービス・ドメインを再構成する前に、赤いクラスターの状態を解決することです。 OpenSearch 赤のクラスター状態のドメインを再設定すると、問題が複雑化し、状態を解決するまで、設定状態が [処理中] のままドメインがスタックする可能性があります。

赤いクラスターの自動修復

クラスターのステータスが 1 時間以上赤く表示され続けている場合、 OpenSearch Service は割り当てられていないシャードを再ルーティングするか、過去のスナップショットから復元することで、自動的に問題を解決しようとします。

1 つ以上の赤色のインデックスの修正に失敗し、クラスターのステータスが合計 14 日間赤色のままである場合、 OpenSearch Service はクラスターが次の基準の少なくとも 1 つを満たしている場合にのみ追加のアクションを実行します。

アベイラビリティーゾーンが 1 つだけである
専用マスターノードがある
バースト可能なインスタンスタイプ (T2 または T3) が含まれる

この時点で、クラスタがこれらの基準のいずれかを満たしている場合、 OpenSearch Service は次の 7 日間にわたって、これらのインデックスを修正しないと割り当てられていないシャードがすべて削除されることを説明する通知を毎日送信します。21 日経ってもクラスターのステータスが赤色のままの場合、 OpenSearch Service は赤色のインデックスにある未割り当てのシャード (ストレージとコンピューティング) をすべて削除します。これらのイベントのそれぞれについて、 OpenSearch サービスコンソールの通知パネルに通知が届きます。詳細については、「クラスターヘルスイベント」を参照してください。

処理の継続的な高負荷からの復旧

赤のクラスター状態がデータノードの処理の継続的な高負荷によるものであるかどうかを判断するには、次のクラスターメトリクスをモニタリングします。

関連するメトリクス	説明	復旧
JVM MemoryPressure	クラスター内のすべてのデータノードで使用する Java ヒープのパーセンテージを指定します。このメトリクスの [最大] の統計を表示し、Java ガベージコレクターが十分なメモリの回収に失敗したことで生じる少量ずつのメモリプレッシャーを検出します。このパターンは通常、複雑なクエリまたは大きいデータフィールドが原因です。 x86 インスタンスタイプは、コンカレントマークスイープ (CMS) ガベージコレクターを使用します。このガベージコレクターは、アプリケーションスレッドとともに一時停止を短くします。通常の収集処理中に CMS が十分なメモリを再利用できない場合、完全なガベージコレクションがトリガーされ、アプリケーションが長時間一時停止し、クラスターの安定性に影響する可能性があります。 ARM ベースの Graviton インスタンスタイプは、Garbage-First (G1) ガベージコレクターを使用します。G1 ガベージコレクターは CMS に似ていますが、追加の短い一時停止とヒープの最適化を使用して、完全なガベージコレクションの必要性をさらに減らします。いずれの場合も、ガベージコレクションが満杯になったときにガベージコレクターが再利用できる量を超えてメモリー使用量が増え続けると、 OpenSearch メモリー不足エラーでクラッシュします。すべてのインスタンスタイプで使用率を 80% 以下にすることをお勧めします。 `_nodes/stats/jvm` API は、JVM 統計の有用な要約、メモリプールの使用量、およびガベージコレクションの情報を提供します。 `GET domain-endpoint/_nodes/stats/jvm?pretty`	JVM のメモリサーキットブレーカーを設定します。詳細については、「JVM OutOfMemoryError」を参照してください。問題が解決しない場合は、不要なインデックスを削除する、ドメインへのリクエストの数または複雑性を減少する、インスタンスを追加する、あるいはより大きなインスタンスタイプを使用します。
CPUUtilization	クラスター内のデータノードで使用する CPU リソースのパーセンテージを指定します。このメトリクスの [最大] の統計を表示し、使用量の多い継続的なパターンを探します。	データノードを追加するか、既存のデータノードのインスタンスタイプのサイズを大きくします。
ノード	クラスターのノード数の指定。このメトリクスの [最小] の統計を表示します。サービスがクラスターの新しいインスタンス群をデプロイすると、この値が変動します。	データノードを追加します。

黄色のクラスター状態

黄色のクラスター状態は、すべてのインデックスのプライマリシャードがクラスター内のノードに割り当てられ、少なくとも 1 つのインデックスのレプリカシャードは割り当てられていないことを意味します。 OpenSearch Service がレプリカを割り当てることができるノードは他にないため、単一ノードクラスターは常に黄色のクラスターステータスで初期化されます。緑のクラスター状態を確保するには、ノード数を増やします。詳細については、「Amazon OpenSearch Service ドメインのサイズ設定」を参照してください。

マルチノードクラスターは、新しいインデックスを作成した後、またはノード障害の後に、一時的に黄色のクラスター状態になることがあります。このステータスは、 OpenSearch クラスター全体でデータを複製することで自動的に解決されます。ディスク容量の不足も黄色のクラスター状態を引き起こす可能性があります。クラスターは、ノードにレプリカシャードを収容するディスク領域がある場合のみ、レプリカシャードを配布できます。

ClusterBlockException

以下の理由により、ClusterBlockException エラーを受け取る場合があります。

使用可能なストレージ領域の不足

クラスター内の 1 つ以上のノードのストレージ容量が、1) 使用可能なストレージスペースの 20%、または 2) 20 GiB のストレージスペースの最小値未満の場合、ドキュメントの追加やインデックスの作成などの基本的な書き込み操作が失敗し始める可能性があります。ストレージ要件の計算 OpenSearch Service がディスク容量をどのように使用するかの概要を示します。

問題を回避するには、FreeStorageSpace OpenSearch サービスコンソールでメトリックスを監視し、 CloudWatch FreeStorageSpace特定のしきい値を下回ったときにトリガーするアラームを作成します。 GET /_cat/allocation?vまた、シャード割り当てとディスク使用量の便利な概要も表示されます。ストレージ容量不足に関連する問題を解決するには、 OpenSearch サービストメインをスケーリングして、より大きなインスタンスタイプ、より多くのインスタンス、または EBS ベースのストレージを使用するようにします。

JVM メモリ負荷が高い

JVM MemoryPressure メトリックスが 30 分間 92% を超えると、 OpenSearch Service は保護メカニズムをトリガーし、すべての書き込み操作をブロックして、クラスターが赤のステータスになるのを防ぎます。保護が有効な状態では、書き込みオペレーションは ClusterBlockException エラーで失敗し、新しいインデックスは作成できず IndexCreateBlockException エラーがスローされます。

JVM MemoryPressure メトリクスが 88% 以下に戻って 5 分間続くと、保護は無効になり、クラスターへの書き込み操作のブロックは解除されます。

高い JVM のメモリ負荷は、クラスターに対するリクエスト数の急増、ノード全体でのシャード割り当ての不均衡、クラスター内の過度に多いシャード、大量のフィールドデータまたはインデックスマッピング、または入ってくる負荷を処理できないインスタンスタイプによって引き起こされることがあります。また、集計やワイルドカードを使用したり、クエリで広い時間範囲を使用したりすることによって発生することもあります。

クラスターへのトラフィックを減らし、JVM のメモリ負荷が高い問題を解決するには、次の 1 つ以上を試してください。

ノードあたりの最大ヒープサイズが 32 GB になるようにドメインをスケールする。
古いインデックスや未使用のインデックスを削除して、シャードの数を減らす。
POST index-name/_cache/clear?fielddata=true API オペレーションでデータキャッシュをクリアする。キャッシュをクリアすると、進行中のクエリが中断される可能性があることに注意してください。

一般的に、将来 JVM メモリの負荷が高くなるのを避けるために、次のベストプラクティスに従ってください。

テキストフィールドでの集計を避けるか、インデックスのマッピングタイプを keyword に変更します。
適切な数のシャードを選択して、検索とインデックス作成のリクエストを最適化します。
定期的に未使用のインデックスを削除するように Index State Management (ISM) ポリシーを設定します。

Multi-AZ with Standby への移行中にエラーが発生した

既存のドメインを Multi-AZ with Standby に移行する際に、次の問題が発生する場合があります。

スタンバイのないドメインからスタンバイのあるドメインへの移行している最中に、インデックス、インデックステンプレート、ISM ポリシーのいずれかを作成する

スタンバイのないマルチ AZ からスタンバイのあるマルチ AZ に移行する際にインデックスを作成し、そのインデックスのテンプレートまたは ISM ポリシーが、推奨されているデータコピーのガイドラインに従っていない場合、データの不一致が生じて移行に失敗する可能性があります。この状況を回避するには、3 の倍数のデータコピー数 (プライマリノードとレプリカの両方を含む) で新しいインデックスを作成します。移行の進行状況は、DescribeDomainChangeProgress API を使って確認できます。レプリカ数のエラーが発生した場合は、エラーを修正してからAWS サポートに連絡し、移行を再試行します。

データコピーの数が間違っている

ドメインに適切な数のデータコピーがないと、Multi-AZ with Standby への移行は失敗します。

JVM OutOfMemoryError

JVM の OutOfMemoryError は、一般的に次のいずれかの JVM サーキットブレーカーに到達したことを意味します。

サーキットブレーカー	説明	クラスター設定プロパティ
親ブレーカー	すべてのサーキットブレーカーで JVM ヒープメモリのパーセンテージの合計に許可されます。デフォルト値は 95% です。	`indices.breaker.total.limit`
フィールドデータブレーカー	JVM ヒープメモリのパーセンテージは、メモリに単一のデータフィールドをロードすることを許可します。デフォルト値は 40% です。大きいフィールドを用いてデータをアップロードする場合は、この上限を引き上げる必要があります。	`indices.breaker.fielddata.limit`
リクエストブレーカー	JVM ヒープメモリのパーセンテージは、サービスリクエストに応答するために使用されるデータ構造に許可されます。デフォルト値は 60% です。サービスリクエストが集計の計算を含む場合は、この上限を引き上げる必要がある場合があります。	`indices.breaker.request.limit`

障害が発生したクラスターノード

Amazon EC2 インスタンスでは、予期しない終了と再起動が発生する場合があります。通常、 OpenSearch サービスはノードを自動的に再起動します。ただし、 OpenSearchクラスター内の 1 つ以上のノードが障害状態のままになることがあります。

この状態を確認するには、 OpenSearch サービスコンソールでドメインダッシュボードを開きます。[クラスターのヘルス] タブに移動し、[ノード合計数] メトリクスを見つけます。報告されるノード数がクラスターに設定した数より小さいかどうかを調べます。メトリクスが、1 つ以上のノードが 1 日以上ダウンしていることを示している場合は、AWS サポートまでお問い合わせください。

また、 CloudWatch この問題が発生したときに通知するアラームを設定することもできます。

注記

[合計ノード] メトリクスは、クラスター設定の変更中およびサービスの定期的なメンテナンス中は、正確ではありません。この動作は想定されるものです。メトリクスは、すぐに正しい数のクラスターノードを報告します。詳細については、「Amazon OpenSearch Service での設定変更」を参照してください。

クラスターを予期しないノード終了や再起動から保護するには、 OpenSearch サービスドメイン内のインデックスごとに少なくとも 1 つのレプリカを作成します。

シャードの最大制限を超えました

OpenSearch 7 も同様です。 x バージョンの Elasticsearch では、ノードあたりのシャード数は 1,000 個以下のデフォルト設定になっています。 OpenSearch/Elasticsearch は、新しいインデックスの作成などのリクエストによってこの制限を超えるとエラーを返します。このエラーが発生した場合は、いくつかのオプションがあります。

さらにデータノードをクラスターに追加します。
_cluster/settings/cluster.max_shards_per_node 設定を増加します。
_shrink API を使用して、ノードのシャード数を減らします。

ドメインが処理状態でスタックしている

OpenSearch 設定変更の途中、サービスドメインは「処理中」状態になります。設定変更を開始すると、 OpenSearch Service が新しい環境を作成する間、ドメインのステータスが「処理中」に変わります。新しい環境では、 OpenSearch Service は適用可能なノードの新しいセット (データ、マスター、など UltraWarm) を起動します。移行が完了すると、古いノードは終了します。

次のいずれかの状況が発生した場合、クラスターは「処理中」状態でスタックすることがあります。

新しいデータノードセットの起動は失敗します。

新しいデータノードセットへのシャード移行は失敗します。
検証チェックがエラーで失敗しました。

これらの各状況における詳細な解決手順については、「Amazon OpenSearch Service ドメインが「処理中」状態で停止しているのはなぜですか? を参照してください。。

低 EBS バーストバランス

OpenSearch いずれかの汎用 (SSD) ボリュームの EBS バースト残高が 70% を下回るとコンソール通知が送信され、残高が 20% を下回るとフォローアップ通知が送信されます。この問題を解決するには、クラスターをスケールアップするか、読み取り/書き込み IOPS を減らしてバーストバランスをクレジットすることができます。gp3 ボリュームタイプを使用するドメインと、ボリュームサイズが 1,000 GiB を超える gp2 ボリュームを使用するドメインのバーストバランスは 0 のままになります。詳細については、「汎用 SSD ボリューム (gp2)」を参照してください。EBS バースト残高はメトリックスで監視できます。BurstBalance CloudWatch

監査ログを有効にできない

OpenSearch サービスコンソールを使用して監査ログの公開を有効にしようとすると、次のエラーが発生することがあります。

CloudWatch Logs ロググループに指定されたリソースアクセスポリシーでは、Amazon OpenSearch Service がログストリームを作成するための十分なアクセス権限を付与していません。リソースアクセスポリシーを確認してください。

このエラーが発生した場合は、ポリシーの resource 要素に正しいロググループ ARN が含まれていることを確認してください。その場合は、次のステップを実行します。

数分間待ちます。
ウェブブラウザでページを更新します。
[既存のグループを選択] を選択します。
[既存のロググループ] では、エラーメッセージを受け取る前に作成したロググループを選択します。
[アクセスポリシー]セクションで、[既存のポリシーを選択] を選択します。
[既存のポリシー] では、エラーメッセージを受け取る前に作成したポリシーを選択します。
[有効] を選択します。

プロセスを数回繰り返してもエラーが続く場合は、AWS サポートに連絡してください。

インデックスが閉じない

OpenSearch このサービスは Elasticsearch バージョン 7.4 以降の _close OpenSearch API のみをサポートしています。古いバージョンを使用していて、スナップショットからインデックスを復元している場合は、既存のインデックスを削除することができます (それの再インデックスの前または後)。

クライアントライセンスのチェック

LogstashとBeatsのデフォルトディストリビューションには独自のライセンスチェックが含まれており、のオープンソースバージョンには接続できません。 OpenSearchService では、これらのクライアントの Apache 2.0 (OSS) ディストリビューションを必ず使用してください。 OpenSearch

リクエストのスロットリング

永続的に 403 Request throttled due to too many requests または 429 Too Many Requests エラーを受け取る場合は、垂直スケーリングを検討してください。ペイロードによってメモリ使用量が Java ヒープの最大サイズを超える場合、Amazon OpenSearch Service はリクエストを調整します。

ノードに SSH 接続できない

SSH OpenSearch を使用してクラスター内のどのノードにもアクセスすることはできず、直接変更することもできません。opensearch.yml代わりに、コンソール AWS CLI、または SDK を使用してドメインを設定してください。 OpenSearchREST API を使用してクラスターレベルの設定をいくつか指定することもできます。詳細については、「Amazon OpenSearch サービス API リファレンス」と「」を参照してくださいAmazon OpenSearch Service でサポートされているオペレーション。

クラスターのパフォーマンスについてさらに詳しく知りたい場合は、エラーログとスローログをに公開できます CloudWatch。

「オブジェクトのストレージクラスで有効ではない」スナップショットエラー

OpenSearch サービススナップショットは S3 Glacier ストレージクラスをサポートしていません。このエラーは、オブジェクトを S3 Glacier ストレージクラスに移行するライフサイクルルールが S3 バケットに含まれている場合に、スナップショットのリストを取得しようとすると発生する場合があります。

バケットからスナップショットを復元する必要がある場合は、S3 Glacier からオブジェクトを復元し、オブジェクトを新しいバケットにコピーして、スナップショットリポジトリとして新しいバケットを登録します。

無効なホストヘッダー

OpenSearch サービスでは、Hostクライアントがリクエストヘッダーで指定する必要があります。有効な Host 値は、次のような、https:// のないドメインエンドポイントです。


Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com

Invalid Host Headerリクエストを行う際にエラーが発生した場合は、 OpenSearch Hostクライアントまたはプロキシのヘッダーにサービスドメインエンドポイント (IP アドレスなどではない) が含まれていることを確認してください。

無効な M3 インスタンスタイプ

OpenSearch このサービスは、Elasticsearch バージョン 6.7 以降を実行している既存のドメインへの M3 OpenSearch インスタンスの追加や変更をサポートしていません。Elasticsearch 6.5 以前では、M3 インスタンスを引き続き使用できます。

新しいインスタンスタイプの選択をお勧めします。Elasticsearch 6.7 OpenSearch 以降を実行しているドメインには、以下の制限が適用されます。

既存のドメインで M3 インスタンスを使用していない場合、今後これらに変更することはできません。
既存のドメインを M3 インスタンスタイプから別のインスタンスタイプに変更した場合、元に戻すことはできません。

ホットクエリは有効化すると動作しなくなります。 UltraWarm

UltraWarm ドメインで有効にすると、search.max_buckets設定に既存のオーバーライドがない場合、 OpenSearch Service 10000 はメモリを大量に消費するクエリがウォームノードを飽和させないように、値を自動的にに設定します。ホットクエリが 10,000 個を超えるバケットを使用している場合は、有効にすると動作しなくなる可能性があります。 UltraWarm

Amazon OpenSearch Service はマネージド型の性質上、この設定を変更できないため、サポートケースを開いて制限を増やす必要があります。制限の増加には、プレミアムサポートサブスクリプションは必要ありません。

アップグレード後にダウングレードできない

インプレースアップグレードは元に戻すことができませんが、AWS サポートに連絡すれば、新しいドメインで自動的なアップグレード前のスナップショットを復元する支援が得られます。たとえば、ドメインをElasticsearch 5.6から6.4にアップグレードする場合、 AWS Support はアップグレード前のスナップショットを新しいElasticsearch 5.6ドメインに復元するお手伝いをします。元のドメインの手動スナップショットを作成した場合は、このステップを自分で実行することができます。

すべての AWS リージョンのドメインの概要が必要

次のスクリプトは、Amazon EC2 describe-regions AWS CLI コマンドを使用して、 OpenSearch サービスを利用できるすべてのリージョンのリストを作成します。次に、各リージョンを呼び出しますlist-domain-names。


for region in `aws ec2 describe-regions --output text | cut -f4`
do
    echo "\nListing domains in region '$region':"
    aws opensearch list-domain-names --region $region --query 'DomainNames'
done

リージョンごとに次の出力が表示されます。


Listing domains in region:'us-west-2'...
[
  {
    "DomainName": "sample-domain"
  }
]

OpenSearch サービスが利用できないリージョンは「エンドポイント URL に接続できませんでした」を返します。

OpenSearch ダッシュボード使用時のブラウザエラー

ダッシュボードを使用してサービスドメイン内のデータを表示すると、ブラウザはサービスエラーメッセージを HTTP レスポンスオブジェクトにまとめます。 OpenSearch 原因となるサービスエラーを表示し、デバッグを支援するため、Chrome の開発者モードなどのウェブブラウザで一般的に利用されている開発ツールを使用できます。

Chrome でサービスエラーを表示する

Chrome のトップメニューバーから、[表示]、[デベロッパー]、[デベロッパーツール] の順に選択します。
[ネットワーク] タブを選択します。
[状態] 列で、状態が 500 の任意の HTTP セッションを選択します。

Firefox でサービスエラーを表示する

メニューで、[ツール]、[ウェブデベロッパー]、[ネットワーク] の順に選択します。
状態が 500 の任意の HTTP セッションを選択します。
[レスポンス] タブを選択して、サービス応答を表示します。

ノードシャードとストレージスキュー

「shard skew」のノードは、クラスター内の 1 つ以上のノードに、他のノードに比べて非常に多くのシャードがある場合に発生します。「storage skew」のノードは、クラスター内の 1 つ以上のノードに、他のノードに比べて非常に多くのストレージ (disk.indices) がある場合に発生します。ドメインがノードを置き換え、シャードをそのノードに引き続き割り当てているときなど、これらの条件は両方とも一時的に発生する可能性がありますが、それらが持続する場合は対処する必要があります。

両方のタイプのスキューを識別するには、_cat/allocation API オペレーションを実行し、レスポンスの shards と disk.indices のエントリを比較します。


 shards    | disk.indices  | disk.used  | disk.avail   | disk.total   | disk.percent |  host     | ip       | node
    264    |      465.3mb  |   229.9mb  |      1.4tb   |      1.5tb   |            0 |  x.x.x.x  | x.x.x.x  | node1
    115    |        7.9mb  |    83.7mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node2
    264    |      465.3mb  |   235.3mb  |      1.4tb   |      1.5tb   |            0 |  x.x.x.x  | x.x.x.x  | node3
    116    |        7.9mb  |    82.8mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node4
    115    |        8.4mb  |      85mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node5

一部のストレージスキューは正常ですが、平均から 10% を超えるものは重要です。シャードの分散にスキューがあると、CPU、ネットワーク、およびディスク帯域幅の使用量にもスキューが生じる可能性があります。通常、データが多いほどインデックス作成と検索オペレーションが増大するため、最も重いノードはリソースに最も負荷のかかるノードである傾向があり、軽いノードは十分に活用されていないキャパシティーを表します。

修正: データノード数の倍数であるシャード数を使用して、各インデックスがデータノード全体で均等に分散されるようにします。

インデックスシャードとストレージスキュー

「shard skew」のインデックスは、1 つ以上のノードが、他のノードよりも多くのインデックスのシャードを保持する場合に発生します。「storage skew」のインデックスは、1 つ以上のノードが、不均衡に大量のインデックスの合計ストレージを保持する場合に発生します。

_cat/shards API 出力を操作する必要があるため、インデックススキューはノードスキューよりも識別が困難です。クラスターまたはノードメトリクスに何らかのスキューの兆候がある場合は、インデックスのスキューを調査します。インデックススキューの一般的な兆候は次のとおりです。

データノードのサブセットで発生する HTTP 429 エラー
データノード全体における不均等なインデックスまたは検索オペレーションのキューイング
データノード全体における不均等な JVM ヒープおよび/または CPU 使用率

修正: データノード数の倍数であるシャード数を使用して、各インデックスがデータノード全体で均等に分散されるようにします。それでもインデックスストレージやシャードスキューが発生する場合は、サービスドメインがブルー/グリーンデプロイされるたびにシャードの再割り当てを強制する必要があるかもしれません。 OpenSearch

VPC アクセス選択後の許可されていないオペレーション

OpenSearch サービスコンソールを使用して新しいドメインを作成する場合、VPC またはパブリックアクセスを選択できます。VPC アクセスを選択すると、 OpenSearch Service は VPC 情報をクエリし、適切な権限がない場合は失敗します。


You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation

このクエリを有効にするには、ec2:DescribeVpcs、ec2:DescribeSubnets、および ec2:DescribeSecurityGroups オペレーションへのアクセス権を持っている必要があります。この要件は、コンソールのみを対象としています。 AWS CLI を使用して VPC エンドポイントを使用してドメインを作成および設定する場合、それらの操作にアクセスする必要はありません。

VPC ドメイン作成後、読み込みでスタックする

VPC アクセスを使用した新規のドメインを作成後、ドメインの [設定の状態] が [読み込み中] から先に進行しない場合があります。この問題が発生した場合は、お住まいのリージョンで AWS Security Token Service (AWS STS) が無効になっている可能性があります。

VPC エンドポイントを VPC に追加するには、 OpenSearch Service がその役割を引き受ける必要があります。AWSServiceRoleForAmazonOpenSearchServiceしたがって、特定のリージョンで VPC アクセスを使用する新しいドメインを作成するには、 AWS STS を有効にする必要があります。有効化と無効化の詳細については AWS STS、『IAM ユーザーガイド』を参照してください。

API へのリクエストが拒否されました。 OpenSearch

OpenSearch API にタグベースのアクセス制御が導入されたことで、これまでになかったアクセス拒否エラーが表示されるようになるかもしれません。これは、1 つ以上のアクセスポリシーに ResourceTag 条件を使用する Deny が含まれており、それらの条件が現在尊重されていることが原因である可能性があります。

例えば、次のポリシーは、ドメインにタグ environment=production がある場合にのみ、設定 API からの CreateDomain アクションへのアクセスを拒否するために使用されます。アクションリストには ESHttpPut も含まれていますが、拒否ステートメントはそのアクションまたはその他の ESHttp* アクションには適用されませんでした。


{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:CreateDomain",
      "es:ESHttpPut"
    ],
    "Effect": "Deny",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

OpenSearch HTTP メソッドのタグサポートが追加されたことで、上記のような IAM ID ベースのポリシーでは、アタッチされたユーザーはアクションへのアクセスを拒否されるようになります。ESHttpPut以前は、タグの検証がない場合でも、添付されたユーザーは PUT リクエストを送信できました。

ドメインをサービスソフトウェア R20220323 以降に更新した後にアクセス拒否エラーが表示され始めた場合は、ID ベースのアクセスポリシーをチェックして、これが当てはまるかどうかを確認し、必要に応じてアクセスを許可するように更新してください。

Alpine Linux から接続できない

Alpine Linux では、DNS レスポンスのサイズが 512 バイトに制限されています。Alpine Linux バージョン 3.18.0 OpenSearch 以前からサービスドメインに接続しようとすると、ドメインが VPC 内にあり、ノードが 20 を超えると DNS 解決に失敗することがあります。Alpine Linux バージョン 3.18.0 以降を使用している場合は、20 を超えるホストを解決できます。詳細については、Alpine Linux 3.18.0 のリリースノートを参照してください。

ドメインが VPC 内にある場合は、他の Linux ディストリビューション (Debian、Ubuntu、CentOS、Red Hat Enterprise Linux、Amazon Linux 2 など) を使用して接続することをお勧めします。

Search Backpressure のリクエストが多すぎる

CPU ベースのアドミッションコントロールは、トラフィックの自然な増加と急増の両方について、現在のキャパシティに基づいてノードに対するリクエストの数をプロアクティブに制限するゲートキーピングメカニズムです。多すぎるリクエストは、拒否される際に HTTP 429「リクエストが多すぎます」ステータスコードを返します。このエラーは、クラスターリソースの不足、リソースを大量に消費する検索リクエスト、またはワークロードの意図しない急増のいずれかを示します。

Search Backpressure は拒否の理由を提供し、リソースを大量に使用する検索リクエストを微調整するのに役立ちます。トラフィックが急増した場合は、エクスポネンシャルバックオフとジッターを使用してクライアント側で再試行することをお勧めします。

SDK を使用する場合の証明書のエラー

AWS SDK はコンピュータの CA 証明書を使用するため、SDK AWS を使用しようとしたときにサーバー上の証明書を変更すると、接続に失敗する可能性があります。エラーメッセージはさまざまですが、通常は次のテキストが含まれています。


Failed to query OpenSearch
...
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

コンピューターの CA up-to-date 証明書とオペレーティングシステムをそのまま使用することで、このような障害を防ぐことができます。ユーザーが自分のコンピュータを管理していない企業環境でこの問題が発生した場合は、必要に応じて管理者から支援を得て更新プロセスを行う必要があります。

以下のリストは、オペレーティングシステムと Java の最小バージョンを示しています。

2005 年 1 月以降の更新プログラムがインストールされた Microsoft Windows バージョンでは、必要な CA が信頼リストに 1 つ以上含まれています。
Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5 (2007 年 2 月)、Mac OS X 10.5 (2007 年 10 月)、および以降のバージョンでは、必要な CA が信頼リストに 1 つ以上含まれています。
Red Hat Enterprise Linux 5 (2007 年 3 月)、6、7、および CentOS 5、6、および 7 では、必要な CA がデフォルトの CA 信頼リストに 1 つ以上含まれています。
Java 1.4.2_12 (2006 年 5 月)、5 Update 2 (2005 年 3 月)、および以降のすべてのバージョン (Java 6 (2006 年 12 月)、7、8 を含む) では、必要な CA がデフォルトの CA 信頼リストに 1 つ以上含まれています。

以下に示す 3 つの証明機関があります。

Amazon Root CA 1
Starfield Services Root Certificate Authority - G2
Starfield Class 2 Certification Authority

最初の 2 つの認証局からのルート証明書は Amazon Trust Services から入手できますが、 up-to-date コンピュータを保管しておく方が簡単な解決策です。ACM から提供される証明書の詳細については、「AWS Certificate Manager に関するよくある質問」を参照してください。

注記

現在、us-east-1 OpenSearch リージョンのサービスドメインは、別の機関の証明書を使用しています。近い将来、これらの新しい証明機関が使用されるように、リージョンを更新する予定です。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Amazon OpenSearch Service 名称変更

ドキュメント履歴