これは適切なアーキテクチャですか、それとも改善できますか？

ビジネス/企業の要件と私たちの建築家の好みの組み合わせにより、私には少し離れているように見える特定のアーキテクチャにたどり着きましたが、私は非常に限られた建築知識しかなく、クラウド知識がさらに少ないため、確認するための健全性チェックが大好きですここで行うことができる改善がある場合：

背景：ゼロから完全に書き直した既存のシステムの代替品を開発しています。これには、BAPI / SOAP Webサービスを介してSAPインスタンスからデータを調達し、SAPにないデータ用に独自のデータベースを使用する必要があります。現在、管理対象のすべてのデータは、分散アプリケーションのローカルDB、または移行元のMySQLデータベースに存在します。既存の分散アプリの機能を複製する一握りのWebアプリケーションを作成し、管理するデータに対して管理関連の機能を提供する必要があります。

ビジネス/エンタープライズ要件：

• 私たちが管理するデータベースは、MS SQL Serverに実装する必要があります

• 作成するデータベースの数を最小限に抑える

• フェーズ1では、アプリケーションをAzureにデプロイしますが、将来的にはこれらのアプリケーションをオンプレミスにする機能が必要です

• 運用チームは、コードの管理が大幅に簡単になると感じているため、すべてをドッキングすることを望んでいます。

• データの複製を最小化/排除

• コーディングスタックは、マイクロサービスと管理アプリの場合は.NET Coreになりますが、メインのフロントエンドアプリケーションの場合はAngular 5になります。

これらの要件から、私たちの建築家はこの設計を思いつきました：

私たちのフロントエンドは、一連のマイクロサービス（「ドメイン」レベルでかなり大きいため、この用語を軽く使用します）からフィードし、各ドメインで読み取りサービスと書き込みサービスに分割されます。どちらもスケーラブルで、Kubernetesを通じて負荷分散されます。それぞれには、データベース内の読み取り専用のコピーがコンテナ内にアタッチされており、読み取り専用コピーへの更新をプッシュする書き込みに使用できるdbの単一のマスターインスタンスがあります。

（低品質の画像については申し訳ありませんが、当然、建築家の頭を除いて、これに関する実際のドキュメントがないため、メモリからやり直しています。）

サービス間の通信は、各サービスがリッスンし、関連するメッセージを処理するメッセージキューを介して行われます。情報のために通信を提供するためのサービスを必要とするものはまだ特定されていないため、これの主な用途は電子メールの生成です。複数のサービスの関与を必要とする「ビジネスロジック」に関連するものは、フロントエンドから流れる可能性が高く、フロントエンドは各サービスを個別に呼び出し、原子性を扱います。

私の見解では、間違った方法でこすりつけているのは、読み取り専用のdbインスタンスがサービスのDockerコンテナー内でスピンアップしていることです。サービス自体とdbは、負荷の点で要求が大幅に異なるため、それらを個別に負荷分散できれば、はるかに理にかなっています。MYSQLには、マスター/スレーブ構成でそれを行う方法があると思います。この場合、負荷が高くなるたびに新しいスレーブを起動できます。特に、システムがクラウドにあり、インスタンスごとに支払いを行っている場合、別のdbインスタンスのみが必要なときにサービス全体の新しいインスタンスをスピンアップすると無駄になります（反対に、実際にちょうど新しいデータベースコピーをスピンアップすると、 Webサービスインスタンスが必要です）。ただし、これに対するMS SQL Serverの制限はわかりません。

私の最大の懸念は、MS SQL Serverの実装に関するものです。読み取り専用インスタンスをサービスに非常に密に結合すると、気分が悪くなります。これを行うより良い方法はありますか？

注：私はソフトウェアエンジニアリングについてこれを尋ねると、ここで私を指摘しました。これが適切なSEではない場合は、申し訳ありません。

また、MS SQL Serverタグはありません

私の最大の懸念は、MS SQL Serverの実装に関するものです。読み取り専用インスタンスをサービスに非常に密に結合すると、気分が悪くなります。これを行うより良い方法はありますか？

基本的に設計したのはキャッシングシステムです。サービスコンテナーにはデータのローカルコピーがあるため、読み取りのために余分なネットワークトリップを行う必要はありません。

ご指摘のとおり、より標準的なアプローチは、すべてのコンテナーが読み取り可能なリードレプリカのクラスターを用意することです。これにより、アプリケーションサーバーとは別にそれらをスケーリングできます。これは、通常、さまざまなものが必要になるためです（すべてのアプリケーションコンテナーに大量のRAMを割り当てますか？）。これにより、データベース読み取りのネットワーク呼び出しが追加されますが、それが問題であることが証明されるまでは、アーキテクチャを複雑にしてそれを解決することはしません。

それが問題になる場合、問題を処理するはるかに軽量な方法は、memcacheやredisなどの実際のキャッシュをローカルで実行することです。個々のオブジェクトのTTLを適切に調整すると、まれにしか要求されないデータが自動的にドロップされ、アプリケーションサーバーの負荷が軽減されます。

アーキテクチャについてはたくさん話すことができましたが、これはdevopsコミュニティなので、データベースのみを実行することについての主な懸念に対処します。

簡潔な答え：

マイクロサービスごとに "Azure SQL"と言うように設計を変更する場合は、問題ありません。各マイクロサービスは、独自の個別のAzure SQLデータベースインスタンスを持つことができます（共有クラスターで実行されている可能性がありますが、ユーザーには見えません）。後でオンプレミスに移動するには、kubernetesで「Azure SQLのような」セットアップを構築するか、単に従来のSQL Serverクラスターをオンプレミスで実行するかを決定できます。以下で説明するように、Azure SQLを使用しても、アーキテクチャがAzureに固定されません。

長い答え：

MS SQL Serverは、オープンソースデータベースやステートレスアプリケーションサービスと比較して、大量のメモリを必要とします。また、ソフトウェアライセンスが必要です（コストの最適化については以下で説明します）。そのため、ライセンス付きインスタンスをサービスごとに実行することは、特に費用対効果が高くない場合があります。1つのSQLServerインスタンスのライセンスを取得し、その上でサービスごとのプライベートデータベースを多数実行できます。SQL ServerのサービスとしてのマネージドデータベースバージョンであるAzure SQLをより適切に使用します。「SQL Server用Amazon RDS」を備えたAWSに移動できるため、Azureにロックされることはありません。本格的なクラウドプロバイダーは、すべての主要なデータベースに対して、専門的に管理されたデータベースサービスを提供します。

また、同じkubernetesポッドでデータベースを実行していることを指摘すると、アプリケーションサーバーのコードではそれらを個別にスケーリングできません。また、ステートレスアプリケーションサーバーは、永続的なストレージを持たないポッドで実行できます。その後、ステートレスアプリケーションサーバーが停止して、自由に再起動し、クラウドアベイラビリティゾーン間を簡単に移動できます。明らかに、データベースにはポッドが「所有」する永続的なストレージが必要です。したがって、データベースには永続的なボリュームの要求が必要です。これらを高可用性で実行する場合は、ステートフルセットとして実行する必要があります。アプリケーションサーバーと同じポッドでデータベースを実行することは、開発者がローカルで実行する可能性がありますが、SQL Serverの起動はコードよりも10倍遅いためお勧めしません。Macラップトップではなく、ポートを公開するSQL Server Dockerイメージを実行します。

マイクロサービスごとに非常に標準的なアーキテクチャと見なされ、独自の論理（ただし必ずしも物理的ではない）データベースを備えていますが、多数のレプリカを持つステートレスサービスとして実行するため、独立してスケーリングできます。また、AzureはRedisをキャッシュとして非常によくサポートしています。したがって、各マイクロサービスが独自の論理プライベートデータベース、独自のプライベートRedisキャッシュ、および個別にスケーリングされた多くのポッドを持つことは、標準アーキテクチャと見なされます。Azure SQLとAzure Redisをレンタルしている場合、物理的に実行する方法を選択することはできません。そして、なぜあなたはしたいですか？「使用した分だけ支払う」ことができる高性能の復元力のあるセットアップを実行する方法を専門家に理解させ、簡単にレンタルできるクラウドでのステートフルサービスの管理ではなく、ビジネスロジックの作成に集中してもらいます。

ラップトップでローカルにMS SQL Server Expressを実行してデバッグと単体テストを行い、マイクロサービスデータベースがすべてAzure SQLで実行されているAzureのKubernetesにデプロイする開発者を見てきました。チームが本番環境でAzure SQLに対して実行するのを見ましたが、AzureのプレーンVMでSQL Serverセットアップに対してテストしました。どうして？Azure SQLには「製品価格」のみが付属しているためです。その組織にはSQL ServerのオンプレミスとDBAがすでに存在していたため、AzureのVMにSQL Serverをインストールして実行し、テスト環境をホストする方が安価でした。すべてのマイクロサービスには独自のプライベートデータベースがありました。2ノードクラスターを備えたVM上の共有SQL Serverインスタンスの弾力性のために、マイクロサービスデータベースごとにテストします。本番環境では、マイクロサービスごとのインスタンスはすべて、高パフォーマンスと高可用性を実現するためにAzure SQL上にありました。