本記事は Amazon Web Services, Technical Writer である Liz Snyder、Senior Principal Solutions Architect である Jon Handler によって投稿されたものです。

Amazon OpenSearch Service は、OpenSearch およびレガシー Elasticsearch クラスタのセキュリティ確保、デプロイ、スケールアップ運用を容易にするマネージドサービスです。

Amazon OpenSearch Service のサービスソフトウェアリリース R20220323 では、JVMMemoryPressure メトリックの動作が変更されました。このメトリックは、Young プールと Old プールを含む全体的なヒープ使用量を報告するようになりました。Graviton ベースのデータノード (C6、R6、および M6 インスタンス) を使用している場合、または Auto-Tune を有効にしてガベージコレクションアルゴリズムを G1GC に切り替えている場合、この変更により OpenSearch の Java ヒープに関する問題の検出および対応能力が向上します。

Javaガベージコレクションの基本

Java におけるオブジェクトは、ヒープメモリに割り当てられます。Amazon OpenSearch Service では、ヒープメモリがインスタンスの RAM の半分を占めます (およそ 32 GBが上限) 。アプリケーションが実行されると、ヒープ内のオブジェクトが生成・破棄されるにつれてヒープが断片化し、新しいオブジェクトの割り当てが困難になります。Java のガベージコレクション・アルゴリズムは、定期的にヒープを調査し、未使用のオブジェクトのメモリを回収します。また、必要に応じてヒープを圧縮し、より連続した空き領域を確保します。

• Young generation – Young generation のメモリプールは、新しいオブジェクトが割り当てられる場所です。Young generation はさらに、すべての新しいオブジェクトが開始される Eden 領域と、1 回のガベージコレクションサイクルに耐えたオブジェクトが Eden から移動する 2 つの Survivor 領域 (S0 と S1) に分けられます。Young generation が満杯になると、Java はマークされていないオブジェクトを一掃するために、マイナーガベージコレクションを実行します。Young generation に残っているオブジェクトは、最終的に Old generation に移動するまで年齢(age)が増加します。
• Old generation – Old generation のメモリプールには、長寿命(long-lived)のオブジェクトが格納されます。Young generation でガベージコレクションを何度も繰り返した後、オブジェクトがある年齢(age)に達すると、Old generation に移されます。

Java プロセスは、コマンドラインオプションで選択された異なるガベージコレクションアルゴリズムを採用することができます。

• Concurrent Mark Sweep (CMS) – 異なるプールがメモリ上で分離されます。ストップ・ザ・ワールドの一時停止、ヒープ圧縮が定期的に行われます。Young generation のプールは小さいです。Graviton 以外のすべてのデータノードで CMS が使用されています。
• Garbage-First Garbage Collection (G1GC) – すべてのヒープメモリは単一ブロックであり、異なるメモリ領域 (リージョン) が異なるプールに割り当てられています。プールは物理メモリ内で非連続です。ストップ・ザ・ワールドの一時停止やヒープコンパクションは頻繁には行われません。Young generation のプールはより大きくなっています。すべての Graviton データノードで G1GC が使用されています。Amazon OpenSearch Service の Auto-Tune 機能は、Graviton 以外のデータノードでも G1GC を選択する可能性があります。

CloudWatch コンソールを使用し、これらのデータポイントに関する統計情報を、メトリクスと呼ばれる時系列データの順序付きセットとして取得することができます。Amazon OpenSearch Service は、現在、JVM メモリプレッシャーに関連する3つのメトリクスを CloudWatch に発行しています。

• JVMMemoryPressure – クラスタ内のすべてのデータノードで使用される Java ヒープの最大パーセンテージ。
• MasterJVMMemoryPressure – クラスタ内のすべての専用マスターノードに使用されるJava ヒープの最大パーセンテージ。
• WarmJVMMemoryPressure – クラスタ内の UltraWarm ノードに対して使用される Java ヒープの最大パーセンテージ。

Amazon OpenSearch Service はサービスソフトウェアリリース R20220323 で、実際のメモリ使用率をより正確に反映するために、これらのメトリクスを計算する際に使用するロジックを改善しました。

課題

以前は、すべてのデータノードが CMS を使用しており、Young プールはメモリのごく一部でした。Amazon OpenSearch Service が CloudWatch に発行したJVM メモリプレッシャーのメトリクスは、Java ヒープの Old プールだけを考慮していました。Old generation の使用量だけを見ることで、ヒープ使用量の問題を検出することができました。

ドメインが G1GC を使用する場合、Young プールが大きくなり、ヒープ全体に占める割合が大きくなります。オブジェクトはまず Young プールで作成され、その後 Old プールに移動されるため、使用量のかなりの部分が Young プールにある可能性があります。しかし以前のメトリックは、Old プールについてのみ報告していました。このため、ドメインは Young プールで潜在的なメモリ不足に陥る可能性があります。

変更点

サービスソフトウェアリリース R20220323 において、Amazon OpenSearch Service は、CloudWatch に送信する 3 つの JVM メモリプレッシャーメトリクスのロジックを変更し、使用中の Java ヒープの合計 (Old generation と Young generation) を考慮するようにしました。このアップデートの目的は、Amazon OpenSearch Service のドメイン全体で、より正確な総メモリ使用量の値を提供することです。特に Graviton インスタンスタイプでは、G1GC ロジックによって、実際の使用量を計算するためにすべてのメモリプールを考慮することが重要になります。

期待される効果

Amazon OpenSearch Service のドメインを最新のサービスソフトウェアリリースに更新すると、Amazon OpenSearch Service がCloudWatch に送信する以下のメトリクスは、Old メモリプールだけでなく、Young generation と Old generation のメモリプールの JVM メモリ使用量を報告するようになります。

• JVMemoryPressure
• MasterJVMMemoryPressure
• WarmJVMMemoryPressure

主に G1GC が設定されたドメインで、これらのメトリクスの値が増加していることが分かるかもしれません。場合によっては、Young generation のメモリプールではガベージコレクションがより頻繁に行われるため、メモリの使用パターンがまったく異なることに気づくかもしれません。これらのメトリクスに対して作成した CloudWatch アラームがトリガーされるかもしれません。このような現象が続く場合は、RAM サイズ 64 GiB を上限としてインスタンスを垂直方向にスケールさせることを検討してください。

標準的なプラクティスとして、利用可能なメモリが少ないドメインでは、Amazon OpenSearch Service はさらなる書き込み操作をブロックして、ドメインが赤のステータスになることを防ぎます。アップデート後にメモリ使用量を監視し、ドメインにおける実際の使用量を把握する必要があります。_nodes/stats/jvm API は、JVM 統計、メモリプールの使用状況、ガベージコレクション情報の有用なサマリを提供します。

まとめ

Amazon OpenSearch Service は、実際の利用状況をより正確に反映するために、直近で JVM メモリ使用量の計算に使用するロジックを改善しました。JVMMemoryPressure、MasterJVMMemoryPressure、および WarmJVMMemoryPressure の CloudWatchメトリクスは、メモリ使用量を計算する際に、Old generation だけでなく、Old generation と Young generation の両方のメモリプールを考慮するようになりました。これらのメトリクスの詳細については、Amazon CloudWatch を用いた OpenSearch クラスターメトリクスのモニタリング を参照してください。

メトリクスの更新により、ドメインはより正確にメモリ使用量の数値を反映するようになり、以前に設定した CloudWatch アラームの閾値を超える可能性があります。これらのメトリクスに対するアラームを監視し、それに応じてクラスタをスケールして最適なメモリ使用量を維持するようにしてください。

Amazon OpenSearch Service のエキサイティングなアップデートと新機能にご期待ください。

翻訳はソリューションアーキテクト 榎本 貴之 が担当しました。原文はこちらです。