この記事で書かないこと

アーキテクチャ等は記事が数多くあるため触れません。
コスト関連
実際の手法
法律やコンプライアンス関連
aws, terraformなどツールの使用方法

なぜ・何を書くのか？

なぜ

SREでインターンをしていて、社会人になる前にDBの運用業務まで知っておきたいと感じたからです。
運用業務のイメージを掴むことをモチベーションにしています。

また、同じエンジニアを目指す学生の参考になればと思いterraformのサンプルコードを提供します。
※awsのシェア率が高いためRDSを使います。

何を

そもそもDBの運用業務の概要を説明できる自信がないためChatGPTに聞いてみました。

Q) データベースの運用や保守では何が行われますか？

A) データベースの運用や保守は、データベースの正常な動作を確保し、データのセキュリティと可用性を維持するために行われる重要な活動です。以下に、一般的なデータベースの運用や保守で行われる主な活動を挙げてみます：

1. バックアップとリカバリ：データベース内の情報を定期的にバックアップし、データ損失を防止するために必要な手順を確立します。バックアップは、データベースが壊れた場合や災害が発生した場合に備えて重要です。

2. パフォーマンスチューニング：データベースのパフォーマンスを最適化するために、クエリの最適化やインデックスの作成、ハードウェアのアップグレードなどを実施します。これにより、データベースの応答時間が改善され、効率的に運用されます。

3. セキュリティ管理：データベース内の情報を保護するために、アクセス制御、暗号化、監査などのセキュリティ対策を実施します。重要なデータが漏洩しないように対策を講じることが必要です。

4. アップグレードとパッチ適用：データベースシステムのバージョンアップやセキュリティパッチの適用を定期的に行い、最新の機能やセキュリティ対策を利用します。

5. 監視とトラブルシューティング：データベースの健全性を保つために、24/7で監視を行い、問題が発生した場合には迅速に対応し、障害を解決します。

6. データベースの設計変更：アプリケーションの要件が変化した場合や、データベースのスキーマに変更が必要な場合には、慎重に設計変更を行います。

7. データの整合性維持：データベース内のデータが一貫性を保ち、正確で信頼性のある情報を提供できるように、データの整合性を維持します。

8. インシデント対応と災害復旧：システム障害や災害が発生した場合には、迅速に対応してデータベースを元の状態に復旧させるための計画を立て、適切な手順を実行します。

これらの活動は、データベースの安定した運用とデータのセキュリティを確保するために欠かせないものであり、専門的な知識と適切な手続きに基づいて実施されます。

とのことです。この記事では以下を書きたいと思います。

1 バックアップとリカバリ
3 セキュリティ管理：(認証は書きません)
4 アップグレードとパッチ適用
5 監視
追加項目としてブルーグリーンアップデートにも触れます

参考になりそうな仕様を公式ドキュメントを基にまとめます。

バックアップとリカバリ

ドキュメント: バックアップの使用

スナップショットのお話

リージョン辺り100個までs3に保存され、自動・手動のスナップショットで構成されている。
削除時にスナップショットを取る指定ができ、これを使用して復元が可能。(マルチAZでは削除時に取れないような記載がある)
自動バックアップも削除されるが、削除保護は指定可能。

スナップショットのリージョン間のレプリケーションは割愛します。

バックアップウィンドウ

バックアップウィンドウの指定がある場合自動バックアップはこの時間帯に行われ、このウィンドウを超える場合も継続される。
メンテナンスウィンドウと重複はできない.

バックアッププロセスでは通常数秒間のI/Oが一時中断することがある。
マルチAZではセカンダリで取られるのでプライマリの中断はないが、sql serverはプライマリからとられる。

負荷が大きい場合はスキップされる可能性があるが、PITR (ポイントインタイムリカバリ) で次のバックアップウィンドウで試行できる。

自動バックアップの有効化

terraformのドキュメントには記載がないが、バックアップ保持期間を0以外に設定することで自動バックアップが有効になる。

自動バックアップの保持/削除

自動バックアップは期限切れになるとシステムにより削除される。

final snapshotと自動バックアップは扱いが違い、final snapshotには有効期限がない。

復元

自動バックアップからの復元はこちらを参考に.
他にはDBインスタンスのidentifier, resource idを使用しての復元も可能。

また、以下の制限がある模様。

1 つの AWS リージョンで保持できる自動バックアップの最大数は 40 個です。
これは、DB インスタンスの制限には含まれません。
40 の実行 DB インスタンスと追加の 40 の自動バックアップを同時に保持できます。
保持されている自動バックアップには、パラメータグループ
またはオプショングループについての情報は含まれません。

自動バックアップの管理に AWS Backup を使用する

詳細は割愛します。ドキュメント: What is AWS Backup?.
フルマネージドで手動バックアップとして認識される。
バックアッププランというものを作成し、RDSにタグを付与することで管理できるらしい。

手法

セキュリティ

ドキュメント: Amazon RDS でのセキュリティ

暗号化

一般的なユースケースではKMSで十分かと思うのでこちらを前提に書きます。

DB インスタンス、自動バックアップ、リードレプリカ、スナップショット用のストレージの保管時にデータが暗号化されます。
暗号化済みのスナップショットをコピーする際に別のキーを使用して暗号化可能。

DB インスタンスの暗号化

暗号化されたDBインスタンスを作成後はキーを変更できない。

作成時にのみ暗号化可能だが、暗号化されていないDBインスタンスのスナップショットを取り、それを暗号化して復元することもできる。DBスナップショットのコピー

他のサービスとのインテグレーション

AWS CloudTrail ログ

RDSのユーザー、ロール、AWSのサービスによって実行されたアクションの記録が可能。
AWS CloudTrail での Amazon RDS API コールのモニタリング
.

拡張モニタリング

DBインスタンスのOSのメトリクスを取得できる。
拡張モニタリングを使用した OS メトリクスのモニタリング

Amazon RDS Performance Insights

チラ見した感じはクエリレベルのパフォーマンスを見れる感じ。
Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング.

ログ

エンジンによって様々なので割愛。
Amazon RDS ログファイルのモニタリング

その他、Trusted Advisor, 推奨事項の表示などもできる。

アップグレード・メンテナンス

ドキュメント: DB インスタンスのメンテナンス, DB インスタンスのエンジンバージョンのアップグレード

メンテナンス

terraformのaws_db_instanceのおそらくapply_immediatelyをtrueに設定しない限り、DBインスタンスへの変更(パッチやバージョンアップデート)はメンテナンスウィンドウ内でスケジュールされます。

マルチ AZ 配置のメンテナンス

以下の順序で適用される。

スタンバイに対してメンテナンスを実行する。
スタンバイをプライマリに昇格させる。
旧プライマリでメンテナンスを実行し、その旧プライマリが新しいスタンバイになる。

しかし、エンジンのアップグレードはプライマリ・セカンダリを同時に変更してしまう。

DBインスタンスのアップグレードはローリングアップグレードが実行される。

メンテナンスウィンドウ

ほとんどのメンテナンスイベントは30以内に完了するが、規模が大きいとそれ以上かかるかも。
メンテナンスウィンドウを指定しないとランダムで曜日を選択しスケジュールされる。

OSのアップデート

必須とオプションがあり、オプションはAmazon RDS イベント通知にサブスクライブするを利用できる。
必須アップデートは適用日前にスケジュールすること。

アップグレード

メジャー・マイナーどちらのアップグレードにもダウンタイムが必要。
軽減策としてブルー/グリーンデプロイを使用できる。

マイナーバージョンの自動アップグレード

自動アップグレードではメンテナンスウィンドウ中にスケジュールされる。

監視

ドキュメント: Amazon RDS インスタンスでのメトリクスのモニタリング

パフォーマンス

以下のメトリクスをモニタリング可能。

ネットワークスループット
クライアント接続
読み取り、書き込み、メタデータのいずれかのオペレーションの I/O
DB インスタンスのバーストクレジットバランス

モニタリングツール

メトリクスリファレンスが参考になりそう。

CloudWatch メトリクス.Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング
RDS Performance Insights とオペレーティングシステムのモニタリング
- RDS Performance Insights – データベース負荷を評価する。Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング
- Amazon RDS 拡張モニタリング – オペレーティングシステムのメトリクス拡張モニタリングを使用した OS メトリクスのモニタリング
DevOps Guru for RDS でパフォーマンスの異常を分析する

ブルー/グリーンデプロイ

ドキュメント: データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する

ゼロダウンタイムにはならない。 が切り替えには1分未満。
RDS for MariaDB と RDS for MySQLのみがサポート。

例

ステージング環境がグリーン、本番がブルーでグリーンでバージョンアップグレードを適用後安全に切り替えを実行できる。
ブルーがマルチAZならグリーンもマルチAZになる。

ワークフロー

ブルー/グリーンデプロイの作成により、本番のDBのトポロジをコピーしgreenという名前でステージングが作成される。
ステージングでのアップグレードや変更
ブルー/グリーンデプロイの切り替えで昇格が行われる.
本番だったDBはoldn(nは数字)に、ステージングは本番DBの名前になる.
ブルー/グリーンデプロイの削除で削除する。(ブルーへの影響はない)

考慮事項

DbiResourceIdで追跡されるためブルーだったDBとは一致しない。そのため変わったリソースIDをインテグレーションサービス用に更新する必要がある。
CloudTrail, Performance Insights, aws Backupなど。

真面目にドキュメント読んで疲れた...

その他

読みたい人はどうぞ。

SLA

ドキュメント: Amazon RDS サービスレベルアグリーメント
.
awsがこれを満たせなかった場合僕たちが払うお金が少なくなる。

マルチ AZ DB インスタンスおよびマルチ AZ DB クラスタ SLA

月間稼働率	サービスクレジット率
99.0%以上、99.95%未満	10%
95.0%以上、99.0%未満	25%
95.0%未満	100%

シングル DB インスタンス SLA

月間稼働率	サービスクレジット率
99.0%以上、99.5%未満	10%
95.0%以上、99.0%未満	25%
95.0%未満	100%

参考