従来のOpenSearch運用で感じていた課題
OpenSearchクラスターの運用において、自分が特に面倒だと感じていたのは「どこから調べ始めればいいかわからない」問題でした。
ユーザーから「検索が遅い」という報告を受けて、まずCloudWatchでCPU使用率やJVMメモリを確認する。特に問題なさそうに見えるので、次にシャードの配置状況を確認する。ホットノードにシャードが偏っているかもしれない。いや、そもそもインデックスのサイズが大きすぎるのかも…。
このように、あちこちのメトリクスやAPIを行き来しながら原因を探るプロセスは、経験を積んだエンジニアでも時間がかかります。まして運用経験が浅いメンバーにとっては、かなりハードルが高い作業だったと思います。
Cluster Insightsが変えるもの
Cluster Insightsは、OpenSearchバージョン2.17以降で利用できる統合モニタリングダッシュボード機能です。追加料金なしで提供されており、OpenSearch UIからアクセスできます。
この機能の本質は「厳選されたインサイトと実行可能な緩和手順を提供すること」にあります。単にメトリクスを可視化するだけでなく、「何が問題で、どう対処すべきか」まで示してくれるのが特徴です。
CloudWatchやAmazon OpenSearch Serviceコンソールでは実現困難だった、ノード・インデックス・シャードレベルの詳細なメトリクスが単一のインターフェースで確認できます。事後対応型のトラブルシューティングから、プロアクティブな最適化への転換を目指した設計思想を感じます。
5層構成のOverviewページ
Cluster InsightsのOverviewページは5つのセクションで構成されています。それぞれの役割を見ていきましょう。
Current Cluster Statusはクラスターの健全性ステータス（Green、Yellow、Red）をドーナツチャートで表示します。パッと見で全体像を把握できるのがいいですね。
Insights Trendは過去30日間の問題パターンを追跡するセクションです。運用変更の影響監視や繰り返し発生する問題のトラブルシューティングに活用できます。例えば、毎週月曜の朝にシャードカウントの警告が出ているなら、週末のバッチ処理で何かが起きている可能性を疑えます。
Current Open Insightsはクラスター全体で現在アクティブなインサイトの数と重大度の内訳を表示します。重大度はCritical/High/Medium/Lowの4段階で、優先順位をつけた対応が可能です。
OpenSearch Service Clustersは接続されたすべてのドメインを一覧表示し、健全性ステータス、インサイト数、ノード数、シャード数、アクティブなクエリなどの統計情報を確認できます。マルチドメイン環境での横断的な監視に便利です。
Top Insights by Severityは即座に対応が必要な問題を優先順位付けするセクションです。シャードサイズ問題、ディスク容量問題、パフォーマンスボトルネックなど、重要な問題に最初に集中できるようになっています。
各インサイトの詳細分析
個別のインサイトを選択すると、より詳細な分析画面に遷移します。
リソースマップでは、影響を受ける各ノードとイ��デックスが視覚的に表示されます。ノードID、シャード数、問題の原因となっているインデックスなどの重要情報が一目でわかります。
推奨事項は2段階で提示されます。クラスターレベルの推奨事項はクラスターのスケーリングやグローバルシャード割り当て設定の調整など、全体的なアーキテクチャ改善に関するもの。インデックスレベルの推奨事項は個々のインデックスに対する具体的なアクションです。
面白いのは、「過去10日間に検索またはインデックス作成操作がなく、少なくとも5日以上経過しているシャードをUltraWarmストレージに移動する」といった具体的な提案がなされる点。単に「ストレージを節約しろ」ではなく、「このシャードをUltraWarmに」と指し示してくれます。
インサイトカタログの中身
どんなインサイトが検出されるのか、主要なものを見ていきましょう。
Cluster Write BlockedはCritical重大度で、クラスターのFreeStorageが総容量の20%未満または20GB以下に低下した場合に発生します。この状態ではライト操作がブロックされる可能性があるため、緊急対応が必要です。
Large Shardは段階的な重大度設定になっています。50GB〜100GBでLow、100GB〜200GBでMedium、200GBを超えるとHighです。大規模シャードはクエリレイテンシー増加、復旧時間延長、ノード過負荷につながるので、適切なサイズに分割することが推奨されます。
Shard CountはHigh重大度で、シャード/GBのヒープ比が25を超える場合、またはノード上のシャード数が900以上に到達した場合に発生します。OpenSearch 2.17以降では、JVMヒープサイズの16GBあたり1,000シャードをサポートする動的計算方式が導入されました。ノードあたり最大4,000シャードが上限です。
KMS Key InaccessibleはCritical重大度で、保存時の暗号化に使用されるKMSキーへのアクセスを失った場合に発生します。データにアクセスできなくなる可能性があるため、即座の対応が必須です。
Incorrect Cluster Manager ConfigurationもCritical重大度です。専用のCluster Managerノードなしで2つのデータノードを持つ場合、または2つの専用Cluster Managerノードを持つ場合に発生します。クォーラム喪失とクラスター不安定性のリスクがあるため、3つの専用Cluster Managerノードを異なる可用性ゾーンに配置することが推奨されます。
Node、Index、Shard、Queryビュー
Cluster InsightsはOverview以外にも、詳細なメトリクスを確認できる複数のビューを提供しています。
Nodeビューでは、ヒートスコア（全体的なノード健全性を示す指標）やリソース使用率（CPU、メモリ、ディスク）を確認できます。検索およびインデックスのレイテンシーとレート、各ノードで実行されている上位N個のシャードとクエリへのクイックリンクも便利です。
特定のノードで問題が発生している場合、そのノードIDをクリックすると時間経過に伴うリソース使用量の傾向が表示されます。上位N個のシャードリンクをクリックすれば、選択したノードで実行されているシャードのみにフィルタリングされたShardビューに直接移動できるので、問題の切り分けがスムーズです。
Indexビューではドキュメント数、ストレージサイズ、検索レイテンシーとレート、インデックスレイテンシーとレ���トを監視できます。どのインデックスがクラスターの負荷を引き起こしているかを把握し、インデックス設定レベルでの最適化機会を特定するのに役立ちます。
Shardビューは個々のシャードのメトリクスを表示し、クラスターパフォーマンスの最も詳細なビューを提供します。シャード配置の不均衡を識別し、ターゲットを絞った修復アクションを実行できます。
Queryビューはすべてのクエリの実行統計、CPU/メモリ使用量、完了進捗状況を分解するライブダッシュボードです。ノード・インデックス・ユーザー別の分布を示すドーナツチャートとスコアボードにより、パフォーマンスボトルネックと重いワークロードを迅速に特定できます。
Query Insightsとの連携
Cluster InsightsはOpenSearch 2.12で導入されたQuery Insights機能とも統合されています。
Top N Queriesはレイテンシ、CPU使用率、メモリ消費に基づいて最もリソース集約的なクエリを特定する機能です。日次のバッチ処理で突然重いクエリが走り始めた場合など、素早く原因を特定できます。
Query Groupingは同様の構造を持つクエリをグループ化し、パターン分析を実現します。パラメータの値だけが異なる同一構造のクエリを1つの項目として扱えるので、「特定のパターンのクエリが重い」といった傾向を把握しやすくなります。
Live Query Monitoringは現在実行中のクエリをリアルタイムに監視し、長時間実行クエリを特定してキャンセルできます。暴走クエリを発見したら、その場で止められるのはありがたいですね。
実運用での活用指針
Cluster Insightsを実運用に組み込む際の指針を整理しておきます。
Criticalインサイトへの対応として、Cluster Status Red、Cluster Write Blocked、KMS Key Inaccessible、Incorrect Cluster Manager Configurationは即時対応が必須です。SLA達成時間は1時間以内を目標にすべきでしょう。
Highインサイトへの対応として、Large Shard（200GB以上）、Shard Count超過、Low Disk（25GB未満または25%未満）は営業時間内対応で、SLA達成時間は4時間以内が目安です。
Mediumインサイトへの対応として、Cluster Status Yellow、Misconfigured Replica、Misconfigured Index Settingsは計画的対応で問題なく、SLA達成時間は24時間以内で十分でしょう。
セキュリティの観点では、すべての本番環境クラスターでAWS KMSカスタマー管理キー（CMK）による暗号化を有効にしておくべきです。デフォルトのAWS管理キーは避け、年1回以上のキーローテーションを実施することを推奨します。
レプリケーション設定については、最小レプリカ数1を確保し、複数AZ構成では各シャードとそのレプリカを異なるAZに配置します。Multi-AZ with Standby（2つのアクティブAZ + 1つのスタンバイAZ）の活用も検討してください。
Cluster Insightsは、OpenSearch運用のハードルを下げてくれる良い機能だと感じています。追加料金なしで利用できるので、OpenSearch 2.17以上を使っているなら、ぜひ有効化してみてください。
