運用していく中で、クラスター構成やインデックス設定がワークロードに適していないことでパフォーマンスの問題が生じることがあります。短期的にはクラスタのスケールといった対処も必要ですが、原因を精査することがその後の運用において重要です。本記事では、パフォーマンストラブルが起きた際に確認すべきポイントを、順を追って紹介していきます。各ポイントは質問の形式で記載されているので、質問への回答を作成しながら根本原因の調査や、対処を検討するための参考情報を整理することができます。クラスタを簡単に構築し、全文検索やログ基盤といったユースケースで用いられるサービスです。クラスタの設定としてノード数やノードのタイプ、インデックスの設定としてシャード数などを設定してワークロードごとに適した構成を柔軟に作ることが可能です。いったクラスタの構成やインデックス、シャードの設定が実際のワークロードに適していないものになっている場合、レイテンシーが増加したり、スロットリングやエラーが生じるといったトラブルが起きてしまう場合があります。サイジングに関するベストプラクティスは公開されていますが、それに則って構築を行っても現実的にはその通りに行かない場合があります。突発的なワークロードの増大やアプリケーションの機能追加に伴うワークロードパターンの変更など、予想外のことが起きた場合には問題が生じてしまう可能性もあります。いった場合に対応としてノードのスケールアップやスケールアウトを行うことでトラブルが解決してしまうこともありますが、根本の問題を特定せずに行った場合はその対応が一時しのぎにしかならなかったり、コストが無駄にかかってしまったりといったようなことが起きてしまう危険があります。トラブルが起きた際には、問題を切り分け、根本的な問題の事象を特定しそこに適切にアプローチしていくことが重要になります。本記事は、そういったパフォーマンスに関するトラブルが起きた際にどういった項目を確認して問題を切り分けていくのか、特定した問題に対してどのような対処を行えばいいのかについて質問形式でまとめたものになります。本記事でのトラブルシュート全体の流れとしては以下のようになります。調査に必要なメトリクスや設定情報を取得する。得られた情報をもとに質問への回答を行う。メトリクスとともに、回答した結果や質問の補足事項から、問題の根本原因の仮説とそれに対する対策を立てる。対策を実施し、問題が解消されるかを観察する。3.については仮説をもとにさらに詳細な調査を行い、ボトルネックや問題発生の条件を深ぼる必要がある場合もあります。トラブルシュートに必要な情報の収集トラブルシュートを行うためには調査のための材料を集める必要があります。コマンドを説明します。ついてもメトリクスを取得する仕組みを用意いただき同じ項目を確認することで、同様の流れでトラブルシューティングを行うことができます。画面にはいくつかのメトリクスについてすぐに確認ができるように用意がしてあります。これらのメトリクスを確認することで簡単にトラブルシューティングのポイントを把握することができるため、まずはマネージメントコンソール上のメトリクスを確認することからはじめます。インスタンスのヘルスというタブから各ノードのリソース状況の確認を行います。メモリプレッシャーといった主だったメトリクスを可視化してくれます。クラスターメトリクスのモニタリングを参照してください。コマンドはドメインに関する設定情報を取得するためのものです。詳細はドキュメントを参照してください。調べたい対象のドメイン名に変更して実行してください。インデックス一覧取得。インデックスのサイズが適切かを確認する。シャードが特定ノードに偏って配置されていないかを確認する。はじめから使えるようにプリインストールされています。リクエストを直接送信することができます。呼び出すこともできます。認証を使っている場合のコマンド例になります。インデックス一覧取得。インデックスのサイズが適切かを確認する。シャードが特定ノードに偏って配置されていないかを確認する。よって取得できる各種情報に関してはトラブルシューティングを行う上での基本的な情報になるため、ひとまず全て取得することをおすすめします。トラブルシュートのための質問ここまでトラブルシュートに関する質問に答えるための情報を集める方法について確認してきました。ここからはその情報を使って実際に問題を特定するための質問に回答していきます。以下の図は本記事でのトラブルシュートに関する質問回答のフローチャートになります。クラスタヘルスや負荷の状況から問題を切り分けるまずは、メトリクスや問題が起きているクエリの種類からおおまかな問題の切り分けを行います。マネージメントコンソールから確認できるクラスタの各ノードのヘルスに異常なものがありますか?ヘルスが赤色の場合、プライマリシャードの一部が未割り当てになっています。使ってシャード数を変更するなど対応を行ってください。対象のインデックスが不要な場合削除してください。シャードの割り当てが失敗した理由を確認してください。メトリクスを確認して負荷に対するリソースが不足していないか確認してください。詳細については赤のクラスター状態に関するドキュメントを確認してください。ヘルスが黄色の場合、レプリカシャードの一部が未割り当てになっています。もちいて対象のインデックスのレプリカシャード数を変更してください。メトリクスを確認してください。詳細については黄色のクラスター状態に関するドキュメントを確認してください。マネージメントコンソールから確認したデータノードのメトリクスからリソース使用状況やインデックス作成のレイテンシーや検索のレイテンシーに偏りはありますか?これらのメトリクスに偏りがみられる場合、特定のノードに負荷が偏っていることが伺えます。要因としては、シャードの偏りが懸念されます。使用率が高騰しているなどのリソースのメトリクスに異常がある場合は、どのような処理が基の原因になっているかを特定する必要があります。確認することでどちらのリクエストが原因で負荷が上昇しているかを判断します。シャードに関する問題を確認するメトリクスから負荷の偏りが確認できる場合、シャードに関する問題が起きていることが疑われます。次に示すようなチェック項目を確認して、実際にシャードに関する問題が起きているか確認します。参考にしていただくことをお勧めします。結果について、ノード毎のシャード数に偏りがありますか?偏りがある場合、シャード数とノード数のバランスが悪いことが考えられます。ベストプラクティスにしたがってシャード数がノード数の倍数になるように設定してください。用いることができます。シャード数がノード数よりも少ない場合、特定のノードのみにシャードが配置されてしまい、ノード全体からみると負荷が偏る原因になることもあります。結果について、各インデックス毎のシャードの配置について特定のノードへの偏りがありますか?クラスタ全体のシャードとしては偏りがなくても、特定のインデックスのシャードに偏りがある場合そのインデックスへのクエリが原因で問題を引き起こす場合があります。偏りがある場合にはシャード数とノード数のバランスが悪いことが考えられます。この場合にもベストプラクティスにしたがってシャード数がノード数の倍数になるように設定してください。必要のない、または使用していないインデックスが多数ありますか?必要のないインデックスが多数あるとそれらのインデックスに関するシャードが原因で、高頻度でリクエストされるインデックスのシャードに偏りが生まれてしまう可能性が高まります。することが推奨されます。コールドストレージにアクセス頻度の低いインデックスを移行することも検討してください。つのシャードの大きさは小さすぎても大きすぎても問題が起きる可能性があります。用いてシャード数を変更してそれぞれのシャードの大きさを適切なサイズになるように変更してください。それ以下でもノードのヒープメモリに対してシャード数が多すぎる場合には問題が起きる場合があります。程度でも注意が必要になります。用いてシャード数を変更します。よるインデックスの設定の変更を検討してください。多くのシャードが必要になる場合には、マスターノードのリソースメトリクスも併せて確認してスケールアップを行うことも検討してください。インデクシングに関わる問題を確認するインデクシングにまつわる問題が生じている場合は、スレッドプールやキューに関連するメトリクスの状況を確認して根本の問題がどこにあるのかを特定します。なっている場合には書き込み処理のブロックが発生しています。ブロックが発生している場合にはあわせて次のメトリクスを確認してください。以上になっている場合はリソースが不足している可能性があります。それぞれについて、クラスターのスケールを検討してください。改善、ノードのスケールを検討してください。されたインデクシングリクエストがないか確認をします。ある場合は、リクエストの数が設定されている上限を超過しているかメモリが不足している可能性があります。確認して、キューの状況を確認してください。リソース不足が考えられます。この場合、データノードのスケールを検討してください。アプリケーション側の書き込みロジックを変更することも重要になる場合があります。リソースに関するメトリクスを確認してキューにタスクが保持されているタイミングやその原因を特定してください。顕著に増加しているといったように、これら2つのメトリクスの動きに相関がない場合は、リソースの不足が考えられます。CPU、メモリーなどのリソースに関するメトリクスを確認して、ボトルネックを特定してください。結果と合わせてキューの状態とレイテンシの増加のタイミングの関係を確認してください。検索クエリに関わる問題を確認するインデクシング処理の場合と同様に、クエリ処理の場合も読み取りにまつわるメトリクスを確認することで根本の原因としてなにが起きているのかを特定していきます。確認して、拒否された検索リクエストがありませんか?このメトリクスから拒否された検索スレッドプールのタスク数を確認できます。確認してキューの状態を確認してください。キューに溜まってしまっているタスクの数が常に高い状態の場合は検索クエリの処理性能に問題があるため、リソース側のメトリクスも併せて確認しスケールを検討してください。変更することで改善が見られる場合もあります。つのメトリクスを確認してレイテンシーだけが著しく増加しているような場合には、リソースの不足が懸念されます。つのメトリクスの乖離がおきているタイミングのリソースメトリクスを確認してボトルネックを特定します。結果とあわせてリクエストの拒否やキューの状態についても同じタイミングで問題が起きていないか確認します。項目の質問から問題が起こっている原因の調査を行いました。その結果をもとに問題が生じているタイミングのリソースのメトリクスを確認することで、問題の原因のボトルネックになっている箇所を特定しスケールの検討の材料にします。以上の状態が続く場合にはスケールを検討してください。ヒープ領域の使用量を確認します。以上の状態が続く場合にはスケールを検討してください。FreeStorageSpace各ノードタイプごとの空き容量です。エラーが発生することがあります。結果からクラスタ全体とノード毎のストレージが不足していないかを確認して、不要なインデックスの削除や適宜スケールを検討してください。クラスタの設定を確認してください。バージョンも新しいものになります。それによってロジックや使われているアルゴリズムの改善が伴う場合、パフォーマンスの向上が見込めます。クラスタの設定を確認してください。ベースラインが高く設定されている関係で、小規模のデータでもより安定した性能をより低価格で達成できます。場合にはその懸念がありません。詳しくはドキュメントを参照してください。クレジットを消費してベースラインを超えたパフォーマンスを発揮するバーストと呼ばれる機能を使用します。クレジットが枯渇してしまった場合に性能が不安定になってしまいます。インスタンスは本番環境での利用が非推奨となっています。余剰クレジットについての無制限モードがデフォルトでオフになっています。クレジットが枯渇している場合はインスタンスタイプの変更を検討してください。非常に小さなワークロードを想定した設定になっているため本番環境での使用は非推奨となっています。ついても小規模なワークロード向けのオプションになっているため注意が必要です。メモリもスワップの対象になってしまいます。これにより、パフォーマンスが安定しなくなる場合があります。詳細はドキュメントを参照してください。トラブルについて、質問形式で根本の問題を特定するためのチェックポイントをまとめました。上記の確認項目に加えて、理想的にはアプリケーション側のログやメトリクスと付き合わせることで問題特定の精度を高めることも検討してください。いったツールを使用している場合にはそちらがボトルネックになっていないか確認していただくことも重要です。構築する際にはノード数やインデックスのシャード数などの設定についてパフォーマンスやコスト最適といった観点でのベストプラクティスが紹介されています。最初に構築する際にはこちらを参考にしていただき、そもそも問題が起きにくいような構成を検討していただくことも重要になります。実際にトラブルが起きてしまった際には、本記事の質問への回答を実施して問題の特定のための参考にしていただければ幸いです。テリトリーのお客様を中心にクラウド活用の技術支援を担当しています。