データベースのパフォーマンスを監視および最適化する方法：実用ガイド

アプリケーションアーキテクチャの特定の側面だけでなく、アプリケーションアーキテクチャ全体を見て、さまざまな部分がどのように接続されているかを理解できることが重要です。可観測性が最初に来て、次に監視が続きます。

この投稿では、アーキテクチャのデータベース部分について詳しく説明し、データベースのパフォーマンスを監視および最適化する方法を示します。以下の原則のほとんどは、スタックに関係なく、またはPostgreSQL、MongoDB、またはその他のデータベースのパフォーマンスを監視および最適化するかどうかに関係なく適用されます。

データベースのパフォーマンスを監視する理由

クエリが非常に遅く、アプリが結果を待たなければならない場合、エンドユーザーやアプリの一部で処理が停止します。

渋滞のように、他の場所で何かが起こった結果として、一部が静止してしまう可能性があります。多くのクエリの解決に時間がかかりすぎる場合は、他のクエリが邪魔になっている可能性があります。

あなたの目標は、アプリの他の部分で問題が発生し始める前に、問題がどこから来ているのかを見つけることです。

次のステップは、監視を積極的に使用してアーキテクチャを最適化し、処理を高速化する方法を確認することです。しかし、私たちは自分たちの前に進んでいます-ステップ1から始めましょう：

ステップ1：AKAインスツルメンテーションデータベースのパフォーマンスの測定

データベースの監視は、正しいことを確実に測定することから始まります。

• エラー

• パフォーマンス

• クエリの平均と90パーセンタイル期間

• 総スループット -スループットが問題になる場合にトリガー/フラグを設定する別の方法を提供します

幸いなことに、そのデータの取得はすでに完了しています。APMソフトウェアを使用すると、計測および測定する対象を構成できる可能性があります。 AppSignalを使用する場合、データの収集と集約は、多くの設定を行わなくても自動的に行われます。私たちはあなたのために重労働をしました！

ステップ2：出発点-影響の大きいクエリを見つける

アプリをインストルメント化し、実際のデータが届き始めると、パターンが浮かび上がります。 AppSignalでは、ナビゲーションの[改善]の下に、最も遅いAPIリクエストと最も遅いクエリの画面を作成しました：

この画面は、最適化の優れた出発点になります。デフォルトでは、遅いクエリは影響によってソートされます。それらはあなたがよくするクエリです。影響は、スループットx平均クエリ時間です。

これらの並べ替えを切り替えると、ボリュームが最も大きいクエリ、最も遅いクエリ（ただし、おそらく無視できる1泊1回のバックグラウンドジョブ）、および最も影響力のあるクエリがわかります。

簡単なサイドステップ：いくつかの個別のクエリを修正する

これで、修正に飛び込むためのいくつかのクエリを見つけることができます。

遅いクエリをクリックすると、クエリのスループットや応答時間からクエリ名自体まで、すべての詳細が右側に表示されます。

ピークの応答時間にカーソルを合わせると、[ここで何が起こったのか]オプションをクリックしてズームインできます。その時点でどのようなエラーが発生したか、そのサンプルで、ホストで何が発生したかがわかります。

1つの特定のアンチパターンであるN+1で非常に目立つようにしました。 N + 1anti-patternは、前のクエリのすべての結果に対してクエリが実行されたときに発生します。

クエリ数はN+1で、Nは最初のクエリ結果のクエリ数です。その最初のクエリの結果が1つである場合、N + 1 =2です。結果が1,000の場合、N + 1=1,001のクエリです。ブーム。

クエリがN+1アンチパターンに従っている場合、それは幸せな事故です。ここでラベルが付けられているので、すぐに見つけることができます：

ここでは、それらを解決する方法については説明しません。N+1クエリに関する別のブログ投稿を作成しました。

さて、ここで、いくつかのクレイジーなものを修正したと仮定しましょう。それらを修正すると、それらがいつ発生し、応答時間が最悪であるかに気づきました。

ステップ3：検索 パターンの決定-何が間違っていますか？

監視とは、多くの場合、問題が発生したときを確認することです。しかし、監視に関する複雑さの一部は、セットアップにとって「間違っている」と見なされるべきものを定義することです。また、問題が解決した場合、それとも解決しない問題を見逃したりする場合は、アラートを受け取りますか？

クエリの平均スループットと期間を見てみましょう。APMソフトウェアで設定できるようになります。 AppSignalを使用してNode.jsを監視し、データベースとしてPostgreSQLを使用している場合は、最も重要な指標を使用してダッシュボードを自動的に作成します。

node-postgresダッシュボードには次のようなデータが表示されます：

これをアプリに設定したい場合は、こちらをご覧ください。

異なる時間範囲を切り替えると、平均1時間で消える短いピークと、より長い時間範囲にズームアウトしたときに高いままのピークが表示されます。

最も遅いクエリ画面を見た経験から、主な原因とそのピーク時についてのアイデアが得られました。

スループットの特定の短いピークは問題ない場合があります。たとえば、ホストがクエリを遅くする他のプロセスを実行している場合があります。

長いクエリ時間またはピークスループットにズームインすることをお勧めします。 95パーセンタイルと平均を比較すると、遅いクエリがすべての人によって経験されているのか、小さなサブセットによってのみ経験されているのかがわかります。これは、修正すべき点を示すのに役立つ場合があります。

ステップ4：保持する必要があるもの 夜起きますか？

通常、スペクトルのノイズの多い側から開始することをお勧めします。Pag​​erDutyではなく、メールやSlackなど、目を覚まさないチャネルでアラートを出すためのいくつかのトリガー。

「event_duration」メトリックでカスタムメトリックトリガーを作成し、平均フィールドを選択して、アプリの平均クエリ時間に関するアラートを取得します。90パーセンタイルまたは95パーセンタイルを選択して、アプリが遭遇する最も遅いクエリに関するアラートを取得します。

次に、アラートを受け取るイベントのタイプと名前空間の「group」タグと「namespace」タグを構成します。たとえば、グループの場合は「active_record」（Rails）または「postgres」（Node.js）または「ecto」（Elixir）、名前空間の場合は「web」または「background」：

1週間後、いくつかのパターンが見られ始め、どのケースに注意が必要で、どのケースが通常は解決するかがわかります。

次に、トリガーを調整してノイズを減らし、特定のアラートで目覚めさせたいときにチャネルを追加します。

ステップ5：データベース監視の設定で完了

さて、理論的には、適切な監視設定が必要です。適切なデータが入り、ビットがファンに当たる前に警告するトリガーを設定し、いくつかの大きな原因を発見しました。やるべきだよね？

実際には、アプリの使用量が増え、新しいボトルネックが生じる可能性があります。 Orcodeの変更はデータベースに影響を与え、期間が長くなる可能性があります。または、巨大なペイロードを持つ特定のフィールドが何かをトリガーします。どんなに経験を積んでも、新しい問題やボトルネックが発生します。

しかし、適切な設定を行うと、警告が表示され、これらの問題を解決するためにアーキテクチャを深く掘り下げる方法を知っているという事実に安心感を感じることができます。

そして、おそらく、他のネジが緩む前に、大きな「影響のある」クエリを改善することに喜びを感じることができます。それが私たちが最も愛しているものです-それとstroopwafels。

AppSignalを試して、ストロープワッフルを入手🍪

ストロープワッフルといえば、世界中に送ります。 Ruby、Elixir、Node.js用のAppSignalAPMソフトウェアを試してみてください。無料トライアルを設定してご連絡いただければ、家にストループワフェルの箱をお送りします。