Amazon OpenSearch Service に関するよくある質問

はい。コンソールのドメイン作成ウィザードで数回クリックするだけで、新しい Amazon OpenSearch Service ドメインを作成できます。新規ドメインの作成時に、インスタンス数、インスタンスタイプ、ドメインに割り当てる EBS ボリュームを指定できます。また、既存の Amazon OpenSearch Service ドメインの変更や削除にもコンソールを使用できます。

はい。Amazon OpenSearch Service は Amazon VPC と統合されています。VPC アクセスを選択すると、VPC の IP アドレスは Amazon OpenSearch Service ドメインに接続され、すべてのネットワークトラフィックが AWS ネットワーク内に留まり、インターネットにアクセスできなくなります。さらに、セキュリティグループと IAM ポリシーを使用して、Amazon OpenSearch Service ドメインへのアクセスを制限できます。

はい。AWS CloudFormation は、Amazon OpenSearch Service をサポートしています。詳細については、CloudFormation テンプレートリファレンスドキュメントをご覧ください。

はい。ドメインの専用マスターノードを構成できます。専用マスターの構成を選択すると、インスタンスタイプとインスタンス数を指定できます。

はい。同じ Amazon OpenSearch Service ドメインで複数の Elasticsearch または OpenSearch インデックスを作成できます。Elasticsearch および OpenSearch は、ドメインに割り当てられたインスタンス間で、インデックスとそれに関連するレプリカを自動的に分散させます。

Amazon OpenSearch Service では、データの取り込みに関して以下の 3 つのオプションをサポートしています。

• 大量のデータの場合は、Amazon Kinesis Data Firehose をお勧めします。これは、データスループットに応じて自動的にスケールされ、継続的な管理が不要なフルマネージドサービスです。また、ロードの前にデータの変換、バッチ設定、圧縮を行うことも可能です。
• Amazon OpenSearch Service は Logstash との統合をサポートしています。Amazon OpenSearch Service ドメインは、Logstash 実装からのすべてのログに対応するデータストアとして構成できます。
• インデックスや Bulk API などのネイティブ Elasticsearch (バージョン 7.10 まで) または OpenSearch API を使用して、データをドメインにロードできます。

はい。Amazon OpenSearch Service は Logstash との統合をサポートしています。Amazon OpenSearch Service ドメインを Logstash の実装によって発生するすべてのログのバックエンドストアとして設定できます。Amazon OpenSearch Service ドメインへのアクセスコントロールの種類は 2 つあります。リクエスト署名を使用して Logstash の実装で発生する呼び出しを認証するか、リソースベースの IAM ポリシーを使用して Logstash 実装を実行するインスタンスの IP アドレスを指定するか選択できます。

はい。Amazon OpenSearch Service は、OpenSearch ダッシュボードと Kibana (1.5 から 7.10 バージョン) を利用した視覚化機能を提供しています。

ローカルのオンインスタンスストレージ、または EBS ボリュームのどちらかを選択できます。ドメイン作成時に EBS ストレージを選択した場合、必要に応じてストレージボリュームのサイズを増減できます。

磁気、汎用、プロビジョンドの IOPS EBS ボリュームから選択できます。

はい。Amazon OpenSearch Service は、インスタンスの選択や関連する EBS ボリュームのサイズに基づいてストレージをデプロイします。ノードあたりの最大ストレージは、EBS gp3 ストレージを使用して、R6g.12xlarge インスタンスで 24 TB です。デフォルトでは 1 つの Amazon OpenSearch Service ドメインあたり最大で 80 個のデータノードを使用できるため、1 つのドメインに割り当てられるストレージは約 1920 TB です。AWS サポートセンターでケースを作成することで、ドメインあたりのサービス制限を最大 200 個のインスタンスまで引き上げるようリクエストできます。200 個のインスタンスがあれば、1 個のドメインに約 3 PB のストレージを割り当てることができます。

データインスタンスを単一の AZ にデプロイすると、専有マスターインスタンスも同じ AZ にデプロイされます。ただし、データインスタンスを 2 つまたは 3 つの AZ にまたがってデプロイすると、専有マスターインスタンスは Amazon OpenSearch Service によって 3 つの AZ に自動的に分散されます。このルールの例外は、リージョンに AZ が 2 つしかない場合、またはすべての AZ では使用できないマスターインスタンスに対して古い世代のインスタンスタイプを選択した場合に発生します。詳細については、ドキュメントをご覧ください。

本番稼働用ワークロードでは、可用性が向上するため、データインスタンスを 3 つの AZ にまたがってデプロイすることをお勧めしています。また、AZ 間で均等に分散させるために、インスタンスを 3 の倍数でプロビジョニングすることをお勧めします。3 つの AZ が利用できないリージョンでは、偶数のデータインスタンスで 2 つの AZ 配置を使用することをお勧めします。いずれの場合も、専有マスターインスタンスを 3 つプロビジョニングすることをお勧めしています。

AWS コンソール、CLI、SDK を使用すれば、既存のドメインでも新規のドメインでも 3 つの AZ 配置を有効にできます。詳細については、ドキュメントをご覧ください。

いいえ。3 つの AZ 配置を有効にしても Amazon OpenSearch Service の料金は発生しません。ドメイン内のインスタンスの数に対してのみお支払いただきます。インスタンスがデプロイされている AZ の数に対して料金は発生しません。

シャードがアベイラビリティーゾーンに確実に分散されるように、複数の AZ に設定されたすべてのドメインでゾーン対応が有効になります。コンソールでは、2 つまたは 3 つの AZ 配置を明示的に選択できるようになりました。「ゾーン対応」で以前に設定されたドメインは、再設定されない限り、2 つの AZ にまたがってデプロイされます。詳細については、ドキュメントをご覧ください。

AZ 内の 1 つ以上のインスタンスにアクセスできない、またはインスタンスが機能しない場合、Amazon OpenSearch Service は自動的に同じ AZ 内の新しいインスタンスを起動して、影響を受けるインスタンスを置き換えます。まれに、新しいインスタンスを AZ で起動できないことがあります。その場合、ドメインが複数の AZ にわたってインスタンスをデプロイするように設定されている場合は、Amazon OpenSearch Service は他の利用可能な AZ で新しいインスタンスを起動します。AZ の問題が解決すると、Amazon OpenSearch Service はインスタンスがドメイン用に設定された AZ に均等に分散されるようにインスタンスをリバランスします。詳細については、ドキュメントをご覧ください。

1 つのレプリカを設定する場合でも、3 つの AZ をお勧めしています。AZ の中断が 3 つの AZ のドメイン内で発生した場合 3 分の 1 の容量しか失われませんが、2 つの AZ のドメイン内で中断が発生した場合は半分の容量が失われてしまいます。また、3 つの AZ ドメインでは、1 つの AZ が中断されても、Amazon OpenSearch Service が残りの 2 つの AZ にフォールバックし、AZ 間レプリケーションをサポートすることができます。2 つの AZ ドメインでは、1 つの AZ が中断されると AZ 間レプリケーションが失われるため、可用性がさらに低下する可能性があります。詳細については、ドキュメントをご覧ください。

ドメインがデプロイされる AZ の数は、VPC ドメイン用に設定したサブネットの数に対応します。3 つの AZ 配置を有効にするには、VPC ドメインに少なくとも 3 つのサブネットを設定する必要があります。VPC の設定の詳細については、ドキュメントをご覧ください。

はい。パブリックインターネットアクセスを行うプログラムは、パブリックエンドポイントから Amazon OpenSearch Service ドメインにアクセスできます。自社のデータセンターが、Direct Connect または SSH トンネリングを使用して Amazon VPC に既に接続されている場合には、VPC アクセスを使用することもできます。どちらの場合も、AWS 外部のサーバーで実行しているプログラムが Amazon OpenSearch Service ドメインにアクセスできるように、IAM ポリシーやセキュリティグループを設定できます。 署名付きリクエストの詳細については、こちらをクリックしてください。

既存の Elasticsearch または OpenSearch クラスターからデータを移行するには既存のクラスターのスナップショットを作成し、そのスナップショットを Amazon S3 バケットに保存します。次に新規 Amazon OpenSearch Service ドメインを作成し、Restore API を使用して、スナップショットのデータを新しく作成した Amazon OpenSearch Service ドメインにロードします。

Amazon OpenSearch Service ではコンソール、API、CLI を使用して Amazon OpenSearch Service ドメインのスケーリングを制御できます。アプリケーションのニーズに合わせてインスタンスまたはストレージボリュームを追加、削除、変更することで、Amazon OpenSearch Service ドメインをスケールできます。Amazon OpenSearch Service は Amazon CloudWatch と統合されており、CloudWatch により生成される Amazon OpenSearch Service ドメインの状態に関するメトリクスを使用して、ドメインの適切なスケーリングを判断できます。

いいえ。インスタンスおよびストレージボリュームの追加/変更オペレーションはオンラインで行うことができ、Amazon OpenSearch Service ドメインのスケーリングにダウンタイムは必要ありません。

はい。OpenSearch/Elasticsearch インデックスのレプリカを有効にし、複数のアベイラビリティーゾーンを使用する場合、Amazon OpenSearch Service は自動的にプライマリシャードとレプリカシャードを異なる AZ のインスタンスに分散させます。

はい。Amazon OpenSearch Service では Amazon CloudWatch によって、ノード数、クラスターの正常性、検索可能ドキュメント、EBS メトリクス (該当する場合)、データおよびマスターノードの CPU、メモリ、ディスク使用率など、複数のメトリクスが公開されます。利用可能な CloudWatch メトリクスの一覧は、サービスドキュメントをご覧ください。

はい。AWS CloudTrail は、アカウントに対する AWS API 呼び出しを記録し、ログファイルを配信するウェブサービスです。AWS CloudTrail で生成される AWS API の呼び出し履歴を利用して、セキュリティの分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。AWS CloudTrail の詳細については、AWS CloudTrail の詳細ページをご覧ください。CloudTrail をオンにするには、CloudTrail の AWS マネジメントコンソールのホームページにアクセスしてください。

スナップショットは、その時点での Amazon OpenSearch Service ドメインのコピーです。

スナップショットを作成しておくと、ノード障害によってデータ損失が発生した場合や、万が一ハードウェア障害が発生した場合に役立ちます。スナップショットを使用すれば、事前にロードしたデータによって Amazon OpenSearch Service ドメインを復旧するか新規 Amazon OpenSearch Service ドメインを作成できます。バックアップを使用する別の一般的な理由はアーカイブを目的とするものです。スナップショットは Amazon S3 に保存されます。

はい。Amazon OpenSearch Service では、デフォルトで、各 Amazon OpenSearch Service ドメインのスナップショットが毎時間自動的に作成され、14 日間保持されます。

Amazon OpenSearch Service は、1 時間ごとの自動スナップショットを直近 14 日分保持します。

毎時間の自動スナップショット作成に追加料金はかかりません。スナップショットは無料で Amazon OpenSearch Service S3 バケットに保存され、ノードリカバリの目的で使用できます。

はい。Amazon OpenSearch Service によって毎日自動で作成されるスナップショットに加えて、 スナップショット API を使用して追加の手動スナップショットを作成できます。手動のスナップショットは S3 バケットに保存され、それに応じた Amazon S3 バケットの使用料が発生します。

はい。お客様は新規 Amazon OpenSearch Service ドメインを作成し、OpenSearch/Elasticsearch の Restore API を使用して、スナップショットのデータを新しく作成した Amazon OpenSearch Service ドメインにロードできます。

Amazon OpenSearch Service に保存されている毎日のスナップショットは、ドメインの削除と同時に削除されます。ドメインを削除する前に、手動スナップショットプロセスによって独自の S3 バケットにドメインのスナップショットを作成することを検討してください。独自の S3 バケットに保存されたスナップショットは、Amazon OpenSearch Service ドメインが削除されても影響を受けません。

Amazon OpenSearch Service は Amazon CloudWatch Logs を通して、エラーログ、検索スローログ、インデックススローログの 3 つの Elasticsearch または OpenSearch ログを公開します。これらのログはトラブルシューティングのパフォーマンスと、ドメインでの安定性の問題に役立ちます。

スローログは、操作のさまざまな段階のパフォーマンスを追跡できるログファイルです。OpenSearch と Elasticsearch では次の 2 種類のスローログを公開しています。

• インデックススローログ – このログでは、インデックス作成処理に関する洞察が得られ、このログを使用してインデックスの設定を微調整します。
• 検索スローログ – このログでは、クエリの取得と実行速度に関する洞察が得られます。このログは、OpenSearch または Elasticsearch で任意の種類の検索操作のパフォーマンスを微調整するのに役立ちます。

スローログの詳細については、OpenSearch のドキュメントを参照してください。

スローログは、コンソールからボタンをクリックするか、CLI と API を使用して有効にすることができます。詳細については、ドキュメントをご覧ください。

はい。特定のインデックスの設定を更新して、そのインデックスのスローログを有効または無効にできます。詳細については、ドキュメントをご覧ください。

Amazon OpenSearch Service でスローログを有効にすると、特定のドメインのインデックスを対象として、Amazon CloudWatch Logs に生成されたログを発行するオプションが有効になります。ただし、ログを生成するためには、1 つ以上のインデックスの設定を更新して、ログ記録処理を開始する必要があります。スローログを有効にするためのインデックス構成の設定の詳細については、ドキュメントをご覧ください。

いいえ。ログファイルの生成は、インデックスの設定とは関係なく実行されます。ログファイルの生成を無効にするには、インデックスの設定を更新する必要があります。スローログを有効にするためのインデックス構成の設定の詳細については、ドキュメントをご覧ください。

スローログに対するログ記録の詳細度のみを変更できます。OpenSearch と Elasticsearch はスローログに対して複数のレベルのログ記録を公開します。インデックスの設定で適切なレベルを設定する必要があります。スローログを有効にするためのインデックス構成の設定の詳細については、OpenSearch のドキュメントをご覧ください。

スローログまたはエラーログを有効にすると、 Amazon OpenSearch Service では、生成されたログの Amazon CloudWatch Logs へのパブリッシュを開始します。Amazon OpenSearch Service の料金はスローログを有効にしても発生しません。ただし、標準の CloudWatch の料金が適用されます。

OpenSearch は Apache Log4j 2 と、(最も軽度のものから順に) TRACE、DEBUG、INFO、WARN、ERROR、FATAL というその組み込みログレベルを使用します。エラーログを有効にした場合、Amazon OpenSearch Service は WARN、ERROR、FATAL のログの行と、DEBUG レベルの一部のエラーを CloudWatch に発行します。詳細については、ドキュメントをご覧ください。

スローログは、AWS コンソールからボタンをクリックするか、CLI と API を使用して有効にすることができます。詳細については、ドキュメントをご覧ください。

いいえ。エラーログはドメイン全体について公開されます。つまり、有効化されると、そのドメインのすべてのインデックスからのログエントリーが使用可能となります。

いいえ。エラーログは Elasticsearch バージョン 5.x 以降のみで使用可能です。

はい。CloudWatch に作成できる各ログエントリは、255,000 文字に制限されています。ログエントリがこの制限を上回った場合、255,000 文字で切り捨てられます。

スローログは、インデックスのトラブルシューティングを行うか、パフォーマンスを微調整する場合にのみ必要です。推奨する方法は、パフォーマンスに関する追加の洞察が必要なインデックスに対してのみ、ログ記録を有効にすることです。また、調査が終了したら、ログ記録を無効にして、有効なログ記録による追加の費用が発生しないようにします。詳細については、ドキュメントをご覧ください。

CloudWatch では、複数の方法でログを使用できます。ログデータの表示、S3 へのエクスポート、またはリアルタイムでの処理を行うことができます。詳細については、CloudWatch Logs デベロッパーガイドを参照してください。

はい。スローログは、Amazon OpenSearch Service でサポートされる、すべてのバージョンの OpenSearch および Elasticsearch で有効にできます。ただし、Elasticsearch のバージョンごとにログ設定を指定する方法が少し異なります。詳細については、ドキュメントをご覧ください。

いいえ。ダウンタイムは発生しません。ログステータスが更新されるたびに、AWS では、バックグラウンドで新しいクラスターがデプロイされ、既存のクラスターが新しいクラスターに置き換えられます。この処理によってダウンタイムは発生しません。ただし、新しいクラスターがデプロイされるため、ログステータスの更新は瞬時に行われません。

Amazon OpenSearch Service は現在、どの OpenSearch バージョンまたは Elasticsearch バージョン 5.x 以降のドメイン向けインプレースのバージョンアップグレードもサポートしています。アップグレード向けにサポートしているターゲットバージョンは、5.6、6.3、6.4、6.5、6.7、6.8、7.1、7.4、7.7、7.8、7.9、7.10 です。 詳細については、ドキュメントを参照してください。

さまざまな Elasticsearch バージョンからの移行の詳細については、ドキュメントをご覧ください。

いいえ。ドメインはアップグレード中も使用可能です。しかし、アップグレードプロセスにはシャードの移動を含み、これはドメインのパフォーマンスに影響を与えます。ドメインの負荷が低いときにアップグレードすることをお勧めします。

インプレースアップグレードは Elasticsearch 5.x 以降を実行しているドメインのみ可能です。ドメインのバージョンが 5.x 以降の場合、アップグレード可能性チェックを実行してドメインが希望のバージョンにアップグレードできるかどうかを検証できます。詳細については、ドキュメントをご覧ください。

アップグレード可否の検証のために実行されるテストの詳細なリストについては、ドキュメントをご覧ください。

いいえ。インプレースアップグレード開始後は、アップグレードが完了または失敗するまではドメイン設定の変更はできません。アップグレードが進行中にもデータの読み取り、書き込みは継続できます。また、ドメインの削除もできます。この場合アップグレードは終了し、ドメインは削除されます。

バージョンアップグレードプロセスは自動的にシステムのスナップショットをとり、スナップショットが成功した場合にのみ実際のアップグレードが始まります。自動スナップショットの開始時間に達したときにアップグレードが進行中の場合、自動スナップショットはその日はスキップされ、次の日に継続します。

Amazon OpenSearch Service はアップグレード開始前に一群のテストを実行し、アップグレードを妨げる既知の問題を確認します。問題が発見されなければ、サービスはドメインのスナップショットをとって、スナップショットが成功すればアップグレードプロセスが始まります。何らかの段階で問題が発生した場合、アップグレードは開始されません。

問題が小さなもので修復可能なものであれば、Amazon OpenSearch Service は自動的にこれに対処し、アップグレードの妨げを解除します。しかし、問題がアップグレードの妨げとなる場合は、サービスはアップグレードまでにとったスナップショットに戻して、エラーをログに入れます。アップグレードの進捗状況からのログの確認の詳細については、ドキュメントをご覧ください。

はい。アップグレードログは AWS コンソールから見るか、または CLI または SDK を用いてリクエストできます。詳細については、ドキュメントをご覧ください。

いいえ。アップグレードが開始されると、完了または失敗するまで一時停止やキャンセルはできません。

はい。しかし、ドメインすべての同じバージョンにしておきたければ、アップグレードする前にアップグレード可能性チェックを実行することをお勧めします。このステップにより、他のドメインにない問題を含むドメインを発見することができます。

データの量とクラスターのサイズにより、アップグレード完了には数分から数時間かかります。

いいえ。インプレースのバージョンアップグレードでは、クラスター中の全データもまたアップグレードプロセスの一環として復元されます。ドメインのみのアップグレードをご希望の場合、データのスナップショットをとり、ドメインからすべてのインデックスを削除し、インプレースのバージョンアップグレードを開始してください。別の方法として、新しいバージョンで別のドメインを作成し、そのドメインにデータを復元することもできます。

古いバージョンにダウングレードする必要がある場合、AWS Support に連絡して、新しいドメインにアップグレード前の自動スナップショットを復元してください。元のドメインの手動スナップショットを取った場合は、このステップを自分で行うことができます。

Multi-AZ with Standby は Amazon OpenSearch Service の新しいデプロイオプションで、ビジネスクリティカルなワークロードの高可用性と一貫したパフォーマンスを実現します。Multi-AZ with Standby を使用すると、OpenSearch Service がマネージドクラスターは、ノードドロップなどのインフラ障害や単一のアベイラビリティゾーン障害に強く、単一のアベイラビリティゾーン障害が発生した場合でも、パフォーマンスや可用性に影響を与えないことが保証されます。Multi-AZ with Standby には、ベストプラクティスを適用して複雑さを軽減することで、クラスターの構成と管理を簡素化できるという利点もあります。

Multi-AZ with Standby を有効にするには、マネージドクラスターが以下の条件を満たす必要があります。

• OpenSearch 1.3 またはそれ以降のバージョンを実行してください。
• 3-AZ を使用して AWS リージョンにデプロイします。現在、AWS 北カリフォルニアリージョンは 3-AZ をサポートしていないため、Multi-AZ with Standby には適していません。
• データノードの数は 3 の倍数にする必要があります。
• データコピー (プライマリ + レプリカ) の数は 3 の倍数でなければなりません。
• リーダーのサイズ設定ガイドライン (クラスター内のノード数、シャード数、マッピング数に基づく推奨サイズ) に従ってください。

Multi-AZ with Standby を使用すると、Amazon OpenSearch Service が一部のインフラストラクチャ障害を検出し、自動的に復旧します。Amazon OpenSearch Service は、以下のいずれかのイベントが発生した場合、1 分以内に自動的にアクティブノードからスタンバイノードにフェイルオーバーします。

• 1 つのアクティブ AZ またはアクティブ AZ のすべてのノードの喪失
• 1 つのアクティブ AZ への接続切断
• アクティブ AZ のインスタンスハードウェア障害
• アクティブ AZ のノードでのストレージ障害

現在、Multi-AZ with Standby は以下のイベントには対応していません。

• マスター Quorum の喪失 (このイベントからの回復には数分かかる場合があるため)
• 複数のアベイラビリティ―ゾーンの喪失
• リージョンへの接続切断
• 複数の AZ で 50% 以上のノード喪失
• ワークロード特性の変化によるコンピューティングまたはストレージの不足によるダウンタイム
• 不正クエリによるダウンタイム
• ARPS や ALB のような Amazon OpenSearch Service が依存している 1 つ以上のサービスの喪失
• バージョンアップグレード中の OpenSearch ダッシュボードのダウンタイム

いいえ。原則として、サイズのガイドラインは変わりません。Multi-AZ with Standby には、クラスターのサイズ設定に必要なメンタルモデルを簡略化するための前提条件があります。マネージドクラスターのサイズ設定の考え方は、ワークロードを処理するのに必要な容量を確認し、冗長性を確保するために 50% を追加するというものです。現在の「ゾーン認識」オプションとMulti-AZ with Standby オプションの主な違いは、可用性を維持するための冗長容量または追加容量の処理方法です。Multi-AZ with Standby では、1 つの AZ の容量を明示的にスタンバイとして予約できるように、各 AZ に少なくとも 1 つのデータコピーを持つ必要があります。このスタンバイ容量は、AZ の中断またはインスタンス障害時のフェイルオーバーターゲットとして機能します。従来のモデルでは、ワークロードに対応するために最適なレベルのリソースを維持する必要があります。クラスターのサイズ設定の問題がないか引き続きモニタリングし、ワークロード特性に変化があれば対応策を取ることになります。

いいえ。Amazon OpenSearch Service は責任共有モデルに基づいて機能します。お客様自身でクラスターのサイズがワークロードに合わせて設定されていることを確認してください。Multi-AZ with Standby を使用すると、クラスターをセットアップするメンタルモデルが簡素化します。エラーとレイテンシーメトリクス、ストレージ、CPU、RAM の使用率をモニタリングして、クラスターの過負荷によりスケーリングが必要になる可能性があることを示すシグナルがないかどうかを確認し続ける必要があります。

いいえ。Multi-AZ with Standby は追加料金なしで利用できます。ワークロード処理のために、クラスターにデプロイされたリソースの料金を引き続きお支払いいただきます。クラスターがすでにベストプラクティスに従っていて、3 AZ クラスターのデータのコピーが少なくとも 3 つある場合は、Multi-AZ with Standby に移行しても追加コストが発生する可能性はほとんどありません。ただし、クラスターのサイズが小さかったり、ワークロード処理に十分な冗長容量がない場合は、可用性とパフォーマンスを向上させるために、容量を追加して Multi-AZ with Standby に移行する必要があります。スタンバイ容量は、設定された合計容量から予約されます。

Amazon OpenSearch Service SLA は、Amazon OpenSearch Service に最低 99.9% の月間稼働率を保証しています。

Amazon OpenSearch Service のマルチ AZ ドメインで、毎月の請求サイクル中に月間稼働率が 99.9% 未満の場合、Amazon OpenSearch Service SLA に基づく Amazon OpenSearch Service の SLA クレジットの対象となります。

SLA のすべての利用規約に関する完全な詳細と、請求の提出方法の詳細については、Amazon OpenSearch Service SLA の詳細ページをご覧ください。

クラスター間検索は、接続された 2 つのクラスター間でクエリや集計を実行できるようにする Elasticsearch および OpenSearch の機能です。参加しているクラスター間に軽量の単方向接続をセットアップすることで機能します。

クラスター間検索に参加するには、ドメインが以下の条件を満たしている必要があります。

• 参加するドメインで OpenSearch または Elasticsearch バージョン 6.8 以降を使用している
• 参加するドメインで転送中の暗号化を有効にしている
• 参加するドメインで Fine Grained Access Control (FGAC) を有効にしている
• 参加するドメインバージョンを新しいバージョンにするときに、ローリングアップグレードのルールを遵守している

現在クラスター間検索をサポートしているのは以下のインスタンスタイプです

• i2、i3 ファミリー
• r3、r4、r5 ファミリー
• m4、m5 ファミリー
• c4、c5 ファミリー
• Graviton ファミリー

t2 および m3 ファミリーインスタンスでは、技術的な制限のためクラスター間検索がサポートされていません。

はい。参加するドメインは 2 つの異なる AWS アカウントに属することができます。

はい。

クラスター間検索を開始するには、こちらのドキュメントに従ってください。

クラスター間レプリケーションは、Amazon OpenSearch Service のお客様が、同じまたは異なるAWS リージョンにある 1 つのクラスターから別のクラスターへ、低レイテンシーでインデックスのコピーと同期を自動化できる新しい機能です。

クラスター間レプリケーションに参加するには、ドメインが以下の条件を満たしている必要があります。

• 参加するドメインで Elasticsearch バージョン 7.10 を使用している
• 参加するドメインで転送中の暗号化を有効にしている
• 参加するドメインで Fine Grained Access Control (FGAC) を有効にしている
• 参加するドメインバージョンを新しいバージョンにするときに、ローリングアップグレードのルールを遵守している

はい。2 つの異なる AWS リージョンのドメインは、クラスター間レプリケーションに参加できます。

いいえ。現在のクラスター間レプリケーションは、Ultrawarm や Cold Storage をサポートしていません。

はい。Amazon OpenSearch Service との間で転送 (IN および OUT) されたデータについて、標準の AWS データ転送料金をお支払いいただきます。

2021 年 4 月 12 日に、当社は Elasticsearch と Kibana のコミュニティ主導のオープンソースフォークである OpenSearch プロジェクトを発表しました。当社は、OpenSearch に長期的な投資を行い、ユーザーが安全で高品質の完全にオープンソースの検索および分析スイートを引き続き利用し、新しく革新的な機能の豊富なロードマップを使用できるようにすることに尽力してきました。このプロジェクトには、OpenSearch (Elasticsearch 7.10.2 から派生) と OpenSearch ダッシュボード (Kibana 7.10.2 から派生) が含まれます。2021 年 7 月 12 日に OpenSearch のバージョン 1.0 をリリースしました。OpenSearch への長期的な取り組みの一環として、2021 年 9 月 7 日にマネージドサービスで OpenSearch 1.0 のサポートを追加し、名前を Amazon Elasticsearch Service から Amazon OpenSearch Service に変更しました。OpenSearch 1.0 と共に、サービスで 7.10 までのレガシー Elasticsearch バージョンを引き続きサポートしていきます。名前の変更の他は、継続的な運用、開発方法、またはビジネスでの使用に影響を与えることなく、同じ優れたエクスペリエンスを引き続き提供していきますのでご安心ください。OpenSearch の詳細については、https://opensearch.org をご覧ください。

当社は、お客様のためにこの名前の変更を可能な限りシームレスにするよう努めてきました。新しい SDK/設定 API など、サービスから最高の利点を確実に引き出すためのアクションがお客様から必要となる側面があります。既存の SDK は互換性の観点から引き続き機能しますが、新しい設定 API を必要とする新しい機能は、新しい SDK にのみ実装されます。そのため、新しい SDK に移行することをお勧めします。さらに、新しい SDK に関係なく、IAM ポリシーから名前を変更した設定 API を使用するように移行することを強くお勧めします。現在のところ、既存の IAM ポリシーは引き続き古い API 定義で機能します。ただし、新しい API ベースのアクセス許可検証に移行し、最終的にはお客様のポリシーで新しい API を使用していただく必要があります (特に名前が変更された API の場合、例えば CreateElasticsearchDomain から CreateDomain)。詳細については、ドキュメントを参照してください。

いいえ。下位互換性の観点から、お使いの既存の設定が引き続き OpenSearch 1.0 で機能することを保証します。ただし、前述のように、最終的には最新の SDK に移行して、よりクリーンで最新のエクスペリエンスを享受することをお勧めします。

いいえ。料金に変更はありません。

OpenSearch には、Elasticsearch B.V. の Apache ライセンスによる Elasticsearch コードの一部と、その他のソースコードが含まれています。Elasticsearch B.V. はその他のソースコードのソースではありません。ELASTICSEARCH は、Elasticsearch B.V. の登録商標です。

OpenSearch 1.x にアップグレードすることで、お客様の検索インフラストラクチャが成長中のダイナミックな Apache ライセンスのオープンソースプロジェクト上に構築され、OpenSearch 1.2 (この記事の執筆時点) で利用できる豊富な革新的改善と機能にアクセスすることができます。 エンタープライズグレードのセキュリティ、アラート、データライフサイクル管理、観測性、機械学習ベースの異常検出などの機能は、すべてOpenSearch Service の一部で、追加のライセンス料は必要ありません。

アップグレードの際には、ブルー/グリーン (BG) デプロイプロセスを使用します。BG の間、サービスは新しい設定とバージョンで OpenSearch Service クラスターにノードを追加し、古いノードからデータを移行し、データ移行が完了したら古いノードを削除します。BG の間、検索 API とインデックス作成 API は利用可能で、通常通り機能します。BG はクエリやインデックスのリクエストに干渉しないように設計されていますが、一部の変更 (特にセキュリティ関連の設定の変更を伴うもの) により、変更期間中にダッシュボードが使用できなくなることがあります。

OpenSearch は Elasticsearch と OpenSearch の複数のバージョンをサポートしていますが、そのうちのいくつかはすでに標準サポートおよび延長サポートの終了日が発表されています。エンジンバージョンの全リストと対応するサポート日については、ドキュメントを参照してください。延長サポートの詳細については、延長サポートをご覧ください。

AWS では、Apache-2.0 ライセンスの Elasticsearch を 19 バージョン管理しています。これらのバージョンは、現時点では非推奨ではなく、非推奨の予定もありません。

はい、アップグレードは BG デプロイプロセスをトリガーします。アップグレードの準備とステップについては、こちらをご覧ください。

RI に関する特定の状況に基づいた情報については、AWS アカウントチームと連携してください。

OpenSearch プロジェクト 1.0 は、オープンソース Elasticsearch 7.10.2 のフォークです。Elasticsearch 7.10 とワイヤー互換性があるので、使い方を変更する必要はありません。移行するには、ドメインを 6.x、7.x シリーズの以前のバージョンから Elasticsearch 7.10 にアップグレードしてスナップショットをとり、そのスナップショットを OpenSearch Service 1.x が稼働しているドメインに復元することができます。クライアントやツールの中には、バージョンチェックを含むものがあり、クライアントやツールが OpenSearch Service で動作しない場合があります。アップグレードする際には、互換性モードを有効にして、これらのバージョンチェックを回避してください。

ほとんどの場合、既存のクライアントを引き続き使用することができます。API やコア検索機能は、Elasticsearch のバージョン 7.10.2 と互換性があります。古いクライアントをご利用の場合や、クライアントがバージョンチェックを行う場合、またはメジャーなバージョン 5 や 6 など古いバージョンの Elasticsearch を対象とした機能を利用している場合は、スムーズな移行のためにクライアントを 7.10.2 の最低サポート水準にしてみることをお勧めします。

OpenSearch プロジェクトでは、Amazon OpenSearch Service 上のエンジンの OpenSearch バージョンに対応するために特別に構築された幅広いクライアントをサポートしています。最新の OpenSearch クライアント、およびそれらのクライアントについてサポートされているプログラミング言語のリストと、お客様のクライアントを照らし合わせてみてください。

互換モード機能を有効にして、他のベンダーのクライアントと相互運用することもできますが、OpenSearch が報告するバージョンを確認することを忘れないでください。この設定を有効にすると、OpenSearch Service エンジンが導入される前に開発されたクライアントに対して、サービスがバージョン 7.10.2 で応答するようになります。

Elasticsearch 5.x のインデックスは、Elasticsearch 7.10 や OpenSearch 1.x と互換性がありません。新しいインデックスを作成し、ソースからデータをロードする必要があります。ログ分析のワークロードを実行している場合、新しいドメインで完全なデータセットを構築する間に、データ保持戦略が並列実行に対応しているかどうかを評価することができます。

はい。お客様のリージョン、業界、プロジェクトの複雑さに合ったパートナーのリストをリクエストするには opensearchmigration-si-support@amazon.com にご連絡ください。AWS パートナーネットワーク (APN) のパートナーは、お客様によるアップグレードをサポートするためのトレーニングを受けており、経験を積んでいます。 

OpenSearch 1.0 は、Elasticsearch 7.10.2 のフォークです。OpenSearch と Elasticsearch は互換性があります。互換モードを有効にすると、Elasticsearch のクライアントも OpenSearch 1.0 と互換性を持ちます。

Amazon OpenSearch Service は、Elasticsearch エンジンのバージョン 7.10.2 以降を提供していませんし、今後も提供することはありません。

Elasticsearch をフォークした際に AWS が発表したように、当社は OpenSearch を中心とした活発なコミュニティを構築することを意図していたのであり、これまで実際にそのようなコミュニティを構築してきました。私たちは OpenSearch のロードマップを公開し、コミュニティの意見を取り入れ、機能の優先順位を決定しています。私たちは、Elasticsearch との互換性を維持するために、あらゆる合理的な努力をします。私たちの目標は、コミュニティと Amazon OpenSearch Service のお客様と共に成長することです。

Elasticsearch および Kibana のバージョン 6.8.0 から 7.10.2 および Open Distro for Elasticsearch (ODFE) 1.x から OpenSearch Service 1.0 に直接アップグレードすることができます。ODFE から OpenSearch へのローリングアップグレードは、まず ODFE 1.13 にアップグレードし、その後 OpenSearch 1.0 にアップグレードすることをお勧めします。

移行のリソースはこちらをご覧ください。

分析移行

Amazon OpenSearch Service への移行

OpenSearch Service で起動されるすべてのエンジンバージョンは、デフォルトで標準サポートの対象となります。標準サポートの一環として、AWS は定期的なバグ修正とセキュリティアップデートを提供します。あるバージョンの標準サポートが終了すると、AWS は標準サポート終了日から少なくとも 12 か月間の延長サポート期間を提供します。延長サポート期間中、AWS は重要なセキュリティ修正とオペレーティングシステムパッチを提供します。これにより、サポートされている最新のエンジンバージョンへのアップグレードを計画する時間を確保できます。延長サポートのバージョンを実行する場合、標準のインスタンスコストとストレージコストに加えて、定額料金/正規化インスタンス時間 (NIH) が請求されます。延長サポートの詳細とさまざまなバージョンのスケジュールについては、ドキュメントをご覧ください。料金に関する情報については、料金ページを参照してください。

いいえ。標準サポートが終了したバージョンを実行しているドメインは、自動的に延長サポートの対象となり、それに応じて料金が設定されます。標準サポート対象の新しいバージョンにドメインをアップグレードすると、延長サポートの請求は行われなくなります。

延長サポートを実施しているドメインには、標準のインスタンスおよびストレージ料金に加えて、追加の定額料金/正規化インスタンス時間 (NIH) が課金されます。地域別の正確な価格については、料金ページをご覧ください。お客様のドメインには、標準サポート終了の翌日から、延長サポートの料金が自動的に課金されます。ご利用のドメインで標準サポート日と延長サポート日が公開されているバージョン (詳細はこちらをご覧ください) を実行している場合、スタンダードサポート終了日の 3 か月前に、Personal Health Dashboard、OpenSearch Service コンソール、EventBridge イベントを通じて通知を送信します。OpenSearch Service での通知のモニタリングの詳細については、こちらのドキュメントを参照してください。

延長サポート対象のバージョンを実行しているドメインには、追加の定額料金/正規化インスタンス時間 (NIH) が課金されます。NIH は、インスタンスサイズ (例: medium、large) とインスタンス時間数の係数として計算されます。たとえば、米国東部 (バージニア北部) で m7g.medium.search インスタンスを 24 時間実行していて、その料金が 1 時間あたり 0.068 USD (オンデマンド) の場合、通常、インスタンスコストとして 1.632 USD (0.068 USD x 24) を支払うことになります。延長サポートのバージョンを実行している場合は、NIH あたり 0.0065 USD の追加料金が発生します。これは 0.0065 USD x 24 (インスタンス時間数) x 2 (サイズ正規化係数、medium サイズインスタンスの場合は 2) として計算され、24 時間の延長サポートとして 0.312 USD になります。24 時間分にお支払いいただく合計金額は、標準インスタンス使用コスト (ストレージを除く) と延長サポートコストの合計である 1.944 USD (1.632 USD + 0.312 USD) になります。詳細については、ドキュメントをご覧ください。

ドメインを標準サポートの対象となるエンジンバージョンにアップグレードしてください。特定のバージョンが標準サポートの対象となるのは、公開された標準サポート終了日まで、またはそのバージョンの標準サポート終了日が発表されていない場合です。

いいえ。標準サポートまたは延長サポートの対象となるバージョン、またはサポート終了が発表されていないバージョンにアップグレードすることをお勧めします。特定のバージョンの延長サポートが終了すると、そのバージョンを実行しているドメインはバグ修正やセキュリティアップデートを受けられなくなります。

あるバージョンの延長サポートが終了すると、その特定のバージョンのためのバグ修正やセキュリティ更新はリリースされなくなります。サポートされていないバージョンを実行しているドメインは分離され、データは少なくとも 30 日間保存されます。分離されたドメインにはアクセスできなくなり、サポートされているバージョンを実行している新しいドメインにデータを復元する必要があります。特定のバージョンの延長サポートが終了する前に、ドメインをサポート対象バージョンに更新することを強くお勧めします。さらにサポートが必要な場合は、AWS サポートまでお問い合わせください。

はい。使用したいエンジンバージョンが延長サポートの対象である限り、制限なく通常どおりサービスを引き続き運用できます。

延長サポートの一環として、AWS は必要に応じて重要なセキュリティ修正とオペレーティングシステムパッチを提供します。

はい。アップグレード元およびアップグレード先のバージョンによって異なります。サポートされているアップグレードパスのリストについて、こちらのドキュメントを参照してください。ES 1.5 や ES 2.3 などのレガシーバージョンから移行する場合、インプレースアップグレードはサポートされません。レガシーバージョンを実行しているドメインをアップグレードする手順については、こちらのドキュメントを参照してください。

Amazon DynamoDB と OpenSearch Service のゼロ ETL 統合により、トランザクションデータストアから検索データストアへのデータのレプリケーションをオーケストレートする際の運用面の複雑さが軽減されます。トランザクションデータストアと検索データストアの同期を維持するために使用されるデータパイプラインにより、構築と管理が困難でコストがかかり、追跡が困難な断続的なエラーが発生する可能性があります。この統合により、Amazon DynamoDB のお客様は、DynamoDB のトランザクションデータが書き込まれてから数秒以内に Amazon OpenSearch Service で利用できるようにするフルマネージドソリューションを提供することで、トランザクションデータからほぼリアルタイムの検索結果を取得できるようになります。

Amazon OpenSearch Service と Amazon DynamoDB のゼロ ETL 統合では、Amazon OpenSearch Ingestation を使用して運用データを Amazon DynamoDB から Amazon OpenSearch Service にシームレスに移動します。統合を有効にするには、まずデータをレプリケートする必要がある Amazon DynamoDB テーブルを選択します。このゼロ ETL 統合により、お客様のアカウントに Amazon OpenSearch Ingeston パイプラインが設定され、Amazon OpenSearch Service が管理するクラスターまたはサーバーレスコレクションへのデータのレプリケートが行われます。OpenSearch Ingestion は Amazon DynamoDB テーブルの構造を分析し、同等の Amazon OpenSearch Service マネージドドメインまたはサーバーレスコレクションを作成し、DynamoDB テーブルの既存のデータを使用して送信先のブートストラップを行います。オプションで、お客様は Amazon OpenSearch Service で作成されるインデックスのスキーマを指定することができます。DynamoDB テーブルへの更新はすべて、お客様が手動で操作しなくても Amazon OpenSearch Service にレプリケートされます。

このゼロETL機能は、Amazon OpenSearch Ingestを使用してAmazon DynamoDBからAmazon OpenSearch Serviceにデータを移動し、Amazon OpenSearch Ingestパイプラインのネイティブデータ変換機能を活用して、移動中のデータを集約してフィルタリングします。Amazon DynamoDB テーブルからデータを移動する場合、お客様はいくつかのフィールドを削除するか、既存のフィールド全体の集計に基づいて新しいフィールドを作成したい場合があります。オプションとして、お客様が OpenSearch Ingeston 用のカスタムロジックを記述して、特注のトランスフォーメーション機能を実現することもできます。データ全体をソースからシンクに移動したいだけの他のユーザーには、このゼロ ETL 統合により、すぐに使える OpenSearch Ingesttion ブループリントが提供され、ボタンを数回クリックするだけで統合を実行できるようになります。

OpenSearch Ingeston がこれら両方のシステム間でデータをレプリケートするために必要なアクセス許可を持っていることを確認するために、DynamoDB と OpenSearch Service のゼロ ETL 統合により、Amazon DynamoDB テーブルからデータを読み取り、OpenSearch ドメインまたはコレクションに書き込むために必要なアクセス許可を持つ IAM ロールが作成されます。その後、OpenSearch Ingestistion パイプラインがこの役割を引き受け、データをソースからターゲットに移動する際に常に適切なセキュリティ体制が維持されるようにします。

Amazon OpenSearch Ingestion が提供するダッシュボードでは、お客様による Amazon DynamoDB とのゼロ ETL 統合に関連するすべてのメトリクスを、Amazon CloudWatch のリアルタイムログとともに表示できます。これにより、お客様は、ユーザー定義のしきい値に違反したときにトリガーされるカスタムアラートを設定できます。

OpenSearch Service クエリエンジンは、Amazon S3 や S3 ベースのデータレイクなどのクラウドオブジェクトストアに保存されている運用データの分析をサポートするようにリアーキテクトされました。データの複製は行いません。数秒で差が出るような場合は、新しいインテグレーションに組み込まれたクエリアクセラレーション機能を使用して、クエリのパフォーマンスを向上させるだけでなく、読み込みの速いダッシュボードを構築できます。

AWS マネジメントコンソールから使用を開始するには、お客様は OpenSearch Service バージョン 2.11 以降を実行している既存の OpenSearch Service ドメインから新しいデータソースを設定します。新しいダイレクトクエリデータソースを設定する場合、OpenSearch Service から Amazon S3 内のデータを簡単にクエリできるように、お客様は Amazon S3 と AWS Glue データカタログへの読み取り/書き込みアクセスを提供する必要があります。お客様は IAM ポリシーをカスタマイズして、Amazon S3 の特定のバケットまたは AWS Glue データカタログ内のリソースへのアクセスを制限できます。コンソールで新しいデータソースを設定したら、お客様は OpenSearch Service にアクセスして、ロールベースのアクセス制御、クエリパフォーマンスを高速化するためのアクセラレーション、さらに VPC フローログ、Elastic ロードバランサー ログ、NGINX ログなどの一般的なログタイプのテンプレート用のすぐに使用できるダッシュボードを設定できるようになります。お客様には、ダイレクトクエリ OpenSearch コンピュートユニット (OCU、使用料が適用されます) の形式で消費されたコンピューティングリソースに対して請求されます。新しいデータソースを設定したら、お客様は OpenSearch API または OpenSearch ダッシュボードから直接データのクエリを開始できます。

お客様は、ワークロードによって消費されたリソースに対してのみ料金を支払います。OpenSearch Service は、外部データを直接クエリしたり、OpenSearch Service でオプションのインデックスを管理したりするのに必要なコンピューティングに対してのみ料金を請求します。コンピューティング能力は、Amazon OpenSearch Serverless Amazon OpenSearch Ingestion で使用されているのと同じユニットである OpenSearch コンピュートユニット (OCU) で測定されます。OCU の数は、データに基づいてインデックスをクエリまたは維持するために必要な vCPU とメモリに直接対応します。データインジェストのラベルが付いた OCU 時間のコンピューティングのエントリが 1 つ表示されます。OCU は、1 分単位の細度で 1 時間単位で請求されます。アクティブなクエリやインデックス作成アクティビティがない場合、OCU は消費されません。Amazon S3 または AWS Glue データカタログの費用は、お客様のアカウントに別途請求されます。料金の詳細については、Amazon OpenSearch Service の料金ページをご覧ください。

Amazon OpenSearch Service と Amazon Security Lake の統合により、直接検索、分析情報の取得、Security Lake に保存されているデータの分析のエクスペリエンスが効率化されます。これらはすべて OpenSearch Service 内で実行できます。Security Lake と OpenSearch Service を統合するには、クエリアクセスとデータアクセスの 2 つの方法があります。

クエリアクセスの統合により、セキュリティアナリストは OpenSearch Dashboards コンソールを使用して Security Lake のデータに対して直接クエリを実行し、オンデマンドのインデックス作成と事前構築されたコンテンツを活用してセキュリティ関連のクエリを開始できます。データアクセスの統合の場合は、OpenSearch インジェストサービスが事前設定された Security Lake ブループリントを提供します。これには、Security Lake から Open Cybersecurity Schema Framework (OCSF) Parquet ファイルを取り込むためのデフォルト設定が含まれています。Security Lakeとのゼロ ETL 統合は、クラスターではなく、OpenSearch UI を備えたコレクションでのみ提供されます。

開始するには、まず AWS 環境に既存の Security Lake をセットアップする必要があります。これにより、企業のセキュリティデータの一元的なストレージとアクセスが可能になります。

その後、AWS マネジメントコンソールまたは AWS CloudFormation テンプレートを使用して、2 つのサービス間の統合を有効にできます。これには、Amazon OpenSearch Service がセキュリティレイク内のデータに安全にアクセスしてクエリを実行できるように、必要な権限とアクセス制御を設定することが含まれます。

その後、OCSF で利用できる事前構築済みのクエリとインテグレーションを確認して、一般的なセキュリティ分析のユースケースをすぐに使い始めることができます。また、高度な分析や視覚化のニーズに合わせて、Security LakeからOpenSearch Service への特定のデータセットのオンデマンドでのインデックス作成を設定することもできます。