AWS でデータベースを始めるのに必要な 10 のこと
1. データベースの稼働環境の選択肢
データベースサービス
アプリケーション最適化のみ自分でやる
どのように選ぶか？
どこまで自分で面倒を見るか
自動化されるデータベース管理タスク
⾃動化されたパッチ適⽤
拡張モニタリング
定期的に実施するメンテナンス
オンプレミスでAmazon RDSすることもできる
Amazon RDS on Outposts
2. 適材適所のデータベースサービス
データベースに求められる様々な要件が増えてきて、すべての要求を満たせなくなってきた
"A one size fits all database doesn't fit anyone."
Analytics
3. セキュリティに対する重要な考え⽅
特別なオプションを使用しなくてもRDS/Auroraの標準機能でSSL/TLSを使った暗号化をサポート データやバックアップの暗号化
内部の監査には Database Auditing
外からの操作についてはAPI Auditing
4. ⾼いアベイラビリティを確保する⽅法
RDSはEBSボリュームを1つのAZに持つ
別のAZにEBSボリュームのレプリケーションを作る
障害発生時
secondaryがprimaryに昇格
primaryだったものは利用可能な状態に戻ればsecondaryとして動く
Auroraの場合、ストレージを3つのAZに持つ
AuroraでもマルチAZを取れる
ボリュームはもともと分散しているのでコンピュートする部分をマルチにするかどうか
reader / writer で分けることで障害発生時に早く復旧できる
read負荷をオフロード
Auroraのreader
接続先のDBがreaderなのかwriterなのかを判別できない
RDSのバックアップ&リカバリ
5分間隔でトランザクションログのバックアップをS3に取得
EBSボリュームのバックアップもS3におく
EBSスナップショット（前回からの差分バックアップ）
マルチAZ構成の場合はバックアップ時のIO瞬断ペナルティを避けられる
Auroraのバックアップ&リカバリ
バックアップは常にストリーミングで取られる
IO瞬断もない
取られたスナップショットは別リージョンに保存できる
同一インスタンスで特定時点に戻せる
意図しないDML, DDLを戻せる
別インスタンスを作ってバックアップからリカバリする必要がない
5. 柔軟にスケーラビリティを調整する⽅法
再起動だけでインスタンスタイプを変更可能
RDS
汎用 (GP2)
6. ライセンスモデルと各種有償サポート
RDSで選択可能なライセンスモデル
License Included
利用者が別途用意する必要はなくAWSが提供
License Includedモデルではスケールアップ・スケールダウンの際にライセンスも追従可能
使用したリソースぶんのみ課金されるため
通常はNコアぶんのライセンスを買うことになる
7. フルマネージドデータベースサービスで注意するポイント
RDS / Auroraともに制限事項がある
各DB製品の特定バージョンしかサポートされていない
OSにログイン不可、特権ユーザーでの接続不可
バージョンアップ・パッチ適用
ハードウェア・OS・データベースの安全性・堅牢性に関わるバッチが出ることは当然ある メンテナンスウィンドウで指定した曜日・時間帯に開始
数ヶ月に一度の頻度で発生
8. 運⽤で重要なデータベースのモニタリング
CloudWatch Metrics
CloudWatch Logs
CloudWatch Alerm
CloudWatch Events
RDS拡張モニタリング
より詳細なOSのメトリクスを取得できる
最小で1秒ごとに取得できる
RDS Performance Insights
セッション数やトランザクション数など、OSのメモリやCPUの使用量だけではわからない問題を把握するのに使える
性能影響の高いホスト、ユーザーの特定
9. コスト最適化
開発環境・テスト環境は停止することでコストを抑えることができる
停止中はストレージ・バックアップに課金され、コンピュート部分は課金されない
RDS、Auroraクラスタ単位で起動・停止ができる
使用頻度が少ないならバックアップを取得してインスタンスを削除してもよい
インスタンスの購入オプション
長期の利用コミットによる割引
リザーブドからはみ出たぶんだけこちらにすることができる
10. AWSにデータベース移⾏を⾏う場合のステップやサービス
サービスを選択するときに機能表でマルバツ付けて判断するのはあまりよくない
MySQL 8.0やPostgreSQL 12がMUST要件ならAuroraはその時点で選べない