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

はじめに

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

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

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

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

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

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

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

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

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

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

各マイクロサービスに独自のデータベースを提供することで、このカスケード効果を分離し、開発者が調整を減らし、自信を高めて必要な変更を加えることができるようにします。これは、サービスを、適切に定義されたインターフェースを通じてのみ相互に対話する、個別の焦点を絞ったコンポーネントとして管理するという目標をさらに推進します。

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

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

結論

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

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