僕が考えるRDS を激推する理由
バックアップが楽ちん
RDS を推したい理由の上位にくるのがバックアップの手軽さです。
AWS の公式にも記載がある通り、バックアップを自動で取ってくれます。
過去に クラウドサーバー 上にインストールした MySQL のバックアップ手法として、cron にて AWS SDK for PHP を用いて S3にダンプファイルを保管する手法を取っていた自分からすると RDS のバックアップはかなり楽ちんです。
だって、以下の設定が不要になりますからね。笑
- AWS SDK for PHP のインストール
- cron にて日次の実行処理を記述
- S3 に送信処理を記述
デフォルトで有効になっている Amazon RDS の自動バックアップ機能により、データベースとトランザクションログがバックアップされます。Amazon RDS では DB インスタンスのストレージボリュームのスナップショットを自動的に作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。
このバックアップは、バックアップウィンドウと呼ばれるユーザーが設定可能な 30 分間隔の時間に 1 日 1 回行われます。自動バックアップは、お客様が設定した日数の間、保持されます (バックアップ保持期間と呼ばれます)。自動バックアップの保持期間は、最大 35 日間まで設定できます。
また、 RDS には自動バックアップに加えてポイントインタイムリカバリという機能があり、特定の時点に戻すことができます。(5分毎にデータベースの変更ログのアーカイブが自動で実行されます)
これは、データの損失を最小限に抑えることのできる機能となっており、ポカしやすい人には必需品と言えるほどの機能となっています。
先程申し上げた日次のバックアップだけでは不足しているバックアップ分を補填しているので、個人的にはすごく好きです。
DB インスタンスを特定の時点に復元し、新しい DB インスタンスを作成できます。
死活監視が楽ちん
RDS はデフォルトでメトリクスデータを1分間隔で CloudWatch に送信してくれます。
(CloudWatch はメトリクスの収集、アラームの設定、ログの収集と監視などを対応してくれるサービスです)
これも自分ごとではありますが、死活監視をするために以下のようなインフラを構築しました。
イメージ | 設定手順 |
|
手順書いてみたんですけど、すっげー面倒くさいですね。。。
その反面、 RDS では上記のような面倒くさい事をしなくても死活監視が簡単にできてしまうんです。
下記のあたりを見てれば DBが生きているかどうかを判別することができるので、すごく楽です。
- データベースの稼働状況
- CPU使用率
- メモリ使用率
- ディスクストレージ
- データベースのクエリおよびスロークエリ
これらに対して閾値を設定して異常状態を感知できるようにすれば、僕が構築したよく分からない事はしなくても済むなんて素敵すぎる!!!!
フェイルオーバーが楽ちん
フェイルオーバー の構成を取っていると何らかの障害が起きた際に被害を最小限に止めることができます。
実際に手動で組み込んだことはないのですが、天下の Oracle 様の解説記事を読んでみるとごちゃごちゃと設定が必要そうで、適切な冗長構成を取るのが難しそうな印象を受けました。
対して RDS は以下の条件を満たせば、冗長構成を取ることが可能となっています。
- マルチアベイラビリティーゾーン
- ホットスタンバイオプションの有効化
実際の手法を確認したい方はこちらの記事をご確認ください。
まとめ
単純なDBを構築したい場合、RDS を使うことで楽に安全に構築することができます。
過去の自分に戒めを込めて、 RDS 使うと幸せになれることを胸張って伝えていきたいです。笑