Azure SQL Database の Premium / Business Critical では、「ゾーン冗長可用性」(ZR) が GA した機能としてサポートされています。(Business Critical ではプレビュー段階)
Premium / Business Critical のデータベースはローカルの SSD を使用して Always On 可用性グループのテクノロジーを使用して可用性が担保されています。
ローカル冗長の構成
ローカル冗長 (LR) の構成については、Premium および Business Critical サービス レベルのローカル冗長可用性 に記載されており、次のような構成となっています。
ローカル冗長の場合は、同一の AZ 内のサーバーを使用してデータの同期が行われています。
ゾーン冗長の構成
ゾーン冗長を使用した場合は、次のような構成となります。
ゾーン冗長の場合は、異なる AZ にデータベースが配置され、データの同期が行われる構成となります。
ゾーン冗長を使用した場合の性能への影響
SQL Database でゾーン冗長を使用する場合、
- Always On 可用性グループのテクノロジーが使用されている
- 可用性ゾーンに分散される場合は物理的に分離された場所になるため、ネットワークのレイテンシーが LR より高くなる
ということを意識しておくと、性能への影響を考える際にはよいのではないでしょうか。
可用性ゾーン の説明には次のように記載されています。
Azure 可用性ゾーンは、ラウンドトリップ待ち時間が 2 ミリ秒未満の高パフォーマンス ネットワークによって接続されます。
AZ 間は高速なネットワークで接続が行われていますが、「2ミリ秒未満」のネットワークの待機が発生する可能性があります。
SQL Server の Always On のテクノロジーを使用した場合、プライマリのサーバーで更新された内容は、セカンダリ (待機系) のサーバーに同期されます。
データ損失を防ぐためには、「同期モード」による同期が必要となりますが、同期モードを使用している場合には「セカンダリが更新を受け取り永続化したことの応答を待ってからコミットを完了する」というような動作となります。
セカンダリからの応答を受け取る部分については、プライマリとセカンダリ間のネットワークの最小の応答性能の影響を大きく受けることになります。
次のようなテーブル作成 / PowerShell のスクリプトを実行することで、サーバー内の処理として、どの程度の時間で 1 Insert が完了したかを計測することができます。
<#
CREATE TABLE TEST(C1 int identity)
#>
$con = New-Object System.Data.SqlClient.SqlConnection("[Connection String]")
$con.Open()
$handler = [System.Data.SqlClient.SqlInfoMessageEventHandler] {
param($sender, $event)
Write-Host ($event.Message -split "`n")[2]
}
$con.add_InfoMessage($handler)
$con.FireInfoMessageEventOnUserErrors = $true
$cmd = $con.CreateCommand()
$cmd.CommandText = "SET STATISTICS TIME ON;INSERT INTO TEST DEFAULT VALUES;SET STATISTICS TIME OFF"
1..20 | %{
$cmd.ExecuteNonQuery() | Out-Null
}
$con.Close()
$con.Dispose()
左がローカル冗長 (LR) / 右がゾーン冗長 (ZR) を設定した場合の 1 Insert の処理時間となります。
LR の場合は、平均 1 ms で処理が完了していますが、ZR の場合は平均 2ms となっていることが確認できます。
この事から、ZR を使用した場合は、プライマリとセカンダリの物理的な距離が離れるため、変更 (INSERT / UPDATE / DELETE) 処理の最小処理時間に多少の影響が発生するということが確認できます。(参照系のワークロードは、セカンダリからの応答は影響を受けませんので、更新系のワークロードがサーバー間のネットワークの影響を受けます (厳密には最新のデータの読み取りが 1,2 ms 程度遅れるのですが)))
細かなトランザクションのコミットが必要となるワークロードでは、この 1 ms の違いの積み重ねが、全体の処理時間に影響を与えるケースがあるかもしれません。
1,2 ms での更新処理の性能への影響が問題ないのであれば、このあたりの処理時間の影響は考慮しなくても問題ないと思います。
まとめ
ゾーン冗長はサーバーが配置されるロケーションを同一リージョン内で物理的に分離することができますが、これにより各サーバー間のネットワークの処理性能に多少の影響が発生します。
1,2 ms の更新系の処理への影響が問題ないのであれば、ネットワーク的な距離が離れたことによる影響は考慮しなくても問題ないと思いますが、影響がある場合には、ゾーン冗長によるメリットと処理時間へのデメリットを天秤にかける必要が出てくるのではないでしょうか。