トップ > IT > 「Amazon RDS for Aurora Deep Dive」講演メモ (AWS Summit Tokyo 2015) #AWSSummit

「Amazon RDS for Aurora Deep Dive」講演メモ (AWS Summit Tokyo 2015) #AWSSummit

IT CloudComputing

メモったので、貼付けておきます。
間違い等あるかもしれませんが、その場合はごめんなさい。



  • Auroraは現在Preview中
    • 頻繁にデプロイ・機能変更が行われている
  • 今日の話の内容は6/2時点のもの

フルマネージドなDB

  • データベースを数分で作成可能
  • 自動でパッチの適用
  • 1クリックでスケールアウト
  • S3への継続的バックアップ

Amazon Aurora

  • AWSがクラウド時代にRDBを作るとするとどうなるかを1から考えた
  • エンタープライズグレードの可用性とOSSレベルのコストを両立
  • 現在はLimited Preview
  • Virginia/Oregon/Irelandリージョンで動いている
  • 5/20よりpreviewがプロダクション環境へ移行
    • Beta環境はクローズ

AuroraのPricing

  • 現在は、r3シリーズのみでの提供
  • ライセンス料金は不要
  • MySQLと100%互換なので、ロックインはない
  • インスタンス分の課金に加えて、ストレージ課金とIO課金もある

特徴

  • MySQL5.6との互換性を保つように開発されている
  • ストレージが10GBから64TBまでシームレスに拡張
  • 3AZに2つずつ、計6つのデータコピーを保持
    • S3にStreaming Backupを実施
  • VPC内に起動
  • 99.99%の可用性を実現するように設計されている

なぜ、AmazonがDBを再考したか

  • 現在のモノリシックなデータベースでは、スケールアウトさせるとコスト・可用性・柔軟性の面で問題
  • 今、データベースを再度実装するならどうするか？
    • 1970年代の方法では実装しない
    • ハイエンドデータベースの要なスピードと可用性
    • OSSデータベースのシンプルさとコスト効果の高さ
    • 利用した分だけ支払うモデル

Service Oriented Architecture

  • ログとストレージレイヤをシームレスにスケールするストレージサービスに移動
  • EC2, DynamoDB, SWFなどのAWSサービスを管理コンポーネントに採用
  • S3を利用して高い可用性でストリーミングバックアップ

キャッシュレイヤの分離

  • キャッシュをデータベースプロセス外に移動させた
  • データベースプロセスのリスタートが発生してもキャッシュが残った状態を維持可能

Auroraのストレージ

  • SSDを利用したシームレスにスケールするストレージ
  • 標準でHAを実現
    • 3AZに6つのコピー
    • 2ディスクが利用不可でも読み書き可能
  • Log Structure Storage
  • Auroraが6本のディスクへの書き込みを待たずに、少なくとも4つに書き込みが完了したらすぐに次の処理を実行
  • ホットスポットの影響を取り除き、非常に高い並列度を実現
  • ストレージはSSDベースのディスクに10GBずつのブロック内に分散して書き込まれる

ストレージの特徴

  • リードレプリカもマスタと同じストレージを参照
  • 継続的なS3への増分バックアップ
  • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化

Log Structure Storage

  • 追記型のストレージシステム
    • 常に末尾にデータを追加していくだけ
    • GCによりデータを効率的に格納する
  • シーケンシャルに読み出す事が出来る
  • 常に最新のデータが末尾にある
  • これらの特徴によりS3への継続バックアップ・書き込み性能の向上を実現

ディスク障害の検知と修復

  • 2つのコピーに障害が起きても、読み書きに影響は無い
  • 3つのコピーに障害がおきても、読み込みは可能
  • 障害が起きても自動で修復

レプリケーション

  • Consistency - 異常を修復
  • Latency - 同期 vs 非同期レプリケーション
  • network I/Oを効率的に行う
  • Binlogによるレプリケーションではない
  • マスターへの負荷を最小限にしつつ、15台までリードレプリカを作成可能
  • 100ms以内のレプリケーション遅延
  • マスタとリードレプリカで同じディスクを共有しているため、フェイルオーバーでデータロスが無い

セキュリティ

  • データの暗号化
  • SSLを利用
  • VPCを使ったネットワーク分離
  • ノードへの直接アクセスは不可能

DBクラスタ

  • マスタとリードレプリカをひとまとめにしたもの
  • フェイルオーバーが発生しても、常にマスタを参照できるエンドポイントが1つ存在する
  • DB Parameter GroupとDB Cluster Parameter Group(クラスタ内で共通設定)がある

フェイルオーバーとリプレース

  • リードレプリカが存在する場合は、1分程度でフェイルオーバー
    • リードレプリカが存在しない場合は、10分程
    • 今後、開発が進めばもっとはやくなるかも
  • 優先的にフェイルオーバーさせるノードを1つ指定可能
    • Multi-AZ配置として、別AZで起動する
  • ノードリプレース時に新Auroraノードを起動するAZを指定可能

クラスタエンドポイント

  • Writer/Readerのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すエンドポイントが存在する
  • 各Auroraノードはエンドポイントを持っている
  • クラスタのエンドポイントはその時のアクティブなWriterのCNAME
  • 参照は各Readerを参照する
  • 障害が起こると、別ノードが昇格し、エンドポイントの指し先が変わる

高速なデータ修復

  • Disk readの一環としてオンデマンドでredo logの適用を行う
  • 並列、分散、非同期で行われる
    • MySQLだとシングルスレッドなので時間がかかる

Streaming SnapshotとPITR

  • 各セグメントごとにS3へ継続的に増分バックアップを取得
  • パフォーマンスに影響なし
  • PITRで5分前から、Backup Retention Periodまでの任意の位置に秒単位で復元可能

障害テスト

  • SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能
    • 擬似的に、障害をシミュレートできる

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

  • クエリ並列度は高い、データサイズが大きいケースで高価を発揮
  • ロック機構や暮れ裏キャッシュに手を入れて性能向上を行っている
    • write heavyな環境ではoffがおすすめ
    • CPUを効率的に利用する改善を入れているので、CPU使用率がMySQLと比較して高くなるが、性能は落ちにくくなっている
  • 性能は最大5倍
    • re:Inventで発表されたものは、4インスタンスからr3.8xlargeにSysbenchを並列実行したケース
  • TPC-Cã‚’r3.8xlargeに実行した場合は、2.5倍の性能を計測

マイグレーション

  • RDSからのマイグレーションは、クリック1つ
  • MyISAMに対応していない
  • MyISAMが含まれている場合は、コンバートが発生するためにディスク容量が必要
  • MySQLからレプリケーション可能
    • Auroraからのレプリケーションはサポートしない

使いどころ

  • クエリ同時実行数やテーブルサイズが大きいケース
  • 複数のサーバにシャーディングをしている
    • 障害時の影響は考慮



まとめ


クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

rx7 読者になる

関連記事
コメントを書く