サービス レベル別の高可用性
Azure SQL の可用性オプションと機能について理解するには、サービス レベルを理解する必要があります。 選択したサービス レベルによって、デプロイするデータベースまたはマネージド インスタンスの基になるアーキテクチャが決まります。
検討する購入モデルには、DTU と仮想コアの 2 つがあります。 このユニットでは、高可用性を実現するための仮想コアのサービス レベルとそのアーキテクチャに焦点を当てます。 DTU モデルでは、Basic レベルと Standard レベルを General Purpose と同等と見なし、Premium レベルを Business Critical と同等と見なすことができます。
General Purpose
General Purpose サービス レベルのデータベースとマネージド インスタンスの可用性アーキテクチャは同じです。 次の図をガイドとして利用して、最初に、"アプリケーション" と "制御リング" を検討します。 アプリケーションはサーバー名に接続し、次にゲートウェイ (GW) に接続します。ゲートウェイは、アプリケーションの接続を VM で実行されている適切なサーバーに向けます。 General Purpose の場合、プライマリ レプリカでは、ローカルに接続されている SSD が tempdb に使われます。 データ ファイルとログ ファイルは、ローカル冗長ストレージ (1 つのリージョンに複数のコピー) である Azure Premium Storage に格納されます。 さらに、バックアップ ファイルは Azure Standard Storage に格納されます。これは既定では RA-GRS です。 RA-GRS は、複数のリージョンにコピーがあるグローバル冗長ストレージです。
このラーニング パスの前のモジュールで説明したとおり、Azure SQL のすべては、Azure のバックボーンとして機能する Azure Service Fabric 上に構築されています。 Azure Service Fabric によってフェールオーバーの実行が必要と判断された場合、フェールオーバーは、フェールオーバー クラスター インスタンス (FCI) と同様のものになります。 Service Fabric では、予備容量があるノードが検索され、新しい SQL Server インスタンスが起動されます。 データベース ファイルが接続され、復旧が実行されます。ゲートウェイは、アプリケーションが新しいノードに向かうように更新されます。 仮想ネットワーク、リスナー、または更新プログラムは必要ありません。 この機能は組み込まれています。
Business Critical
次に考慮すべきサービス レベルは Business Critical です。このレベルでは通常、すべての Azure SQL サービス レベル (General Purpose、Hyperscale、Business Critical) において最高のパフォーマンスと可用性を実現できます。 Business Critical は、低待機時間と最小限のダウンタイムを必要とするミッション クリティカルなアプリケーションを対象としています。
Business Critical は、バックグラウンドで Always On 可用性グループ (AG) をデプロイすることと似ています。 General Purpose レベルとは異なり、Business Critical でのデータおよびログ ファイルはすべて直接接続されている SSD 上で実行され、ネットワーク待機時間が大幅に短縮されます。 (General Purpose ではリモート ストレージが使用されます)。この AG には 3 つのセカンダリ レプリカがあります。 そのうちの 1 つを読み取り専用エンドポイントとして (追加料金なしで) 使用できます。 トランザクションでは、少なくとも 1 つのセカンダリ レプリカによってトランザクション ログの変更が書き込まれたときに、コミットを完了できます。
セカンダリ レプリカの 1 つを使った読み取りスケールアウトはセッション レベルの整合性をサポートしているため、レプリカが利用できないことによる接続エラーが発生した後に読み取り専用セッションが再接続されると、読み取り/書き込みレプリカを使った 100% 最新ではないレプリカにリダイレクトされる可能性があります。 同様に、アプリケーションが読み取り/書き込みセッションを使用してデータを書き込み、読み取り専用セッションを使用してすぐに読み取る場合、レプリカに最新の更新がすぐに表示されない可能性があります。 この待機時間は、非同期のトランザクション ログの再実行操作に起因して発生します。
何らかの種類の障害が発生し、サービス ファブリックによりフェールオーバーが必要であると判断された場合、セカンダリ レプリカへのフェールオーバーは高速です。これは、レプリカが既に存在し、データがアタッチされているためです。 フェールオーバーでは、リスナーは必要ありません。 ゲートウェイでは、フェールオーバー後も接続をプライマリにリダイレクトします。 この切り替えはすばやく実行され、その後、サービス ファブリックによって別のセカンダリ レプリカが起動されます。
Hyperscale
Hyperscale サービス レベルは Azure SQL Database でのみ使用できます。 このサービス レベルでは、キャッシュとページ サーバーの階層化された層を使用して、データ ファイルに直接アクセスせずにデータベース ページにすばやくアクセスするように機能が拡張されているため、このレベルには固有のアーキテクチャがあります。
このアーキテクチャではペアのページ サーバーが使用されるため、水平方向にスケーリングしてすべてのデータがキャッシュ レイヤーに格納されるようにすることができます。 さらに、この新しいアーキテクチャにより、Hyperscale では最大 100 TB の大きさのデータベースをサポートすることもできます。 スナップショットを使用しているため、サイズに関係なく、ほぼ瞬時のデータベース バックアップが行われます。 データベースの復元は数時間や数日ではなく数分で完了します。 また、ワークロードに合わせるために一定の時間でスケールアップまたはスケールダウンすることもできます。
興味深いのは、このアーキテクチャでログ サービスがどのように引き出されたかということです。 ログ サービスは、レプリカとページ サーバーのフィードに使用されます。 ログ サービスがランディング ゾーンへの書き込みを実行するとトランザクションをコミットできるため、コミットにはセカンダリ コンピューティング レプリカによる変更の使用は必要ありません。 他のサービス レベルとは異なり、セカンダリ レプリカが必要であるかどうかは、ユーザーが決定できます。 0 から 4 個のセカンダリ レプリカを構成でき、それらはすべて読み取りスケールに使用できます。
他のサービス レベルと同様、Service Fabric で必要と判断された場合は自動フェールオーバーが行われますが、復旧時間はセカンダリ レプリカが存在するかどうかによって異なります。 たとえば、レプリカがない状態でフェールオーバーが発生する場合、シナリオは、General Purpose サービス レベルのシナリオと似ています。つまり、Service Fabric では最初に予備容量を見つける必要があります。 レプリカが 1 つ以上ある場合、復旧は高速になり、Business Critical サービス レベルにより近い速度になります。
Business Critical は、低待機時間が必要な小規模なログ書き込みのワークロードに対して最高のパフォーマンスと可用性を維持しますが、Hyperscale サービス レベルでは、MB/秒の単位でより高いログ スループットを得ることができ、最大のデータベース サイズを提供し、より高いレベルの読み取りスケールを実現する最大 4 つのセカンダリ レプリカを提供します。 そのため、2 つのどちらかを選ぶ場合は、ワークロードを考慮する必要があります。