ES|QLの使用 - クラスター間でのES|QLの使用（Using ES|QL across clusters）

クラスター間でのES|QLの使用
前提条件
セキュリティモデル
- TLS証明書認証
- APIキー認証
リモートクラスターの設定
複数のクラスターにわたるクエリ
- Esql
- Esql
クラスター間でのエンリッチ
- Esql
- Esql
コーディネーターモードでのエンリッチ
- Esql
- Esql
複数のエンリッチコマンド
- Esql
ES|QLクエリからクラスターまたはインデックスを除外する
- Esql
- Esql
オプションのリモートクラスター
アップグレード中のクラスター間クエリ

クラスター間でのES|QLの使用

ES|QLのクラスター間検索は技術プレビュー中であり、将来のリリースで変更または削除される可能性があります。Elasticは問題を修正するために取り組みますが、技術プレビューの機能は公式GA機能のサポートSLAの対象ではありません。

ES|QLを使用すると、複数のクラスターにわたって単一のクエリを実行できます。

前提条件

クラスター間検索にはリモートクラスターが必要です。Elasticsearch Serviceでリモートクラスターを設定するには、Elasticsearch Serviceでのリモートクラスターの設定を参照してください。自分のハードウェアでElasticsearchを実行している場合は、リモートクラスターを参照してください。
リモートクラスターの設定がクラスター間検索をサポートしていることを確認するには、サポートされているクラスター間検索の設定を参照してください。
クラスター間検索の完全な機能を利用するには、ローカルクラスターとリモートクラスターが同じサブスクリプションレベルである必要があります。
ローカルコーディネーティングノードは、remote_cluster_clientノードロールを持っている必要があります。
スニッフモードを使用する場合、ローカルコーディネーティングノードはリモートクラスターのシードノードおよびゲートウェイノードに接続できる必要があります。コーディネーティングノードとして機能できるゲートウェイノードの使用をお勧めします。シードノードはこれらのゲートウェイノードのサブセットである可能性があります。
プロキシモードを使用する場合、ローカルコーディネーティングノードは設定されたproxy_addressに接続できる必要があります。このアドレスのプロキシは、リモートクラスターのゲートウェイおよびコーディネーティングノードへの接続をルーティングできる必要があります。
クラスター間検索には、ローカルクラスターとリモートクラスターで異なるセキュリティ権限が必要です。クラスター間検索のための権限の設定およびリモートクラスターを参照してください。

セキュリティモデル

Elasticsearchは、クラスター間検索（CCS）用に2つのセキュリティモデルをサポートしています：

クラスターに接続するために使用されているセキュリティモデルを確認するには、GET _remote/infoを実行します。APIキー認証メソッドを使用している場合、応答に"cluster_credentials"キーが表示されます。

TLS証明書認証

TLS証明書認証は、相互TLSを使用してリモートクラスターを保護します。これは、単一の管理者が両方のクラスターを完全に制御している場合に好まれるモデルです。一般的に、役割とその権限は両方のクラスターで同一であることをお勧めします。

前提条件および詳細な設定手順については、TLS証明書認証を参照してください。

APIキー認証

以下の情報は、APIキーに基づくセキュリティモデルを使用してクラスター間でES|QLを使用することに関するものです。そのページの完全な設定手順に従う必要があります。このページには、ES|QLに特有の追加情報のみが含まれています。

APIキーに基づくクラスター間検索（CCS）は、クラスター間の許可されたアクションに対するより詳細な制御を可能にします。これは、異なるクラスターに異なる管理者がいる場合や、誰がどのデータにアクセスできるかをより制御したい場合に好まれるモデルです。このモデルでは、クラスター管理者はクラスターとユーザーに与えられるアクセスを明示的に定義する必要があります。

次の手順を実行する必要があります：

クラスター間APIキーの作成 APIを使用してリモートクラスターでAPIキーを作成するか、Kibana APIキーUIを使用します。
ローカルクラスターの設定の手順の一部として、APIキーをローカルクラスターのキーストアに追加します。ローカルクラスターからのすべてのクラスター間リクエストは、APIキーの権限に制約されます。

APIキーに基づくセキュリティモデルでES|QLを使用するには、従来のクエリDSLベースの検索を使用する場合には必要ないかもしれない追加の権限が必要です。以下の例のAPI呼び出しは、APIキーに基づくセキュリティモデルを使用してES|QLを使用してリモートインデックスをクエリできる役割を作成します。最終的な権限であるremote_clusterは、リモートエンリッチ操作を許可するために必要です。

Python

resp = client.security.put_role(
   name="remote1",
   cluster=[
   "cross_cluster_search"
   ],
   indices=[
   {
   "names": [
   ""
   ],
   "privileges": [
   "read"
   ]
   }
   ],
   remote_indices=[
   {
   "names": [
   "logs-*"
   ],
   "privileges": [
   "read",
   "read_cross_cluster"
   ],
   "clusters": [
   "my_remote_cluster"
   ]
   }
   ],
   remote_cluster=[
   {
   "privileges": [
   "monitor_enrich"
   ],
   "clusters": [
   "my_remote_cluster"
   ]
   }
   ],
)
print(resp)

Js

const response = await client.security.putRole({
  name: "remote1",
  cluster: ["cross_cluster_search"],
  indices: [
   {
   names: [""],
   privileges: ["read"],
   },
  ],
  remote_indices: [
   {
   names: ["logs-*"],
   privileges: ["read", "read_cross_cluster"],
   clusters: ["my_remote_cluster"],
   },
  ],
  remote_cluster: [
   {
   privileges: ["monitor_enrich"],
   clusters: ["my_remote_cluster"],
   },
  ],
});
console.log(response);

コンソール

POST /_security/role/remote1
{
  "cluster": ["cross_cluster_search"],
  "indices": [
   {
   "names" : [""],
   "privileges": ["read"]
   }
  ],
  "remote_indices": [
   {
   "names": [ "logs-*" ],
   "privileges": [ "read","read_cross_cluster" ],
   "clusters" : ["my_remote_cluster"]
   }
  ],
   "remote_cluster": [
   {
   "privileges": [
   "monitor_enrich"
   ],
   "clusters": [
   "my_remote_cluster"
   ]
   }
   ]
}


	ローカルクラスターには`cross_cluster_search`クラスター権限が必要です。
	通常、ユーザーはローカルおよびリモートインデックスの両方を読み取る権限を持っています。ただし、役割がリモートクラスターのみを検索することを意図している場合、ローカルクラスターには`read`権限が必要です。ローカルクラスターへの読み取りアクセスを提供し、ローカルクラスター内のインデックスを読み取ることを禁止するには、`names`フィールドを空の文字列にすることができます。
	リモートクラスターへの読み取りアクセスが許可されているインデックス。設定されたクラスター間APIキーもこのインデックスの読み取りを許可する必要があります。
	APIキーに基づくセキュリティモデルでクラスター間でES/QLを使用する場合、`read_cross_cluster`権限は常に必要です。
	これらの権限が適用されるリモートクラスター。このリモートクラスターは、クラスター間APIキーで構成され、リモートインデックスをクエリする前にリモートクラスターに接続されている必要があります。リモートクラスター情報 APIを使用して接続を確認します。
	リモートエンリッチを許可するために必要です。これがないと、ユーザーはリモートクラスターの`.enrich`インデックスから読み取ることができません。`remote_cluster`セキュリティ権限は、バージョン8.15.0で導入されました。

その後、上記で作成した権限を持つユーザーまたはAPIキーが必要です。以下の例のAPI呼び出しは、remote1役割を持つユーザーを作成します。

Python

resp = client.security.put_user(
   username="remote_user",
   password="<PASSWORD>",
   roles=[
   "remote1"
   ],
)
print(resp)

Js

const response = await client.security.putUser({
  username: "remote_user",
  password: "<PASSWORD>",
  roles: ["remote1"],
});
console.log(response);

コンソール

POST /_security/user/remote_user
{
  "password" : "<PASSWORD>",
  "roles" : [ "remote1" ]
}

ローカルクラスターからのすべてのクラスター間リクエストは、リモートクラスターの管理者によって制御されるクラスター間APIキーの権限に制約されることを忘れないでください。

バージョン8.15.0以前に作成されたクラスター間APIキーは、ES|QLとENRICHに必要な新しい権限を追加するために置き換えるか更新する必要があります。

リモートクラスターの設定

セキュリティモデルが設定されると、リモートクラスターを追加できます。

次のクラスター更新設定 APIリクエストは、3つのリモートクラスターを追加します：cluster_one、cluster_two、cluster_three。

Python

resp = client.cluster.put_settings(
   persistent={
   "cluster": {
   "remote": {
   "cluster_one": {
   "seeds": [
   "35.238.149.1:9300"
   ],
   "skip_unavailable": True
   },
   "cluster_two": {
   "seeds": [
   "35.238.149.2:9300"
   ],
   "skip_unavailable": False
   },
   "cluster_three": {
   "seeds": [
   "35.238.149.3:9300"
   ]
   }
   }
   }
   },
)
print(resp)

Ruby

response = client.cluster.put_settings(
  body: {
   persistent: {
   cluster: {
   remote: {
   cluster_one: {
   seeds: [
   '35.238.149.1:9300'
   ],
   skip_unavailable: true
   },
   cluster_two: {
   seeds: [
   '35.238.149.2:9300'
   ],
   skip_unavailable: false
   },
   cluster_three: {
   seeds: [
   '35.238.149.3:9300'
   ]
   }
   }
   }
   }
  }
)
puts response

Js

const response = await client.cluster.putSettings({
  persistent: {
   cluster: {
   remote: {
   cluster_one: {
   seeds: ["35.238.149.1:9300"],
   skip_unavailable: true,
   },
   cluster_two: {
   seeds: ["35.238.149.2:9300"],
   skip_unavailable: false,
   },
   cluster_three: {
   seeds: ["35.238.149.3:9300"],
   },
   },
   },
  },
});
console.log(response);

コンソール

PUT _cluster/settings
{
  "persistent": {
   "cluster": {
   "remote": {
   "cluster_one": {
   "seeds": [
   "35.238.149.1:9300"
   ],
   "skip_unavailable": true
   },
   "cluster_two": {
   "seeds": [
   "35.238.149.2:9300"
   ],
   "skip_unavailable": false
   },
   "cluster_three": {
   "seeds": [
   "35.238.149.3:9300"
   ]
   }
   }
   }
  }
}


	`cluster_three`で`skip_unavailable`が設定されていなかったため、`false`のデフォルトを使用します。詳細については、オプションのリモートクラスターのセクションを参照してください。

複数のクラスターにわたるクエリ


#### Esql
``````esql
FROM cluster_one:my-index-000001
| LIMIT 10
`

同様に、このES|QLリクエストは、3つのクラスターからmy-index-000001インデックスをクエリします：

ローカル（「クエリ中」）クラスター
2つのリモートクラスター、cluster_oneとcluster_two

Esql

FROM my-index-000001,cluster_one:my-index-000001,cluster_two:my-index-000001
| LIMIT 10

同様に、このES|QLリクエストは、すべてのリモートクラスター（cluster_one、cluster_two、およびcluster_three）からmy-index-000001インデックスをクエリします：

Esql

FROM *:my-index-000001
| LIMIT 10

クラスター間でのエンリッチ

ES|QLのクラスター間でのエンリッチは、ローカルエンリッチと同様に機能します。エンリッチポリシーとそのエンリッチインデックスがすべてのクラスターで一貫している場合、リモートクラスターがない場合と同様にエンリッチコマンドを記述するだけです。このデフォルトモードでは、ES|QLはローカルクラスターまたはリモートクラスターのいずれかでエンリッチコマンドを実行でき、計算やクラスター間データ転送を最小限に抑えることを目指します。ポリシーがローカルクラスターとリモートクラスターの両方で一貫したデータを持っていることを確認することは、ES|QLが一貫したクエリ結果を生成するために重要です。

APIキーに基づくセキュリティモデルを使用したES|QLのクラスター間でのエンリッチは、バージョン8.15.0で導入されました。バージョン8.15.0以前に作成されたクラスター間APIキーは、新しい必要な権限を使用するために置き換えるか更新する必要があります。APIキー認証セクションの例を参照してください。

次の例では、cluster_oneリモートクラスターでhostsポリシーを使用してエンリッチを実行できます。

Esql

FROM my-index-000001,cluster_one:my-index-000001
| ENRICH hosts ON ip
| LIMIT 10

リモートクラスターに対してのみES|QLクエリを使用したエンリッチもローカルクラスターで発生する可能性があります。これは、以下のクエリがローカルクラスターにもhostsエンリッチポリシーが存在する必要があることを意味します。

Esql

FROM cluster_one:my-index-000001,cluster_two:my-index-000001
| LIMIT 10
| ENRICH hosts ON ip

コーディネーターモードでのエンリッチ

ES|QLは、ES|QLがローカルクラスターでエンリッチコマンドを実行するように強制する_coordinatorモードを提供します。このモードは、リモートクラスターでエンリッチポリシーが利用できない場合や、クラスター間でエンリッチインデックスの一貫性を維持することが困難な場合に使用する必要があります。

Esql

FROM my-index-000001,cluster_one:my-index-000001
| ENRICH _coordinator:hosts ON ip
| SORT host_name
| LIMIT 10


### リモートモードでのエンリッチ
ES|QLは、ターゲットインデックスが存在する各リモートクラスターでエンリッチコマンドを独立して実行するようにES|QLを強制する`````_remote`````モードも提供します。このモードは、ターゲット（メイン）インデックスがこれらのホストからのログイベントを含む各地域のホストの詳細情報など、各クラスターで異なるエンリッチデータを管理するのに便利です。  
以下の例では、`````hosts`````エンリッチポリシーがすべてのリモートクラスターに存在する必要があります：`````querying`````クラスター（ローカルインデックスが含まれているため）、リモートクラスター`````cluster_one`````、および`````cluster_two`````。
#### Esql
``````esql
FROM my-index-000001,cluster_one:my-index-000001,cluster_two:my-index-000001
| ENRICH _remote:hosts ON ip
| SORT host_name
| LIMIT 10
`

statsコマンドの後に_remoteエンリッチを実行することはできません。以下の例はエラーになります：

Esql

FROM my-index-000001,cluster_one:my-index-000001,cluster_two:my-index-000001
| STATS COUNT(*) BY ip
| ENRICH _remote:hosts ON ip
| SORT host_name
| LIMIT 10

複数のエンリッチコマンド

同じクエリに異なるモードで複数のエンリッチコマンドを含めることができます。ES|QLは、それに応じて実行しようとします。たとえば、このクエリは、最初に任意のクラスターでhostsポリシーを使用してエンリッチを実行し、その後ローカルクラスターでvendorsポリシーを使用してエンリッチを実行します。

Esql

FROM my-index-000001,cluster_one:my-index-000001,cluster_two:my-index-000001
| ENRICH hosts ON ip
| ENRICH _coordinator:vendors ON os
| LIMIT 10


#### Esql
``````esql
FROM my-index-000001,cluster_one:my-index-000001,cluster_two:my-index-000001
| ENRICH _coordinator:hosts ON ip
| ENRICH _remote:vendors ON os
| LIMIT 10
`

ES|QLクエリからクラスターまたはインデックスを除外する

クラスター全体を除外するには、FROMコマンドでクラスターエイリアスの前にマイナス記号を付けます。たとえば：-my_cluster:*:

Esql

FROM my-index-000001,cluster*:my-index-000001,-cluster_three:*
| LIMIT 10

特定のリモートインデックスを除外するには、FROMコマンドでインデックスの前にマイナス記号を付けます。たとえばmy_cluster:-my_index:

Esql

FROM my-index-000001,cluster*:my-index-*,cluster_three:-my-index-000001
| LIMIT 10

オプションのリモートクラスター

ES|QLのクラスター間検索は現在、skip_unavailable設定を尊重していません。その結果、リクエストで指定されたリモートクラスターが利用できないか失敗した場合、ES|QLクエリのクラスター間検索は設定に関係なく失敗します。

私たちは、ES|QLのクラスター間検索の動作を他のクラスター間検索APIと整合させるために積極的に取り組んでいます。これには、応答内の各クラスターに対する詳細な実行情報（実行時間、選択されたターゲットインデックス、シャードなど）を提供することが含まれます。

アップグレード中のクラスター間クエリ

ローカルクラスターでローリングアップグレードを実行している間でも、リモートクラスターを検索することができます。ただし、ローカルコーディネーティングノードの「アップグレード元」と「アップグレード先」バージョンは、リモートクラスターのゲートウェイノードと互換性がある必要があります。

アップグレードの期間を超えて同じクラスター内で複数のバージョンのElasticsearchを実行することはサポートされていません。

アップグレードに関する詳細については、Elasticsearchのアップグレードを参照してください。