翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon CloudSearch のトラブルシューティング
次のトピックでは、Amazon CloudSearch の使用中に発生する可能性がある問題の解決策について説明します。
**Topics**
+ [ドキュメントのアップロード](#ts.uploaddocs)
+ [Amazon CloudSearch ドメイン内のすべてのドキュメントの削除](#ts.cleardomain)
+ [ドキュメントの削除後も Amazon CloudSearchドメインが縮小しない](#ts.notscalingdown)
+ [ドキュメント更新のレイテンシー](#ts.slowupdates)
+ [ドキュメントを Amazon CloudSearch ドメインにアップロードする際に大量の 5xx エラーが発生する](#troubleshooting-upload-timeouts)
+ [Amazon CloudSearch での検索のレイテンシーとタイムアウト](#ts.searchfailures)
+ [Amazon CloudSearch のファセットクエリの検索のレイテンシー](#ts.slow-facet-searches)
+ [Amazon CloudSearch ドメインの検索時に 5xx エラーが急増する](#troubleshooting-increased-errors)
+ [Amazon CloudSearch でインデックス作成オプションを更新した後のインデックス作成エラー](#ts.indexingfailures)
+ [Amazon CloudSearch リクエストの送信時にドメインが見つからない](#troubleshooting-domain-not-found)
+ [ドメイン情報により、検索可能なドキュメントの数が返されない](#troubleshooting-searchable-documents)
+ [構成サービスアクセスポリシーが Amazon CloudSearch で機能しない](#troubleshooting-configuration-access-policies)
+ [検索およびドキュメントサービスアクセスポリシーが Amazon CloudSearch で機能しない](#troubleshooting-search-doc-access-policies)
+ [Amazon CloudSearch コンソールのアクセス許可エラー](#troubleshooting-console-access)
+ [ワイルドカードを使用してテキストフィールドを検索すると、予期した結果が生成されない](#ts.wildcardsearchresults)
+ [ディープページ分割でカーソルを使用した場合の結果の不整合](#ts.deeppaging)
+ [SDK を使用する場合の証明書のエラー](#troubleshooting-certificates)
## ドキュメントのアップロード
ドキュメントデータの形式が正しくない場合や無効な値が含まれている場合、アップロードを試みる、またはそのデータを使用してドメインのフィールドの設定を試みると、エラーが発生します。よくある問題と解決策を以下に示します。
+ **無効な JSON** — JSON を使用している場合、まずドキュメントバッチに JSON 構文エラーがないことを確認します。これは、[JSON Validator](http://jsonlint.com) などの検証ツールを使用して実行します。その結果、データに存在する根本的な問題が特定されます。
+ **無効な XML** —ドキュメントバッチは、正しい形式の XML にする必要があります。フィールドに XML データが含まれている場合、特に問題が発生する可能性が高くなります。データは、XML でエンコードされているか、CDATA セクションに囲まれている必要があります。問題を特定するには、[W3C Markup Validation Service](http://validator.w3.org/) などの検証ツールを使用してドキュメントバッチを実行します。
+ **ドキュメントバッチとして認識されない** — コンソールを使用してデータをアップロードするときに、Amazon CloudSearch が有効なドキュメントバッチとしてデータを認識しない場合、Amazon CloudSearch は、単一のコンテンツフィールドと `content_encoding`、`content_type`、 などの汎用メタデータフィールドが含まれる有効なバッチを生成します`resourcename`。これらの通常ドメイン用に設定されたフィールドではないため、フィールドが存在しないことを示すエラーが発生します。同様に、無効なバッチからドメインを設定しようとした場合、Amazon CloudSearch はバッチ内のフィールドではなくコンテンツフィールドとメタデータフィールドで応答します。
まず、バッチが有効な XML または JSON であることを確認します。有効な場合、無効なドキュメント ID がないか確認し、各ドキュメントにオペレーションタイプを指定したことを確認します。追加オペレーションの場合、各ドキュメントにタイプ、ID、および少なくとも 1 つのフィールドが指定されていることを確認します。削除オペレーションでは、タイプおよび ID のみ指定する必要があります。データの形式の詳細については、「[ドキュメントバッチの作成](preparing-data.md#creating-document-batches)」を参照してください。
+ **ドキュメント ID の値が不適切** —ドキュメント ID には、文字または数字と次の文字を含めることができます。 \$1 - = \$1 ; : / ? @ & @ & ドキュメント ID は、1～128 文字以内にする必要があります。
+ **複数値フィールドに値がない** — JSON でドキュメントデータを指定するときは、空の配列をフィールドの値として指定することはできません。複数値フィールドには、1 個以上の値を含める必要があります。
+ **不適切な文字** — ドキュメントバッチの生成中にデータをフィルタしない場合に検出が困難となる 1 つの問題は、XML で無効な文字が含まれていることです。JSON バッチと XML バッチにはどちらも、XML で有効となる UTF-8 文字を含めることができます。[JSON Validator](http://jsonlint.com) や [W3C Markup Validation Service](http://validator.w3.org/) などの検証ツールを使用すると、無効な文字を特定できます。
## Amazon CloudSearch ドメイン内のすべてのドキュメントの削除
Amazon CloudSearch には現在、ドメイン内のすべてのドキュメントを削除するメカニズムが用意されていません。
## ドキュメントの削除後も Amazon CloudSearchドメインが縮小しない
インデックスサイズに合わせてドメインがスケールアップされ、多数のドキュメントを削除すると、次に完全なインデックスを再構築したときにドメインが縮小されます。インデックスは定期的に自動再構築されますが、できるだけ迅速にスケールダウンするには、キュメントの削除が完了したら、明示的に[インデックス作成を実行](indexing.md)してください。
## ドキュメント更新のレイテンシー
大量の単一ドキュメントバッチを送信すると、各ドキュメントが検索可能になるまでの時間が長くなる可能性があります。大量の更新トラフィックがある場合、更新をバッチ処理する必要があります。5 MB の制限に近いバッチサイズを使用することをお勧めします。詳細については、「[ドキュメントバッチの作成](preparing-data.md#creating-document-batches)」を参照してください。
1 日あたり (24 時間ごと) 最大 10,000 のドキュメントバッチをロードでき、各バッチサイズの合計は最大 5 MB です。1 日あたりのデータよりさらに多くのボリュームをロードすると、ドキュメント更新のレイテンシーが増えます。このリスクを軽減するには、より大きい必要なインスタンスタイプを選択することで更新容量を増やすことができます。詳細については、「[Amazon CloudSearch でのスケーリングオプションの設定](configuring-scaling-options.md)」を参照してください。
## ドキュメントを Amazon CloudSearch ドメインにアップロードする際に大量の 5xx エラーが発生する
アップロードを並列処理する場合で、ドメインが search.m1.small インスタンスにある場合、許容できないほど高い割合で 504 または 507 エラーが発生することがあります。必要なインスタンスタイプをより大きいインスタンスタイプに設定すると、更新容量が増大し、エラー率が下がります。5xx エラー処理の詳細については、「[エラー処理](error-handling.md)」を参照してください。アップロード容量を増大するようにドメインのサイズを事前設定する方法については、「[Amazon CloudSearch でのスケーリングオプションの設定](configuring-scaling-options.md)」を参照してください。
## Amazon CloudSearch での検索のレイテンシーとタイムアウト
応答時間が遅い、内部サーバーエラー (通常は 507 または 509 エラー) が頻繁に発生する、または検索対象のデータのボリュームが大幅に増加することなく、検索ドメインで消費されるインスタンス時間数が増える場合は、検索リクエストを微調整して処理オーバーヘッドを減らすと役立つことがあります。詳細については、「[Amazon CloudSearch での検索リクエストのパフォーマンスのチューニング](tuning-search.md)」を参照してください。必要なレプリケーション数を増やしても、検索リクエストの処理が速くなることがあります。詳細については、「[Amazon CloudSearch でのスケーリングオプションの設定](configuring-scaling-options.md)」を参照してください。
507 および 509 エラーは通常、検索サービスが過負荷であることを示しています。これは、送信しようとする検索リクエストのボリュームまたは複雑さに起因する可能性があります。Amazon CloudSearch は通常、負荷を処理するために自動的にスケーリングされます。追加の検索インスタンスのデプロイには時間がかかるため、エクスポネンシャルバックオフ再試行ポリシーを使用して、リクエストレートを一時的に下げてリクエストの失敗を最小限に抑えることをお勧めします。詳細については、「[エラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)」を参照してください。
単一の小さな検索インスタンスに複雑な検索クエリを送信するなど、特定の使用パターンでは、自動スケーリングがトリガーされずにタイムアウトが発生することがあります。高いエラー率が繰り返し発生する場合、Amazon CloudSearch の [[Service Limit Request]](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-cloudsearch-partitions-and-instances) (サービスの制限リクエスト) フォームを介して明示的に追加容量をリクエストできます。
## Amazon CloudSearch のファセットクエリの検索のレイテンシー
`buckets` オプションを選択してファセット情報をバケットしているときにクエリのパフォーマンスが遅くなる場合は、バケット方法を `interval` に設定してください。詳細については、「[ファセット情報のバケット](faceting.md#bucketing-facets)」を参照してください。
## Amazon CloudSearch ドメインの検索時に 5xx エラーが急増する
検索ドメインでトラフィックが急増した場合、Amazon CloudSearch はドメインに検索インスタンスを追加して増加した負荷を処理することにより対応します。ただし、新しいインスタンスをセットアップするまで数分かかります。新しいインスタンスがリクエストを処理できるようになるまで、5xx エラーが一時的に増加することがよくあります。5xx エラー処理の詳細については、「[エラー処理](error-handling.md)」を参照してください。予期される検索リクエストの急増を処理するために、ドメインを事前スケーリングする方法については、「[Amazon CloudSearch でのスケーリングオプションの設定](configuring-scaling-options.md)」を参照してください。
## Amazon CloudSearch でインデックス作成オプションを更新した後のインデックス作成エラー
ドメインのインデックス設定を変更した場合、場合によっては、インデックス作成を実行すると検証失敗エラーが発生することがあります。これは、設定したインデックスフィールドオプションが、インデックス内にすでに存在するドキュメントと互換性がないことを意味します。具体的には、インデックスフィールドのタイプを変更しましたが、そのタイプと互換性がないデータを含んでいるドキュメントがインデックスにあります。例えば、`literal` フィールドを `int` フィールドに変更し、一部のドキュメントのそのフィールドに英数字が含まれている場合にこの状況が発生する可能性があります。この場合、Amazon CloudSearch は処理された ALL フィールドのステータスを `FailedToValidate` 状態に設定します。互換性のない設定の変更をロールバックすると、インデックスを再構築できるようになります。変更が必要な場合、互換性のないドキュメントを更新するか、インデックスから削除し、新しい設定を使用する必要があります。エラーの原因となった変更を特定できない場合や、互換性のないドキュメントの特定するのに支援が必要な場合は、サポートにお問い合わせください。
## Amazon CloudSearch リクエストの送信時にドメインが見つからない
2013-01-01 コマンドラインツールまたは SDK を使用して 2011-02-01 ドメインにアクセスすることはできません。同様に、2013-01-01 コマンドラインツールまたは SDK を使用して 2011-02-01 ドメインにアクセスすることもできません。リクエストで正しい API バージョンを指定しており、適切なコマンドラインツールまたは SDK を使用していることを確認してください。
## ドメイン情報により、検索可能なドキュメントの数が返されない
`aws cloudsearch describe-domains` と `DescribeDomains` は、ドメイン内の検索可能なドキュメントの数を返しません。検索可能ドキュメントの数を取得するには、コンソールを使用するか、`matchall` リクエストをドメインの検索エンドポイントに送信します。
```
q=matchall&q.parser=structured&size=0
```
## 構成サービスアクセスポリシーが Amazon CloudSearch で機能しない
2011 ドメインと 2013 ドメインの両方があり、設定サービスにアクセスするための IAM ポリシーを設定済みの状態で、*権限がない*ことを示すエラーが発生する場合、2011-02-01 API と 2013-01-01 API では、Amazon CloudSearch ARN が異なる点に注意してください。ユーザーが 2011 ドメインと 2013 ドメインの両方にアクセスできるようにするには、IAM ポリシーで両方の ARN へのアクセスを許可する必要があります。例:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudsearch:*",
],
"Resource": "arn:aws:cloudsearch:*",
"Resource": "arn:aws:cs:*"
}
]
}
```
2011 ポリシーにより特定のドメインまたはアクションへのアクセス権が付与されている場合、それらの制限をポリシーに含める必要があります。2011 ドメインでサポートされるアクションは `cloudsearch:*` だけであるため、2011-01-01 API で作成されたドメインにリソースレベルのアクセス許可を設定しようとすると他のエラーが発生する可能性がある点に注意してください。
## 検索およびドキュメントサービスアクセスポリシーが Amazon CloudSearch で機能しない
ドメインの検索およびドキュメントサービスエンドポイントのアクセスポリシーを設定していながら「*403 Request forbidden by administrative rules*」エラーが発生する場合、次のいずれかの問題が原因と考えられます。
+ リクエストで API バージョンとリソース名が指定されていることを確認します。例えば、2013-01-01 API を使用してドキュメントをアップロードするには、ドメインのドキュメントサービスエンドポイントに `/2013-01-01/documents/batch` を付加する必要があります。
```
doc-movies-123456789012.us-east-1.cloudsearch.amazonaws.com/2013-01-01/documents/batch
```
2013-01-01 API を使用して検索リクエストを送信するには、ドメインの検索エンドポイントに `/2013-01-01/search` を付加する必要があります。
```
search-movies-123456789012.us-east-1.cloudsearch.amazonaws.com/2013-01-01/search?q=star+wars&return=title
```
2013-01-01 API を使用して候補を取得するには、ドメインの検索エンドポイントに `/2013-01-01/suggest` を付加する必要があります。
```
search-movies-123456789012.us-east-1.cloudsearch.amazonaws.com/2013-01-01/suggest?q=kat&suggester=mysuggester
```
+ EC2 インスタンスから接続する場合、アクセスポリシーにより EC2 インスタンスのパブリック IP アドレスが指定されることを確認します。
+ 接続元のマシンがルーターの背後にある場合、アクセスポリシーによりパブリック向けの IP アドレスが指定されることを確認します。
詳細については、「[Amazon CloudSearch のアクセスの設定](configuring-access.md)」を参照してください。
## Amazon CloudSearch コンソールのアクセス許可エラー
コンソールにアクセスするには、`DescribeDomains` アクションへのアクセス許可が必要です。特定のドメインとアクションへのアクセスは、設定済みの IAM アクセスポリシーにより制限される可能性があります。さらに、Amazon S3 バケットまたは DynamoDB テーブルからデータをアップロードするには、それらのサービスとリソースにアクセスする必要があります。Amazon CloudSearch アクセスポリシーの詳細については、「[Amazon CloudSearch のアクセスの設定](configuring-access.md)」を参照してください。
## ワイルドカードを使用してテキストフィールドを検索すると、予期した結果が生成されない
検索リクエストを送信すると、インデックスに存在する用語に対して一致できるように、検索対象のテキストには同じテキスト処理が行われます。ただし、プレフィックス検索を実行する場合、検索用語でテキスト分析は実行されません。これは、ステミングが有効な場合、末尾が `s` のプレフィックスを検索すると、用語の単数形には通常一致しないことを意味します。これは、複数形だけでなく末尾が `s` のあらゆる用語に適用される可能性があります。例えば、サンプル映画データの `actor` フィールドで `Anders` を検索した場合、一致する映画が 3 つあるとします。`Ander*` を検索した場合、それらの映画に加えて他のいくつかの映画が一致します。一方、`Anders*` を検索した場合、一致はありません。これは、用語が `ander` としてインデックスに格納されており、`anders` はインデックスにないためです。
ステミングのために、ワイルドカード検索を行っても関連する一致がすべて返されない場合、`AlgorithmicStemming` オプションを none に設定することでテキストフィールドのステミングを抑制できます。または、データを `literal` フィールドではなく `text` フィールドにマッピングできます。
Amazon CloudSearch によるテキストの処理方法の詳細については、「[Amazon CloudSearch でのテキスト処理](text-processing.md)」を参照してください。
## ディープページ分割でカーソルを使用した場合の結果の不整合
ドキュメントスコア (`_score`) によってソートされた結果セットを、カーソルを使用してページ分割すると、リクエストの合間にインデックスが更新された場合に結果が不整合になることがあります。ドメインのレプリケーション数が 1 より大きい場合にも同様の現象が発生することがあります。これは、更新が結果整合性方式でドメイン内のインスタンス間に適用されるためです。問題になる場合は、スコアによるソートを避けてください。`sort` オプションを使用して特定のフィールドでソートするか、または `q` の代わりに `fq` を使用して検索条件を指定できます。(ドキュメントスコアはフィルタークエリでは計算されません)
## SDK を使用する場合の証明書のエラー
AWS SDK ではご使用のコンピュータ上の CA 証明書が使用されるため、AWS サーバー上の証明書が変更されると、SDK を使用しようとした際に接続エラーが発生することがあります。エラーメッセージはさまざまですが、通常は次のテキストが含まれています。
```
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)」を参照してください。
**注記**
これらの証明書は必須ではありませんが、2017 年 11 月に AWS サーバーへのデプロイが予定されています。