AWS Summit 2015 - Day1 - Aurora Deep Dive - 絶品ゆどうふのタレ

AWS 星野さん

Auroraについて

RDSの5番目のエンジン
クラウド時代に特化した新しいDBエンジン
エンタープライズグレードの可用性とOSSレベルのコスト
previewだが、5/20からproduction環境に移行
料金体系
- R3シリーズのみの提供
- ライセンス料は不要
- MySQLとのコンパチブルを保つ
  - ロックインはない
特徴
- MySQL 5.6との互換性
  - マイナーバージョン指定は特にしない
- ストレージが10GB - 64Tまで自動で拡張
  - パフォーマンスインパクトもない
- 3AZに２つずつ、６つのコピーを保存
- VPC内に起動
- 99.99%の可用性

なぜデータベースを再考したか

モノリシックなDB
- 複数の機能レイヤーが１つのアプリケーションになっている
- スケールアウトする場合、このセットで増やす必要がある
- コスト・可用性・柔軟性の問題
今、再実装するならどうなるか？
- 1970年代の方法では実装しない
- スケールアウトが簡単で、セルフヒーリングなもの
- AWSと簡単に連携したい
これをフルマネージドで提供する

アーキテクチャ

ログレイヤ
ストレージレイヤ
- バックにスケールするストレージサービスを採用
- EC2 / Dynamo / SWF などを管理コンポーネントに採用
キャッシュレイヤの分離
- キャッシュをDBプロセスの外に置いた
- DBを再起動しても、キャッシュが残る
ストレージ
- 6つのストレージにコピー
- 一部のストレージに書き込みが多くなった場合、一部のホットスポットを取り除く
- SSDベースで10GBずつのブロックに分散して書き込む
リードレプリカも同じストレージを参照
- 壊れた場合も再ストレイピング、ミラーの修復なども自動で走る
Log Structured Storage
- 追記型のストレージシステム
  - 常に末尾にデータ追加
  - GC
- 新規データは末尾に追記
- これが10GBのチャンクごとに書き込みが行われる
ディスク障害検知
- 2つのコピーに障害があっても読み書き可能
- 3つ障害があっても読込は可能
- 自動検知して修復
レプリケーション
- Binlogによるレプリケーションではない
  - 同一のディスクを見ている
- マスターの負荷を最小限にしつつ、15台のリードレプリカを作成可能
- 同じデータのディスクを参照しているので、フェイルオーバーしてもデータロスがない
セキュリティ
- データの暗号化
- SSL
- 直接ログインは不可
DBクラスタ
- DBクラスタという概念を持っている
  - マスタとリードレプリカ
- DB Parameter Group / Cluster Parameter Group
新しいメトリクス画面
- キャッシュ・CPU使用率についてわかりやすくなる
フェイルオーバーとリプレース
- リードレプリカがある場合は1分程度でフェイルオーバー可能
- 優先的にフェイルオーバーさせるノードを指定可能
- ノードリプレース時の起動先AZを指定可能
クラスタエンドポイント
- WriterのCNAMEになっていて、壊れたら別の新しいノードに切り替わる
- Readerはそうはなっていないので、アプリケーションで対応
高速なデータ修復
- 並列、分散、非同期で行われる
Streaming snapshotとPITR
- バックアップを残す期間を指定可能
- 任意の時間に秒単位で戻すことが可能
  - 現在では、2分前のデータから可能
SQLによるフェイルオーバーのテスト
- 擬似的に障害をシミュレート