翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon OpenSearch Service のトラブルシューティング このトピックでは、一般的な Amazon OpenSearch Service の問題の特定と解決方法について説明します。[AWS サポート](https://aws.amazon.com/premiumsupport/)に問い合わせる前に、このセクションの情報を参照してください。 ## OpenSearch Dashboards にアクセスできない OpenSearch Dashboards エンドポイントは、署名付きリクエストをサポートしていません。ドメインのアクセスコントロールポリシーで、特定の IAM ロールにのみアクセス権が付与されており、[Amazon Cognito 認証](cognito-auth.md)を設定していない場合は、Dashboards にアクセスしようとするときに次のエラーが発生する場合があります。 ``` "User: anonymous is not authorized to perform: es:ESHttpGet" ``` OpenSearch Service ドメインで VPC アクセスを使用している場合、このエラーを受け取らない可能性がありますが、リクエストがタイムアウトする可能性があります。この問題の修正、および利用できるさまざまな設定オプションの詳細については、「[Dashboards へのアクセスの制御](dashboards.md#dashboards-access)」、「[VPC ドメインのアクセスポリシーについて](vpc.md#vpc-security)」、および「[Amazon OpenSearch Service での Identity and Access Management](ac.md)」を参照してください。 ## VPC ドメインにアクセスできない 「[VPC ドメインのアクセスポリシーについて](vpc.md#vpc-security)」および「[VPC ドメインをテストする](vpc.md#vpc-test)」を参照してください。 ## 読み取り専用状態のクラスター 以前の Elasticsearch のバージョンと比較すると、OpenSearch と Elasticsearch 7.*x* は、クラスターの調整に別のシステムを使用します。この新しいシステムでは、クラスターがクォーラムを失うと、アクションを実行するまでクラスターは使用できなくなります。クォーラム損失には 2 つの形式があります。 + クラスターが専用マスターノードを使用している場合は、半分以上が利用できないときにクォーラム損失が発生します。 + クラスターで専用マスターノードを使用していない場合は、データノードの半分以上が利用できないときにクォーラム損失が発生します。 クォーラム損失が発生し、クラスターに複数のノードがある場合、OpenSearch Service はクォーラムを復元し、クラスターを読み取り専用状態にします。これには 2 つのオプションがあります。 + 読み取り専用状態を削除し、クラスターをそのまま使用します。 + [スナップショットからクラスターまたは個々のインデックスを復元します](managedomains-snapshot-restore.md)。 クラスターをそのまま使用する場合は、次のリクエストを使用してクラスターの状態が緑色であることを確認します。 ``` GET _cat/health?v ``` クラスターの状態が赤の場合、スナップショットからクラスターを復元することをお勧めします。トラブルシューティングのステップについては、[赤のクラスター状態](#handling-errors-red-cluster-status) も合わせてお読みください。クラスターの状態が緑色の場合は、次のリクエストを使用して、予想されるすべてのインデックスが存在することを確認します。 ``` GET _cat/indices?v ``` 次に、いくつかの検索を実行して、予想されるデータが存在することを確認します。存在する場合は、次のリクエストを使用して読み取り専用状態を削除できます。 ``` PUT _cluster/settings { "persistent": { "cluster.blocks.read_only": false } } ``` クォーラム損失が発生し、クラスターにノードが 1 つしかない場合、OpenSearch Service はノードを置き換え、クラスターを読み取り専用状態に*しません*。それ以外の場合、オプションは同じです。つまり、クラスターをそのまま使用するか、スナップショットから復元します。 どちらの場合も、OpenSearch Service は、[Health Dashboard](https://phd.aws.amazon.com/phd/home#/) に 2 つのイベントを送信します。最初のステップでは、クォーラムの損失が通知されます。2 番目のステップは、OpenSearch Service でクォーラムが正常に復元された場合に発生します。の使用の詳細については Health Dashboard、[AWS Health 「 ユーザーガイド](https://docs.aws.amazon.com/health/latest/ug/)」を参照してください。 ## 赤のクラスター状態 赤のクラスター状態は、少なくとも 1 つのプライマリシャードとそのレプリカがノードに割り当てられていないことを意味します。OpenSearch Service は、インデックスの状態にかかわらず、すべてのインデックスの自動スナップショットを取得しようとしますが、赤色のクラスター状態が維持されている間、スナップショットは失敗します。 赤のクラスター状態の最も一般的な原因は、[クラスターノードの障害](#handling-errors-failed-cluster-nodes)と、継続的な高負荷による OpenSearch プロセスのクラッシュです。 **注記** OpenSearch Service は、クラスター状態にかかわらず 14 日間自動スナップショットを保存します。したがって、赤のクラスター状態が 2 週間を超えて続くと、最後に正常な自動スナップショットが削除され、クラスターのデータが完全に失われることになります。OpenSearch Service ドメインが赤色のクラスターステータスになった場合は、お客様自身で問題に対処するか、サポートチームにサポートを依頼するか サポート を問い合わせることができます。[CloudWatch アラームを設定](cloudwatch-alarms.md)して、赤のクラスター状態が発生したときに通知を受けることもできます。 最終的に、赤のシャードにより赤のクラスターが発生し、赤のインデックスにより赤のシャードが発生します。赤のクラスター状態の原因となっているインデックスを識別するため、OpenSearch にはいくつかの有用な API が用意されています。 + `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 ``` 赤のインデックスを削除することが、赤のクラスター状態を修正するための最速の方法です。赤のクラスター状態の理由によっては、OpenSearch Service ドメインをスケールし、より大きなインスタンスタイプ、より多くのインスタンス、またはより EBS ベースのストレージを使用して、問題のあるインデックスの再作成を試みることができます。 問題のあるインデックスを削除することが可能でない場合、[スナップショットを復元する](managedomains-snapshot-restore.md)、インデックスからドキュメントを削除する、インデックスの設定を変更する、レプリカの数を減らす、または他のインデックスを削除してディスク領域を解放することができます。重要なステップは、OpenSearch Service ドメインを再設定する*前に*、赤のクラスター状態を解決することです。赤のクラスター状態のドメインを再設定すると、問題が複雑化し、状態を解決するまで、設定状態が [**処理中**] のままドメインがスタックする可能性があります。 ### 赤いクラスターの自動修復 クラスターステータスが赤になって連続して 1 時間以上経過した場合、OpenSearch Service は、未割り当てのシャードを再ルーティングするか、過去のスナップショットから復元することによってクラスターを自動的に修正しようとします。 1 つ以上の赤いインデックスの修正に失敗し、クラスターステータスが合計で 14 日間赤のままのとき、OpenSearch Service は、クラスターで以下の条件のうち*少なくとも 1 つ*が満たされている場合にのみ追加のアクションを実行します。 + アベイラビリティーゾーンが 1 つだけである + 専用マスターノードがある + バースト可能なインスタンスタイプ (T2 または T3) が含まれる この時点で、これらの条件のうちの 1 つがクラスターで満たされている場合、OpenSearch Service は、次の 7 日間にわたって、これらのインデックスを修正しないとすべての未割り当てのシャードが削除されることを説明する[通知](managedomains-notifications.md)を毎日送信します。21 日が経過してもクラスターステータスが赤である場合、OpenSearch Service はすべての赤いインデックスの未割り当てシャード (ストレージとコンピューティング) を削除します。通知は、これらの各イベントの OpenSearch Service コンソールの **[Notifications]** (通知) パネルに表示されます。詳細については、「[クラスターヘルスイベント](monitoring-events.md#monitoring-events-cluster-health)」を参照してください。 ### 処理の継続的な高負荷からの復旧 赤のクラスター状態がデータノードの処理の継続的な高負荷によるものであるかどうかを判断するには、次のクラスターメトリクスをモニタリングします。 | 関連するメトリクス | 説明 | 復旧 | | --- | --- | --- | | JVMMemoryPressure | クラスター内のすべてのデータノードで使用する 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](#handling-errors-jvm_out_of_memory_error)」を参照してください。 問題が解決しない場合は、不要なインデックスを削除する、ドメインへのリクエストの数または複雑性を減少する、インスタンスを追加する、あるいはより大きなインスタンスタイプを使用します。 | | CPUUtilization | クラスター内のデータノードで使用する CPU リソースのパーセンテージを指定します。このメトリクスの [最大] の統計を表示し、使用量の多い継続的なパターンを探します。 | データノードを追加するか、既存のデータノードのインスタンスタイプのサイズを大きくします。 | | ノード | クラスターのノード数の指定。このメトリクスの [最小] の統計を表示します。サービスがクラスターの新しいインスタンス群をデプロイすると、この値が変動します。 | データノードを追加します。 | ## 黄色のクラスター状態 黄色のクラスター状態は、すべてのインデックスのプライマリシャードがクラスター内のノードに割り当てられ、少なくとも 1 つのインデックスのレプリカシャードは割り当てられていないことを意味します。単一ノードクラスターでは、OpenSearch Service がレプリカを割り当てることができる他のノードがないため、常に黄色のクラスター状態で初期化されることに注意してください。緑のクラスター状態を確保するには、ノード数を増やします。詳細については、「[Amazon OpenSearch Service ドメインのサイジング](sizing-domains.md)」を参照してください。 マルチノードクラスターは、新しいインデックスを作成した後、またはノード障害の後に、一時的に黄色のクラスター状態になることがあります。OpenSearch がクラスター全体でデータをレプリケートすると、この状態は自己解決されます。[ディスク容量の不足](#handling-errors-watermark)も黄色のクラスター状態を引き起こす可能性があります。クラスターは、ノードにレプリカシャードを収容するディスク領域がある場合のみ、レプリカシャードを配布できます。 ## ClusterBlockException 以下の理由により、`ClusterBlockException` エラーを受け取る場合があります。 ### 使用可能なストレージ領域の不足 クラスター内の 1 つまたは複数のノードのストレージ容量が、最小値である 1) 使用可能なストレージ容量 20%、または 2) ストレージ容量 20 GiB を下回った場合、ドキュメントの追加やインデックスの作成などの基本的な書き込みオペレーションが失敗する可能性があります。「[ストレージ要件の計算](bp-storage.md)」では、OpenSearch Service によるディスク容量の使用の概要について説明します。 問題を回避するには、OpenSearch Service コンソールの `FreeStorageSpace` メトリクスをモニタリングし、[CloudWatch アラームを作成](cloudwatch-alarms.md)して、`FreeStorageSpace` が特定のしきい値を下回ったときにトリガーします。`GET /_cat/allocation?v` は、シャードの割り当てとディスク使用量の有用な概要も提供します。ストレージ容量の不足に関連する問題を解決するには、OpenSearch Service ドメインをスケールし、より大きなインスタンスタイプ、より多くのインスタンス、またはより EBS ベースのストレージを使用します。 ### JVM メモリ負荷が高い **JVMMemoryPressure** メトリクスが 30 分の間 92% を超えると、クラスターが赤の状態に到達しないように、OpenSearch Service は保護メカニズムをトリガーし、すべての書き込み操作をブロックします。保護が有効な状態では、書き込みオペレーションは `ClusterBlockException` エラーで失敗し、新しいインデックスは作成できず `IndexCreateBlockException` エラーがスローされます。 [**JVMMemoryPressure**] メトリクスが 88% 以下に戻った状態が 5 分間続くと、保護が無効になり、クラスターへの書き込み操作はブロックされません。 高い JVM のメモリ負荷は、クラスターに対するリクエスト数の急増、ノード全体でのシャード割り当ての不均衡、クラスター内の過度に多いシャード、大量のフィールドデータまたはインデックスマッピング、または入ってくる負荷を処理できないインスタンスタイプによって引き起こされることがあります。また、集計やワイルドカードを使用したり、クエリで広い時間範囲を使用したりすることによって発生することもあります。 クラスターへのトラフィックを減らし、JVM のメモリ負荷が高い問題を解決するには、次の 1 つ以上を試してください。 + ノードあたりの最大ヒープサイズが 32 GB になるようにドメインをスケールする。 + 古いインデックスや未使用のインデックスを削除して、シャードの数を減らす。 + `POST index-name/_cache/clear?fielddata=true` API オペレーションでデータキャッシュをクリアする。キャッシュをクリアすると、進行中のクエリが中断される可能性があることに注意してください。 一般的に、将来 JVM メモリの負荷が高くなるのを避けるために、次のベストプラクティスに従ってください。 + テキストフィールドでの集計を避けるか、インデックスの[マッピングタイプ](https://opensearch.org/docs/latest/opensearch/mappings/#dynamic-mapping)を `keyword` に変更します。 + [適切な数のシャードを選択](bp-sharding.md)して、検索とインデックス作成のリクエストを最適化します。 + 定期的に[未使用のインデックスを削除](bp.md#bp-stability-remove)するように Index State Management (ISM) ポリシーを設定します。 ## Multi-AZ with Standby への移行中にエラーが発生した 既存のドメインを Multi-AZ with Standby に移行する際に、次の問題が発生する場合があります。 ### スタンバイのないドメインからスタンバイのあるドメインへの移行している最中に、インデックス、インデックステンプレート、ISM ポリシーのいずれかを作成する スタンバイのないマルチ AZ からスタンバイのあるマルチ AZ に移行する際にインデックスを作成し、そのインデックスのテンプレートまたは ISM ポリシーが、推奨されているデータコピーのガイドラインに従っていない場合、データの不一致が生じて移行に失敗する可能性があります。この状況を回避するには、3 の倍数のデータコピー数 (プライマリノードとレプリカの両方を含む) で新しいインデックスを作成します。`DescribeDomainChangeProgress` API を使って移行の進行状況を確認できます。レプリカ数のエラーが発生した場合は、エラーを修正してから[AWS サポート](https://aws.amazon.com/premiumsupport/) に連絡し、移行を再試行します。 ### データコピーの数が間違っている ドメインに適切な数のデータコピーがないと、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 Service はノードを再起動します。ただし、OpenSearch クラスターの 1 つ以上のノードが失敗した状態のままであることがあります。 この状態を確認するには、OpenSearch Service コンソールでドメインダッシュボードを開きます。[**クラスターのヘルス**] タブに移動し、[**ノード合計数**] メトリクスを見つけます。報告されるノード数がクラスターに設定した数より小さいかどうかを調べます。メトリクスが、1 つ以上のノードが 1 日以上ダウンしていることを示している場合は、[AWS サポート](https://aws.amazon.com/premiumsupport/)までお問い合わせください。 [CloudWatch アラームを設定](cloudwatch-alarms.md)して、この問題が発生したときに通知を受けることもできます。 **注記** [**合計ノード**] メトリクスは、クラスター設定の変更中およびサービスの定期的なメンテナンス中は、正確ではありません。この動作は想定されるものです。メトリクスは、すぐに正しい数のクラスターノードを報告します。詳細については[Amazon OpenSearch Service で設定変更を行う](managedomains-configuration-changes.md)を参照してください。 クラスターを予期しないノードの終了と再起動から保護するには、OpenSearch Service ドメインで各インデックスに少なくとも 1 つのレプリカを作成します。 ## シャードの最大制限を超えました OpenSearch および 7.*x* バージョンのElasticsearch のデフォルト設定は、ノードあたり 1,000 シャード以下です。OpenSearch/ElasticSearch は、新しいインデックスの作成などのリクエストが原因でこの制限を超えると、エラーをスローします。このエラーが発生した場合は、いくつかのオプションがあります。 + さらにデータノードをクラスターに追加します。 + `_cluster/settings/cluster.max_shards_per_node` 設定を増加します。 + [\$1shrink API](supported-operations.md#version_api_notes-shrink) を使用して、ノードのシャード数を減らします。 ## ドメインが処理状態でスタックしている OpenSearch Service ドメインは、[設定変更](managedomains-configuration-changes.md)中に、「処理中」状態になります。設定変更を開始すると、ドメインの状態は 「処理中」に変わり、その間、OpenSearch Service によって新しい環境が作成されます。新しい環境では、OpenSearch Service は、適用可能なノード (データ、マスター、UltraWarm など) の新しいセットを起動します。移行が完了すると、古いノードは終了します。 次のいずれかの状況が発生した場合、クラスターは「処理中」状態でスタックすることがあります。 + 新しいデータノードセットの起動は失敗します。 + 新しいデータノードセットへのシャード移行は失敗します。 + 検証チェックがエラーで失敗しました。 これらの各状況における詳細な解決ステップについては、「[Amazon OpenSearch Service ドメインが「処理中」状態のまま変わらないのはなぜですか。](https://aws.amazon.com/premiumsupport/knowledge-center/opensearch-domain-stuck-processing/)」を参照してください。 ## 低 EBS バーストバランス OpenSearch Service は、いずれかの汎用 (SSD) ボリュームの EBS バーストバランスが 70% を下回ったときにコンソール通知を送信し、バランスが 20% を下回った場合はフォローアップ通知を送信します。この問題を解決するには、クラスターをスケールアップするか、読み取り/書き込み IOPS を減らしてバーストバランスをクレジットすることができます。gp3 ボリュームタイプを使用するドメインと、ボリュームサイズが 1,000 GiB を超える gp2 ボリュームを使用するドメインのバーストバランスは 0 のままになります。詳細については、「[汎用 SSD ボリューム (gp2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html#EBSVolumeTypes_gp2)」を参照してください。`BurstBalance` CloudWatch メトリクスを使用して、EBS バーストバランスをモニタリングできます。 ## ボリュームサイズ変更中の EBS メトリクスの増加 Amazon Elastic Block Store ボリュームサイズを変更すると、`Write Throughput`、`Write Throughput Micro bursting`、`Disk Queue Depth`、`IOPS` などのさまざまな EBS メトリクスが一時的に増加することがあります。これは、サイズ変更操作中に予想される動作であり、通常は数秒かかります。ただし、この期間は、変更するボリュームサイズによって異なる場合があります。 レイテンシーの問題やリクエストの拒否を回避するには、クラスターが正常でネットワークトラフィックが少ない場合にのみ EBS ボリュームのサイズ変更を実行します。 ## 監査ログを有効にできない OpenSearch Service コンソールを使用して監査ログの公開を有効にしようとすると、次のエラーが発生する場合があります。 CloudWatch Logs グループで指定されているリソースアクセスポリシーは、Amazon OpenSearch Service がログストリームを作成するための十分な許可を付与していません。リソースアクセスポリシーを確認してください。 このエラーが発生した場合は、ポリシーの `resource` 要素に正しいロググループ ARN が含まれていることを確認してください。その場合は、次のステップを実行します。 1. 数分間待ちます。 1. ウェブブラウザでページを更新します。 1. [**既存のグループを選択**] を選択します。 1. [**既存のロググループ**] では、エラーメッセージを受け取る前に作成したロググループを選択します。 1. [アクセスポリシー]セクションで、[**既存のポリシーを選択**] を選択します。 1. [**既存のポリシー**] では、エラーメッセージを受け取る前に作成したポリシーを選択します。 1. [**有効**] を選択します。 プロセスを数回繰り返してもエラーが続く場合は、[AWS サポート](https://aws.amazon.com/premiumsupport/)に連絡してください。 ## インデックスが閉じない OpenSearch Service は、OpenSearch および Elasticsearch バージョン 7.4 以降では、[https://opensearch.org/docs/latest/api-reference/index-apis/close-index/](https://opensearch.org/docs/latest/api-reference/index-apis/close-index/) API のみをサポートします。古いバージョンを使用していて、スナップショットからインデックスを復元している場合は、既存のインデックスを削除することができます (それの再インデックスの前または後)。 ## クライアントライセンスのチェック Logstash と Beats のデフォルトのディストリビューションには、独自のライセンスチェックが含まれており、オープンソースバージョンの OpenSearch への接続に失敗します。OpenSearch Service では、これらのクライアントの Apache 2.0 (OSS) ディストリビューションを使用してください。 ## リクエストのスロットリング 永続的に `403 Request throttled due to too many requests` または `429 Too Many Requests` エラーを受け取る場合は、垂直スケーリングを検討してください。Amazon OpenSearch Service は、ペイロードによってメモリ使用量が Java ヒープの最大サイズを超える場合、リクエストをスロットリングします。 ## ノードに SSH 接続できない OpenSearch クラスターのノードへのアクセスに SSH 接続が使用できず、`opensearch.yml` を直接変更できません。代わりに、 コンソール AWS CLI、、または SDKsを使用してドメインを設定します。OpenSearch REST API を使用して、いくつかのクラスターレベル設定を指定することもできます。詳細については、「[Amazon OpenSearch Service API リファレンス](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)」と [Amazon OpenSearch Service でサポートされているオペレーション](supported-operations.md) を参照してください。 クラスターのパフォーマンスをより詳細に把握する必要がある場合は、[CloudWatch にエラーログとスローログを公開](createdomain-configure-slow-logs.md)できます。 ## 「オブジェクトのストレージクラスで有効ではない」スナップショットエラー OpenSearch Service のスナップショットは、Amazon Glacier ストレージクラスをサポートしていません。このエラーは、オブジェクトを Amazon Glacier ストレージクラスに移行するライフサイクルルールが S3 バケットに含まれている場合に、スナップショットのリストを取得しようとすると発生する場合があります。 バケットからスナップショットを復元する必要がある場合は、Amazon Glacier からオブジェクトを復元し、オブジェクトを新しいバケットにコピーして、スナップショットリポジトリとして[新しいバケットを登録](managedomains-snapshot-registerdirectory.md)します。 ## 無効なホストヘッダー OpenSearch Service では、クライアントがリクエストヘッダーで `Host` を指定する必要があります。有効な `Host` 値は、次のような、`https://` のないドメインエンドポイントです。 ``` Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com ``` リクエスト作成時に `Invalid Host Header` エラーを受け取った場合、クライアントまたはプロキシが `Host` ヘッダーに OpenSearch Service ドメインエンドポイント (IP アドレスなどではなく) を含めているかどうかを確認してください。 ## 無効な M3 インスタンスタイプ OpenSearch Service では、OpenSearch または Elasticsearch バージョン 6.7 以降を実行している既存のドメインへの M3 インスタンスの追加または変更がサポートされていません。Elasticsearch 6.5 以前では、M3 インスタンスを引き続き使用できます。 新しいインスタンスタイプの選択をお勧めします。OpenSearch または Elasticsearch 6.7 以降を実行するドメインには、次の制限が適用されます。 + 既存のドメインで M3 インスタンスを使用していない場合、今後これらに変更することはできません。 + 既存のドメインを M3 インスタンスタイプから別のインスタンスタイプに変更した場合、元に戻すことはできません。 ## ホットクエリが UltraWarm を有効にした後に動作を停止する ドメインで UltraWarm を有効にしたときに、`search.max_buckets` 設定への既存の上書きがない場合、OpenSearch Service は自動的に値を `10000` に設定して、メモリ負荷の高いクエリがウォームノードを飽和させないようにします。ホットクエリが 10,000 を超えるバケットを使用している場合、UltraWarm を有効にしたときにそれらが動作を停止する場合があります。 Amazon OpenSearch Service の管理された性質により、この設定を変更できないため、サポートケースを開いて制限を増やす必要があります。制限の増加には、プレミアムサポートサブスクリプションは必要ありません。 ## アップグレード後にダウングレードできない [インプレースアップグレード](version-migration.md)は元に戻すことができませんが、[AWS サポート](https://aws.amazon.com/premiumsupport/)に連絡すれば、新しいドメインで自動的なアップグレード前のスナップショットを復元する支援が得られます。たとえば、ドメインを Elasticsearch 5.6 から 6.4 にアップグレードする場合、 AWS Support はアップグレード前のスナップショットを新しい Elasticsearch 5.6 ドメインに復元するのに役立ちます。元のドメインの手動スナップショットを作成した場合は、[このステップを自分で実行](managedomains-snapshots.md)することができます。 ## すべての のドメインの概要が必要 AWS リージョン 次のスクリプトは、Amazon EC2 [describe-regions](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-regions.html) AWS CLI コマンドを使用して、OpenSearch Service を使用できるすべてのリージョンのリストを作成します。次に、リージョンごとに [list-domain-names](https://docs.aws.amazon.com/cli/latest/reference/es/list-domain-names.html) を呼び出します。 ``` 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 Service が利用できない場合は、「エンドポイント URL に接続できませんでした」というメッセージが返されます。 ## OpenSearch Dashboards を使用する場合のブラウザエラー Dashboards を使用して、OpenSearch Service ドメインのデータを表示する場合、ブラウザは HTTP レスポンスオブジェクトのサービスエラーメッセージをラップします。原因となるサービスエラーを表示し、デバッグを支援するため、Chrome の開発者モードなどのウェブブラウザで一般的に利用されている開発ツールを使用できます。 **Chrome でサービスエラーを表示する** 1. Chrome のトップメニューバーから、[**表示**]、[**デベロッパー**]、[**デベロッパーツール**] の順に選択します。 1. [**ネットワーク**] タブを選択します。 1. [**状態**] 列で、状態が 500 の任意の HTTP セッションを選択します。 **Firefox でサービスエラーを表示する** 1. メニューで、[**ツール**]、[**ウェブデベロッパー**]、[**ネットワーク**] の順に選択します。 1. 状態が 500 の任意の HTTP セッションを選択します。 1. [**レスポンス**] タブを選択して、サービス応答を表示します。 ## ノードシャードとストレージスキュー *shard skew* のノードは、クラスター内の 1 つ以上のノードに、他のノードに比べて非常に多くのシャードがある場合に発生します。*storage skew* のノードは、クラスター内の 1 つ以上のノードに、他のノードに比べて非常に多くのストレージ (`disk.indices`) がある場合に発生します。ドメインがノードを置き換え、シャードをそのノードに引き続き割り当てているときなど、これらの条件は両方とも一時的に発生する可能性がありますが、それらが持続する場合は対処する必要があります。 両方のタイプのスキューを識別するには、[\$1cat/allocation](https://opensearch.org/docs/latest/opensearch/rest-api/cat/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 つ以上のノードが、不均衡に大量のインデックスの合計ストレージを保持する場合に発生します。 [\$1cat/shards](https://opensearch.org/docs/latest/opensearch/rest-api/cat/cat-shards/) API 出力を操作する必要があるため、インデックススキューはノードスキューよりも識別が困難です。クラスターまたはノードメトリクスに何らかのスキューの兆候がある場合は、インデックスのスキューを調査します。インデックススキューの一般的な兆候は次のとおりです。 + データノードのサブセットで発生する HTTP 429 エラー + データノード全体における不均等なインデックスまたは検索オペレーションのキューイング + データノード全体における不均等な JVM ヒープおよび/または CPU 使用率 **修正**: データノード数の倍数であるシャード数を使用して、各インデックスがデータノード全体で均等に分散されるようにします。それでもインデックスストレージまたはシャードスキューが見られる場合は、シャードの再割り当てを強制する必要がある可能性があります。これは、OpenSearch Service ドメインのすべての[ブルー/グリーンデプロイ](managedomains-configuration-changes.md)で発生します。 ## VPC アクセス選択後の許可されていないオペレーション OpenSearch Service コンソールを使用して新しいドメインを作成する場合、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 ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)を参照してください。 ## OpenSearch API への拒否されたリクエスト OpenSearch API のタグベースのアクセス制御の導入により、以前は見られなかったアクセス拒否エラーが表示されるようになる可能性があります。これは、1 つ以上のアクセスポリシーに `ResourceTag` 条件を使用する `Deny` が含まれており、それらの条件が現在尊重されていることが原因である可能性があります。 例えば、次のポリシーは、ドメインにタグ `environment=production` がある場合にのみ、設定 API からの `CreateDomain` アクションへのアクセスを拒否するために使用されます。アクションリストには `ESHttpPut` も含まれていますが、拒否ステートメントはそのアクションまたはその他の `ESHttp*` アクションには適用されませんでした。 ------ #### [ JSON ] **** ``` { "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 Service ドメインに接続しようとした場合、ドメインが VPC 内にあり、ノードが 20 を超えていると、DNS 解決が失敗することがあります。Alpine Linux バージョン 3.18.0 以降を使用している場合は、20 を超えるホストを解決できます。詳細については、[Alpine Linux 3.18.0 のリリースノート](https://alpinelinux.org/posts/Alpine-3.18.0-released.html)を参照してください。 ドメインが VPC 内にある場合は、他の Linux ディストリビューション (Debian、Ubuntu、CentOS、Red Hat Enterprise Linux、Amazon Linux 2 など) を使用して接続することをお勧めします。 ## Search Backpressure のリクエストが多すぎる CPU ベースのアドミッションコントロールは、トラフィックの自然な増加と急増の両方について、現在のキャパシティに基づいてノードに対するリクエストの数をプロアクティブに制限するゲートキーピングメカニズムです。多すぎるリクエストは、拒否される際に HTTP 429「リクエストが多すぎます」ステータスコードを返します。このエラーは、クラスターリソースの不足、リソースを大量に消費する検索リクエスト、またはワークロードの意図しない急増のいずれかを示します。 Search Backpressure は拒否の理由を提供し、リソースを大量に使用する検索リクエストを微調整するのに役立ちます。トラフィックが急増した場合は、エクスポネンシャルバックオフとジッターを使用してクライアント側で再試行することをお勧めします。 ## SDK を使用する場合の証明書のエラー AWS SDKsコンピュータの CA 証明書を使用するため、 AWS サーバー上の証明書を変更すると、SDK の使用時に接続が失敗する可能性があります。エラーメッセージはさまざまですが、通常は次のテキストが含まれています。 ``` Failed to query OpenSearch ... SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ``` このようなエラーは、コンピュータ上の CA 証明書とオペレーティングシステムを最新の状態にしておくことで回避できます。ユーザーが自分のコンピュータを管理していない企業環境でこの問題が発生した場合は、必要に応じて管理者から支援を得て更新プロセスを行う必要があります。 以下のリストは、オペレーティングシステムと 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\$112 (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](https://www.amazontrust.com/repository/) から入手できますが、もっと簡単なソリューションは、コンピュータを最新の状態にしておくことです。ACM から提供される証明書の詳細については、「[AWS Certificate Manager に関するよくある質問](https://aws.amazon.com/certificate-manager/faqs/#certificates)」を参照してください。 **注記** 現時点では、us-east-1 リージョン内の OpenSearch Service ドメインには別の機関からの証明書が使用されます。近い将来、これらの新しい証明機関が使用されるように、リージョンを更新する予定です。 ## バージョンの互換性の問題によりカスタムプラグインのインストールが失敗する **問題**: プラグインと実行中の OpenSearch インスタンスのバージョンが一致しないため、プラグインのインストールに失敗しました。このシステムは、次のエラーを返します。 ``` PluginValidationFailureReason : The provided plugin could not be loaded. ``` **原因**: このプラグインは OpenSearch \$1*\$1MAJOR\$1*.\$1*\$1MINOR\$1.\$1PATCH\$1* 用にコンパイルされていますが、現在の環境では OpenSearch \$1*\$1MAJOR\$1*.\$1*\$1MINOR\$1*.0 が実行されています。OpenSearch には、安定性とセキュリティ上の理由から、プラグインとコア OpenSearch インストール間の正確なバージョンマッチングが必要です。 **解決方法**: OpenSearch バージョン \$1*\$1MAJOR\$1*.\$1*\$1MINOR\$1* でプラグインをビルドして、クラスターのバージョンを一致させます。 **OpenSearch のバージョンを検証して更新するには** 1. クラスターの API またはダッシュボードを使用して、次のコマンドを実行します。*デフォルトのプレースホルダー値*を、ユーザー自身の情報に置き換えます。 **API リクエスト:** ``` curl -X GET your-opensearch-endpoint/ ``` **ダッシュボードの開発ツールコンソール:** ``` GET / ``` コマンドは次の形式で情報を返します。 ``` { "name": "node-id", "cluster_name": "account-id:domain-name", "cluster_uuid": "cluster-uuid", "version": { "distribution": "opensearch", "number": "2.17.0", "build_type": "tar", "build_hash": "unknown", "build_date": "2024-12-17T11:00:09.799828091Z", "build_snapshot": false, "lucene_version": "9.11.1", "minimum_wire_compatibility_version": "7.10.0", "minimum_index_compatibility_version": "7.0.0" }, "tagline": "The OpenSearch Project: https://opensearch.org/" } ``` 1. バージョン番号が \$1*\$1MAJOR\$1*.\$1*\$1MINOR\$1*.0 でない場合、以下を実行してプラグインを再構築します。 1. プラグインの `descriptor.properties` を更新してバージョン \$1*\$1MAJOR\$1*.\$1*\$1MINOR\$1*.0 を指定します。 1. プロジェクトタイプに応じたコマンドを使用してプラグインを再構築します。 1. 新しく構築された `.zip` ファイルを使用して [update-package](https://docs.aws.amazon.com/cli/latest/reference/opensearch/update-package.html) コマンドを実行します。 1. [associate-package](https://docs.aws.amazon.com/cli/latest/reference/opensearch/associate-package.html) コマンドを実行して、前のステップで `update-package` コマンドを実行したときに作成された最新のプラグインバージョンを関連付けます。