メニュー
Amazon Elasticsearch Service
開発者ガイド (API Version 2015-01-01)

Amazon Elasticsearch Service ドメインの管理

Amazon Elasticsearch Service (Amazon ES) ドメイン内のドキュメントサイズが大きくなり、数が増えるにつれ、また、ネットワークトラフィックが増大するにつれて、Elasticsearch クラスターの設定の更新が必要になる場合があります。ドメインを再設定する時期を把握するには、ドメインメトリクスを監視する必要があります。独自のインデックススナップショットを管理する、ドメインに対するデータ関連の API 呼び出しを監査する、ドメインにタグを割り当てる、という選択肢もあります。ここでは、これらのタスクや、ドメインの管理に関連する他のタスクを実行する方法を説明します。

専用マスターノードについて

Amazon Elasticsearch Service (Amazon ES) は、クラスターの安定性を向上するために専用マスターノードを使用します。専用マスターノードは、クラスター管理タスクを実行するクラスターノードですが、データを保持したりデータのアップロードリクエストに応答したりはしません。このように、クラスター管理タスクをオフロードすると、Elasticsearch クラスターの安定性が向上します。

注記

製品内の各 Amazon ES ドメインに、3 つの専用マスターノードを割り当てることを推奨します。

専用マスターノードは次のクラスター管理タスクを実行します:

  • クラスター内のすべてのノードを追跡する

  • クラスター内のインデックスの数を追跡する

  • 各インデックスに属するシャードの数を追跡する

  • クラスター内のノードのルーティング情報を維持

  • クラスター内のインデックス作成やノードの作成/削除など、状態が変化した後に、クラスターの状態を更新する

  • クラスターの状態に施された変更を、クラスター内のすべてのノードにわたって複製する

  • クラスター内のデータノードの可用性を監視するハートビートシグナル (定期的なシグナル) の送信により、すべてのクラスターノードの状態を監視する

次の図は、10 のインスタンスを持つ Amazon ES ドメインを表しています。インスタンスのうち 7 つはデータノードで、3 つは専用マスターノードです。専用マスターノードのうち、1 つのみがアクティブで、グレーの専用マスターノード 2 つは、アクティブな専用マスターノードが失敗したときのために、バックアップとして待機します。すべてのデータアップロードリクエストは、7 つのデータノードにより保存され、すべてのクラスター管理タスクは、アクティブな専用マスターノードにオフロードされます。

専用マスターインスタンスは検索およびクエリリクエストを処理しませんが、そのサイズは管理可能なインスタンス、インデックス、シャードの数と大きな相関があります。実稼働用クラスターでは、専用マスターインスタンスには以下のサイズをお勧めします。これらの推奨事項は、サービスの一般的なワークロードに基づいているため、ワークロード要件により異なります。

Instance Count

推奨される最小専用マスターインスタンス

5–10

m3.medium.elasticsearch

10–20

m4.large.elasticsearch

20–50

c4.xlarge.elasticsearch

50–100

c4.2xlarge.elasticsearch

インスタンス数の制限の詳細については、「クラスターとインスタンスの制限」を参照してください。vCPU、メモリ、料金表など、特定のインスタンスタイプの詳細については、Amazon Elasticsearch Instance Prices を参照してください。クラスターの設定を変更した場合に発生する料金については、Amazon Elasticsearch Service の料金表を参照してください。

設定変更について

Amazon ES では、ドメインの更新時に Blue/Green デプロイプロセスが使用されます。Blue/Green は通常、2 つの本稼働環境 (ライブとアイドル) に使用して、ソフトウェアの変更時に両者間で切り替える方法を指します。Amazon ES の場合は、ドメインの更新用に新しい環境を作成し、これらの更新の完了後に新しい環境にユーザーをルーティングする方法を指します。この方法では、新しい環境へのデプロイに失敗しても、ダウンタイムを最小限に抑えることができ、元の環境を維持することができます。

ドメインの更新は、設定の変更を行った場合に発生しますが、サービスに対するソフトウェア変更が Amazon ES チームによって行われた場合にも発生します。設定の変更を行うと、ドメインの状態が Processing に変化します。Amazon ES チームによってソフトウェアの変更が行われた場合、状態は Active のままになります。どちらの場合も、クラスターの状態と Amazon CloudWatch メトリクスを調べると、ドメイン更新中はクラスター内のノード数が一時的に倍増していることを確認できます。次の図では、設定の変更中にノード数が 11 から 22 に倍増し、更新が完了すると 11 に戻っていることがわかります。

 ドメイン設定の変更中にノード数が 11 から 22 に倍増している。

この一時的な倍増により、管理対象のノード数が急に倍になるため、クラスターの専用マスターノードへの負荷が高くなります。専用マスターノードでは、Blue/Green デプロイに関連するオーバーヘッドを処理するための十分な容量を維持することが重要です。

重要

設定の変更およびサービスのメンテナンス中に、追加料金は発生しません。課金対象となるのは、クラスター用にリクエストしたノード数のみです。

専用マスターノードに過度な負荷がかかることを防ぐには、次の表に示されている Amazon CloudWatch メトリクスを使用して、使用率を監視できます。これらのメトリクスが、推奨される最大値に達した場合は、より大きなインスタンスタイプを使用してください。

CloudWatch メトリクス ガイドライン
MasterCPUUtilization 専用マスターノードの CPU 使用率 (%) を計測します。ドメインのステータスがアクティブのときにこのメトリクスが 40% を超え、ドメインのステータスが処理中のときに 60% を超える場合、インスタンスタイプのサイズを大きくすることをお勧めします。
MasterJVMMemoryPressure 専用マスターノードの JVM メモリ使用率 (%) を計測します。ドメインのステータスがアクティブのときにこのメトリクスが 60% を超え、ドメインのステータスが処理中のときに 85% を超える場合、インスタンスタイプのサイズを大きくすることをお勧めします。

詳細については、次のトピックを参照してください。

ゾーン対応 (コンソール) の有効化

それぞれの AWS リージョンは地理別に分類された地域であり、アベイラビリティーゾーンと呼ばれる複数の独立したロケーションを持っています。ノードまたはデータセンターの障害時にデータの損失を防ぎ、ダウンタイムを最小限に抑えるには、Amazon ES コンソールを使用し、同じリージョンの 2 つのアベイラビリティーゾーンに対して、Elasticsearch クラスターに属するノードとレプリカインデックスシャードを割り当てることができます。この割り当ては、ゾーン対応と呼ばれます。ゾーン対応を有効にする場合、ネイティブ Elasticsearch API を使用してクラスターのレプリカシャードを作成する必要があります。Amazon ES はアベイラビリティーゾーン全体のノードにレプリカを分散し、クラスターの可用性を向上します。クラスターのゾーン対応を有効にすると、ネットワークレイテンシーが少し長くなります。

重要

ゾーン対応では、インスタンス数を偶数にする必要があります。すべてのインデックスのデフォルト設定で、レプリカの数は 1 つです。インデックスに対してレプリカの数を 0 に指定する場合、ゾーン対応は 2 番目のアベイラビリティーゾーンにシャードを複製しません。シャードを複製しない場合、2 番目のアベイラビリティーゾーンに分散するレプリカがなく、機能を有効にしてもデータ損失を防げません。

次の図では、ゾーン対応が有効な 4 ノードクラスターを表しています。サービスは、すべてのプライマリインデックスシャードを 1 つのアベイラビリティゾーンに配置し、すべてのレプリカシャードを 2 番目のアベイラビリティゾーンに配置します。

ゾーン対応 (コンソール) を有効にするには

  1. https://aws.amazon.com にアクセスし、[Sign In to the Console] を選択します。

  2. [Analytics] で、[Elasticsearch Service] を選択します。

  3. ナビゲーションペインにある、[My domains] で、Amazon ES ドメインを選択します。

  4. [Configure cluster] を選択します。

  5. [Node configuration] ペインで、[Enable zone awareness] を選択します。

  6. [Submit] を選択します。

詳細については、EC2 ドキュメントの「リージョンとアベイラビリティーゾーン」を参照してください。

Amazon CloudWatch を使用した、クラスターメトリクスと統計情報の監視 (コンソール)

Elasticsearch クラスターは、Elasticsearch を実行し、Amazon ES ドメインを操作するために必要な、1 つ以上のデータノード、オプションの専用マスターノード、ストレージの集合です。Elasticsearch クラスターの各ノードは、パフォーマンスメトリクスを Amazon CloudWatch に 1 分間隔で自動的に送信します。これらの、無料提供のメトリクスを表示するには、Amazon Elasticsearch Service コンソールの [Monitoring] タブを使用します。

統計からは、各メトリクスに対する、幅広い情報が得られます。たとえば、クラスター内のすべてのノードの CPU の平均使用率を算出するには、CPUUtilization メトリクスの Average 統計を表示します。メトリクスはそれぞれ、3 つのカテゴリのうちのどれかに分けられます。

注記

サービスは、メトリクスを 2 週間アーカイブし、その後破棄します。

メトリクスの設定可能な統計情報を表示するには (コンソール)

  1. https://aws.amazon.com にアクセスし、[Sign In to the Console] を選択します。

  2. [Analytics] で、[Elasticsearch Service] を選択します。

  3. ナビゲーションペインにある、[My domains] で、Amazon ES ドメインを選択します。

  4. [Monitoring] タブを選択します。

  5. 表示するメトリクスを選択します。

  6. [Statistic] の一覧から統計を選択します。

    各メトリクスに関連する統計の一覧は、クラスターメトリクスの表を参照してください。統計のなかには、特定のメトリクスに関連のないものがあります。たとえば、SUM 統計メトリクスは、ノードには意味がありません。

  7. 更新グラフを選択します。

クラスターメトリクス

注記

メトリクスが Amazon Elasticsearch Service コンソールで使用できない場合にクラスターメトリクスを確認するには、Amazon CloudWatch を使用します。

AWS/ES 名前空間には、次のクラスターのメトリクスが含まれます。

メトリクス 説明
ClusterStatus.green

すべてのインデックスのシャードがクラスターのノードに割り当てられることを示します。

関連する統計: Minimum、Maximum

ClusterStatus.yellow すべてのインデックスのプライマリシャードがクラスターのノードに割り当てられていることを示しますが、少なくとも 1 つのインデックスのレプリカシャードは割り当てられていません。レプリカを割り当てることができる 2 番目のノードがないため、単一ノードクラスターがこのクラスター状態に常に初期化します。緑のクラスター状態を取得するためにノード数を増やすか、Elasticsearch API を使用してインデックスの number_of_replicas の設定を 0 に設定することができます。詳細については、「Amazon Elasticsearch Service ドメインの設定」および Elasticsearch ドキュメントの「Update Indices Settings」を参照してください。

関連する統計: Minimum、Maximum

ClusterStatus.red

少なくとも 1 つのインデックスのプライマリとレプリカの両方のシャードが、クラスターのノードに割り当てられないことを示します。この状態の一般的な原因は、クラスターの 1 つ以上のデータノードで空きストレージ領域が不足していることです。次に、空きストレージ領域が不足すると、影響を受けるデータノードやノードにサービスがレプリカシャードを分散できず、Red クラスターステータスで、すべての新しいインデックスは開始できません。復旧するには、EBS ベースのストレージを既存のデータノードに追加する、より大きなインスタンスタイプを使用する、インデックスを削除してスナップショットから復元する、のいずれかを実行する必要があります。詳細については、「Red Cluster Status」を参照してください。

関連する統計: Minimum、Maximum

Nodes

Amazon ES クラスターのノード数。

関連する統計: Minimum、Maximum、Average

SearchableDocuments

クラスター内のすべてのインデックスで検索可能なドキュメントの合計数。

関連する統計: Minimum、Maximum、Average

DeletedDocuments

クラスター内のすべてのインデックスで削除されたドキュメントの合計数。

関連する統計: Minimum、Maximum、Average

CPUUtilization

クラスター内のデータノードで使用する CPU リソースの最大パーセンテージ。

関連する統計: Maximum、Average

FreeStorageSpace

クラスター内のすべてのデータノードの空き容量 (メガバイト単位)。メトリクスが 0 に到達すると、Amazon ES は ClusterBlockException をスローします。復旧するには、インデックスを削除する、より大きなインスタンスを追加する、既存のインスタンスに EBS ベースのストレージを追加する、のいずれかを実行する必要があります。詳細については、「空きストレージ領域の不足からの復旧」を参照してください。

注記

FreeStorageSpace は、Elasticsearch _cluster/stats API が提供する値より常に低くなります。Amazon ES は、内部操作のために、各インスタンスの記憶域の一定割合を予約します。

関連する統計: Minimum

ClusterUsedSpace

クラスター用の合計使用領域 (メガバイト単位)。Amazon CloudWatch コンソールでこのメトリクスを表示できますが、Amazon ES コンソールでは表示できません。

関連する統計: Minimum、Maximum

ClusterIndexWritesBlocked

クラスターで、着信する書き込みリクエストを受け入れるか、ブロックするかを指定します。値 0 では、クラスターでリクエストを受け入れます。値 1 ではリクエストをブロックします。

クラスターでリクエストをブロックする原因としては、多くの要素が考えられます。代表的なものとしては、FreeStorageSpace が少なすぎる、JVMMemoryPressure が高すぎる、CPUUtilization が高すぎるなどがあります。この問題を軽減するには、ディスク容量の追加やクラスターのスケーリングを検討します。

関連する統計: Maximum

注記

このメトリクスは、Amazon CloudWatch コンソールでは表示できますが、Amazon ES コンソールでは表示できません。

JVMMemoryPressure

クラスター内のすべてのデータノードで使用する Java ヒープの最大パーセンテージ。

関連する統計: Maximum

AutomatedSnapshotFailure

クラスターの失敗した自動スナップショットの数。1 の値は、自動スナップショットが過去 36 時間、ドメイン用に取られなかったことを示します。

関連する統計: Minimum、Maximum

CPUCreditBalance

クラスター内の、データノードに使用できる残りの CPU クレジット。CPU クレジットは、フル CPU パフォーマンスを 1 分間実現します。詳細については、『Amazon EC2 開発者ガイド』の「CPU クレジット」を参照してください。このメトリクスは、t2.micro.elasticsearch、t2.small.elasticsearch、t2.medium.elasticsearch インスタンスタイプでのみ使用できます。

関連する統計: Minimum

KibanaHealthyNodes

Kibana のヘルスチェック。値 1 は正常な動作を示します。値 0 は Kibana がアクセス不可であることを示します。通常、Kibana の状態はクラスターの状態を反映しています。

関連する統計: Minimum

注記

このメトリクスは、Amazon CloudWatch コンソールでは表示できますが、Amazon ES コンソールでは表示できません。

次のスクリーンショットは、前述の表で説明してあるクラスターメトリクスを示します。

専用マスターノードメトリクス

AWS/ES 名前空間には専用マスターノードの次のメトリクスが含まれます。

メトリクス 説明
MasterCPUUtilization

専用マスターノードが使用する CPU リソースの最大パーセンテージ。このメトリクスが 60 パーセントに達する場合、インスタンスタイプのサイズを増やすことをお勧めします。

関連する統計: Average

MasterFreeStorageSpace

このメトリクスは関係ないため無視できます。 このサービスはデータノードとしてマスターノードを使用しません。

MasterJVMMemoryPressure

クラスター内のすべての専用マスターノードで使用する Java ヒープの最大パーセンテージ。このメトリクスが 85 パーセントに達する場合、より大規模なインスタンスタイプに移行することをお勧めします。

関連する統計: Maximum

MasterCPUCreditBalance

クラスター内の専用マスターノードで使用できる、残りの CPU クレジット。CPU クレジットは、フル CPU パフォーマンスを 1 分間実現します。詳細については、「CPU クレジット」 (Linux インスタンス用 Amazon EC2 ユーザーガイド) を参照してください。このメトリクスは、t2.micro.elasticsearch、t2.small.elasticsearch、t2.medium.elasticsearch インスタンスタイプでのみ使用できます。

関連する統計: Minimum

MasterReachableFromNode

MasterNotDiscovered 例外のヘルスチェック。値 1 は正常な動作を示します。値 0 は、/_cluster/health/ の動作が正常ではないことを示します。

動作が正常でないとは、マスターノードが停止しているか、到達不可能であることを意味します。通常、これらの原因はネットワーク接続または AWS 依存関係の問題です。

関連する統計: Minimum

注記

このメトリクスは、Amazon CloudWatch コンソールでは表示できますが、Amazon ES コンソールでは表示できません。

次のスクリーンショットは、前述の表で説明してある専用マスターノードのメトリクスを示しています。

EBS ボリュームメトリクス

AWS/ES 名前空間には、次の EBS ボリュームのメトリクスが含まれます。

メトリクス 説明
ReadLatency

EBS ボリュームでの読み取り操作のレイテンシー (秒単位)。

関連する統計: Minimum、Maximum、Average

WriteLatency

EBS ボリュームでの書き込み操作のレイテンシー (秒単位)。

関連する統計: Minimum、Maximum、Average

ReadThroughput

EBS ボリュームでの読み取り操作のスループット (バイト/秒単位)。

関連する統計: Minimum、Maximum、Average

WriteThroughput

EBS ボリュームでの書き込み操作のスループット (バイト/秒単位)。

関連する統計: Minimum、Maximum、Average

DiskQueueDepth

EBS ボリュームに対する保留中の入出力 (I/O) リクエストの数。

関連する統計: Minimum、Maximum、Average

ReadIOPS

EBS ボリュームでの読み取り操作の入出力 (I/O) 操作数 (1 秒あたり)。

関連する統計: Minimum、Maximum、Average

WriteIOPS

EBS ボリュームでの書き込み操作の入出力 (I/O) 操作数 (1 秒あたり)。

関連する統計: Minimum、Maximum、Average

次のスクリーンショットは、前述の表で説明してある EBS ボリュームメトリクスを示します。

AWS CloudTrail での Amazon Elasticsearch Service ドメインの監査

Amazon Elasticsearch Service (Amazon ES) は AWS アカウント、またはその代理によって行われた AWS API 呼び出しをすべて記録するサービスである AWS CloudTrail と統合されています。ログファイルは Amazon S3 バケットに渡されます。これは、バケットにログファイルを書き込む CloudTrail 許可を与えるバケットポリシーを使用して作成、設定したものです。CloudTrail は、Amazon Elasticsearch Service コンソールによって送信されたものを含むすべての Amazon ES 設定サービス API コールを取得します。

CloudTrail により収集された情報を使用して、検索ドメインのアクティビティを監視できます。Amazon ES に対してどのようなリクエストが行われたか (リクエストの実行元 IP アドレス、実行者、実行日時など) を判断できます。CloudTrail の詳細 (設定する方法や有効にする方法など) については、AWS CloudTrail User Guide を参照してください。CloudTrail の S3 バケットを作成し、設定する方法について詳細は、「CloudTrail のAmazon S3 バケットポリシー」を参照してください。

注記

CloudTrail は、Amazon Elasticsearch Service への設定関連の API 呼び出しのみ、イベントをログ記録します。データ関連の API は記録されません。

次の例では、Amazon ES のサンプルの CloudTrail ログを示します。

Copy
{ "Records": [ { "eventVersion": "1.03", "userIdentity": { "type": "Root", "principalId": "000000000000", "arn": "arn:aws:iam::000000000000:root", "accountId": "000000000000", "accessKeyId": "A*****************A" }, "eventTime": "2015-07-31T21:28:06Z", "eventSource": "es.amazonaws.com", "eventName": "CreateElasticsearchDomain", "awsRegion": "us-east-1", "sourceIPAddress": "Your IP", "userAgent": "es/test", "requestParameters": { "elasticsearchClusterConfig": {}, "snapshotOptions": { "automatedSnapshotStartHour": "0" }, "domainName": "your-domain-name", "eBSOptions": { "eBSEnabled": false } }, "responseElements": { "domainStatus": { "created": true, "processing": true, "aRN": "arn:aws:es:us-east-1:000000000000:domain/your-domain-name", "domainId": "000000000000/your-domain-name", "elasticsearchClusterConfig": { "zoneAwarenessEnabled": false, "instanceType": "m3.medium.elasticsearch", "dedicatedMasterEnabled": false, "instanceCount": 1 }, "deleted": false, "domainName": "your-domain-name", "domainVersion": "1.5", "accessPolicies": "", "advancedOptions": { "rest.action.multi.allow_explicit_index": "true" }, "snapshotOptions": { "automatedSnapshotStartHour": "0" }, "eBSOptions": { "eBSEnabled": false } } }, "requestID": "05dbfc84-37cb-11e5-a2cd-fbc77a4aae72", "eventID": "c21da94e-f5ed-41a4-8703-9a5f49e2ec85", "eventType": "AwsApiCall", "recipientAccountId": "000000000000" } ] }

CloudTrail 内の Amazon Elasticsearch Service 情報

AWS アカウントで CloudTrail のログ記録を有効にすると、Amazon Elasticsearch Service (Amazon ES) オペレーションに対する API 呼び出しがログファイルに記録されます。Amazon ES レコードは、他の AWS サービスレコードと一緒にログファイルに記録されます。CloudTrail は、期間とファイルサイズに基づいて、新しいファイルをいつ作成して書き込むかを決定します。

すべての Amazon ES 設定サービスのオペレーションが記録されます。たとえば、CreateElasticsearchDomainDescribeElasticsearchDomainUpdateElasticsearchDomainConfig を呼び出すと、CloudTrail ログファイルにエントリが生成されます。各ログエントリには、誰がリクエストを生成したかに関する情報が含まれます。ログ内のユーザー ID 情報は、リクエストが、ルートまたは IAM ユーザーの認証情報を使用して送信されたか、ロールまたはフェデレーションユーザーの一時的なセキュリティ認証情報を使用して送信されたか、あるいは別の AWS サービスによって送信されたかを確認するために役立ちます。詳細については、userIdentityCloudTrail Event Reference フィールドを参照してください。

必要であれば、バケット内にログファイルを無期限に保存するか、Amazon S3 ライフサイクルのルールを定義して、自動的にログファイルをアーカイブまたは削除することができます。デフォルトでは Amazon S3 のサーバー側の暗号化(SSE)を使用して、ログファイルが暗号化されます。ログファイルの配信時にすぐにアクションを実行する場合、新しいログファイルの配信時に CloudTrail により Amazon SNS 通知を発行することを選択できます。詳細については、「Configuring Amazon SNS Notifications for CloudTrail」を参照してください。また、複数の AWS リージョンと複数の AWS アカウントからの Amazon ES ログファイルを 1 つの Amazon S3 バケットに集約することもできます。詳細については、「Receiving CloudTrail Log Files From Multiple Regions」を参照してください。

Amazon Elasticsearch Service ログファイルエントリの概要

CloudTrail ログファイルには、複数の JSON 形式イベントで構成される 1 つ以上のログエントリを記録できます。ログエントリは任意の送信元からの単一のリクエストを表し、リクエストされたアクション、パラメータ、アクションの日時などに関する情報を含みます。ログエントリは、特定の順序で生成されるわけではなく、パブリック API 呼び出しのスタックトレース順に並んではいません。CloudTrail ログファイルは、Amazon ES 設定サービス API コールだけでなく、AWS アカウントに関するすべての AWS API コールイベントを含みます。ただし、ログファイルを読み取って、eventSource es.amazonaws.com 用にスキャンできます。eventName 要素には、呼びだされた設定サービスアクションの名前が含まれます。

Amazon Elasticsearch Service リクエストの署名

使用する言語の SDK が AWS に用意されている場合は、その SDK を使用して Amazon Elasticsearch Service (Amazon ES) リクエストを送信することをお勧めします。AWS SDK を使用する方が、Amazon ES API を直接使用するよりも、リクエストの署名プロセスがきわめてシンプルで、大幅な時間の節約になります。SDK は開発環境と統合できるため、関連するコマンドへのアクセスが簡単です。

Amazon ES 設定サービスのオペレーション を直接呼び出す場合は、自分のリクエストに署名する必要があります。設定サービスのリクエストには常に署名が必要です。アップロードおよび検索リクエストは、これらのサービスに対する匿名アクセスを設定していないかぎり、署名されている必要があります。

リクエストに署名するには、暗号化ハッシュ関数を使用してデジタル署名を計算します。この関数は入力に基づいてハッシュ値を返します。入力には、リクエストのテキスト、およびシークレットアクセスキーが含まれます。ハッシュ関数から返されるハッシュ値をリクエストに署名として含めます。署名は、リクエストの Authorization ヘッダーの一部です。

Amazon ES は、リクエストを受け取ると、リクエストの署名に使用されたものと同じハッシュ関数と入力を使用して署名を再計算します。再計算された署名とリクエスト内の署名が一致した場合、Amazon ES はリクエストを処理します。それ以外の場合、リクエストは拒否されます。

Amazon ES は、AWS 署名バージョン 4 を使用した認証をサポートします。詳細については、「Signature Version 4 Signing Process」を参照してください。

注記

Amazon ES は、署名して Logstash イベントをサービスにエクスポートするために、Logstash 出力プラグインを提供します。logstash-output-amazon-es plugin をダウンロードして、手順については README.md を参照してください。

Amazon Elasticsearch Service ドメインのタグ付け

Amazon ES タグを使用して、Amazon ES ドメインにメタデータを追加できます。AWS は、タグに意味論的意味を適用しません。タグは文字列として厳密に解釈されます。タグには、次の要件があります。

タグ要素 説明
タグキー タグキーは、必須のタグ名です。タグキーは添付される Amazon ES ドメインで一意にする必要があります。タグキーと値の基本的な制限の一覧については、「ユーザー定義タグの制限」を参照してください。
タグ値 タグ値は、タグの省略可能な文字列値です。タグ値は null を指定できます。また、タグセット内で一意である必要はありません。例えば、project/Trinity と cost-center/Trinity のタグセット内に 1 つのキーと値のペアを使用できます。タグキーと値の基本的な制限の一覧については、「ユーザー定義タグの制限」を参照してください。

各 Amazon ES ドメインには、その Amazon ES ドメインに割り当てられているすべてのタグを格納するタグセットがあります。AWS は Amazon ES ドメインにタグを自動的に設定しません。タグセットには、最大 50 個のタグを格納でき、空にすることもできます。Amazon ES ドメインに追加したタグのキーがそのリソースの既存のタグのキーと同じ場合、既存の値は新しい値によって上書きされます。

これらのタグを使用して、類似のリソースの費用をグループ化することで、コストを追跡できます。Amazon ES ドメインタグは、Amazon ES ドメインを定義して関連付ける名前と値のペアです。その名前はキーと呼ばれます。タグを使用して、Amazon ES ドメインに任意の情報を割り当てることができます。たとえば、タグキーを使用してカテゴリを定義し、タグ値をそのカテゴリのアイテムにすることができます。具体的には、「project」というタグキーと「Salix」というタグ値を定義して、Amazon ES ドメインが Salix プロジェクトに割り当てられていることを示すことができます。また、タグキーとして environment=test や environment=production などを使用して、Amazon ES ドメインがテスト用なのか本稼働用なのかを示すこともできます。Amazon ES ドメインに関連付けられているメタデータの追跡が簡単になるように、一貫した一連のタグキーを使用することをお勧めします。

タグを使用して AWS 請求書を整理し、自分のコスト構造を反映することもできます。そのためには、サインアップして、タグキー値が含まれた AWS アカウントの請求書を取得する必要があります。その後、同じタグキー値を持つリソースに従って請求情報を整理し、結合したリソースのコストを確認します。たとえば、複数の Amazon ES ドメインにキーと値のペアをタグ付けし、請求情報を整理して複数のサービスにおける各ドメインの合計コストを確認できます。詳細については、『AWS 請求情報とコスト管理』の「コスト配分タグの使用」を参照してください。

注記

タグは承認用にキャッシュに格納されます。そのため、Amazon ES ドメインに対するタグの追加や更新には数分かかることがあります。

タグの操作 (コンソール)

以下の手順を使用してリソースタグを作成します。

タグを作成するには (コンソール)

  1. https://aws.amazon.com にアクセスし、[Sign In to the Console] を選択します。

  2. [Analytics] で、[Elasticsearch Service] を選択します。

  3. ナビゲーションペインで、Amazon ES ドメインを選択します。

  4. ドメインダッシュボードで、[Manage tags] を選択します。

  5. [Key] 列に、タグキーを入力します。

  6. (オプション) [Value] 列にタグ値を入力します。

  7. [Submit] を選択します。

タグを削除するには (コンソール)

以下の手順を使用してリソースタグを削除します。

  1. https://aws.amazon.com にアクセスし、[Sign In to the Console] を選択します。

  2. [Analytics] で、[Elasticsearch Service] を選択します。

  3. ナビゲーションペインで、Amazon ES ドメインを選択します。

  4. ドメインダッシュボードで、[Manage tags] を選択します。

  5. 削除するタグの横にある [Remove] を選択します。

  6. [Submit] を選択します。

コンソールを使用したタグの操作の詳細については、『AWS Management Console Getting Started Guide』の「Working with Tag Editor」を参照してください。

タグの操作 (AWS CLI)

AWS CLI で --add-tags コマンドを使用して、リソースタグを作成することができます。

構文

add-tags --arn=<domain_arn> --tag-list Key=<key>,Value=<value>

パラメータ 説明
--arn タグが添付される Amazon ES ドメインの Amazon リソースネーム。
--tag-list スペースで区切られたキーと値のペアの以下の形式のセット: Key=<key>,Value=<value>

次の例は、logs ドメイン用に 2 つのタグを作成します。

Copy
aws es add-tags --arn arn:aws:es:us-east-1:379931976431:domain/logs --tag-list Key=service,Value=Elasticsearch Key=instances,Value=m3.2xlarge

remove-tags コマンドを使用して Amazon ES ドメインからタグを削除できます。

構文

remove-tags --arn=<domain_arn> --tag-keys Key=<key>,Value=<value>

パラメータ 説明
--arn タグが添付される Amazon ES ドメインの Amazon リソースネーム (ARN)。
--tag-keys Amazon ES ドメインから削除するスペース区切りのタグ値のセット。

次の例は、logs ドメインから前述の例で作成した 2 つのタグを削除します。

Copy
aws es remove-tags --arn arn:aws:es:us-east-1:379931976431:domain/logs --tag-keys service instances

list-tags コマンドで Amazon ES ドメインの既存のタグを表示できます。

構文

list-tags --arn=<domain_arn>

パラメータ 説明
--arn タグが添付される Amazon ES ドメインの Amazon リソースネーム (ARN)。

次の例は、ログドメイン: のすべてのリソースタグをリスト表示します。

Copy
aws es list-tags --arn arn:aws:es:us-east-1:379931976431:domain/logs

タグの操作 (AWS SDK)

AWS SDK では (Android および iOS SDK を除く)、AddTagsListTags および RemoveTags の各オペレーションも含めて、Amazon ES 設定 API リファレンスで定義されたすべてのアクションがサポートされています。AWS SDK のインストールと使用の詳細については、「AWS Software Development Kits」を参照してください。