理解するマイクロサービス建築

チームが次の状態から移行するときモノリシックアプリケーションマイクロサービスアーキテクチャを使用すると、達成感を感じることがよくあります。アプリケーションをより小さく管理しやすいサービスに分割するというアイデアは、革新的であるように思えます。各サービスは個別に開発、展開、拡張できるため、柔軟性と速度が向上します。しかし、実際のトラフィックが急増すると、興奮はすぐに不満に変わる可能性があります。

マイクロサービスでは独立したスケーリングとデプロイが可能ですが、多くのチームは重大な間違いを犯しています。それは、すべてのサービスを単一の共有データベースにリンクしているということです。これは、分散モノリスという一般的な落とし穴につながります。このアーキテクチャは、特に負荷が高い場合に、スケーリング時に重大な課題を引き起こす可能性があります。

マイクロサービスの本質を理解することが重要です。マイクロサービスは、アプリケーション開発をより小さな焦点を絞った部分に分割することで、簡素化することを目的としています。通常、各サービスは単一の機能を実行し、API を通じて他のサービスと通信します。このモジュール式のアプローチにより、保守性が向上し、システム全体に影響を与えることなく、個々のコンポーネントを簡単に更新できるようになります。

分散モノリスとは何ですか?

分散モノリスは、サービスを個別に拡張しようとすると発生しますが、それらはすべて同じデータベースに依存します。すべてのサービスが同じソースにリクエストを送信するため、この設定ではボトルネックが発生します。通常、これがどのように展開されるかは次のとおりです。

複数のサービスがリクエストを 1 つのデータベースに集めます。これにより、大量の同時リクエストが発生し、データベースに負荷がかかる可能性があります。
トラフィックの増加はデータベースの過負荷につながり、速度低下やタイムアウトを引き起こす可能性があります。
遅延の問題が発生し、応答時間が遅くなり、ユーザーがイライラし、ビジネスパフォーマンスに影響を与える可能性があります。

つまり、サービスが拡張できても、データベースがそれに追いつくことができないのです。この不一致により、マイクロサービスが期待どおりに実行されていないという認識につながることがよくあります。

という幻想スケーラビリティ

マイクロサービスは、システムの各部分を個別に拡張するという魅力的な約束を提示します。しかし、この約束は誤解を招く可能性があります。よくあることは次のとおりです。

サービスはサイロで開発および展開されるため、チーム間の調整が不足する可能性があります。
各サービスは水平方向に拡張するように設計されており、サービスのインスタンスを追加して負荷の増加に対処できます。
すべてのサービスは単一のデータベースインスタンスを共有するため、競合とパフォーマンスの問題が発生します。

このアプローチでは、多数の接続とクエリによってデータベースが過負荷になる状況が生じます。マイクロサービス自体に問題があるわけではありません。むしろ、共有データベースが危機点となります。たとえば、サービス B がデータを書き込んでいる間にサービス A がデータを読み取る必要がある場合、競合が発生して遅延が発生します。

その結果、チームは新機能の開発に集中するよりも、データベースパフォーマンスのトラブルシューティングに多くの時間を費やすことになる可能性があります。これはフラストレーションや生産性の低下につながる可能性があります。

データベースの過負荷の一般的な症状

アプリケーションが拡大するにつれて、データベースに負担がかかっている兆候に気づく場合があります。これらの症状を早期に認識することで、将来の大きな問題を回避できます。一般的な兆候は次のとおりです。

遅延の増加:リクエストの処理に時間がかかり、ユーザーエクスペリエンスの低下につながります。
接続プール疲労困憊:データベースは、サービスによって要求された同時接続の数を処理できません。
トランザクションロック:過剰なロックが発生し、他のトランザクションの進行が妨げられる場合があります。

これらの症状は一時的な速度の低下を示すだけではありません。これらは、アーキテクチャの構造に関するより深い問題を示唆しています。たとえば、サービスで多数のタイムアウトが発生している場合、データベースがリクエストを十分に迅速に処理できないことが原因である可能性があります。

レイテンシのスパイクを理解する

データベースの過負荷の最初の警告兆候の 1 つは、遅延のスパイクです。これはエラーやクラッシュなしで発生しますが、リクエストが徐々に遅くなるという形で現れます。この状況がどのように発展するかは次のとおりです。

サービス A は新しいエンドポイントを導入し、データベースの負荷を増加させるいくつかのクエリを追加します。
サービス B は、特にデータベースがそのようなクエリに対して最適化されていない場合、負荷を増加させる複雑な結合操作を実行します。
サービス C は数秒ごとにデータをポーリングするため、データベースにさらに負荷がかかり、問題が複雑になります。

個人的には、これらの変更は無害に見えるかもしれません。ただし、これらが集合すると、データベースが過負荷状態になり、需要に対応するのに苦労する可能性があります。ここでの実際的な例は、複数のサービスが製品データベースと対話する単純な電子商取引アプリケーションです。注文サービスが新しい注文を書き込もうとしている間に、製品詳細サービスが製品情報をクエリすると、データベースが同時負荷を処理できない場合、両方のサービスで大幅な遅延が発生する可能性があります。

マイクロサービスのスケーリングに関する重要な考慮事項

🚫

共有データベースを避ける
サービスリクエストのボトルネックを防ぎます。

💾

キャッシュ戦略の実装
データベースの負荷を軽減し、応答時間を短縮します。

🔑

データの所有権を確保する
明確なデータ責任をサービスに割り当てます。

🌉

APIゲートウェイを使用する
トラフィックを管理し、サービス通信を改善します。

⏳

モニターの遅延の問題
応答時間の遅さを特定して解決します。

監視ツールは、このような遅延のスパイクを特定するのに非常に役立ちます。 New Relic や Datadog などのツールはデータベースのパフォーマンスに関する洞察を提供し、チームが速度低下の正確な原因を特定するのに役立ちます。

サービスのスケーリングの影響

サービスをスケーリングすると、予期しない課題が発生する可能性があります。たとえば、サービスインスタンスの数を 2 から 20 に増やすと、いくつかの影響が生じる可能性があります。

よりオープンな接続:新しいサービスインスタンスごとにデータベースへの接続が必要となるため、同時接続数が増加します。
アイドル状態のトランザクションの増加:これらのトランザクションはリソースを消費し、データベースの速度を低下させる可能性があります。
ロック競合の可能性が高くなります:複数のインスタンスがデータベースに書き込もうとすると、ロックが発生し、遅延が発生する可能性があります。

アプリケーションはサービスの遅延は許容範囲内であると報告するかもしれませんが、実際には、データベースはリクエストの流入に苦戦しています。サービスのスケーリングはデータベースのスケーリングと同じではないことを認識することが重要です。

接続をより効果的に管理するには、接続プーリング戦略の実装を検討してください。たとえば、HikariCP のような接続プールマネージャーを使用すると、同時接続の数を制限し、データベースの応答性を確保できます。

なぜキャッシング完全な解決策ではない

この時点で、通常、誰かが解決策としてキャッシュの実装を提案します。キャッシュによって応答は確かに高速化されますが、根本的な問題は解決されません。

書き込みには引き続き同じデータベースへのアクセスが必要です。キャッシュされた読み取りによりパフォーマンスが向上しますが、書き込み操作は依然としてデータベースにアクセスします。
キャッシュの無効化は複雑なタスクになる可能性があります。キャッシュとデータベースの同期を維持すると、不整合が生じる可能性があります。
サービス間でのデータの一貫性を維持するのは困難な場合があります。サービスが異なればキャッシュ状態も異なる可能性があり、データが古くなってしまう可能性があります。

本質的に、キャッシュは構造的な解決策ではなく、一時的な修正として機能します。一部の症状は軽減される可能性がありますが、共有データベースの過負荷という根本的な問題には対処できません。実際的なアプローチは、Redis や Memcached のような分散キャッシュメカニズムを実装することです。ただし、落とし穴を避けるためにキャッシュ戦略を慎重に設計することが重要です。

たとえば、アプリケーションがデータベースにクエリを実行する前に、まずキャッシュにデータがあるかどうかを確認するキャッシュアサイドパターンを検討できます。データが見つからない場合は、データベースから取得してキャッシュに追加できます。このアプローチは、頻繁にアクセスされるデータをすぐに利用できるようにしながら、データベースの負荷を軽減するのに役立ちます。

中心的な問題: データベースの所有権の共有

多くのマイクロサービスアーキテクチャの根本的な問題は、データベースの所有権の共有です。この設定は複雑さと非効率をもたらします。

密結合されたサービス:各サービスはデータベーススキーマと密接に結合するため、他のサービスに影響を与えずに 1 つのサービスを変更することが困難になります。
1 つのサービスの変更が他のサービスに意図せず影響を与える可能性があります。1 つのサービスがデータベーススキーマを変更すると、他のサービスの機能が損なわれる可能性があります。
運用の複雑さは次のように増加します。サービスの数が増えるにつれて、データベースアクセスの管理とパフォーマンスの確保はますます困難になります。

マイクロサービスの利点を真に活用するには、データの管理方法とアクセス方法を再考することが重要です。効果的な解決策の 1 つは、各サービスがデータを所有するマイクロサービスデータ管理パターンを採用することです。このアプローチにより、共有データベースの問題が解消され、より効率的なサービス対話が可能になります。

たとえば、ユーザーサービス、注文サービス、製品サービスがある場合、それぞれがデータベースを維持できます。ユーザーサービスはユーザーデータを管理し、注文サービスは注文情報を処理し、製品サービスは製品の詳細を処理します。この分離により、共有データベースにボトルネックを引き起こすことなく、各サービスを独立して拡張できます。

効果的なマイクロサービスのスケーリングのための戦略

マイクロサービスアーキテクチャを効果的に管理するには、次の戦略を検討してください。

データ所有権を分散化:各サービスは独自のデータを所有する必要があり、結合を減らし、独立したスケーリングを可能にします。
API ゲートウェイを実装します。ゲートウェイを使用してリクエストを管理し、データベースの直接のやり取りを減らします。これは、サービス間の通信を合理化するのに役立ちます。
イベントソーシングを使用します。変更をイベントとしてキャプチャし、データベースに直接アクセスしなくてもサービスが反応できるようにします。これにより、アーキテクチャの応答性が向上する可能性があります。
データベースのシャーディングを検討してください。データベースをより小さく、管理しやすい部分に分割します。これにより、さまざまなサービスが独自のデータベースシャードと対話できるようになり、競合が軽減されます。
クエリの最適化:データベースクエリが効率的であることを確認します。遅いクエリを分析およびリファクタリングして、パフォーマンスへの影響を最小限に抑えます。

これらのアプローチは、マイクロサービスの利点を維持しながら、共有データベースによってもたらされる課題を軽減するのに役立ちます。

マイクロサービスを効果的にスケーリングする

デカップリングサービス

サービスが独立して動作することを確認します。

データベースの配布

サービスごとに個別のデータベースを割り当てます。

リクエストの最適化

同時リクエストの数を減らします。

負荷分散の実装

トラフィックをサービス間で均等に分散します。

マイクロサービス実装の成功例

いくつかの組織は、データベースの過負荷を回避しながらマイクロサービスの実装に成功しています。例えば：

Netflix:マイクロサービスと独立したデータストレージを組み合わせて使用し、高いトラフィック負荷をサポートします。彼らは、大規模なインフラストラクチャを効果的に管理できるようにする独自のデータ戦略を採用しています。
ウーバー:イベント駆動型アーキテクチャを実装し、データベースに直接依存せずにサービスが通信できるようにします。このアーキテクチャにより、何百万もの乗車とトランザクションをシームレスに処理できるようになります。

両社は、適切なデータ管理がマイクロサービスのスケーリングの成功にどのようにつながるかを示しています。彼らは、大規模なアプリケーションでマイクロサービスを効果的に利用する方法に関する業界標準を設定しました。

これらの例に加えて、中小企業も成功を収めています。たとえば、新興企業はマイクロサービスを使用して、各サービスが支払い、商品リスト、ユーザーアカウントなどの特定の側面を処理する単純な e コマースプラットフォームを構築する場合があります。各サービスが独自のデータベースを確実に持つことで、データベース層でボトルネックになることなく、必要に応じて各部分を拡張できます。

結論

結論として、マイクロサービスはスケーラブルなアーキテクチャへの道を提供しますが、共有データベースと組み合わせると重大な課題を引き起こす可能性もあります。このセットアップの制限を理解することは、パフォーマンスを妨げる可能性のある落とし穴を避けるために非常に重要です。適切に設計されたマイクロサービスソリューションは、アプリケーションの俊敏性と応答性の向上につながります。

マイクロサービスアーキテクチャの最適化をさらに詳しく知りたい場合は、次のようなツールを検討することを検討してください。無料のオンラインチャートメーカーデータの視覚化に。データの所有権を分散し、サービスがデータベースと対話する方法を再考することで、真にスケーラブルなマイクロサービスアーキテクチャを実現できます。