aws-recipe-user どうもBogartです！
今回はAWS入門者向けにAmazon RDSのスペックアップやメンテナンス時の動作について、簡単な図で説明していきたいと思います。Multi-AZ構成時の障害発生時の動きは資料としてよく見つかるものの、サービスの拡大によるスペック変更やメンテナンス発生時の動きは文章のみのものが多い印象があったのでまとめてみました。
はじめに ~ 障害発生時の動作 ~
前提条件としてAmazon RDSのAurora以外のDBエンジンを利用していた場合の説明となります。
Auroraの動きはまた別途改めてご紹介出来ればと思います。
まずおさらいとしてMulti-AZ構成時における障害発生時の動きを図にします。
障害発生時にフェイルオーバーが発生し、フェイルオーバーが実行される1~2分程度のダウンタイムでスレーブがマスターに昇格し、サービス全体の耐障害性を高めます。ただしフェイルバックは自動では行われません。
次はSingle-AZ構成時の障害発生時の動きを図にします。
実はAmazon RDSは自動的に再起動を行う仕組みが提供されています。AWSが内部的にRDSのDBノードのモニタリングを実施し、問題が発生した場合はAWS側で復旧措置が行われます。ドキュメントではさらっと記載されているだけですがこれもAmazon RDSの大きな機能の１つです。
Amazon RDS – 可用性と耐久性
—
ホストの自動交換
Amazon RDS では、ハードウェア障害が発生した場合、デプロイメントが運用されているコンピューティングインスタンスが自動的に交換されます。
—
スペックアップ＆メンテナンス時の動作
それでは本題のスペックアップやメンテナンスが発生した際の動作について整理していきます。
Multi-AZ 構成時の場合は以下のような動きになります。
文章でも整理をすると以下のようになります。
1. 作業実行時にスレーブで設定が反映される
2. 同期を確保した後にフェイルオーバーを実施
3. フェイルオーバー完了後、元のマスターに対し設定が反映される
4. 同期を確保した後マスターへのフェイルオーバー実施
※1~4までの作業全体で約40分ほどかかる場合がございます。
このようなDBのスペック変更・メンテナンスを最小限のダウンタイムで実現するための複雑なオペレーションを数クリックで行えてしまうなんてAWS以前は考えられませんでしたね！
なおSingle-AZ構成時も図に起こしてみました。
ご覧の通りシンプルにRDSが設定反映時に停止をしてしまうのでMulti-AZ構成時のように最小のダウンタイムでのメンテナンス実現とはいきません。AWSは従量課金型のサービスになりますので一時的にMulti-AZ構成に変更し作業を行うことを推奨いたします！
さいごに
今回はAWS入門者向けにAmazon RDSのスペックアップやメンテナンス実施時の動作についてイメージ図でまとめてみました。実際のところAmazon RDS Multi-AZ構成では99.95％ のSLAを設けられており、実運用ではスペックアップやメンテナンス対応でMulti-AZ構成の恩恵に預かることが多いのではないかと思います。
本記事がAWSによるメンテナンスの際にRDSの動作を説明する際のご参考になれば幸いです。
次回もお楽しみに！
