マイクロサービスアーキテクチャがマイクロサービスごとに個別のデータベースを必要とする場合、コストがかかりすぎて管理できません。なぜそれが必要なのですか？

私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか？データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？これについて教えてくれませんか？

なぜそれが必要なのですか？

あなたはしません。

サービスごとに個別のデータベースを作成すると、ドメイン境界を強制するのに役立ちますが、これは1つの方法にすぎません。すべてのサービスで同じデータベースを共有することを妨げるものは何もありません。

サービスが動作し、他のサービスが所有するデータに対して予期しないことを行わない限り、問題はありません。

何を読んだのかはわかりませんが、マイクロサービスのアーキテクチャについては多くの異なる意見があることに注意してください。これは、このトピックに関する優れたブログ投稿です。

「各マイクロサービスは独自のデータベースを所有および制御する必要があり、2つのサービスがデータベースを共有するべきではない」として、一部の人がこのアイデアを部分的に参照するのを見てきました。アイデアは健全です。サービス間で単一のデータベースを共有しないでください。競合する読み取り/書き込みパターン、データモデルの競合、調整の課題などの競合が発生するためです。

しかし、単一のデータベースは、私たちに多くの安全性と利便性を提供します：ACIDトランザクション、単一の場所、よく理解されている（ちょっと？）、1つの管理場所など。

マイクロサービスへの道のりは、まさに旅です。会社ごとに異なります。厳格なルールはなく、トレードオフがあります。

マイクロサービスの最も難しい部分：データ

ダンウィルソンが答えるように、あなたは本当にそれを必要としません。マイクロサービスは新しいホットなものであり、すべての新しいホットなものと同様に、人々は多くの価値を提供しなくても多くの場所でそれらを使用します。

マイクロサービスを使用すると、「マイクロ」レベルで個別にデプロイおよびスケーリングできます。この細分性により、開発チームをより適切に分離したり、1つの大きなリリースではなく必要に応じてリリースしたり、新しいテクノロジーやプロセスを個別に試したりすることができるため、多くの技術的メリットと非技術的メリットがもたらされます。 DBへの依存関係のため、その多くは。他のサービスのデータを気にせずにサービスをデプロイできない場合は、失われています。

データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？

そうは言っても、あなたはまた間違いです。

クラウドで作業している場合、データベースは安価です。通常無料！もちろん、サーバーには費用がかかりますが、マイクロサービスごとの個々のサーバーについては話していません（少なくとも最初は）。一連の（論理）データベースを備えた単一のサーバーは、クロスデータベースクエリ（「独立して展開可能でスケーラブル」に害を及ぼす依存関係を導入する）を回避することに熱心であれば、問題ありません。地獄、クロスDBクエリは、Azure SQLのような一部のクラウドデータベースサービスでは不可能です。あなたはそこに勤勉である必要さえありません...

また、データベースを共有するマイクロサービスを見たこともありますが、各サービスには独自のスキーマがあります。繰り返しになりますが、データの境界を越えるクエリを回避することに注意を払う必要があります。

多くの場所はそれほど勤勉ではありません。エントリレベルの開発者、マイクロサービスアプローチを重視しない人、チームのリードが貧弱な人、またはタイムラインのプレッシャーが原因で人々が近道をしている人がいます。

独立したデータベースを用意することは、サービスの独立性を可能にするデカップリングを実施する最もクリーンな方法ですが、それが唯一の方法ではありません。そして、それはありませんその高価な-あなたが共有データベースにデータ境界を強制しようとして費やした時間/給与と比較する場合は特に。

なぜそれが必要なのですか？

マイクロサービス、そしてより大部分はSOAの大きな利点は、実装だけでなく、使用されているテクノロジーも、内部の抽象化のレベルが高いことです。たとえば、システムが5つのチームによって5つのマイクロサービスの形式で開発されている場合、1つのチームが他のチームに意見を求めることなく、まったく異なる技術スタック（MicrosoftスタックからLAMPなど）に移行することを決定できます。

Amazon AWSまたはTwilioをご覧ください。それらのサービスがJavaで実装されているかRubyで実装されているか知っていますか？Oracle、PostgreSQL、Cassandra、MongoDBを使用していますか？彼らは何台のマシンを使用していますか？あなたもそれについて気にしますか？言い換えれば、これらの技術的な選択は、それらのサービスの使用方法に影響を与えていますか？...さらに重要なことに、それらが別のデータベースに移動する場合、それに応じてクライアントアプリケーションを変更する必要がありますか？

では、2つのサービスが同じデータベースを使用するとどうなるでしょうか。発生する可能性がある問題のごく一部を次に示します。

• サービス1を開発するチームは、SQL Server 2012からSQL Server 2016に移行したいと考えています。ただし、チーム2は、SQL Server 2016で削除された非推奨の機能に依存しています。

• サービス1は大成功です。2つのマシン（マスターとフェイルオーバー）でデータベースをホストすることは、もはや選択肢ではありません。ただし、クラスターを複数のマシンにスケーリングするには、シャーディングなどの戦略が必要です。一方、チーム2は現在のスケールに満足しており、他の何かに移動する理由はありません。

• サービス1は、デフォルトのエンコーディングとしてUTF-8に移行する必要があります。ただし、Service 2は、Code Page 1252 Windows Latin 1を使用して満足しています。

• サービス1は、特定の名前のユーザーを追加することを決定します。ただし、このユーザーはすでに存在しており、数か月前に2番目のチームによって作成されました。

• サービス1には多くの異なる機能が必要です。サービス2は非常に重要なコンポーネントであり、攻撃のリスクを軽減するためにデータベース機能を最小限に抑える必要があります。

• サービス1には15 TBのディスク容量が必要です。速度は重要ではないので、通常のハードディスクは完全に問題ありません。サービス2には最大50 GBが必要ですが、できるだけ速くアクセスする必要があります。つまり、データはSSDに保存する必要があります。

• ...

すべての小さな選択はすべての人に影響を与えます。すべての決定は、すべてのチームの人々が協力して行う必要があります。妥協する必要があります。それを、SOAのコンテキストでやりたいことを何でもできる完全な自由と比較してください。

[...]管理不能です。

その後、あなたはそれを間違っています。手動で展開していると思います。

これは物事が行われる方法ではありません。データベースを実行する仮想マシン（またはDockerコンテナー）のデプロイメントを自動化する必要があります。それらを自動化した後は、2台のサーバー、20台のサーバー、または2000台のサーバーの展開に大きな違いはありません。

分離されたデータベースの不思議な点は、非常に管理しやすいことです。何十ものチームが使用する巨大なデータベースを管理してみましたか？それは悪夢です。すべてのチームには特定の要求があり、何かに触れるとすぐに誰かに影響を与えます。アプリとデータベースを組み合わせると、スコープが非常に狭くなり、考える必要のあることがはるかに少なくなります。

巨大なデータベースが専門のシステム管理者を必要とする場合、1つのチームだけが使用するデータベースは基本的にこのチームで管理でき（DevOps もそれについてです）、システム管理者の時間を解放します。

それは高すぎる

コストを定義します。

ライセンス費用はデータベースによって異なります。クラウドコンピューティングの時代には、すべての主要企業がライセンスを再設計して、1つの巨大なデータベースではなく、多数の小さなデータベースが存在する状況に対応できると確信しています。そうでない場合は、別のデータベースへの移行を検討してください。ところで、オープンソースのものはたくさんあります。

処理能力について話している場合、仮想マシンとコンテナーはどちらもCPUに優しいので、1つの巨大なデータベースが同じ仕事をしている多くの小さなデータベースよりもCPUの消費量が少ないとは断言できません。

問題がメモリである場合、仮想マシンは適切な選択ではありません。コンテナです。必要以上に多くのRAMを消費しないことを知っていれば、必要なだけスパンすることができます。合計のメモリ消費量は、単一の大きなデータベースと比較して、多くの小さなデータベースの方が高くなりますが、その違いはそれほど重要ではないと思います。YMMV。

あなたが「高価」と考えるものに依存する。

データベースは、必ずしも高価な商用データベースサーバーである必要はありません（Oracleと考えてください）。要件に応じて、SQLiteデータベースまたはファイルシステムを永続的なデータストレージとして使用できます。

これらすべてのサービスは、単一のデータベースインスタンス/サーバーを共有することもでき、サービスごとに分離されたスキーマしかありません。

ここでの重要な議論は、サービスがそのデータを所有および制御する必要があるということです。それをどのように達成するかは、選択と技術的な詳細の問題です。

サービスがデータを所有および制御できる最良の方法は、独自の「個人用」データベースを用意することです。これにより、テクノロジーとデータスキームの進化を自由に選択できます。他のサービスがサービスが所有するデータにアクセスできる唯一の方法は、サービスからデータを要求することです。このようにして、内部データ表現を変更する必要がある場合、簡単に変更でき、他のサービスが中断することはありません。

要約すると、サービスごとにデータベースを持つことは必ずしも高価ではなく、必要でもありません。これは、マイクロサービスを開発するときに、ある時点で行う必要がある決定です。それぞれの選択には、その意味と制限があります。それらを研究し、あなた自身の選択をしてください。