Alibaba Cloud Elasticsearch クラスターの作成時には、ビジネス要件を満たすために、異なるノードタイプのスペックとストレージを設定する必要があります。Elasticsearch クラスターは、データノード、Kibana ノード、専用マスターノード、ウォームノード、フローズンノード、調整ノードで構成され、それぞれが異なる役割を担います。
データノード
データノードは、インデックスデータを保存し、インデックス作成、検索、アグリゲーションを実行します。データノードは、CPU、メモリ、I/O に対する要件が高くなります。リソースが不足している場合は、クラスターに新しいデータノードを追加することを推奨します。
-
クラスターに専用マスターノードがある場合、データノードはデータノードとしてのみ機能します。
-
クラスターに専用マスターノードがない場合、データノードはデータノードと専用マスターノードの両方として機能します。
-
Alibaba Cloud Elasticsearch クラスターは、2 つのコントロールプレーンアーキテクチャのいずれかを使用します。基本コントロールプレーン (v2) またはクラウドネイティブコントロールプレーン (v3) です。v2 アーキテクチャでは、専用マスターノードがないクラスターのスケールアップを行うと、クラスターの再起動がトリガーされます。クラスター全体の負荷が低く、インデックスにレプリカシャードがある場合、再起動中もクラスターは利用可能な状態を維持できます。ただし、書き込みやクエリの負荷が高い特定のシナリオでは、再起動中にアクセスタイムアウトが発生する可能性があります。そのため、これらの操作はオフピーク時間帯に実行することを推奨します。
|
パラメータ |
説明 |
|
データノードのスペック |
テスト環境では 2 vCPU と 4 GiB メモリ のデータノードを使用し、本番環境ではより高いスペックのデータノードを使用することを推奨します。 |
|
データノードのディスクタイプ |
説明
|
|
ESSD パフォーマンスレベル |
データノードのディスクタイプパラメータを ESSD に設定した場合、このパラメータを設定する必要があります。 |
|
データノードのディスク暗号化 |
|
|
データノードあたりのストレージ容量 |
各データノードのストレージ容量は、ディスクタイプによって異なります。単位：GiB。
説明
2,560 GiB を超えるストレージ容量を持つ Ultra Disk のサイズを変更する場合、ディスクがディスクアレイまたは RAID 0 で実行されるように設計されているため、ブルーグリーン変更のみ実行できます。 |
|
データノード数 |
購入するノード数は、ゾーン数の倍数である必要があります。 重要
データノードが 2 つのみのクラスターは、スプリットブレインのリスクが高く、安定性が低くなります。V6.X や V5.X などの以前のバージョンのクラスターにデータノードが 2 つしかない場合、ノードの再起動が必要な際に専用マスターノードが選択されず、クラスターがサービスを提供できなくなる可能性があります。そのため、ビジネス要件に基づいてこのパラメータを設定する必要があります。 |
Kibana ノード
-
Kibana ノードのパラメータは「はい」しか選択できません。
-
1 vCPU と 2 GiB メモリの Kibana ノードは無料です。ただし、1 vCPU と 2 GiB メモリの Kibana ノードはテスト目的でのみ使用することを推奨します。
-
クラスターのパフォーマンスと安定性への影響を考慮し、2 vCPU と 4 GiB メモリ以上のスペックの Kibana ノードを購入することを推奨します。
専用マスターノード
専用マスターノードを使用して、インデックスの作成、インデックスの削除、ノードの追跡、シャードの割り当てなど、クラスターの操作を実行できます。専用マスターノードの安定性は、クラスターの健全性にとって重要です。デフォルトでは、クラスター内の各ノードが専用マスターノードとして使用される可能性があります。インデックス作成、検索、クエリなどの操作には、大量の CPU、メモリ、I/O リソースが必要です。クラスターの安定性を確保するため、専用マスターノードを購入して、専用マスターノードとデータノードを分離することを推奨します。
-
クラスター内の専用マスターノードが無料の場合、クラスターの設定をアップグレードすると、これらのノードに対して課金されます。
-
専用マスターノードを含まず、旧アーキテクチャ (V2) にデプロイされているクラスターでブルーグリーン変更を実行する場合、次回クラスターに変更を加える際にデータノードが再起動されます。そのため、専用マスターノードを購入することを推奨します。
|
パラメータ |
説明 |
|
専用マスターノード |
説明
|
|
専用マスターノードのスペック |
サポートされているスペックは、購入ページで確認できます。 |
|
専用マスターノードのディスクタイプ |
サポートされているディスクタイプは、購入ページで確認できます。 |
|
専用マスターノードのストレージ容量 |
このパラメータの値は 20 GiB のみ設定可能です。 |
|
専用マスターノード数 |
このパラメータの値は 3 のみ設定可能です。 |
ウォームノード
ワークロードに以下の両方のタイプのデータが含まれる場合は、高性能なホットノードと大容量のウォームノードを組み合わせた Hot-Warm アーキテクチャを使用することを推奨します。
-
ホットデータ：頻繁にクエリされ、書き込み負荷が高く、レイテンシに敏感なインデックス。
-
ウォームデータ：クエリ頻度が低く、ほとんど読み取り専用または書き込みがほとんどないインデックス。これらは通常、履歴データです。
ホットデータとウォームデータを異なるノードタイプにデプロイすることで、ウォームデータによるリソース競合がホットデータのパフォーマンスに影響を与えることを防ぎ、ストレージコストを大幅に削減し、クラスター全体の効率と安定性を向上させることができます。
詳細については、「Elasticsearch 5.x における「Hot-Warm」アーキテクチャ」をご参照ください。
専用マスターノードが購入されている場合、ウォームノードはウォームノードとしてのみ使用されます。
専用マスターノードが購入されていない場合、ウォームノードは専用マスターノードとしても使用されます。
|
パラメータ |
説明 |
|
ウォームノード |
購入したウォームノードを無効にすることができます。ウォームノードを無効にする際にクラスターがスタックした場合は、「ウォームノードを無効にした後にクラスターがスタックした場合の対処方法」をご参照ください。 |
|
ウォームノードのスペック |
サポートされているスペックについては、購入ページをご参照ください。 高い I/O と大容量ストレージを要するシナリオでは、
説明
|
|
ウォームノードのディスクタイプ |
Ultra Disk および ESSD がサポートされています。 |
|
ウォームノードのディスク暗号化 |
説明
|
|
ウォームノードのストレージ容量 |
このパラメータの最小値は 500 です。単位：GiB。 |
|
ウォームノード数 |
購入するノード数は、ゾーン数の倍数である必要があります。 |
ウォームノードを購入すると、システムは次の表に示すように、ノード起動パラメータに -Enode.attr.box_type パラメータを追加します。
|
ノードタイプ |
起動パラメータ |
|
データノード |
-Enode.attr.box_type=hot |
|
ウォームノード |
-Enode.attr.box_type=warm |
フローズンノード
フローズンノードは、検索可能なスナップショット機能のコンピューティングレイヤーです。インデックスメタデータを維持し、ローカル共有キャッシュを管理し、クエリに応じて必要なデータブロックを Object Storage Service (OSS) からオンデマンドで取得します。履歴データを Alibaba Cloud OSS にスナップショットとして保存することで、フローズンノードは検索機能を維持しながら、ストレージコストを最大 90% 削減できます。
-
フローズンノードは、V8.17.0 以降のインスタンスでのみサポートされます。フローズンノードを有効にした後は、無効にすることはできません。無効にするには、テクニカルサポートにお問い合わせください。
-
フローズンノードは、データが OSS に保存されるため、大容量のローカルディスクを必要としません。キャッシュヒット率を向上させるために、十分なメモリを設定することを推奨します。
-
詳細な例については、「検索可能なスナップショット」をご参照ください。
|
パラメータ |
説明 |
|
フローズンノード |
V8.17.0 の新しいインスタンスを購入する際、インスタンススペックセクションでチェックボックスを選択することで、この機能を有効にできます。 |
|
フローズンノードのスペック |
4 vCPU と 16 GiB メモリ以上のインスタンスタイプを推奨します。フローズンノードのメモリは、インデックスメタデータを維持し、共有キャッシュを管理します。十分なメモリを確保することで、キャッシュヒット率を向上させることができます。サポートされているスペックについては、購入ページをご参照ください。 |
|
フローズンノードのディスクタイプ |
Ultra Disk および ESSD がサポートされています。ローカルディスクは共有キャッシュとしてのみ機能し、データは OSS に永続化されます。 |
|
フローズンノードのストレージ容量 |
500 GiB 以上を推奨します。ローカルディスク容量は共有キャッシュとして機能します。キャッシュは、ノードの総ディスク容量の 90% または総容量から 100 GiB を引いた値のいずれか小さい方を使用します。Least Recently Used (LRU) ポリシーにより、コールドデータブロックが削除されます。ディスク容量が大きいほど、キャッシュヒット率が高くなります。 |
|
フローズンノード数 |
購入するノード数は、アベイラビリティゾーン数の倍数である必要があります。 |
フローズンノードを購入すると、システムは次の表に示すように、ノード起動パラメータに -Enode.attr.box_type パラメータを追加します。
|
ノードタイプ |
起動パラメータ |
|
データノード |
-Enode.attr.box_type=hot |
|
ウォームノード |
-Enode.attr.box_type=warm |
|
フローズンノード |
-Enode.attr.box_type=frozen |
調整ノード
調整ノードを購入して、データノードの CPU オーバーヘッドを分担できます。これにより、クラスターの処理パフォーマンスとサービスの安定性が向上します。大量のアグリゲーションクエリを必要とするサービスなど、CPU 集約型のサービスでは、調整ノードを購入することを推奨します。
|
パラメータ |
説明 |
|
調整ノード |
クラウドネイティブコントロールアーキテクチャにデプロイされているクラスター (V7.16 以降のクラスター) で購入した調整ノードをリリースすることはできません。クラスター内の調整ノードをリリースできるかどうかは、購入ページで確認できます。 |
|
調整ノードのスペック |
サポートされているスペックは、購入ページで確認できます。 |
|
調整ノードのディスクタイプ |
このパラメータは Ultra Disk のみ設定可能です。 |
|
調整ノードのストレージ容量 |
このパラメータの値は 20 GiB のみ設定可能です。 |
|
調整ノード数 |
購入するノード数は、ゾーン数の倍数である必要があります。 |
参考資料
-
Elasticsearch クラスターの購入方法の詳細については、「Alibaba Cloud Elasticsearch クラスターの作成」をご参照ください。
-
ノードの詳細については、「Node | Elasticsearch Guide」をご参照ください。
-
ノードスペックの料金の詳細については、価格をご参照ください。
よくある質問
ウォームノードを無効にした後にクラスターがスタックする
1. box_type ノード割り当てルールの確認
-
既存のすべてのインデックスの
index.routing.allocation.require.box_type設定をクエリで確認します。GET */_settings/index.routing.allocation.require.box_type出力が
{"index.routing.allocation.require.box_type": "warm"}の場合、インデックスはbox_type=warmのノードに割り当てられることを意味します。 -
インデックステンプレートに
box_type割り当てルールが設定されているかどうかを確認します。すべてのインデックステンプレートをクエリして、
box_type割り当てルールが設定されているかどうかを確認します。テンプレートが"index.routing.allocation.require.box_type": "warm"を返す場合、すべての新しいインデックスはデフォルトでウォームノードに割り当てられます。新しいインデックスが作成されると、テンプレートから設定を継承します。この値がテンプレートに設定されている場合、後続のすべてのインデックスは自動的にこのルールを適用します。
-
GET _ilm/policy?filter_path=*.policy.phases.warm.actions.allocate.require.box_typeすべてのインデックスライフサイクル管理 (ILM) ポリシーのウォームフェーズのノード割り当て設定をクエリで確認します。
インデックスがウォームノードに割り当てられている場合、スケールダウン操作によってウォームノードをシャットダウンすると、クラスターの変更が [変更のスタック] 状態になります。
2. ソリューション
-
ポリシーから
box_type設定を削除する# まず、ILM を停止します。 POST _ilm/stop # 特定の ILM ポリシーを確認します。 GET _ilm/policy/your_policy_name # ILM ポリシーを更新し、ウォームフェーズから box_type 設定を削除します。 PUT _ilm/policy/your_policy_name { "policy": { "phases": { "warm": { "actions": { "allocate": { "require": { "box_type": null # この設定を削除します。 } } } }, "hot": { "actions": { "allocate": { "require": { "box_type": null # 存在する場合は、これも削除します。 } } } } } } } # allocate の下の require フィールドが空の場合は、allocate アクション全体を削除します。 # または、レプリカ数など、他の必要な割り当てルールのみを保持します。 -
インデックステンプレートから
box_type設定を削除する# 特定のテンプレート名を確認します。 GET _template/?filter_path=*.settings.index.routing.allocation.require.box_type # テンプレートを更新し、box_type 設定を削除します。 PUT _template/your_template_name { "settings": { "index.routing.allocation.require.box_type": null } } # または、box_type フィールドなしで完全なテンプレート定義を再送信します。 -
インデックスから
box_type設定を削除する# 特定のインデックスの box_type 設定を削除します。 PUT /your_index_name/_settings { "index.routing.allocation.require.box_type": null } # すべてのインデックスの設定を一括で削除します。 PUT */_settings { "index.routing.allocation.require.box_type": null }