Amazon RDSでの設定変更において得た知見をまとめてみた

こんにちは!

WEBサービス開発グループで入社3年目の添野です。

本記事では、Amazon RDSでの設定変更において得た知見について紹介していきたいと思います。

なおAmazon Auroraは挙動が違うため、本記事では特に明記しない限り除きます。

今回のネタは、

  • RDSエンジンアップグレードにおける挙動
  • RDSマルチAZ化における挙動

です。

まずは1つ目から、

RDSエンジンアップグレードにおける挙動

とあるサービスでRDSのDBエンジンアップグレードをしなければいけない状況がありました。その際にテストインスタンスを作成して挙動を確認したときに、想定とは違う挙動を示していました。

いきなりですが、ここで問題です。

 

RDSエンジンアップグレードにおいて正しい挙動はどれでしょうか。

A. セカンダリインスタンスにエンジンアップグレードが掛かり、プライマリインスタンスにエンジンアップグレードがかかりフェイルオーバーは発生しない

B. プライマリインスタンスにエンジンアップグレードがかかり、フェイルオーバーを経て、昇格した新しいプライマリインスタンスにエンジンアップグレードがかかる

C. プライマリインスタンスとセカンダリインスタンスに同時にエンジンアップグレードがかかるためフェイルオーバーは発生しない

 

答えは「C」です。

AWS公式サポートに問い合わせましたが、このページにある通り、プライマリインスタンスとセカンダリインスタンスに同時にエンジンアップグレードがかかるという仕様があります。

なおフェイルオーバーに関しても、AWS公式サポートに問い合わせましたが、フェイルオーバーの条件に当てはまらないためフェイルオーバーは発生しません。

実際にDBエンジンアップグレードをかけた際のログは以下の通りとなります。バックアップが取得され、途中でシャットダウン処理が入っていること、またフェイルオーバーが発生した形跡がないことが分かります。

それでは最後に2つ目、

RDSマルチAZ化における挙動

とあるサービスで処理が失敗したときに、正常系に戻るようにマルチAZ化の設定を入れることにしました。その際、処理が終わるまでに時間がかかるようになっていました。

具体的には、RDS for PostgreSQLにおいて100GBのストレージを確保した状態で、テストインスタンスを作成して挙動を確認したときは10分程度だったものが、本番時には40分程度まで時間が延びておりました。

テスト時との違いは実データの有無のみであったため、原因はそれではないかと推測しました。そこでAWSサポート公式に問い合わせてみました。

実データの有無で設定が完了するまでに掛かる時間が変わる仕様であると回答をいただきました。

理由としては、よくある質問の「Q: RDS インスタンスをシングル AZ からマルチ AZ に変換するとどうなりますか?」に書かれている通りスナップショットが取得されるためです。もう少し説明すると、スナップショット取得時には、中にあるデータを確認する処理が行われるためです。

まとめ

今回はAWS上で実証実験をした時の記事を執筆しました。
ニフティでは、AWSへの移行を行うプロジェクト、またAWSのサービスを使用して開発現場や実サービスの最適化を行うプロジェクトが進んでおり、その中で試行錯誤を進めながらAWSでの知見を蓄積している段階であります。詳細についてはこちらの記事を確認してください。
またプロジェクトを進めている中でニフティでは解決しきれないことはAWS公式サポートの力を用いて解決を図っております。的確な回答をいただいておりAWS公式サポート担当者の方には大変感謝しております。

なおニフティとしての取り組みやプロジェクトの詳細については、AWS Summit Tokyo 2019で、Day1の基調講演でニフティの前島が、Day2ではニフティの伊達と添野が説明いたします。

最後に、ニフティではエンジニアを募集しています!
AWSのサービスを使って何かのモノを作ってみたい方、一緒に働いてみたい方は、ぜひ採用情報をご確認ください。