マイクロサービスのマルチテナント

Question

マイクロサービスアーキテクチャを使用してSaaSマルチテナント（個別のデータベース））を作成しています。これにより、私とマネージャーの間で、マルチテナントまたはデータベースは、どのテナントであっても（サービスを提供している各サービス）、サービスに関連付けることができます。

マイクロサービスについて私が理解していることから、各サービスはデータレイヤーまでのスタンドアロンアプリケーションですが、マルチテナントにはテナントIDを渡すためのルーター/永続レイヤーと共有データベースが必要です（これはAPIゲートウェイポリシー）。したがって、このようにして、マイクロサービスはSOA=になります。データレイヤーへの単一のポイントに接続するからです。

私たちが何度も議論した点：

1つのデータベースでの管理性、または各テナントの個別のデータベース（一方が容易であれば、他方の悪夢）は？
- バックアップ
- 負荷分散
データベースがクラッシュした場合、またはデータが失われた場合どっちがいい？
マイクロサービスアプリケーションのマルチテナントデータベースアプローチの実現可能性をどのように測定できますか？
セキュリティに関して、マルチテナントでテナントの分離を除外した場合、他に勝るものはありますか？

PS：一部のサービスには、個別にバランスを取る必要のある大きな負荷がかかるため、マイクロサービスは必須です

Berin Loritsch · Accepted Answer

ボトムラインアップフロント：妥協から始める必要があるでしょう。

マイクロサービスとマルチテナンシーは難しいです。ソリューションの実行、保守、構築にかかるコストのトレードオフを検討する必要があります。その答えは、システムをより堅牢かつ安全にするものと矛盾します。課題は、プロジェクトを開始する必要がある場所、および現時点で受け入れる必要がある妥協点を把握することです。

心に留めておくべき2つの公理があります。

複雑さとコストは直接関係します。複雑なものほど、ビルドして維持するのにコストがかかります。
分離されたシステムは一般に安全ですが、より複雑でもあります。2つのテナントデータが接触しない場合、他のテナントに影響を与えることはできません。
私たちはすべてFaceBookではありません。ほとんどの企業は、分離とそれに伴う必要な複雑さよりもコストを心配する必要があることを意味します。

さまざまなトピックを分析し始めると、ある回答の方が正しいことは別の回答には正しくないことがわかります。たとえば、最初のトピックと2番目のトピックの答えは異なります。

保守性

1つは、いくつかのものよりも保守が簡単です。それはあなたのデータベースにとってさらにうまくいきます。

1つの大きな共有データベースクラスターを使用すると、以下の管理が容易になります。

復元する
クラスターの負荷分散

少なくとも彼らはある程度まではそうなるでしょう。発生する可能性のある問題は、アプリケーションのテナントの1つに、他のテナントよりもはるかに多くの要求があるということです。データベースがテナント間の共有リソースである場合、最終的にスーパーユーザーが他のテナントへのサービスに影響を与える状況に遭遇します。それはあなたが初日に心配する必要があるものではないかもしれません。

災害の影響

データベースがダウンした場合は、データベースサーバーを復元してから、最新のバックアップを復元する必要があります。

ダウンしたデータベースサーバーがサービスを提供するすべてのテナントが影響を受けます。
- すべてのテナントの1つのデータベースは、すべての顧客が影響を受けることを意味します
- テナントごとにデータベースを分けると、影響を受けるのはテナントのみになります。
一部のデータベースはスケールアウトするように設計されています
- シャーディングは、クラスター内の複数のノードにデータを分散します
- レプリケーションにより、これらのノードに分散するデータに冗長性が追加されます
- これらは、単一のノードが失われ、データやサービスを失うことなく交換できるように設計されています

スケールアウトするように設計されたデータベースを調べることは価値があります。例としては、Apache Cassandra、Mongo DB、Raven DBなどがあります。ほとんどの NoSQL データベースは、この概念に基づいて設計されています。その結果、1つの「論理」データベースがあることになりますが、複数の処理ノードを使用すると、必要に応じて容量を拡張できます。必要な堅牢性と安全性を確保しながら、データ設計を簡素化することは、価値のある妥協となる場合があります。

マルチテナントデータベースアプローチの実現可能性

それはあなたが評価しなければならないものです。お互いに比較検討しているアプローチは次のとおりです。

すべてに1つのデータベース
テナントごとに1つのデータベース
マイクロサービスごとに1つのデータベース
テナントごとのマイクロサービスごとに1つのデータベース（最大限に分離）

代替案の有用な分析を実行するには、以下を定義する必要があります。

主要なパフォーマンス分野/要件-アプリにとって何が重要かを理解する
ソリューションのコスト
各アプローチを実装するために必要なTシャツサイズの見積もり

グラフを作成し、各アプローチがこれらのチェックマークにどのように当たるかを確認してから、決定を下します。複雑さとコストが直接関連しているという公理を覚えていますか？あなたが今しなければならない決定は、専門家が言うことは最も正しいことではないかもしれません。あなたは予算の制約の範囲内で生活しなければなりません。アプリケーションがより多くの収益をもたらすと、予算が増加します。これにより、今は考えられない方法でシステムを更新できます。

セキュリティ

セキュリティは複雑なトピックであり、非常に多くの側面があるため、国の実際の法的要件に基づいて、またはクライアントが要求する決定を行わなければなりません。以下は、セキュリティ関連の概念の一部です。

否認防止（つまり、ユーザーは実行したアクションを拒否できない）
監査（つまり、悪意のある俳優を見つけるためにユーザーが実行したアクションを再構築できます）
データ保護（つまり、ユーザーは表示を許可されていない情報を表示できません）
インフラストラクチャのセキュリティ（ネットワークアクセス、ファイルアクセスなどが適切に保護されている）
データの暗号化（つまり、ユーザーはネットワークパケットをスニッフィングして他人のデータを発見することはできません）

それだけではありません。多くのセキュリティ面は、選択肢全体で一定です（暗号化、インフラストラクチャセキュリティなど）。ただし、データベース内に複数のテナントからのデータがない場合、データ保護の概念に対する答えはより安全です。ユーザーがデータベースに直接アクセスできない場合は、問題にならない場合があります。

セキュリティの問題に対処するときは、実際に何を処理する必要があるかを理解するのが最善です。

準拠する必要のある法的要件はありますか？（英国および他のいくつかの国では、ユーザーのプライバシーに関する法律が非常に厳格ですが、他の国ではありません）
クライアントが要求する基準はありますか？
セキュリティを向上させるためにできる簡単で低コストなことはありますか？

ユーザーのプライバシーに関する法律を考慮した場合でも、銀行や医療システムのセキュリティ要件は、ソーシャルネットワーキングアプリに必要なものよりもはるかに大きくなります。

まとめ

チーム（マネージャーを含む）は、以下を定義する必要があります。

要件-マルチテナントアプリケーションに実際に必要なもの、およびセキュリティ要件
制約-予算、スケジュール、ツール（使用できないツールを定義するショップもあれば、使用する必要のあるツールを定義するショップもある）
主要パフォーマンス領域-パフォーマンス基準、管理サポートなどが含まれます.

これらがなければ、アプリケーションの固有の要求に適合するものに満足することはできません。最も適切なことは、アプリケーションごとに少し異なることになります。これは、作業する必要のある固有の要件と制約が、実際のものに影響を与えるためです。