.NETフロントエンドとSQLバックエンドで構成されるWebアプリケーションがあります。 WebAPIを使用して.NETフロントエンドに接続するモバイルアプリもあります。現在、アプリケーションは米国の物理サーバーでホストされています。 Webブラウザとモバイルデバイスの両方からアプリケーションにログインする世界中の複数のクライアントがあります。
私たちはかなりの数のクライアントに2つのシナリオを求めてきました。
「アプリケーションを米国以外の国でホストできますか」(セキュリティ/ NSAの懸念事項)
「自分でアプリケーションをホストできますか」(大企業のクライアント向け)
フロントエンドコードを使用した変更管理にはGithubを使用しています。 Gitリポジトリから本番サーバーを更新できる同期ユーティリティを構築したため、Webサイトコードのデプロイはかなり簡単です。ただし、テストサーバーからSQL実稼働サーバーを更新することは、もう少し手動のタスク(スキーマ、ストアドプロシージャなど)です。 SQLで同様の変更管理を行うことができるソフトウェア(redgateなど)があることは知っていますが、それは私の質問ではありません。
一部のクライアントは(セキュリティ上の理由から)1つの場所でのみデータをホストできるようにしたいのに対し、他のクライアントは1つ以上の場所でデータをホストしたい場合を考慮して、ほとんどの企業は複数の地理的場所からのアプリケーションのホスティングをどのように処理しますかまたは、共有されているすべての場所で、最も近いサーバーに接続できるようにします。追加の詳細として、コードに頻繁に変更を加えるため(毎日)、コードとSQLの変更を複数の分離されたホスト環境にプッシュし、すべてが同期していることを確認するのは少し面倒です。
前述のように、現在、データファーム内の物理サーバーでホストしています。 AWS、Azureなどを使用すると、このタスクが簡単になりますか?
私はあなたがここで本当に2つの問題に直面していると思います:
アプリケーションを複数の場所に配置する必要があります。これは、AzureやAWSなどのクラウドプロバイダーが役立つ場所です。そこに存在する必要なしに、複数のリージョンにデプロイできます。組み込みの負荷分散ツールを使用して単一のリージョンにフェイルオーバーを実装することも、Azure TrafficManagerなどのツールを使用して複数のリージョンにまたがることもできます。トラフィックと負荷分散プロファイルに基づいて、ユーザーを単一のリージョンまたは複数のリージョンに割り当てることができます。
2番目の問題は、アプリケーションをデプロイできることです。特に、複数のリージョンに多数のインスタンスが存在する場合はそうです。これは実際にはクラウドの問題ではなく、ツールとプロセスの問題です。複数のリージョンおよび複数のリージョンの複数のインスタンスに拡張する場合、プロセスのどの部分でも手動でデプロイしても、それ以上削減されることはありません。特に負荷分散を行っている場合は、すべてのリージョン(または一部)に安全かつ迅速にデプロイでき、それらがすべて同じになることを知っている必要があります。これを達成する唯一の方法は、プロセスを調べて複雑さを取り除くか、ツールを使用してそれを処理することです。手動のSQL展開には解決策がありますが、Redgateについて言及しますが、他にもあります。VisualStudioにはデータベースバージョン管理ツールもあります。