読者です 読者をやめる 読者になる 読者になる

絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

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に2つずつ、6つのコピーを保存
    • VPC内に起動
    • 99.99%の可用性

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

  • モノリシックなDB

    • 複数の機能レイヤーが1つのアプリケーションになっている
    • スケールアウトする場合、このセットで増やす必要がある
    • コスト・可用性・柔軟性の問題
  • 今、再実装するならどうなるか?

    • 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によるフェイルオーバーのテスト

    • 擬似的に障害をシミュレート

パフォーマンスを引き出すために

Auroraの使いドコロ

  • 同時実行数やテーブルサイズが大きい場合

    • そのままうつせばOK
    • 性能向上の恩恵を受けやすい
  • 複数のサーバにシャードしている場合

    • 複数のDBをひとつのノードに
    • 管理コストの低減
  • 単発のクエリとかが早くなるわけではない

    • インデックスも同様
    • そこのチューニングは今までどおり
    • Explainの結果が変わる可能性は十分ある