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

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

今日、モノリシックアプリケーションは、すべての機能が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トピックをクライアントIDで分割し、スケールアウト/インする方法を示す図

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

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

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

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

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

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

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

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

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

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

サマリー 

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

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

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

サラハン

シニアソフトウェアエンジニア

サラハンはLogicMonitorの従業員です。

LogicBlogを購読して、LogicMonitorの最新の開発に関する最新情報を入手し、ITエキスパートとエンジニアのワールドクラスのチーム、およびITプロフェッショナルが愛する製品。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET