Elasticsearch バージョンアップでのパフォーマンス低下の原因がベトナム語プラグインだった件 - AWS サポート Technical Deep Dive 事例紹介

Summary

本動画では、AWSサポートエンジニアの深掘りケーススタディを紹介します。東京オフィスのOhashiさんが、顧客の技術課題を解決するために行う「ディープダイブ」プロセスについて話します。Amazon OpenSearch Serviceのアップグレード後に発生したパフォーマンス低下をトラブルシューティングし、ベトナム語プラグインが原因であることを特定しました。JVMヒープ使用量の分析やオープンソースツールの活用を通じて問題を解決し、サービスチームが修正を実装しました。AWSサービスのオープンソースソフトウェアを管理する際のディープダイブの重要性と、サポートエンジニアとしての魅力についても触れています。

Takeaways

• 🌐 AWSサポートのディープダイブケーススタディを紹介します。
• 👋 オハシさん、東京オフィスのクラウドサポートエンジニアが話しています。
• 🛠️ 顧客の技術課題を解決するために技術的な専門知識を提供します。
• 🔍 問題解決にはディープダイブと呼ばれる詳細な調査と分析が行われます。
• 🔎 Amazon OpenSearch ServiceはOpenSearchとElasticsearchを管理するサービスです。
• 📈 エラスティックサーチ6.8から7.9へアップグレード後にマスターノードのパフォーマンスが低下した問題が報告されました。
• 📊 バージョン間のメトリックスを比較し、マスターノードの負荷が増加したことが確認されました。
• 🔄 JVM関連のCloudWatchメトリックスをチェックし、大量のガーベッジコレクションが発生していたことが発見されました。
• 📝 ログを掘り下げると、Elasticsearchの言語プラグインであるベトナムプラグインが原因で判明しました。
• 🔧 サポートエンジニアとして問題を再現することは非常に重要です。
• 🔄 rallyを使用して顧客のテストシナリオを再現し、マスターノードの負荷が増加する問題を再現することができました。
• 🐳 Dockerコンテナ内でElasticsearchを実行し、JVMヒープヒストグラムとヒープダンプを分析しました。
• 🔑 ベトナムプラグインのWクラスが大きなヒープ使用量を消費していたことが原因と判明しました。
• 🛑 問題の解決策として、辞書オブジェクトをシングルトンに変換するか、実装方法をレビューすることが提案されました。
• 🌟 AWSサービスはオープンソースソフトウェアを管理型で運用しており、オープンソースツールを活用してディープダイブが可能です。
• 💡 Javaに関する知識が豊富な場合、JVMの問題をトラブルシューティングでき、オープンソースプロジェクトに貢献することもできます。
• 📚 AWSのクラウドサポートエンジニアとして、不足している知識を習得することができます。
• 🤝 オハシさんからのAWSクラウドサポートエンジニアへの興味を呼びかけるメッセージと、チームのキャリアページへのリンクが提供されています。

Q & A

AWSサポートディープダイブケーススタディとはどのようなものですか？

AWSサポートディープダイブケーススタディは、クラウドサポートエンジニアが顧客の技術問題や課題を解決するために、詳細な調査、検証、分析、検討を行うプロセスを紹介するセッションです。

Amazon OpenSearch Serviceとはどのようなサービスですか？

Amazon OpenSearch Serviceは、検索エンジンOpenSearchとElasticsearchを管理するマネージドサービスです。

顧客がElasticsearch 6.8から7.9にアップグレード後に経験した問題とは何でしたか？

顧客が経験した問題は、マスターノードでのパフォーマンスの著しい低下でした。

マスターノードの負荷が増加した原因として疑われた要因は何でしたか？

マスターノードの負荷が増加した原因として疑われた要因は、JVM関連のCloudWatchメトリックスで大量のガーベッジコレクションが発生していたことです。

Elasticsearchの言語プラグインとはどのようなものですか？

Elasticsearchの言語プラグインは、特定の言語に対するテキスト解析やトークン化を提供する機能です。このケースでは、ベトナム語プラグインが問題の原因となりました。

ベトナム語プラグインがマスターノードに与える影響を特定するために行った調査はどのようなものでしたか？

ベトナム語プラグインがマスターノードに与える影響を特定するために、ログを掘り下げ、GitHubで見知らぬログメッセージを検索し、プラグインに関連するログが大量に出力されていたことを発見しました。

問題を再現するために使用したツールは何でしたか？

問題を再現するために、Elasticsearchのベンチマークツールであるrallyを使用しましたが、その後には顧客のテストシナリオに基づいて定義したカスタムシナリオを使用しました。

Dockerコンテナ内で行った調査で何を発見しましたか？

Dockerコンテナ内で行った調査で、ベトナム語プラグインのWクラスが大きなヒープ使用量を消費していることを発見しました。

この問題の根本原因は何でしたか？

問題の根本原因是、インデックスが作成されるたびにロードされる単語辞書（unigram dictionary）でした。辞書は、プラグインが使用されていない場合でもロードされます。

この問題に対する解決策として提案されたものは何でしたか？

この問題に対する解決策として、辞書オブジェクトをシングルトンに変換するか、実装方法を全体的に見直すことが提案されました。

AWSサポートエンジニアとして働くことの魅力は何ですか？

AWSサポートエンジニアとして働くことの魅力は、未知の問題を明確にし、オープンソースツールを活用してディープダイブ調査を行うことができることです。また、Javaに関する知識を身につけ、オープンソースプロジェクトに貢献する機会もあります。

Outlines

00:00

🔍 エラスティックサーチプラグインのトラブルシューティング

この段落では、AWSサポートエンジニアの大橋さんが、クラウドサポートエンジニアとしての日常業務を紹介しています。顧客がElasticsearch 6.8から7.9へアップグレード後、マスターノードでのパフォーマンスの低下を経験した問題を解決するケーススタディを紹介しています。調査の過程で、リクエストレートは減少していたものの、マスターノードの負荷が増加していたことを発見しました。その後、JVM関連のCloudWatchメトリックスをチェックし、マスターノードで大量のガーベッジコレクションが発生していたことを特定しました。ログを掘り下げることで、Elasticsearch 7.7に新たに搭載されたベトナム語プラグインが原因であると判明。このプラグインはアップグレード後にデフォルトでインストールされ、マスターノードにログが溢れており、パフォーマンス低下の原因となっていたと推測されます。しかし、このプラグインがパフォーマンスに与える影響が不明だったので、さらなる調査を続けました。サポートエンジニアとして問題を再現することは非常に重要で、問題を特定しやすくなります。rallyというElasticsearchのベンチマークツールを使って再現を試みましたが、顧客のテストシナリオとは異なり、パフォーマンスが向上していたため、顧客のシナリオに基づいてカスタムシナリオを定義し、SageMakerノートブックからJupyter Labを使用して実行し、マスターノードの負荷増加を再現することができました。その後、Dockerコンテナ内でElasticsearchを実行し、JVMヒープヒストグラムとヒープダンプを分析することで、ベトナム語プラグインの特定のクラスが大きなヒープ使用量を消費していた原因を特定しました。

05:04

🛠️ エラスティックサーチプラグインのメモリ効率化

この段落では、大橋さんが先ほどのケーススタディの続きを説明しています。問題の原因となったベトナム語プラグインのクラスWは、インデックスが作成されるたびに単語辞書をロードしていたことがわかりました。辞書は使用されていなくてもロードされるという問題がありました。解決策としては、辞書オブジェクトをシングルトンに変換するか、実装方法を全体的に見直すことが考えられます。Amazon OpenSearch Serviceでは、日本語のkuromojiプラグインが使用されており、辞書のような大きな読み取り専用オブジェクトに対してシングルトンを適用してメモリ効率を確保しています。このケースでは、調査結果を報告し、サービスチームが修正を実装しました。顧客に調査結果を伝え、ケースをクローズしました。このケースでは、広い視点から原因を絞り込んでいき、仮説を立てながら繰り返し検証を行ったプロセスを経て、問題を明確にすることができました。AWSサービスはオープンソースソフトウェアを管理された形で実行しており、オープンソースツールを活用してディープダイブして検証することができます。DockerやJupyterなどの一般的なスキルを駆使して、再現性の高いポータブルな検証を行うことができます。また、Javaに関する知識が豊富な場合、JVMの問題をトラブルシューティングでき、オープンソースプロジェクトに貢献することもできます。AWSのクラウドサポートエンジニアとして必要なスキルを身につけることができます。

Keywords

💡AWSサポート

AWSサポートとは、Amazon Web Servicesが提供するクラウドサービスに対する専門的な技術サポートを意味します。ビデオでは、AWSサポートエンジニアが顧客の技術的な課題を解決するために、深い洞察と分析を行っている様子が紹介されています。

💡ディープダイブ

ディープダイブは、AWSサポートエンジニアが顧客の問題を解決するために行う徹底的な調査と分析のプロセスです。ビデオでは、このプロセスが問題の特定と解決にどのように役立つかを紹介しています。

💡Amazon OpenSearch Service

Amazon OpenSearch Serviceは、OpenSearchおよびElasticsearchという検索エンジンのためのマネージドサービスです。ビデオでは、このサービスにおいて発生したパフォーマンスの問題を例に、サポートエンジニアが問題解決に取り組んでいる様子が説明されています。

💡パフォーマンスデグレード

パフォーマンスデグレードとは、システムの応答速度や処理能力が低下する状態を指します。ビデオでは、Elasticsearchのバージョンアップ後に発生したマスターノードのパフォーマンス低下が問題として取り上げられています。

💡JVM

JVMとはJava Virtual Machineの略で、Javaアプリケーションを実行するための仮想環境です。ビデオでは、JVMのヒープ使用量の増加がマスターノードの負荷増加につながったとされているため、調査の鍵となる要素となっています。

💡プラグイン

プラグインとは、ソフトウェアに追加の機能を提供するコンポーネントです。ビデオでは、Elasticsearchに含まれるベトナム語プラグインがマスターノードの負荷増加の原因となり得る問題点として特定されています。

💡rally

rallyはElasticsearchのベンチマークツールです。ビデオでは、AWSサポートエンジニアがrallyを使用して顧客のパフォーマンステストを再現し、問題の特定に役立つかを紹介しています。

💡SageMakerノートブック

SageMakerノートブックは、機械学習モデルの開発とデプロイのための対話型開発環境です。ビデオでは、サポートエンジニアがSageMakerノートブックを使用してカスタムシナリオを定義し、問題を再現するプロセスが説明されています。

💡Java

Javaは広く使われるオブジェクト指向プログラミング言語です。ビデオでは、Javaに関する知識がJVMの問題のトラブルシューティングに大変役立つとされており、AWSサポートエンジニアとして必要なスキルの一つとなっています。

💡シングルトン

シングルトンはソフトウェア開発におけるデザインパターンの一つで、特定のクラスのインスタンスがプログラム中にただ一つだけ存在するように制限します。ビデオでは、Amazon OpenSearch Serviceの日本語kuromojiプラグインがシングルトンを用いてメモリ効率を高めていると触れられています。

Highlights

Introduction of AWS Support Deep Dive Case Study by Ohashi, a Cloud Support Engineer.

Explanation of the role of Cloud Support Engineers in assisting customers with technical expertise.

Introduction to Amazon OpenSearch Service as a managed service for search engines OpenSearch and Elasticsearch.

Customer's reported significant performance degradation on the master node after upgrading to Elasticsearch 7.9.

Analysis of different types of nodes in an Amazon OpenSearch Service cluster.

Concern about increased memory load on the dedicated master node.

Comparison of metrics between Elasticsearch 6.8 and 7.9 versions.

Isolation of the issue by changing domain configuration and conducting performance tests.

Discovery of increased garbage collections on the master node via CloudWatch metrics.

Investigation of unfamiliar log messages indicating a language plugin issue.

Identification of the Vietnamese plugin as the likely cause of the performance issue.

Use of rally, an Elasticsearch benchmark tool, to reproduce the customer's issue.

Definition of a custom scenario based on the customer's test scenario for reproduction.

Execution of the custom scenario from a SageMaker notebook using Jupyter Lab.

Analysis of JVM heap histograms and dumps to identify the cause of increased master node load.

Identification of a class from the Vietnamese plugin consuming a large heap usage.

Explanation of the Elasticsearch plugin mechanism and the role of the W class.

Root cause analysis pointing to the unigram dictionary loading issue.

Suggestion of countermeasures such as converting the dictionary object to a singleton.

Mention of the Japanese kuromoji plugin's memory efficiency design using singletons.

Service team's implementation of a fix based on the investigation report.

Emphasis on the iterative process of forming hypotheses and conducting verification in troubleshooting.

Highlighting the value of open-source tools and Docker, Jupyter for reproducible and portable verification.

Importance of Java knowledge in troubleshooting JVM issues and contributing to open-source projects.

Invitation to join AWS as a Cloud Support Engineer and the benefits of the role.

Closing remarks and a link to the team's career page for interested viewers.

Transcripts

[Music]

Hello, welcome to the AWS Support Deep Dive Case Study.

My name is Ohashi, a Cloud Support Engineer working at the Tokyo office.

Our job is to assist our customers' innovation with our technical expertise.

To resolve customers' technical issues and challenges,

we conduct in-depth investigations, verifications, analysis, and considerations in our daily work.

We call this in-depth digging process "Deep Dives".

In this session, as a Deep Dive Case Study,

I'll introduce a troubleshooting case of Analytics Profile.

Let's start the Deep Dive journey of Cloud Support Engineers.

Amazon OpenSearch Service is a managed service for search engines OpenSearch and Elasticsearch.

A customer experienced a significant performance degradation on the master node during performance testing after upgrading from Elasticsearch 6.8 to 7.9,

so we identified the issue.

In Amazon OpenSearch Service, there are several types of nodes that make up a cluster.

The customer was concerned about the increased memory load on the dedicated master node.

First, we compared the metrics between the two versions

found that although the request rate decreased,

the load on the master node had increased.

Although the master node load had increased,

at this point we didn't have enough information to conclude it was due to the version upgrade.

To isolate the reported issue,

we asked the customer to change the domain configuration and contact performance tests.

We narrowed down the likely cause to be the increased load on the master node.

When checking the JVM-related CloudWatch metrics,

we found that a large amount of garbage collections occurred on the master node.

So the change in JVM heap usage looked suspicious.

Digging deeper into the logs, we found a large amount of unfamiliar log messages on the master node.

By searching GitHub for the unfamiliar messages,

we discovered it was a language plugin for Elasticsearch.

The Vietnamese plugin was included in Elasticsearch 7.7, so it did not exist before the upgrade.

After the upgrade, the Vietnamese plugin was installed by default,

its related logs were flooding the master node making it the likely cause.

However, at this point it was unclear whether the Vietnamese plugin impacted the master node performance

or other component changes from the version upgrade caused the issue,

so we continued to investigate deeper.

As a support engineer, reproducing an issue is crucial.

If we can reproduce the issue, it becomes easier to identify the cause.

Even if we failed to identify the cause, it's smoother for the service team to investigate further because we've already narrowed down the possible causes.

So we attempted to reproduce and verify the customer's regression tests.

At this point, our understanding of the customer's test scenario was unclear,

so we used rally, a common Elasticsearch benchmark tool, to reproduce.

However, we found that the performance has actually improved.

Although suspicious logs were output during the rally test, there were fewer than the customer's regression test.

So we decided to define our own scenario based on the customer's test scenario.

The customer's scenario involved more index creation and deletion than search.

We defined a simple custom scenario based on the customer's,

executed it from a SageMaker notebook using Jupyter Lab for easy operation.

As a result, we could reproduce the increased master node load.

However, since Amazon OpenSearch Service is a managed service,

we couldn't access the JVM information of the Elasticsearch processes running on each node.

So we ran open-source Elasticsearch in Docker containers and also performed load tests inside the containers.

Using Java commands inside the containers, we obtained and analyzed JVM heap histograms and heap dumps.

In the end, we found that a class from the Vietnamese plugin called W was consuming a large heap usage and identified the cause.

The mechanism of Elasticsearch plugin is as shown in the screen.

The entry class for each plugin can be checked via the REST API.

A list of W class is generated at the output point of the unfamiliar messages which looks very suspicious.

The root cause of this issue was the unigram dictionary getting loaded every time an index was created.

The tricky part is that the dictionary gets loaded even if the Vietnamese plugin isn't being used.

Possible countermeasures include converting the dictionary object to a singleton or reviewing the entire implementation method.

The Japanese kuromoji plugin available in Amazon OpenSearch Service uses singleton.

It's designed to be memory efficient by applying singletons to large read-only objects like dictionaries.

In this case, based on our report, the service team implemented a fix.

We informed the customer of the investigation results, and the case was closed.

In this case, we gradually drilled down from wide perspectives to isolate the cause.

We also formed hypotheses and conducted verification multiple times during the isolation process.

I think clarifying unknown issues is the best part of working as a support engineer.

Many AWS services run open-source software in a managed fashion.

For those services, we can leverage open-source tools to Deep Dive for verification.

While there are various methods,

Docker and Jupyter are now considered common skills

which enables highly reproducible and portable verification.

There are many situations with analytics and big data related software where Java knowledge is valuable.

Being able to troubleshoot JVM issues is highly valued, and you may even contribute to open-source projects.

Even if you lack such knowledge right now, you can acquire it through the support engineer role at AWS.

I hope you would be interested in becoming a Cloud Support Engineer.

That's it for today's Deep Dive Case Study.

Have you enjoyed the journey of Deep Dive with Cloud Support Engineers?

I hope I was able to share a little bit about the fun of troubleshooting.

In the video description, there is a URL to our team's career page.

It also contains information on other videos and events.

Please check it out if you're interested in joining us as a Cloud Support Engineer.

Thank you for watching!