LogicMonitorでは、主に大量の時系列データを扱います。 私たちの バックエンドインフラストラクチャプロセス 毎日数十億のメトリック、イベント、および構成。
以前のブログでは、からの移行について説明しました モノリスからマイクロサービスへ。 また、なぜ私たちが選んだのかを説明しました クォークス Javaベースのマイクロサービス用のマイクロサービスフレームワークとして。
このブログでは、以下について説明します。
環境内でQuarkusを使用して複数のマイクロサービスを構築したLogicMonitorのメトリックパイプラインは、次のテクノロジースタックにデプロイされています。
当社のマイクロサービスは、Kafkaトピックを使用して通信します。 各マイクロサービスは、いくつかのKafkaトピックからデータメッセージを取得し、処理結果を他のトピックに公開します。
Kafkaの各トピックはパーティションに分割されています。 同じKafkaクラスターを共有している複数のテナントのデータメッセージは、同じトピックに送信されます。
マイクロサービスがデータメッセージをKafkaトピックのパーティションに公開する場合、パーティションはランダムに、またはメッセージのキーに基づくパーティショニングアルゴリズムに基づいて決定できます。 同じデバイスからの時系列データメッセージが同じパーティションに順番に到着し、その順序で処理されるように、メッセージキーとして内部IDを使用することを選択しました。
複数のパーティションにわたるトピックのデータは、バランスが崩れる場合があります。 この場合、一部のデータメッセージは他のパーティションよりも多くの処理時間を必要とし、一部のパーティションには他のパーティションよりも多くのメッセージがあります。 これにより、一部のマイクロサービスインスタンスが遅れます。 この問題を解決するために、データメッセージを複雑さに基づいてさまざまなトピックに分け、コンシューマーグループをさまざまに構成しました。 これにより、サービスをより効率的にスケールインおよびスケールアウトできます。
トピックのデータを消費するマイクロサービスでは、複数のインスタンスが実行されており、それらは同じコンシューマーグループに参加しています。 パーティションはグループ内のコンシューマーに割り当てられ、サービスがスケールアウトすると、さらに多くのインスタンスが作成され、コンシューマーグループに参加します。 パーティションの割り当てはコンシューマー間で再調整され、各インスタンスはXNUMXつ以上のパーティションを取得して作業します。
この場合、パーティションの総数によって、マイクロサービスがスケールアップできるインスタンスの最大数が決まります。 トピックのパーティションを構成するときは、大量のデータを処理するために必要なマイクロサービスのインスタンスの数を考慮する必要があります。
MicroProfile ReactiveMessagingに基づくQuarkusのKafka拡張機能から始めました。 smallrye-reactive-messaging-kafka。 使いやすく、優れたサポートがあります 健康診断.
Kafkaプロデューサーを 命令型の使用法。 プロデューサーのスループットが良好であることを確認するために調整する必要のある構成がいくつかあります。これについては、 クォーカス vs スプリング ブログ。
ただし、Kafkaコンシューマーを設定する際に、いくつかの課題がありました。 これらは、Quarkus vs.Springブログでも言及されています。
最終的に、ApacheKafkaクライアントを使用してKafkaコンシューマーを実装することを選択しました。 たとえば、MicroProfile ReactiveMessagingのKafkaサポートに複数の改善が追加されました。 複数の消費者クライアントを許可する および パターンによるトピックのサブスクライブのサポート。 将来的には、QuarkusのKafka拡張機能をコンシューマー実装用に再評価する可能性があります。
すべてのマイクロサービスは、KubernetesクラスターのDockerコンテナーにデプロイされます。 Kubernetesクラスターでは、複数の名前空間を使用して、複数のテナント間でリソースを分割します。 ほとんどのマイクロサービスは、名前空間レベルでデプロイされます。
クラスターレベルでは、Kubernetesクラスターはクラスターオートスケーラーによってスケールアップおよびスケールダウンできます。 名前空間内のマイクロサービスごとに、 水平ポッドオートスケーラー アプリケーションのCPU使用率に基づいて、コンテナーレプリカの数を自動的にスケーリングします。 名前空間内のマイクロサービスのレプリケーションの数は、その名前空間に属するテナントからの負荷によって異なります。 負荷が高くなり、マイクロサービスのCPU使用率が高くなると、サービスのレプリカが自動的に作成されます。 負荷が低下してCPU使用率が低下すると、それに応じてレプリカの数が減少します。 次の目標は、アプリケーションのカスタムメトリックで水平ポッドオートスケーラーを使用することです。
すべてのマイクロサービスはLogicMonitorで監視されています。 これは、モニターダッシュボードの例です。 これは、CPU使用率の変更により、コンテナーレプリカの数が自動的にスケールアップおよびスケールダウンされたことを示しています。
マイクロサービスのKPI監視にはLogicMonitorを使用します。 KPIメトリックには、次のものが含まれますが、これらに限定されません。
異常検出マイクロサービスダッシュボードの例を次に示します。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
