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

こんにちは、菊池です。

本記事は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日後に再起動する
    • ペンディングのメンテナンスは適用される
    • 再度停止も可能

まとめ

Auroraを除くRDSのフル機能をおさらいするセッションでした。最近サポートされた、インスタンスの停止や今後登場する、Performance Insightなどの新機能も紹介されていましたので、改めてRDSの機能を理解することができるセッションです。