Agent Engine エディションの日常的な運用には、インスタンスモニタリング、Collection 権限、Collection のバックアップと復元が含まれます。
インスタンスモニタリング
インスタンスの実行時メトリクスを確認するには、コンソールでインスタンスの製品ページに移動し、左側メニューで [Monitoring and Logging] > [Cluster Monitoring] を選択します。ビジネスのサービスレベル目標 (SLO) と負荷テストのベースラインに基づいてアラートしきい値を設定してください。コンソールに表示されるメトリクス名とアラートのエントリポイントを使用してください。
[Cluster Monitoring] ページは、メトリクスをカテゴリ別にグループ化しますが、インデックスノードやクエリノードなどのノードロール別にはグループ化しません。2 つのノードタイプを個別に観測するには、[Resource Type] を特定のノードに設定し、ノード名でフィルタリングしてください。インデックスノード名には -index- が含まれます。クエリノード名には -search- が含まれますが、コンソールのメトリクス名では Query と Search の両方が使用されます。Agent Engine エディションにはウォームノードがないため、インデックスノードとクエリノードのみを監視する必要があります。
次の表は、一般的な観測対象をコンソールメトリクスにマッピングしたものです (ディメンション別にグループ化)。クラスターレベルのメトリクスから確認を始め、ノードレベルのメトリクスへとドリルダウンし、スレッドプールのリジェクトをキャパシティのシグナルとして扱ってください。
観測対象 | コンソールメトリクス | ディメンション |
書き込みスループット | Cluster Write QPS | クラスターレベル |
書き込みレイテンシ | Average Cluster Write Latency | クラスターレベル |
クエリスループット | Cluster Query QPS | クラスターレベル |
クエリレイテンシ | Average Cluster Search Latency | クラスターレベル |
CPU 使用率 | Node CPU Utilization_ES Business, Node CPU Utilization_Total | ノードレベル |
ヒープメモリ使用率 | Node Heap Memory Utilization_ES Business | ノードレベル |
リジェクト | Number of Tasks Rejected by the Write Thread Pool, Number of Requests Rejected by the Query Thread Pool | スレッドプールレベル |
Collection 権限
ロールで構成するインデックス権限とクラスター権限が、Collections、Slices、Backings へのアクセスを制御します。
Collection と Backing の認可スコープ
ロールを構成する際は、通常、Collection 名と、それに対応する Backing の両方に対するアクセス権限を付与する必要があります。ロールで次の 2 つの値を構成し、<collection> を Collection の名前に置き換えてください。
<collection>
.sc-<collection>-*たとえば、Collection 名が knowledge-chunks の場合、ロールに knowledge-chunks と .sc-knowledge-chunks-* を構成できます。Collection 名のみを構成して Backing パターンを省略すると、単一ドキュメントの読み書き、MGet、明示的なリフレッシュ、_update_by_query、_delete_by_query で HTTP 403 が返される場合があります。このエラーを解決するには、該当する Backing パターンをロールに追加してください。
権限を付与する前に、プレフィックスの重複がないか確認してください。.sc-knowledge-chunks-* は knowledge-chunks-private の Backing にも一致するため、このパターンだけでは Collection 間の厳密な分離を保証できません。.sc-* はさらに広いスコープを持つため、デフォルトの最小権限構成として使用してはいけません。
操作ごとに必要な権限
次の表に、各操作に必要な権限を示します。
操作 | 必要な権限 |
Collection または Slice の作成、更新、削除 | Collection に対する |
Backing の事前作成 | Collection に対する |
| Collection に対する |
Copy Slice の開始またはキャンセル | Collection に対する |
Branch Slice (Beta) の作成 | Collection に対する |
Collection エイリアスの作成または変更 | Collection 名とエイリアス名の両方に対する |
Collection の取得、Slice のクエリまたは一覧表示、CAT の使用、Copy ステータスのクエリ | Collection に対する |
| Collection に対する |
ドキュメントの読み取り、書き込み、クエリ | 対応する |
|
|
分離と最小権限の原則
manage は、Collection の管理、ウォームアップ、削除を同時に含みます。オンラインの読み書きアカウントには read と write のみを付与してください。ウォームアップ、Backing の事前作成、Copy、Branch、Collection または Slice の管理は、別のサービスアカウントまたは運用保守タスクから開始し、そのアカウントがアクセスできる Collection を制限してください。ビジネス要件によりオンラインアプリケーションがウォームアップを直接実行する必要がある場合は、そのアカウントがこれらの管理機能も持つことを受け入れたうえで、アプリケーションレイヤーで管理 API の呼び出しを制限してください。
さらに、次の原則を適用してください。
アプリケーションアクセスの原則：アプリケーションは常に Collection 名を通じてデータにアクセスする必要があります。Backing 名を直接参照したり保存したりしないでください。Backing に直接アクセスすると、Collection の論理的なエントリポイントと
_sliceスコープの書き換えがバイパスされるため、1 回のリクエストでその Backing 内のすべての Slice のデータを読み取れてしまいます。厳密な分離：Collection 間で認証情報を厳密に分離するには、現在の Backing 名のワイルドカードのみに依存しないでください。Collection 名のプレフィックス重複を避け、プラットフォームまたはアプリケーションレイヤーで独立した分離を行うことで分離を実現し、各権限変更後に実際にアクセス可能なインデックススコープを検証してください。
テナント分離と認証情報：Slice はテナント権限分離の境界ではありません。現在の権限モデルでは、単一テナントの Slice のみを読み取れる Elasticsearch アカウントを、そのテナント向けに発行できません。テナントレベルの認証とデータスコープの制限は、アプリケーションレイヤーで実施してください。Elasticsearch アカウントの認証情報をエンドユーザーに直接配布しないでください。
Collection のバックアップと復元
Collection のバックアップと復元は、名前空間全体を対象とします。インスタンス内のすべての Collection がまとめてバックアップおよび復元されます。特定の Collection または Slice のみを復元したり、復元中に Collection 名を変更したりすることはできません。これらの操作は、チケットを通じてテクニカルサポートが実施します。
復元前に、対象インスタンスには Collection が 1 つも存在してはならず、バックアップと同名の基盤インデックスが残っていてもいけません。バックアップ要件を確定し、本番稼働前に、ソースインスタンス、復元先、バックアップ要件を記載してチケットを提出してください。その後、テクニカルサポートがバージョン、ストレージ条件、グローバル設定への影響を確認し、バックアップウィンドウを調整します。
バックアップ中も、既存の Slice に対する通常のドキュメントの読み取り、クエリ、書き込み、更新、削除は継続できます。バックアップの開始から終了まで、次の管理操作を停止してください。
Collection の作成、更新、削除
Slice の登録または削除 (初回書き込みによってトリガーされる自動登録を含む)
Backing のロールオーバーまたは切り替え
Branch Slice (Beta) の作成
自動的にトリガーされる可能性がある Slice 登録や Backing のロールオーバーなども含め、これらの操作の調整についてテクニカルサポートに支援を依頼してください。バックアップ中にこれらの変更が発生した場合は、バックアップを作成し直してください。