モノリスからマイクロサービスへ

今日、モノリシックアプリケーションは、すべての機能がXNUMXつのユニットに配置されているため、処理するには大きすぎるように進化しています。 多くの企業は、それらをマイクロサービスアーキテクチャに分解する必要があります。

LogicMonitorには、いくつかのレガシーモノリシックサービスがあります。 ビジネスが急速に成長するにつれて、スケールアウトはオプションではなかったため、これらのサービスをスケールアップする必要がありました。 

最終的に、私たちの最大の問題点は次のようになりました。

• サービスをスケールアップするコストは高かった。
• 新機能には、Javaで最適化されていないML / AIアルゴリズムが必要でした。
• 新しい機能の場合、QA、展開、およびメンテナンスのオーバーヘッドは莫大でした。
• 新しいエンジニアのオンボーディングは長く苦痛でした。

この記事では、MonolithとMicroservicesの両方の利点、Microservice、Kafka Microservice通信からの特定の要件、およびデータを分散して負荷を分散する方法について説明します。

モノリスとマイクロサービス

モノリスアプリケーションは、すべての機能がXNUMXつのユニットに組み込まれているアプリケーションです。 マイクロサービスアプリケーションは、単一のユニットを分解する小さなサービスです。 それらは独立して実行され、連携して動作します。 以下は、MonolithとMicroservicesの両方の利点です。 

モノリス：

アプリケーションの複雑さが高くなく、かなり静的でなく、エンジニアの数が「少ない」限り、次のようになります。

• デバッグとテストが簡単 –エンドツーエンドのテストをはるかに高速に実行できます。
• 導入が簡単 –展開はXNUMXつだけです。 
• 開発が簡単 –通常、すべての知識は少数の主要なエンジニアに存在します。
• 管理が容易 –ロギングとパフォーマンスモニタリングは簡単に設定できます。

マイクロサービス：

マイクロサービスは、スケーラブルなアプリケーションを構築し、複雑なビジネス上の問題を解決する上で多くの利点を提供します。

• 簡単な拡張で –各マイクロサービスには非常に特殊なジョブがあり、他のコンポーネントのジョブとは関係ありません。
• パフォーマンスの最適化 –ホットサービスを分離し、他のアプリケーションとは独立してスケールアップ（イン/アウトまたはアップ/ダウン）できます。
• QAとテストが簡単 –各サービスは、明確に定義された入力と出力を使用して自己テストできます。
• 分離 –分離されたサービスは、さまざまなアプリ（WebクライアントやパブリックAPIなど）の目的に対応するために、再構成および再構成も簡単です。 
• さまざまな開発スタック –各サービスは、それ自体に最適な開発スタックを使用して実装できます（たとえば、Python JavaとGoを使用しています）。
• 優れた復元力とフォールトトレランス –分離されたモジュールは、XNUMXつのモジュールのバグがサービス全体をダウンさせるのを防ぎます。 
• 導入が簡単 –マイクロサービスの開発と展開の時間ははるかに短くなります。 

マイクロサービスの要件  

LogicMonitorは、XNUMX日あたり数十億のペイロード（データポイント、ログ、イベント、構成など）を処理します。 高レベルのアーキテクチャは、データ処理パイプラインです。

パイプライン内の各マイクロサービスに対する要件は次のとおりです。

• 各マイクロサービスコンポーネントはステートレスである必要があります（必要に応じて、状態はデータストアに保持されます（Redis、Kafkaなど））。
• 各マイクロサービスコンポーネントは、Xミリ秒でタスクを完了する必要があります
• 各マイクロサービスはk8sコンテナベースであり、動的にスケールアウト/スケールインできます
• エンドツーエンドパイプラインはXミリ秒未満である必要があります
• マイクロサービスのウォームアップ時間はXミリ秒未満である必要があります
• 各マイクロサービスは、X個のCPUコアとY個のGBメモリによって制限されます 
• コスト（インフラストラクチャ/ツール）は、ペイロードあたり年間Xドル未満である必要があります
• 各マイクロサービスは生成する必要があります 有用なログとメトリック 監視用

現在、Java、Python、Goでマイクロサービスが実装されています。 各マイクロサービスはKubernetesクラスターにデプロイされ、メトリックに基づいて自動的にスケールアウトするか、KubernetesのHorizo​​ntal PodAutoscalerを使用してスケールアウトできます。

Javaの場合、複数のマイクロサービスフレームワークを評価した後、新しいJavaマイクロサービスでQuarkusを使用することにしました。 Quarkusは、Java仮想マシン（JVM）用に調整されたKubernetesネイティブのJavaフレームワークです。 

Quarkusを選んだ理由の詳細については、 クォークス対春 ブログ。 

データを分散して負荷を分散する方法

LogicMonitorによって監視されるデータポイントを処理および分析するためのマイクロサービスを実装しました。 各マイクロサービスは、受信データに対して特定のタスクを実行します。 

いくつかのテクノロジーを評価した後、使用することにしました カフカ マイクロサービス間の通信メカニズムとして。 Kafkaは、ストリーミングメッセージのパブリッシュおよびサブスクライブに使用できる分散ストリーミングメッセージプラットフォームです。 Kafkaは、大量のストリーミングデータに対して、高速でスケーラブルで耐久性のあるメッセージプラットフォームを提供します。 

Kafkaトピックを分割する方法

当社のマイクロサービスは、Kafkaトピックを使用して通信します。 各マイクロサービスは、いくつかのKafkaトピックからデータメッセージを取得し、処理結果を他のいくつかのトピックに公開します。 

Kafkaの各トピックはパーティションに分割されています。 トピックのデータを消費するマイクロサービスでは、複数のインスタンスが実行されており、それらは同じコンシューマーグループに参加しています。 パーティションは、グループ内のコンシューマーに割り当てられます。 サービスがスケールアウトすると、さらに多くのインスタンスが作成され、コンシューマーグループに参加します。 パーティションの割り当ては、コンシューマー間で再調整されます。 各インスタンスは、作業するXNUMXつ以上のパーティションを取得します。 

この場合、パーティションの総数によって、マイクロサービスがスケールアップできるインスタンスの最大数が決まります。 トピックのパーティションを構成するときは、大量のデータを処理するために必要なマイクロサービスのインスタンスの数を考慮する必要があります。

データの配布とバランス調整

マイクロサービスがデータメッセージをKafkaトピックのパーティションに公開する場合、パーティションはランダムに、またはメッセージのキーに基づくパーティショニングアルゴリズムに基づいて決定できます。 

同じデバイスからの時系列データメッセージが同じパーティションに順番に到着し、順番に処理されるように、メッセージキーとして内部IDを使用することを選択しました。

複数のパーティションにわたるトピックのデータは、バランスが崩れる場合があります。 私たちの場合、一部のデータメッセージは他のパーティションよりも多くの処理時間を必要とし、一部のパーティションには他のパーティションよりも多くのそのようなメッセージがあります。 これにより、一部のマイクロサービスインスタンスが遅れます。 この問題を解決するために、データメッセージを複雑さに基づいてさまざまなトピックに分け、コンシューマーグループをさまざまに構成しました。 これにより、サービスをより効率的にスケールインおよびスケールアウトできます。

マイクロサービスの状態を維持する場所

一部のマイクロサービスはステートフルであるため、拡張が困難です。 この問題を解決するために、 Redisクラスター 状態を維持します。 

Redis Clusterは、複数のRedisノードの分散実装であり、高速なインメモリデータストアを提供します。 これにより、アルゴリズムモデルを高速に保存およびロードでき、必要に応じてスケールアウトできます。

製品概要 

モノリスをマイクロサービスに移行することは、場合によっては数年かかることがある旅です。

LogicMonitorでは、XNUMX年前にこの旅を始めました。 投資収益率については議論の余地がありません。 メリットには次のものが含まれますが、これらに限定されません。

• 開発の生産性が向上し、技術的負債が削減されます。 
• サービスはより回復力があり、パフォーマンスが向上します。 
• 継続的デプロイがより簡単になり、サービスのダウンタイムが発生しません。
• サービスを拡張する方が簡単で効率的です。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。