Sidekiqの最適化と監視

Sidekiqの最適化または監視についてよく質問があります。モニタリングは一種のゲームですが、Sidekiqのパフォーマンスを最適化することはまったく別の球技です。実際には、最適化は複雑ですが、一見単純な答えから始めましょう...

速度を上げる2つの方法

まず、速度を上げるには2つの方法があります。1つはより大きなジョブ（より多くのメモリまたはIOを使用するか、より複雑になる可能性があります）を実行する方法、もう1つは同時実行設定またはワーカーを調整する（より多くのCPUと場合によってはIOを使用する）方法です。痛い、現実はすでに始まっています：スピードは犠牲になります。追加のメモリ、IO、またはCPUを節約できる場合、これは無料ですが、必要になる可能性のあるトレードオフを認識することが重要であると考えています。

同時実行設定による速度の向上

Sidekiqは、プロセスで複数のスレッドを使用して同時実行を処理します。このようにして、一度に複数のジョブを処理でき、各スレッドは一度に1つのジョブを処理します。デフォルトでは、Sidekiqはプロセスごとに10スレッドを使用します。より多くのスレッドを使用するように構成できるため、同時実行性が向上します。

新しい同時実行モデルはアプリでサポートされている必要があることに注意してください。たとえば、データベースへの接続プールが十分に大きく、ホストがI/O操作の増加に対応できる必要があります。詳細については、並行性に関するSidekiqのドキュメントを確認してください。

複数のワーカーを実行して速度を上げる

複数のプロセスを生成するだけでなく、複数のワーカーを実行することもできます。このようにして、CPUを集中的に使用するパーツをスケールアップし、1つのプロセスで実行する場合に、CPU上で互いに邪魔になる場合に並行して実行することができます。それに追いつきたい場合は、この記事で以前にRubyとグローバルインタープリターロックの並行性について書いてきました。

動作しますか、それとも壊れますか？監視対象とマジックダッシュボード

デフォルトのパラメータを変更すると、アプリケーションのパフォーマンスに影響を与える可能性があります。設定を変更する前に、監視を設定して、変更がプラスの影響を与えるかどうか、またはパフォーマンスを低下させるかどうかを確認することをお勧めします。

ホストレベルで問題が発生していないかどうかを確認することから始めましょう。実行しているハードウェア上でアプリがどれだけリソースを消費しているかを確認する必要があります。メモリとCPUに容量が残っている場合は、同時実行設定を増やして、処理を少し速くすることができます。

使用するAPM（Application Performance Monitoring）に関係なく、おそらくホストメトリックを追跡する方法があります。 AppSignalを使用する場合、ホストのダッシュボードが自動的に作成されます。実際に問題が発生する前にアラートを確実に受け取るために、異常検出を使用して特定のホストのCPU使用率に関するアラートを簡単に設定できます。

それでは、Sidekiqレベルで物事が壊れていないかどうかを見てみましょう。選択したAPMを使用すると、バックグラウンドジョブの監視とアラートを手動で設定できる可能性があります。 AppSignalでは、これは非常に簡単です。Sidekiqマジックダッシュボードでこれを追跡します（最新バージョンのgemを実行すると、最後からセットアップを必要とせずに生成されます）。

この設定では、ジョブステータスを監視する必要があります キューごとに、Slack、PagerDuty、電子メール、または使用するものすべてでアラートが発生するように失敗率のトリガーを設定します。

少ない、大きい仕事？

CPUをトレードオフしながら、速度を上げる方法を簡単に見てきました。それでは、メモリやIO、またはより複雑さをトレードオフしながら速度を上げる方法を見てみましょう。あなたはより大きな仕事を作ることによってそれをすることができると思うでしょう。アイデアは、操作ごとにSidekiqのオーバーヘッドがないため、大規模なジョブを高速化できるということです。ただし、私たちの経験では、Sidekiqのオーバーヘッドによってパフォーマンスが低下することはめったにありません。多くの場合、パフォーマンスを低下させる可能性があるのは、ジョブが実行するデータベースクエリです。より少ないクエリを実行するために、より多くのジョブを組み合わせることがであることがわかります。 パフォーマンスを向上させるための重要な方法。簡略化：1レコードの1000回の更新ではなく、1000レコードの1回の更新を実行します。

これが機能するか機能しないかを確認するために何を監視するか？

まず、ジョブステータスを監視する必要があります ここでもキューごとに、失敗率のトリガーを設定します 。ジョブには時間がかかり、操作も多いため、Sidekiqのメモリ使用量も監視する必要があります。 。 Sidekiqメモリの使用に関するアラートも設定する必要があります 、具体的には、メモリ不足のホスト AppSignalの異常検出を使用します。

キューの長さも監視する必要があります キューごと。これにより、バックログが形成されたとき、つまりワーカーが処理できるよりも多くのキューが作成されたときにアラートが表示されます。 「重要な」ジョブキューに異常検出トリガーを設定することをお勧めします。

APMには表示されないトレードオフ

大規模なジョブの大きな問題は、コーディングが難しいことです。個々のジョブを明示的にべき等にし、それらのステータスを追跡する必要があります。簡単な例では、1人の人にメールを送信するジョブがあり、それが失敗した場合、大きな害を及ぼすことなく再試行できます。 1000人にメールを送信するときに、ジョブが失敗した場合、ジョブが失敗する前にメールした240人に再送したくありません。それが起こらないようにすることで、コードがより複雑になります。

現実の本当の複雑さ

別のリアリティチェックの時間です。多くの場合、Sidekiqで実行されているものが原因で、バックグラウンドプロセスが遅くならない場合があります。クエリを実行しているデータベースのメモリが不足しているため、データベースの処理速度が遅い可能性があります。この投稿で使用するクールな例を探しているときに、そのようなシナリオの1つに遭遇しました。外部APIの応答時間が長いため、期間がピークに達していることがわかりました。 Sidekiqにはそれを解決するものはありません。

問題は1つの場所で発生する可能性がありますが、別の場所で完全に発生するため、AppSignalでは、エラー、パフォーマンス、およびホストメトリックがすべて1つになるように製品を構築しました。このビューの組み合わせたメトリックにより、問題の根本原因を簡単に見つけることができます。

簡単な答えはありません、ありますか？

この記事はSidekiqの監視と最適化の基本から始めましたが、速度がCPUとIOにコストをかけるという現実にすぐに遭遇しました。またはメモリ。または、より複雑なものを導入します。また、アーキテクチャのパフォーマンスの複雑さについて触れましたが、実際には、この投稿で難しいことの約99％をすり抜けました。

ですから、簡単な答えへの期待を払拭したかもしれませんが、この記事がSidekiqのセットアップの最適化と監視について興味深い考えを引き起こしたことを願っています！