Amazon Relational Database Service (Amazon RDS) には、Multi―AZ 配置というサービスがあります。
これは常にスタンバイ用のデータベースを用意しておき、マスターデータベースが何らかの原因でサービスが継続できなくなった場合、即座にスタンバイデータベースを起動させてサービスを継続させるという可用性を向上させるサービスです。
Multi-AZ の名前の通り、同一リージョン内の、別のアベイラビリティゾーンにスタンバイデータベースが配置されます。
マスターデータベースからスタンバイデータベースに切り替える際の通信元からの接続先を DNS の制御でスタンバイデータベースに切り替えたり、スタンバイデータベースをマスターデータベースに変更するなどの一連の処理を「フェイルオーバー」と呼びます。
今回は Amazon RDS for Oracle ( Multi-AZ 配置) でフェイルオーバーした際に必要な時間を検証してまとめます。
Amazon RDS for Oracle 構成
AWSサービス名 | Amazon RDS for Oracle |
エディション | Oracle Standard Edition Two |
バージョン | Oracle 12.1.0.2v17 |
ライセンス | license-included |
テンプレート | 本番稼働用 |
DBインスタンスサイズ | db.m5.xlarge( vCPUs:4 RAM:16GiB EBS:3500Mbps) |
ストレージタイプ | プロビジョンド IOPS(SSD) |
ストレージ割り当て | 1000GiB |
プロビジョン | IOPS 20000 |
マルチAZ配置 | はい(今回の検証に必要) |
リージョン | 東京 |
検証時データベースの状態
今回の検証の前提として、データベースに格納されるデータ量は新規構築直後となり、またトランザクションは発生しない状態で行います。
フェイルオーバーの検証手段・ツール
TNSPING
Oracle データベースクライアントツールの一つTNSPINGコマンドで、Oracle Netネットワーク上のサービスのリスナーに正常に到達できるかどうかを判断します。
Powershell
TNSPINGコマンドと併せて以下の簡易PowershellスクリプトでOracleリスナーに到達できるかどうか1秒間隔で時刻を追跡します。
Powershellスクリプトサンプル
function CheckRdsOracleListener(){ Param( [String] $RdsDnsFQDN )#Param #無限ループ while ( $true ) { $rdsIp = Get-Content .\rdsIpFile.txt $rdsTnsPingAllResult = tnsping $rdsIp $rdsTnsPingResult = $rdsTnsPingAllResult[10] if( ($rdsTnsPingResult).ToString().Contains("OK (") ){ (Get-Date).ToString() + " OK ................. tnsping to $rdsIp " }else{ (Get-Date).ToString() + " NG ................. " (Get-Date).ToString() + " ipconfig /flushdns ... " # DNS キャッシュ クリアする ipconfig /flushdns # 待機一秒 Start-Sleep -Seconds 1 (Get-date).ToString() + " tri to get new ip addr " # RDS IP取得 $nslookupResult = nslookup $RdsDnsFQDN $newIpLine = $nslookupResult[4] $newIp = $newIpLine.ToString().Substring( 10, $newIpLine.Length - 10 ) Write-Host("new ip : '" + "$newIp" + "'") $newIp > ./rdsIpFile.txt } # 待機一秒 Start-Sleep -Seconds 1 } } CheckRdsOracleListener awscomt.xxxxxxxx.ap-northeast-1.rds.amazonaws.com
上記のPowershellを実行した際の出力結果のサンプル
8/17/2019 4:13:09 PM OK ................. tnsping to 172.31.1.195 8/17/2019 4:13:10 PM OK ................. tnsping to 172.31.1.195 8/17/2019 4:13:11 PM OK ................. tnsping to 172.31.1.195 8/17/2019 4:13:12 PM OK ................. tnsping to 172.31.1.195 8/17/2019 4:13:13 PM OK ................. tnsping to 172.31.1.195 8/17/2019 4:13:35 PM NG ................. 8/17/2019 4:13:35 PM ipconfig /flushdns ... Windows IP Configuration Successfull flushed the DNS Resolver Cache. 8/17/2019 4:13:36 PM tri to get new ip addr Non-authoriative answer: new ip : '172.31.1.195' 8/17/2019 4:13:58 PM NG ................. 8/17/2019 4:13:58 PM ipconfig /flushdns ... Windows IP Configuration Successfull flushed the DNS Resolver Cache. 8/17/2019 4:13:59 PM tri to get new ip addr Non-authoriative answer: new ip : '172.31.0.61' 8/17/2019 4:14:01 PM NG ................. 8/17/2019 4:14:01 PM ipconfig /flushdns ... Windows IP Configuration Successfull flushed the DNS Resolver Cache. 8/17/2019 4:14:02 PM tri to get new ip addr Non-authoriative answer: new ip : '172.31.0.61' 8/17/2019 4:14:03 PM OK ................. tnsping to 172.31.0.61 8/17/2019 4:14:05 PM OK ................. tnsping to 172.31.0.61 8/17/2019 4:14:06 PM OK ................. tnsping to 172.31.0.61 8/17/2019 4:14:07 PM OK ................. tnsping to 172.31.0.61 8/17/2019 4:14:08 PM OK ................. tnsping to 172.31.0.61
検証結果
手動で20回強制フェイルオーバーを実行した結果を以下のグラフにしました。
グラフの通り、フェイルオーバーが発生してからリスナーに正常に到達できるまでに必要な時間はバラバラですが、今回の検証結果を見ると最短で48秒かかり、平均で必要な時間は1分14秒となっています。
まとめ
2019年08月17日現在、AWS公式のドキュメントには、「Amazon Aurora以外のデータベースエンジンでは、フェイルオーバーが完了するまで1~2分間要する」との記載があります。
今回、最長でも1分48秒でしたので、この値に収まっていることが確認できました。
今回の検証では、データベースの作成直後かつトランザクションが発生しない状態でデータベースサービスが提供できない時間を計りました。
2分以上かかるケースはありませんでしたが、この時間が早いか遅いかはビジネスの要件によって回答が異なるかと思います。
AWS公式のドキュメントには、「大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります」との記載があります。