RDSの各機能のユースケースについて
記事を書こうと考えた背景
実務ではほぼ毎回出てくるRDS(Amazon Relational Database Service）ですが、
大体他案件からの流用で作成することが多く、各機能やどういった場合に役立つのかについての知識が怪しいため、個人的にまとめておきリファレンスとして活用すべく作成しようと思いました。
マルチAZ配置
２つのAZを選択し、プライマリインスタンスに障害が発生した場合、プライマリインスタンスとは別AZ上のセカンダリインスタンスに自動的に切り替える。
- どういった場合に役立つのか
案件のシステム停止許容時間が数分〜数時間の場合、下記①〜④の障害によるシステム停止を最小限に抑えるためにマルチAZを設定する。
※セカンダリインスタンスへの切り替え時間は通常60〜120秒で完了する。
①AZ障害
②プライマリDBインスタンスのコンピューティングノードの障害
③プライマリDBインスタンスのネットワークの問題
④ストレージまたはEBSボリュームの問題
※補足
RDSはシングル構成だとSLAが算出できないため、ビジネス上クリティカルな案件だと必ずマルチAZを設定する必要があると認識してます。ただ費用面で折り合いが付かずシングル構成となる案件も結構ありはします。。
リードレプリカ
読み込み処理を拡張（スケーリング）する目的で利用する。
-
どういった場合に役立つのか
帳票作成やレポート作成が必要となる案件の場合、通常業務による更新・書き込み処理に負荷をかけないために読み込み専用インスタンス（リードレプリカ）を作成し、そこを参照させることによって読み込み処理による負荷を軽減する。 -
留意点
リードレプリカを作成するとプライマリインスタンス（レプリケーション元）が停止できなくなるため、アプリケーションとDBの断面を揃える必要があるなどの要件がある場合は考慮が必要。
自動パッチ適用
脆弱性によるDBインスタンスのエンジンバージョンのバージョンアップ対応などのメンテナンスを自動化する。
-
どういった場合に役立つのか
DBインスタンスのエンジンバージョンのバージョンアップ（メジャーアップデートやマイナーアップデート）が必要となった場合、自動的にエンジンバージョンをアップデートしてくれる。 -
留意点
ただし実運用フェーズに入っている場合、業務に支障が出ないように業務時間外に手動でのアップデードを推奨（個人的な見解）。メンテナンスウィンドウを設定しておけば自動アップデートも可能だが、こちらはAWSより任意のタイミングで勝手にアップデートされることもあるため（実際にそういうことがあったので・・・）手動によるアップデートが一番安全！！
自動バックアップ
DBインスタンスの完全なバックアップを作成する。
また取得したバックアップは最大３５日間の保持期間を設定できる。
-
どういった場合に役立つのか
DBインスタンスで障害が発生し、現在時点より5分前に戻したいなどの業務要件がある場合、ポイントタイムインリカバリ機能を活用して任意のタイミングに復元できる。 -
留意点
リードレプリカを作成する場合、RDSインスタンスの設定項目である「バックアップ保持期間」を０以外の数値で指定する必要がある。
自動的に取得されたバックアップはDBインスタンスを削除した場合、対象となるスナップショットも削除される。
スナップショット
自動バックアップに対し、こちらはどちらかというとユーザが手動によるバックアップを取得したい場合にDBスナップショットを取得する。
-
どういった場合に役立つのか
ユーザが任意のタイミングでバックアップを取得することが出来る。
実案件だと手動によるDBインスタンスのエンジンバージョンアップ対応の際に、エンジンのバージョンアップ失敗に備えて作業前に手動スナップショットを取るといったことを良くする。 -
留意点
手動により取得されたバックアップはDBインスタンスを削除した場合でも、対象となるスナップショットは削除されない。
まとめ
ぶっちゃけて言えば自動バックアップとスナップショットの違いが曖昧なまま仕事してました😓
そもそも普段の実務では自動バックアップ機能をオフにして、AWS Backupによる手動バックアップを実施しているため普段から殆ど意識してませんでした。。
今後こういった曖昧な理解なままにしてところをなくして行くためにも、こういう場をお借りすることで普段の業務を振り返る機会を作っていきたいと思います！
この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
以上、ありがとうございました！！！
Discussion