【レポート】Deep Dive on Amazon Relational Database Service (RDS) #reinvent #dat302

チャットボット特集

#セッションレポート

#Amazon RDS

#レポート

#AWS

菊池修治

2017.11.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

本記事はAWS re:Invent 2017のセッション「DAT302 - Deep Dive on Amazon Relational Database Service (RDS)」のレポートです。

セッション概要

Amazon RDSは、最適化された安全で可用性の高いデータベースを数回クリックで利用できます。コストパフォーマンスよのいリサイズ可能な容量を提供しながら、データベース管理タスクにかかる時間を削減し、アプリケーションやビジネスに注力できます。Amazon RDSには、Oracle、Microsoft SQL Server、PostgreSQL、MySQL、MariaDBなど、6種類のデータベースエンジンが用意されています。このセッションでは、RDSサービスの詳細な機能、最新機能を紹介します。私たちは、RDSの仕組みと、データベースの最適なパフォーマンス、柔軟性、およびコスト削減を達成するためのベストプラクティスについて掘り下げます。

スピーカーは、Brian Welcker - Principal Product Manager, Amazon RDS, Amazon Web Services です。

レポート

Amazon RDSとは

マネージドRDBサービス
複数のDBエンジンをサポート
自動化されたプロビジョニング/スケール/パッチ/バックアップ/レプリカ
Multi-AZによる可用性

なぜAmazon RDSを使うのか

TCOの削減
ビストインされた高可用性・マルチリージョン構成
99.95%以上のアベイラビリティ

RDSインスタンスの設定

エンジンの選択

Amazon EBS-based Storage
- 商用：Oracle、SQL Server
- OSS：MySQL、PostgreSQL、MariaDB
Aurora Storage System
- Amazon Aurora

インスタンスタイプ

T2
- 1vCPU 1GB RAM 〜 8vCPU、32GB RAM
- 小規模環境向け
M3/M4（汎用）
- 2vCPU 8GB RAM 〜 64vCPU、256GB RAM
- ハイパフォーマンスネットワーク
- CPUを使うワークロードに（例：WordPress）
R3/R4（メモリ最適化）
- 2vCPU 16GB RAM 〜 64vCPU、488GB RAM
- ハイパフォーマンスネットワーク
- クエリキャッシュ/多数のコネクション

ストレージタイプ

GP2
- 最大16TB
- 容量に応じたIOPSパフォーマンス
- 最小100IOPS
- バースト時には3,000IOPS
- 最大10,000IOPS
- 高いコストパフォーマンス
IO1
- 最大16TB
- IOPSパフォーマンスをプロビジョニング
- 最大40,000IOPS（SQL Serverでは20,000IOPS）
- 高パフォーマンスと性能保証
Magnetic
- レガシーむけ
GP2とIO1の選択
- GP2は1TB以下でのバーストクレジットに注意

スケールする方法

CPU/Memory：スケールアップ/ダウン
- 最小のダウンタイムで可能
EBSストレージ
- 最大16TB <- New!
- Elastic Volumeのサポート
- ダウンタイムなしでのストレージスケーリング

HA、リードレプリカ、バックアップ

どのようにHAを構成しているか

Multi-AZ構成によるエンタープライズ級の可用性
自動フェイルオーバー
同期レプリケーション
ワンクリックで有効化
DNSによる切替

なぜリードレプリカを利用するか

リードキャパシティの拡張
他リージョンへのデータの展開
リードレプリカのバージョンアップ
MySQL、MariaDB、PostgreSQLでサポート

Multi-AZとリードレプリカの違い

Multi-AZ
- 同期レプリケーションによる耐久性
- プライマリインスタンスのみがアクティブ
- バックアップはセカンダリから取得
- 常に1つのリージョン、2つのAZを使用
- 自動でフェイルオーバ
リードレプリカ
- 非同期レプリケーションによるスケーラビリティ
- 全てのレプリカでリードがアクティブ
- デフォルトではバックアップされない
- AZ内、AZ間、リージョン間で利用可能
- 手動でスタンドアローンに切替可能

RDSではどのようにバックアップを管理するか

自動/手動の2通りの方法
EBSスナップショットがS3に保存される
トランザクションログもS3に保存され、5分ごとのPITRをサポート
バックアップによるパフォーマンスへの影響はない
スナップショットは他リージョン、他アカウントに共有可能
自動バックアップ
- デフォルト7日、最大35日間保存
- PITRサポート
- ディザスタリカバリーに適する
手動バックアップ
- コンソール/CLI/APIから実行
- 削除するまで保存
- 大きな変更の前、テスト環境用途、削除前の保存に利用

リストア

新しいインスタンスとしてリストアされる
- 新規インスタンスとして設定
- フルパフォーマンスの発揮にはストレージボリュームのウォームアップが必要

セキュリティ

VPCによるネットワークの隔離
IAMによるリソースレベルの権限分離
KMSまたはOracle/Microsoft TDEによる暗号化
SSL通信
AWSレイヤはIAMで制御、DBはgrantで制御

データベース暗号化

KMSによる暗号化
パフォーマンスへの影響なし
キーアクセスの制御
ベストプラクティス
- ソースDBが暗号化されているのならば、レプリカも暗号化する
- 非暗号化DBを暗号化する場合、スナップショットを暗号化コピーする

モニタリング

CoudWatchによるモニタリング
詳細モニタリングオプション
- 50以上のメトリクス
- 最小1秒間隔のモニタリング
- サードパーティツールとの統合
Performance Insights
- ロードアベレージ/アクティブセッション
- データベース/ソースのボトルネックの特定
- Coming soon
サービスイベントの特定
- SNSとの連携（E-mail、テキストメッセージ、HTTP）

メンテナンスとコスト

メンテナンス
- ダウンタイムの発生
- OS、DBのパッチ適用
- DBバージョンアップ
  - マイナーバージョンアップ（自動/手動）
  - メジャーバージョンアップ（手動）
- AWS Personal Health Dash Boardでメンテナンスイベントの確認を
コスト
- インスタンス（/時間）
- ストレージ（/GB月）
- バックアップストレージ（/GB月）
- データ転送量（/GB月）
コスト削減
- リザーブドインスタンス（RI）の適用
- OSS DBではIRサイズフレキシビリティが有効
- RIカバレッジレポート：Coming soon...
インスタンスの停止（Stop）
- コンソール/CLIからの停止が可能
- 停止中はストレージコストのみ発生
- 7日後に再起動する
  - ペンディングのメンテナンスは適用される
  - 再度停止も可能