11

Azure でグローバルにアクセス可能な大規模なアプリケーションを構築する方法について少し調べています。

アプリケーションを可能な限り消費者に近づけるための技術はすでにたくさんあります。

  • 世界中で共有される静的コンテンツ用の CDN エッジ サーバー。
  • さまざまなリージョンのクラウド サービス。Traffic Manager を使用して、ドメイン名を最も近いアプリケーション ホストにルーティングします。

私が少し混乱しているのは、データベースです。SQL Azure を使用している場合は、それを配置するリージョンを指定する必要があります。 SQL Azure インスタンスが西ヨーロッパ (アムステルダム) にあり、顧客がオーストラリアにいて、オーストラリア (NSW) のインスタンスを介してアプリケーションにアクセスしている場合、アプリケーションがデータベースと通信する間に遅延が発生します。

Geo レプリケーションについて私が見たすべての参考文献は、マスターとスレーブの冗長性セットアップのコンテキストにあるようです。しかし、各アプリケーション インスタンスが同じ地理的リージョン内の独自の SQL Azure マスター インスタンスと通信し、SQL Azure がそれらの間の双方向レプリケーションを処理する、マスター マスター セットアップを実現できるかどうか疑問に思っています。

4

2 に答える 2

8

Azure SQL データベースのアクティブ geo レプリケーション:

アクティブ ジオ レプリケーション機能は、同じ Microsoft Azure リージョン内または異なるリージョン内でデータベースの冗長性を提供するメカニズムを実装します (地理的冗長性)。アクティブ Geo レプリケーションは、コミットされたトランザクションをデータベースから最大 4 つのコピーに非同期的にレプリケートします。異なるサーバー上のデータベースの。元のデータベースは、連続コピーのプライマリ データベースになります。各連続コピーは、アクティブなセカンダリ データベースと呼ばれます。プライマリ データベースは、コミットされたトランザクションをアクティブなセカンダリ データベースのそれぞれに非同期的にレプリケートします。任意の時点で、アクティブなセカンダリ データはプライマリ データベースよりわずかに遅れている可能性がありますが、アクティブなセカンダリ データは、プライマリ データベースにコミットされた変更と常にトランザクション的に一貫性があることが保証されています。アクティブ Geo レプリケーションは、最大 4 つのアクティブ セカンダリ、または最大 3 つのアクティブ セカンダリと 1 つのオフライン セカンダリをサポートします。

アクティブ ジオ レプリケーションの主な利点の 1 つは、データベース レベルのディザスター リカバリー ソリューションを提供することです。Active Geo-Replication を使用すると、Premium サービス レベルのユーザー データベースを構成して、同じまたは異なるリージョン内の異なる Microsoft Azure SQL データベース サーバー上のデータベースにトランザクションをレプリケートできます。リージョン間の冗長性により、アプリケーションは、自然災害、壊滅的な人的エラー、または悪意のある行為によって引き起こされたデータセンターの永久的な損失から回復できます。

もう 1 つの重要な利点は、アクティブなセカンダリ データベースが読み取り可能であることです。したがって、アクティブなセカンダリは、レポートなどの読み取りワークロードのロード バランサーとして機能できます。ディザスター リカバリーのために別のリージョンにアクティブなセカンダリを作成できますが、別のサーバーの同じリージョンにアクティブなセカンダリを作成することもできます。両方のアクティブなセカンダリ データベースを使用して、複数のリージョンに分散されたクライアントにサービスを提供する読み取り専用ワークロードのバランスを取ることができます。

master-master がどこにも言及されていないことに注意してください。レプリカは読み取り可能ですが、書き込みはできません。したがって、SQL Azure は単にあなたが望むものをサポートしていないため、この質問は本当に意味がありません。

別の方法として、アプリケーション層のシャーディングを使用して、各テナントを近接データベースに接続しますが、これはデータがバラバラであることを前提としています (オーストラリアの顧客は南米のアイテムを見ていません)。こちらの回答を参照してください。

Cassandraのようなものを調査することもできます。Cassandra は必要なものをサポートしますが、主要なパラダイム シフトであり、ホストして管理する必要があります。

しかし、次のことも質問する必要があります。低レイテンシーを実現するには、マスター-マスター DB が必要ですか? アプリで頻繁に書き込みが発生していますか? 読み取りレイテンシーは簡単に改善できるため、キャッシングと CDN が用意されています。この質問を読んでいるすべてのオーストラリアのユーザーについて考えてみてください。マスター マスター DB からではなく、障害復旧用にgeo レプリケートされたデータベースから提供されます。StackOverflow が SQL Server をスケーリングする方法を参照してください。

于 2014-09-16T09:18:15.307 に答える
2

警告: この点で SQL Azure を使用したことはありませんが、geo レプリケーションを広範囲に使用しました。

Azure に組み込まれているActive Geo Replicationは一方向のコピーであると言うのは正しいと言えます。ある場所にマスター データベースがあり、読み取り専用で利用できる他のデータベースにトランザクションを共有します。

完全な双方向レプリケーションを実現するには、非常にトリッキーな作業です。故障状態の可能性は非常に大きく、テストするのは非常に困難です。これが、トランザクション データベースを使用した双方向レプリケーションを提供している多くの人を見つけるのが難しい理由です。データベースに同じデータがあったとしても、それらは異なるトランザクション履歴を持ち、相互に正確にミラーリングしません。次に、どのデータベースが信頼できるかを決定する必要がある場合、物事は急速に複雑になり始めます。

ただし、これは必ずしも実用的な双方向レプリケーションの実装を妨げるものではありません。独自のデータを把握し、複製する必要があるものと複製しないものを理解すると、複製を抽象的な問題として解決する必要がなくなるため、所有するデータを中心に設計できます。この種の規模で作業することを検討している場合は、その場所でデータを渡すためにすでに多くのキューを使用していることになります。非常に単純な例を挙げると、サービスがデータをデータベースのキューにプッシュして取得し、ポップアウトして保存する場合、同じデータを転送キューにプッシュして他の地理的な場所に転送することは難しくありません。データベースにドロップする処理中の領域。

最終的には、何百万人のユーザーがいて、データベースに何ギガバイトのデータをプッシュするのかを自問する必要があります。これらの数値がかなり低い場合、双方向レプリケーションはほぼ確実に不要であり、それについて考えすぎるのはおそらく時期尚早の最適化です。

于 2014-09-16T09:22:29.510 に答える