マイクロサービスとモノリスがデータベースに与える影響

はじめに

アプリケーションアーキテクチャの最も一般的なアプローチとして、単一の大きなアプリケーションで機能が提供されるモノリシックアプリケーションと、機能が連携する小さなユニットに分割されるマイクロサービスアーキテクチャの2つがあります。これらの設計の選択は、開発体験、デプロイの容易さ、および運用フットプリントに関して、広範囲にわたる影響を与える可能性があります。

アプリケーションアーキテクチャが環境に影響を与える最も重要な方法の1つは、データベースとの連携にどう影響するかです。アプリケーション構造はデータ構造に影響を与えることが多く、データの保存場所や操作方法にも影響を与えます。このガイドでは、モノリシックとマイクロサービスの違い、特にこれらの決定がデータベースにどのように影響するかについて説明します。

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

ソフトウェア開発において、モノリスとマイクロサービスはともにアプリケーションアーキテクチャを記述するものです。

マイクロサービスはデータベースアーキテクチャにどのように影響するか？

上記で議論したアーキテクチャオプションは、開発プロセスがどのようなものになるか、そして本番環境でアプリケーションを運用することがどのようなものになるかに大きな影響を与えます。特に影響を受ける可能性のあるコンポーネントの1つがデータベースです。

モノリシックアプリケーションは、多くの場合、一元化されたデータベースとともにデプロイされます。アプリケーションは読み取り操作をレプリカに渡し、負荷をより均等に分散させる場合がありますが、一般的には、データはすべて1箇所にあります。この場合、一元化されたデータベースは、さまざまなアプリケーションコンテキストと機能に関連する情報を管理する責任を負います。

しかし、マイクロサービスは、より複雑なデータ環境と組み合わされることがよくあります。個々のマイクロサービスは、その特定のサービスのデータを管理することのみを目的とした独自のデータベースインスタンスとともにデプロイされることがよくあります。

サービス固有のデータベースを使用する利点と欠点

このパターンは、開発者が各マイクロサービスを独立して反復およびデプロイできるため、人気があります。開発における最大の調整点の1つは、データベースを変更するコードです。なぜなら、変更がアプリケーションの多くの異なる部分に影響を与える可能性があるからです。あるチームがデータベーススキーマを変更すると、以前のスキーマを期待して書かれた機能が壊れる可能性があります。

各マイクロサービスに独自のデータベースを与えることで、この連鎖的な影響を切り離し、開発者がより少ない調整とより大きな信頼性で必要な変更を加えることができます。これにより、サービスを明確に定義されたインターフェースを介してのみ互いにやり取りする、個別の集中型コンポーネントとして管理するという目標が推進されます。

ただし、マイクロサービスごとのデータベースパターンにも独自の課題がないわけではありません。マイクロサービスの数が増えるにつれて、個々のデータストアの数も増えます。チームは各新しいサービスについてデータベースのデプロイ、バックアップ、フェイルオーバー、その他の懸念を管理する必要があるため、運用要件は増加します。十分に開発されたツールと専門知識がなければ、これはかなり迅速に管理不能になる可能性があります。

開発者は、複数のマイクロサービスにまたがる可能性のあるクエリや更新をどのように調整するかについても考慮する必要があります。たとえば、注文が行われる場合、顧客データ、在庫データ、および注文情報自体は、異なるマイクロサービスによって管理される可能性があります。

まとめ

マイクロサービスパターンは、アプリケーションの拡張を支援し、組織として特定の開発およびデプロイタスクの調整を容易にすることができます。新しいコードがアプリケーションの他の部分に与える影響を制限しながら、より迅速に変更を反復およびリリースするのに役立ちます。

アーキテクチャの選択が、開発プロセス、インフラストラクチャ、および運用要件のさまざまな部分にどのように影響するかを理解することが重要です。マイクロサービスの場合、データベース環境はモノリシックデプロイとは大きく異なることがよくあります。生産性を維持するために、どのような変更を予期し、課題をどのように管理するかを理解することが重要です。