Amazon のトラブルシューティング CloudSearch

以下のトピックでは、Amazon の使用時に発生する可能性のある問題の解決策について説明します CloudSearch。

ドキュメントのアップロード

ドキュメントデータの形式が正しくない場合や無効な値が含まれている場合、アップロードを試みる、またはそのデータを使用してドメインのフィールドの設定を試みると、エラーが発生します。よくある問題と解決策を以下に示します。

• 無効な JSON — JSON を使用している場合、まずドキュメントバッチに JSON 構文エラーがないことを確認します。これは、JSON Validator などの検証ツールを使用して実行します。その結果、データに存在する根本的な問題が特定されます。

• 無効な XML —ドキュメントバッチは、正しい形式の XML にする必要があります。フィールドに XML データが含まれている場合、特に問題が発生する可能性が高くなります。データは、XML でエンコードされているか、CDATA セクションに囲まれている必要があります。問題を特定するには、W3C Markup Validation Service などの検証ツールを使用してドキュメントバッチを実行します。

• ドキュメントバッチとして認識されない — コンソールを使用してデータをアップロードするときに、Amazon CloudSearch がデータを有効なドキュメントバッチとして認識しない場合、Amazon は 1 つのコンテンツフィールドと、content_encoding、、 などの汎用メタデータフィールドを含む有効なバッチ CloudSearch を生成しますcontent_typeresourcename。これらの通常ドメイン用に設定されたフィールドではないため、フィールドが存在しないことを示すエラーが発生します。同様に、無効なバッチからドメインを設定しようとすると、Amazon はバッチ内のフィールドではなくコンテンツフィールドとメタデータフィールドで CloudSearch 応答します。

  まず、バッチが有効な XML または JSON であることを確認します。有効な場合、無効なドキュメント ID がないか確認し、各ドキュメントにオペレーションタイプを指定したことを確認します。追加オペレーションの場合、各ドキュメントにタイプ、ID、および少なくとも 1 つのフィールドが指定されていることを確認します。削除オペレーションでは、タイプおよび ID のみ指定する必要があります。データの形式の詳細については、「Creating Document Batches」を参照してください。

• ドキュメント ID の値が不適切 —ドキュメント ID には、文字または数字と次の文字を含めることができます。 _ - = # ; : / ? @ & @ & ドキュメント ID は、1​～​128 文字以内にする必要があります。

• 複数値フィールドに値がない — JSON でドキュメントデータを指定するときは、空の配列をフィールドの値として指定することはできません。複数値フィールドには、1 個以上の値を含める必要があります。

• 不適切な文字 — ドキュメントバッチの生成中にデータをフィルタしない場合に検出が困難となる 1 つの問題は、XML で無効な文字が含まれていることです。JSON バッチと XML バッチにはどちらも、XML で有効となる UTF-8 文字を含めることができます。JSON Validator や W3C Markup Validation Service などの検証ツールを使用すると、無効な文字を特定できます。

Amazon CloudSearch ドメイン内のすべてのドキュメントの削除

Amazon CloudSearch は現在、ドメイン内のすべてのドキュメントを削除するためのメカニズムを提供していません。

ドキュメントの削除後に Amazon CloudSearch ドメインがスケールダウンしない

インデックスサイズに合わせてドメインがスケールアップされ、多数のドキュメントを削除すると、次に完全なインデックスを再構築したときにドメインが縮小されます。インデックスは定期的に自動再構築されますが、できるだけ迅速にスケールダウンするには、キュメントの削除が完了したら、明示的にインデックス作成を実行してください。

ドキュメント更新のレイテンシー

大量の単一ドキュメントバッチを送信すると、各ドキュメントが検索可能になるまでの時間が長くなる可能性があります。大量の更新トラフィックがある場合、更新をバッチ処理する必要があります。5 MB の制限に近いバッチサイズを使用することをお勧めします。詳細については、「Creating Document Batches」を参照してください。

1 日あたり (24 時間ごと) 最大 10,000 のドキュメントバッチをロードでき、各バッチサイズの合計は最大 5 MB です。1 日あたりのデータよりさらに多くのボリュームをロードすると、ドキュメント更新のレイテンシーが増えます。このリスクを軽減するには、より大きい必要なインスタンスタイプを選択することで更新容量を増やすことができます。詳細については、「Amazon でのスケーリングオプションの設定 CloudSearch」を参照してください。

ドキュメントを Amazon CloudSearch ドメインにアップロードするときに大量の 5xx エラーが発生する

アップロードを並列処理する場合で、ドメインが search.m1.small インスタンスにある場合、許容できないほど高い割合で 504 または 507 エラーが発生することがあります。必要なインスタンスタイプをより大きいインスタンスタイプに設定すると、更新容量が増大し、エラー率が下がります。5xx エラー処理の詳細については、「エラー処理」を参照してください。アップロード容量を増大するようにドメインのサイズを事前設定する方法については、「Amazon でのスケーリングオプションの設定 CloudSearch」を参照してください。

Amazon での検索のレイテンシーとタイムアウト CloudSearch

応答時間が遅い、内部サーバーエラー (通常は 507 または 509 エラー) が頻繁に発生する、または検索対象のデータのボリュームが大幅に増加することなく、検索ドメインで消費されるインスタンス時間数が増える場合は、検索リクエストを微調整して処理オーバーヘッドを減らすと役立つことがあります。詳細については、「Amazon での検索リクエストのパフォーマンスの調整 CloudSearch」を参照してください。必要なレプリケーション数を増やしても、検索リクエストの処理が速くなることがあります。詳細については、「Amazon でのスケーリングオプションの設定 CloudSearch」を参照してください。

507 および 509 エラーは通常、検索サービスが過負荷であることを示しています。これは、送信しようとする検索リクエストのボリュームまたは複雑さに起因する可能性があります。Amazon CloudSearch は通常、負荷を処理するために自動的にスケーリングされます。追加の検索インスタンスのデプロイには時間がかかるため、エクスポネンシャルバックオフ再試行ポリシーを使用して、リクエストレートを一時的に下げてリクエストの失敗を最小限に抑えることをお勧めします。詳細については、「エラーの再試行とエクスポネンシャルバックオフ」を参照してください。

単一の小さな検索インスタンスに複雑な検索クエリを送信するなど、特定の使用パターンでは、自動スケーリングがトリガーされずにタイムアウトが発生することがあります。エラー率が繰り返し発生する場合は、Amazon CloudSearch サービス制限リクエストフォームから追加の容量を明示的にリクエストできます。

Amazon でのファセットクエリの検索レイテンシー CloudSearch

buckets オプションを選択してファセット情報をバケットしているときにクエリのパフォーマンスが遅くなる場合は、バケット方法を interval に設定してください。詳細については、「ファセット情報のバケット」を参照してください。

Amazon CloudSearch ドメイン検索時の 5xx エラーの急激な増加

検索ドメインのトラフィックが突然急増した場合、Amazon は、増加した負荷を処理するためにドメインに検索インスタンスを追加して CloudSearch 応答します。ただし、新しいインスタンスをセットアップするまで数分かかります。新しいインスタンスがリクエストを処理できるようになるまで、5xx エラーが一時的に増加することがよくあります。5xx エラー処理の詳細については、「エラー処理」を参照してください。予期される検索リクエストの急増を処理するために、ドメインを事前スケーリングする方法については、「Amazon でのスケーリングオプションの設定 CloudSearch」を参照してください。

Amazon でインデックス作成オプションを更新した後のインデックス作成の失敗 CloudSearch

ドメインのインデックス設定を変更した場合、場合によっては、インデックス作成を実行すると検証失敗エラーが発生することがあります。これは、設定したインデックスフィールドオプションが、インデックス内にすでに存在するドキュメントと互換性がないことを意味します。具体的には、インデックスフィールドのタイプを変更しましたが、そのタイプと互換性がないデータを含んでいるドキュメントがインデックスにあります。例えば、literal フィールドを int フィールドに変更し、一部のドキュメントのそのフィールドに英数字が含まれている場合にこの状況が発生する可能性があります。この場合、Amazon は処理中のすべてのフィールドのステータスを FailedToValidate状態に CloudSearch 設定します。互換性のない設定の変更をロールバックすると、インデックスを再構築できるようになります。変更が必要な場合、互換性のないドキュメントを更新するか、インデックスから削除し、新しい設定を使用する必要があります。エラーの原因となった変更を特定できない場合や、互換性のないドキュメントの特定するのに支援が必要な場合は、サポートにお問い合わせください。

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 ポリシーを設定していて、認可されていないエラーが表示される場合は、 API と 2011-02-01 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 アドレスが指定されることを確認します。

詳細については、「configure access policies」を参照してください。

Amazon CloudSearch コンソールのアクセス許可エラー

コンソールにアクセスするには、DescribeDomains アクションへのアクセス許可が必要です。特定のドメインとアクションへのアクセスは、設定済みの IAM アクセスポリシーにより制限される可能性があります。さらに、Amazon S3 バケットまたは DynamoDB テーブルからデータをアップロードするには、それらのサービスとリソースにアクセスする必要があります。Amazon CloudSearch アクセスポリシーの詳細については、「」を参照してくださいconfigure access policies。

ワイルドカードを使用してテキストフィールドを検索すると、予期した結果が生成されない

検索リクエストを送信すると、インデックスに存在する用語に対して一致できるように、検索対象のテキストには同じテキスト処理が行われます。ただし、プレフィックス検索を実行する場合、検索用語でテキスト分析は実行されません。これは、ステミングが有効な場合、末尾が s のプレフィックスを検索すると、用語の単数形には通常一致しないことを意味します。これは、複数形だけでなく末尾が s のあらゆる用語に適用される可能性があります。例えば、サンプル映画データの actor フィールドで Anders を検索した場合、一致する映画が 3 つあるとします。Ander* を検索した場合、それらの映画に加えて他のいくつかの映画が一致します。一方、Anders* を検索した場合、一致はありません。これは、用語が ander としてインデックスに格納されており、anders はインデックスにないためです。

ステミングのために、ワイルドカード検索を行っても関連する一致がすべて返されない場合、AlgorithmicStemming オプションを none に設定することでテキストフィールドのステミングを抑制できます。または、データを literal フィールドではなく text フィールドにマッピングできます。

Amazon がテキスト CloudSearch を処理する方法の詳細については、「」を参照してくださいAmazon CloudSearch でのテキスト処理。

ディープページ分割でカーソルを使用した場合の結果の不整合

ドキュメントスコア (_score) によってソートされた結果セットを、カーソルを使用してページ分割すると、リクエストの合間にインデックスが更新された場合に結果が不整合になることがあります。ドメインのレプリケーション数が 1 より大きい場合にも同様の現象が発生することがあります。これは、更新が結果整合性方式でドメイン内のインスタンス間に適用されるためです。問題になる場合は、スコアによるソートを避けてください。sort オプションを使用して特定のフィールドでソートするか、または q の代わりに fq を使用して検索条件を指定できます。(ドキュメントスコアはフィルタークエリでは計算されません)

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

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

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 に関するよくある質問」を参照してください。

注記

これらの証明書は必須ではありませんが、2017 年 11 月に AWS サーバーへのデプロイが予定されています。