マイクロサービスアーキテクチャでマイクロサービスごとに個別のデータベースが必要な場合、コストがかかりすぎて管理できません。なぜそれが必要なのですか？
私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。 Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか？データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？これについて教えてくれませんか？
なぜそれが必要なのですか？
あなたはしません
サービスごとに個別のデータベースを作成すると、ドメインの境界を強制するのに役立ちますが、これは1つの方法にすぎません。すべてのサービスで同じデータベースを共有することを妨げるものは何もありません。
サービスが動作し、他のサービスが所有するデータに対して予期しないことを行わない限り、問題はありません。
何を読んでいるかはわかりませんが、マイクロサービスアーキテクチャについてはさまざまな見解があることに注意してください。これは、このトピックに関する優れたブログ投稿です。
「各マイクロサービスは独自のデータベースを所有および制御する必要があり、2つのサービスがデータベースを共有するべきではない」として、一部の人がこのアイデアを部分的に参照するのを見てきました。アイデアは適切です。サービス間で単一のデータベースを共有しないでください。競合する読み取り/書き込みパターン、データモデルの競合、調整の課題などの競合が発生するためです。
しかし、単一のデータベースは、私たちに多くの安全性と便利さを提供します：ACIDトランザクション、単一の場所、よく理解されている（ちょっと？）、1つの管理場所など。
マイクロサービスへの旅はそれだけです：旅。会社ごとに異なります。 明確で速いルールはなく、トレードオフのみです。
ダンウィルソンが答えるように、あなたは本当にそれを必要としません。マイクロサービスは新しいホットなものであり、すべての新しいホットなものと同様に、人々は多くの価値を提供しなくても多くの場所でそれらを使用します。
マイクロサービスを使用すると、「マイクロ」レベルで個別にデプロイおよびスケーリングできます。この細分性により、開発チームをより適切に分離したり、1つの大きなリリースではなく必要に応じてリリースしたり、新しいテクノロジーやプロセスを個別に試したりすることができるため、多くの技術的利点と非技術的利点がもたらされます。 DBに依存しているため、その多くが発生します。他のサービスのデータを気にせずにサービスをデプロイできない場合は、失われています。
データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？
とはいえ、あなたもまた間違いです。
クラウドで作業している場合、データベースは安価です。通常無料！もちろん、serverはコストがかかりますが、マイクロサービスごとの個々のサーバーについては話していません（少なくとも、最初はそうではありません）。一連の（論理）データベースを備えた単一のサーバーは、クロスデータベースクエリ（「独立してデプロイ可能でスケーラブル」に害を及ぼす依存関係を導入する）を回避することに熱心であれば、問題ありません。地獄、クロスDBクエリは、Azure SQLのような一部のクラウドデータベースサービスでは不可能です。あなたはそこに勤勉である必要すらありません...
また、データベースを共有するマイクロサービスを見たこともありますが、各サービスには独自のスキーマがあります。繰り返しになりますが、データの境界を越えるクエリを回避することに注意を払う必要があります。
多くの場所はそれほど勤勉ではありません。彼らには、エントリレベルの開発者、またはマイクロサービスアプローチを評価しない人、貧しいチームリード、またはタイムラインのプレッシャーがあり、人々がショートカットを実行する原因となっています。
独立したデータベースを持つことは、サービスの独立性を可能にする分離を実施する最もクリーンな方法ですが、それが唯一の方法ではありません。そして、それはthat高価ではありません-特に、共有データベースでデータ境界を強制するために費やした時間/給与と比較すると、特にそうです。
なぜそれが必要なのですか？
マイクロサービス、そしてより大部分は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データベースまたはファイルシステムを使用できます。
これらすべてのサービスは、単一のデータベースインスタンス/サーバーを共有することもでき、サービスごとに分離されたスキーマしかありません。
ここでの重要な論点は、サービスがそのデータを所有および制御する必要があるということです。それをどのように達成するかは、選択と技術的な詳細の問題です。
サービスがデータを所有および制御できる最良の方法は、独自の「個人用」データベースを用意することです。これにより、テクノロジーとデータスキームの進化を自由に選択できます。他のサービスがサービスが所有するデータにアクセスできる唯一の方法は、サービスからデータを要求することです。このように、内部データ表現を変更する必要がある場合、簡単に変更でき、他のサービスが中断することはありません。
要約すると、サービスごとにデータベースを持つことは必ずしも高価ではなく、必要でもありません。これは、マイクロサービスを開発するときに、ある時点で行う必要がある決定です。それぞれの選択肢には、その意味と制限があります。それらを研究し、あなた自身の選択をしてください。