Alibaba Cloud Elasticsearch Agent Engine Edition は、ストレージ容量、書き込みスループット、クエリ性能を独立してスケールできるステートレスアーキテクチャを採用しています。オブジェクトストレージが永続データを保持し、実際の使用量に基づいて課金されます。実際の読み取り/書き込み負荷に合わせてコンピューティングリソースをサイジングし、アクティブデータを中心にローカルキャッシュを計画します。
例えば、増加する履歴ナレッジベースのうち、日常的にアクセスされるのがごく一部である場合、新しいデータをオブジェクトストレージに保存し、コンピューティングとキャッシュリソースをアクティブデータに集中させることができます。これにより、アクセス頻度の低いデータ用にリソースを予約する必要が軽減されます。
データストレージとコンポーネントの責任範囲
コンポーネント | 主な責任範囲 | 計画すべき項目 |
インデックスノード | 受信した書き込みを処理し、インデックス構築とバックグラウンドマージを実行し、永続化が必要なデータをオブジェクトストレージに保存します。 | インポートスループット、持続的な書き込み量、インデックス構築のオーバーヘッド。 |
クエリノード | クエリを実行し、必要なデータをローカルにキャッシュします。キャッシュミス時には、オブジェクトストレージからデータを読み取ります。 | クエリの同時実行数、ベクトル検索のオーバーヘッド、アクティブデータセット、キャッシュ容量。 |
オブジェクトストレージ | インデックスデータ、書き込みログ、サービス実行に必要な永続的な状態を保存します。 | 事前の容量購入や手動拡張は不要で、実際の使用量に基づいて課金されます。 |
コンソールでのノード構成とアクセスエンドポイントについては、「インスタンスの作成と接続」をご参照ください。
書き込み負荷とクエリ負荷の独立したスケーリング
書き込みのピークとクエリのピークは、同じリソース構成を共有する必要はありません。実際のボトルネックとなっているコンポーネントにリソースを追加することで、単一の負荷に対して両方をスケールアウトすることによるリソースの無駄を回避できます。
バルクインポートまたは持続的な書き込み量が増加した場合は、インデックスノードをスケールアウトして書き込みとインデックス構築の能力を向上させます。
クエリの同時実行数が増加した場合は、クエリノードをスケールアウトしてクエリのコンピューティングとキャッシュリソースを追加します。
総データ量が増加してもアクティブデータがほとんど変化しない場合は、ローカルキャッシュをアクティブデータに合わせてサイジングします。永続ストレージは使用量に応じて増加し、ローカルキャッシュは総データ量に比例してスケールする必要はありません。
ノードスペックとノード数は購入ページで利用可能な構成に準じ、シャード計画、バルクの同時実行数、クエリ範囲もリソース使用率に影響します。コールドデータへのアクセスが遅い場合は、ユーザーがナレッジベースを開く前にクエリノードで Slice キャッシュをウォームアップすることで、最初のクエリの読み取り待機時間を短縮できます。
書き込み確認と検索可視性
ID による書き込みを確認するには、GET または mget を使用します。これらはデフォルトでリアルタイムに読み取りを行い、リフレッシュを必要としません。プライマリシャードが利用できない場合の読み取り境界については、「ID による書き込みの確認」をご参照ください。以下の段落では、ドキュメントが検索結果に表示されるようになるタイミングについて説明します。
書き込み確認と検索可視性は 2 つの独立した段階です。書き込みは、書き込みログが永続化された後に確認されます。データが検索結果に表示されるのは、インデックスノードが新しい検索可能なバージョンを生成して公開し、クエリノードがそのバージョンを読み込んだ後です。したがって、書き込みリクエストが成功した直後に検索を実行しても、短時間、新しいドキュメントが返されない場合があります。
通常の書き込みでは、refresh を渡さないでください。代わりに自動バックグラウンドリフレッシュを待ってください。データバージョンの公開と読み込みを頻繁に行うと、リソースのオーバーヘッドが増加するためです。特定の条件下では同期待機を利用できます。デフォルトの更新間隔とこれらの条件については、「リフレッシュとクエリ可視性」をご参照ください。
クエリレプリカ、可用性、従来の Elasticsearch との違い
クエリは、クエリノード上のレプリカシャードによって処理されます。可用性ターゲットに合わせて、クエリレプリカとそれをホストするクエリノードの両方を計画してください。永続データだけでは、クエリサービスが準備が整っているとは限りません。ノードの変更または復旧後は、実際のクエリを実行してサービスが利用可能であることを確認し、ローカルキャッシュが復旧する間のレイテンシーを観察してください。コールドデータへのアクセスが遅い場合、Slice キャッシュをウォームアップすることで、最初のクエリの読み取り待機時間を短縮できます。
従来の Elasticsearch のデータ階層、インデックスライフサイクル管理 (ILM) 、Translog、レプリカ待機パラメータを直接再利用することはできません。詳細については、「従来のステートフルな Elasticsearch との違い」をご参照ください。Collection を作成する際、クエリレプリカ設定 index.number_of_replicas はデフォルトで 2 になります。値が 0 の場合はクエリを処理できず、値が 1 の場合は基本的なクエリ要件のみを満たし、クエリの高可用性 (HA) は提供されません。本番環境では、単一のクエリノードに障害が発生した場合でも利用可能なレプリカがクエリを処理できるよう、少なくとも 2 つのクエリノードを構成してください。永続データはオブジェクトストレージに保持され、クエリレプリカは主にクエリとキャッシュの作業を担当するため、クエリレプリカを追加してもバックアップ戦略の代わりにはなりません。