Amazon Aurora

AWS Black Belt Tech Webinar 2015 (旧マイスターシリーズ)

アマゾンデータ サービスジャパン株式会社

星野豊

自己紹介

• 星野豊 (ほしのゆたか)– @con_mame

– facebook.com/conmame

– ソリューションアーキテクト

• 経歴– 全てオンプレ環境のインフラエンジニア– 全AWS環境のインフラエンジニア

• 担当– Webサービス / game / Video・Live Streamingなどのメディア系のお客様

今回お話する内容は2015/7/28現在の情報です

Amazon Aurora

データベース管理を簡単に

• データベースを数分で作成可能

• 自動でパッチの適用

• 数クリックするだけでスケールアウト可能

• S3への継続的なバックアップ

• 障害の自動検知と自動フェールオーバ

Amazon RDS

2015/7/28 GAリリース！

Virginia / Oregon / Irelandリージョン

Amazon Aurora

• re:Invent 2014で発表されたRDSの新しいエンジン

• Amazonがクラウド時代にリレーショナル・データベースを作るとどうなるかを1から考え構築– 新しい技術的チャレンジを盛り込んでいる

• エンタープライズグレードの可用性とOSSレベルのコストを両立

Amazon Aurora

• Amazon AuroraはRDSが提供するエンジンのうちの1つ– RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Serverが選択可能

• ライセンス料金は不要

• ロックインもない• 使った分だけ課金

vCPU Mem Hourly

Price

db.r3.large 2 15.25 $0.29

db.r3.xlarge 4 30.5 $0.58

db.r3.2xlarge 8 61 $1.16

db.r3.4xlarge 16 122 $2.32

db.r3.8xlarge 32 244 $4.64

• ストレージ: $0.10/GB/month• IO課金: $0.20 per million IO• Virginiaリージョンの価格

Amazon Aurora pricing

Amazon Auroraの特徴

クエリ性能の向上

コストパフォーマンスが良い 高可用性・高耐久性セキュリティにも配慮

MySQL5.6互換スケーラブル

Amazon Auroraの特徴

• MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能

• ストレージが10GBから64TBまでシームレスに拡張

• 3AZに2つずつ、計6つのデータのコピーを保持– S3にストリーミングバックアップを実施

• VPC内に起動– Security GroupやNACLを使用してアクセスコントロール可能

• Amazon Auroraは99.99%の可用性を実現するように設計されている

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

現在のモノリシックなDB

複数の機能レイヤーが1つのアプリケーションになっている

SQL

Transactions

Caching

Logging

現在のモノリシックなデータベース

スケールアウトする場合は、このセットを増やしていく必要がある

SQL

Transactions

Caching

Logging

SQL

Transactions

Caching

Logging

Application

コスト・可用性・柔軟性の面で問題

リレーショナルデータベースをもう一度考える

• 今、データベースを再度実装するならどうするか？– 少なくとも1970年代の方法で実装はしない

– AWSサービスを活かすことができ、スケールアウトが簡単で、セルフヒーリングが出来るようなデータベースを作りたいと考えた

クラウド時代に適したリレーショナルデータベース

• ハイエンドデータベースの様なスピード と 可用性

• オープンソースデータベースのシンプルさとコスト効果の高さ

• MySQLと互換性を保つ

• 利用した分だけお支払いいただく課金モデル

• AWSサービスと簡単に連携

マネージド・サービスとしてご提供

Establishing our ecosystem“Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB

connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise のMariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性の心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを加速させるために一緒に働くことを楽しみにしています。”

— Roger Levy, VP Products, MariaDB

アーキテクチャ

Service Oriented Architecture

• ログとストレージレイヤをシームレスにスケールするストレージサービスに移動

• EC2, Amazon DynamoDB, Amazon SWFなどのAWSサービスを管理コンポーネントに採用

• Amazon S3を利用して99.999999999%の耐久性でストリーミングバックアップ

Data Plane

Logging + Storage

SQL

Transactions

Caching

Amazon S3

Control Plane

Amazon DynamoDB

Amazon SWF

Amazon Route 53

キャッシュレイヤの分離

• キャッシュをデータベースプロセス外に移動させた

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

• サービスにすぐデータベースを戻すことが出来る

SQL

Transactions

Caching

SQL

Transactions

Caching

SQL

Transactions

Caching

キャッシュプロセスをDBプロセス外におくことでDBプロセスの再起動でもキャッシュが残る

Auroraのストレージ• SSDを利用したシームレスにスケールするストレージ

– 10GBから64TBまでシームレスに自動でスケールアップ

– 実際に使った分だけ課金

• 標準でHighly availableを実現– 3AZに6つのデータのコピーを作成

– 2つのディスクが利用不能でも読み書き可能

• 万が一1つのAZが利用不能になっても3本で読み書き可能な状態で稼働

– 3つのディスクが利用不能の場合読み込みのみ可能

• Log structured Storage– redo logを複数の小さなセグメントに分割

– Log pageによってData pageを作成

SQL

Transactions

AZ 1 AZ 2 AZ 3

Caching

Amazon S3

Auroraのストレージ

• Amazon Auroraは6本全てのディスクへの書き込みを待たずに、少なくとも4つのディスクに書き込みが完了するとすぐに次の処理を実行

• ホットスポットの影響を取り除き、非常に高い並列度を実現

• ストレージはSSDベースのディスクに10GBずつのブロック内に分散して書き込まれる

Auroraのストレージの特徴

• リードレプリカもマスタと同じストレージを参照

• Log Structured Storage

• 継続的なS3へ増分バックアップ– パフォーマンスへの影響なし

• 64TBまで自動でストレージがシームレスにスケールアップ– パフォーマンスや可用性に影響無し・利用開始時のプロビジョニング不要

• 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化

Log Structured Storage

• 追記型のストレージ・システム– ログの様に常に末尾にデータを追加していくだけ– データが書き込まれているブロックを上書いたりはしない– GCによりデータを効率的に格納する

• シーケンシャルに読み出すことが出来る• 常に最新のデータが末尾にある• これらの特徴によりS3への継続バックアップや高速なリカバリ、書き込み性能の向上を実現

空きスペース

data

data

先頭

data

data

data

新規データは末尾に追記される

↓

ディスク障害検知と修復

• 2つのコピーに障害が起こっても、読み書きに影響は無い• 3つのコピーに障害が発生しても読み込みは可能• 自動検知、修復

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

読み書き可能読み込み可能

レプリケーション

AZ 1 AZ 2

PrimaryInstance

StandbyInstance

EBS

Amazon S3

EBSmirror

EBS

EBSmirror

MySQL レプリケーション

PITR

シーケンシャル・ライト

シーケンシャル・ライト

AZ 1 AZ 3

PrimaryInstance

Amazon S3

AZ 2

ReplicaInstance

改善点• Consistency –異常を修復• Latency –同期 vs 非同期レプリケーション• network I/Oを効率的に行う

非同期 4/6クオーラム 分散書き込み

Amazon Aurora

ログレコード

Binlog

データDouble-write buffer

metadata

書き込みの種類

レプリケーション

ページキャッシュパージ

Aurora Master

30% Read

70% Write

Aurora Replica

100% New Reads

Shared Multi-AZ Storage

MySQL Master

30% Read

70% Write

MySQL Replica

30% New Reads

70% Write

シングルスレッドでBinlog適用

Data Volume Data Volume

MySQL read scaling

• レプリケーションにはbinlog / relay logが必要

• レプリケーションはマスターへ負荷がかかる

• レプリケーション遅延が増加していくケースがある

• フェイルオーバでデータロスの可能性がある

レプリケーション

• Amazon Auroraは、15台のリードレプリカを作成可能– リードレプリカはマスタサーバとストレージを共有しており、低負荷で粒度の高いほぼ同期型のレプリケーションを行う

– 10-20msのレイテンシーでレプリケーションされる

– RDS for MySQLではリードレプリカは5つまで (孫リードレプリカを入れて30)

セキュリティ• データの暗号化

– AES-256 (ハードウエア支援)– ディスクとAmazon S3に置かれている全ブロックを暗号化– AWS KMSを利用したキー管理 (現在未サポート)

• SSLを利用したデータ通信の保護

• 標準でAmazon VPCを使ったネットワークの分離

• ノードへ直接アクセスは不可能

• 業界標準のセキュリティとデータ保護の認証をサポート

Storage

SQL

Transactions

Caching

Amazon S3

Application

DBクラスタ

• Amazon AuroraはDBクラスタという概念を持っている– マスタ (Writer)とリードレプリカ(Reader)をひとまとめにしたもの

– Parameter GroupやMaintenance WindowもDBクラスタと各ノードそろぞれに存在する

• フェイルオーバが発生しても常にマスタを参照するエンドポイントがクラスタ毎に1つ存在する– アプリケーションからのWriteクエリは常にこのエンドポイントを参照するように設定

DB Parameter GroupとDB Cluster Parameter Group

• RDS for MySQLではDB Parameter Groupのみ

• Auroraでは設定の適用範囲毎にグループを設定– DB Cluster Parameter Group: Auroraクラスタ内全ノードで共通– DB Parameter Group: 各Auroraノード個別の設定

新しいメトリクス画面

• Throughput– Select

– Commit

– DML/DDL

• Latency– Select

– Commit

– DML/DDL

• Cache Hit Ratio– Buffer Cache

– Result Set

• Deadlocks

• Login Failures

• Blocked Transactions

メトリクススキーマ

• INFORMATION_SCHEMA.REPLICA_HOST_STATUS

• mysql.ro_replica_status

mysql> SELECT SERVER_ID, REPLICA_LAG_IN_MILLISECONDS, SESSION_ID FROM

INFORMATION_SCHEMA.REPLICA_HOST_STATUS;

+-----------------+-----------------------------------------------------+-----------------------------------------+

| SERVER_ID | REPLICA_LAG_IN_MILLISECONDS | SESSION_ID |

+-----------------+----------------------------------------------------+-------------------------------------------+

| demo-db01 | 18.458999633789062 | 62c35a1c-2f61-11e5-96de-06be620fb7bd |

| demo-db02 | 0 | MASTER_SESSION_ID |

| demo-db03 | 19.39299964904785 | 6194b000-2f61-11e5-9bf6-12715c13435b |

+-----------------+---------------------------------------+--------------------------------------------------------+

メトリクススキーマ

フェイルオーバとリカバリ

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

• リードレプリカが存在する場合は1分程でフェイルオーバ可能– RDS for MySQLよりも高速にフェイルオーバ可能– リードレプリカが存在しない場合は10分程

• 優先的にフェイルオーバさせるノードを1つ指定可能– Multi-AZ配置として別AZで起動する– RDS for MySQLと違いリードアクセス可能

クラスタエンドポイント• WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエン

ドポイントが存在する

• 各Auroraノードは個別にエンドポイントを持っている

Reader

Writer

クラスタエンドポイント

Aurora Writer Aurora Reader

クラスタエンドポイント

• 各Auroraノードは個別にエンドポイントを持っている

• クラスタエンドポイントは、その時アクティブなAurora WriterノードのCNAME

• Readは各Readerを参照する

Write

クラスタエンドポイント

• フェイルオーバが発生すると、Auroraノードの昇格が行われ、クラスタエンドポイントの指し先が変わる

Aurora Writer Aurora Reader

クラスタエンドポイント

Write

Writer / Readerノードの識別

• innodb_read_onlyを参照– SHOW GLOBAL VARIABLES LIKE 'innodb_read_only’;

– OFF: Writer

– ON: Reader

• アプリケーションやドライバでAuroraノードに対する負荷分散やフェイルオーバーロジックの実装に利用可能– メトリクススキーマのSEESION_IDも利用可能

高速なデータ修復

既存のデータベース

• 最後のチェックポイントからログを適用していく

• MySQLではシングルスレッドなため適用完了までの時間が増加

Amazon Aurora

• Disk readの一環として、オンデマンドでredo logの適用を行う

• 並列、分散、非同期で行われる

Checkpointed Data Redo Log

T0 でクラッシュが発生すると最後のチェックポイントからのログを適用する必要がある

T0 T0

T0 でクラッシュが発生するとredoを並列で分散して非同期でログの適用を行う

Streaming snapshotとPITR

• Amazon Auroraでは各セグメント毎にAmazon S3へ継続的に増分バックアップを取得している– Backup retention periodでバックアップを残す期間を指定可能

• Amazon Auroraが使用しているディスクの仕組みによりパフォーマンスへ影響を与えない

• PITRで5分前からBackup Retention Periodまでの任意の位置に秒単位で復元可能

SQLによるフェイルオーバのテスト

SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能

• データベースノードのクラッシュをシミュレート:ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]

• レプリケーション障害をシミュレート:ALTER SYSTEM SIMULATE percentage_of_failure PERCENT

READ REPLICA FAILURE [ TO ALL | TO "replica name" ]FOR INTERVAL quantity [ YEAR | QUARTER | MONTH | WEEK| DAY | HOUR |

MINUTE | SECOND ];

• 他にも– ディスク障害をシミュレート– ディスクコンジェスションをシミュレート

パフォーマンス

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

• クエリ並列度が高い、データサイズが大きいケースで効果を発揮

• ロック機構やQuery cache・スレッドプールなどに手を入れて性能向上を行っている– write heavyな環境ではoffをおすすめ

– CPUを効率的に利用する改善により、CPU利用率がMySQLと比較して高くなるが、性能が落ちにくくなっている

パフォーマンス測定

Aurora Writer

• 複数のインスタンスから同時に負荷をかけ並列度を上げる

– NWの影響を抑えるために同一リージョンで行う

– 1-2時間など長時間行う

• 単一のインスタンスからだけでは、インスタンス毎のNW帯域の制限に達する可能性がある

• 高負荷環境でもスループット低下を抑える改善が入っているためCPU/メモリ利用率がRDS for MySQLと比較して高くなるケースがある

defaultパラメータの違い

• RDS for MySQLと比べるとbuffer / connection / 周りの値が少なめ

• query cacheがON– ONの状態でも性能が出るようにAuroraでは性能向上が行われている

– Write heavyな環境ではOFFも検討

defaultパラメータの違い

• innodb_change_buffering– NONE

– 今のところ変更不可

– Secondary indexへの更新などに影響が出そうだが、1-2時間など長時間ベンチマークを行い、change bufferに収まらない量になってくると、Auroraの優位性が出てくる

• 数十分の短いベンチマークだと多少影響を受ける可能性がある

新規パラメータ

• thread_handling– Default: multiple-connections-per-thread

– multiple-connections-per-thread, no-threads, one-thread-per-

connection, dynamically-loaded

– 接続を扱うAuroraのスレッドに関する設定

パフォーマンス

• 性能が5倍というのはどのようなケースか– re:Inventで発表された5倍という性能はSysbenchを4インスタンス

(r3.8xlarge + NW関連のkernelパラメータ調整済)からr3.8xlargeのAuroraインスタンスに実行した場合の結果

• TPC-C をr3.8xlargeに実行した場合は約2.5〜5倍の性能を観測している

パフォーマンス

• FAQとパフォーマンステストのガイドライン・テスト用AMIを提供しています– http://aws.amazon.com/rds/aurora/faqs/ の Amazon Aurora

Performance Benchmarking Guide

パフォーマンス

• 価格性能比5倍– Amazon Auroraは高速でSSDベースのストレージにより高速に動作するが、既存のどんなクエリでも5倍高速に実行出来ることを意味しているわけではない

– Amazon Auroraは他の製品よりも、より多くの書き込み・読み込みクエリを同時に扱うことが出来るためデータベースの集約やスループット向上が見込める

– Amazon Aurora独自で高並列なストレージへのアクセスにより保存されているデータへのコンテンションを解決し、クエリを効率よく処理

参考 (re:Inventで発表された資料)

よく見ると

• Auroraはデッドロックをがほんの少し出やすいがリトライを行ってもMｙSQLよりスループットが出る

• CPU / Memoryの利用率がMySQLより高いがスループットが出ている– 分散ロック機構によりCPUリソースを使いきってスループットを出している

何をみるのか？

• よく聞かれる質問– CPU利用率高いんだけど?– メモリ利用量多いんだけど？– Disk IOが多めなんだけど？

• 見てほしいこと

– Auroraはマシンリソースを最大限利用してスループットを出す設計です

– システムトータルでパフォーマンスが向上– 管理コスト、障害耐性、データ保全性

何をみるのか？

• AuroraはMySQL互換ですが、マシンリソースの使い方が根本的に違います

• Auroraが得意な場面・状況を理解してパフォーマンスを測定– マシンリソースを使い切りそうになりながらもMySQLと比べるとスループットやレスポンスタイムの落ち方が緩やか

Amazon Auroraへの移行

RDS for MySQLからマイグレーション

• マネージメントコンソールから数クリックでAmazon Auroraへ移行可能– RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能

– RDS for MySQLは5.6を使う必要がある

マイグレーション時の注意

• RDS for MySQLとParameter Groupで設定出来る項目や規定値などが異なる– 例: max_connection / innodb_buffer_pool_size / query_cache_*など

• マイグレーションに必要なディスクスペース– スナップショットをインポートする場合、インポート前にEBSボリュームを使用しデータをフォーマットする

– データをフォーマットするための追加容量が必要になる場合がある

マイグレーション時の注意

• Amazon AuroraはInnoDBのみサポート– MyISAMなどのストレージエンジンは非対応

• マイグレーション時に自動でMyISAMからコンバートされますが、事前に手動でInnoDBへの変換を行っていただくことがオススメです

マイグレーション時の注意

• MyISAM形式のテーブルが含まれない場合– 移行前のディスクで6TBまで容量を利用可能

• MyISAM形式のテーブルが含まれる場合– マイグレーションを行うテーブルで3TBを超えるものが無いことを確認する

MySQLからレプリケーション

• MySQL5.6からAmazon Auroraへレプリケーションを行うことが可能

• 専用のProcedureを使用

mysql > CALL mysql.rds_set_external_master (DB Hostname or IP address',

3306,’user', ‘password', ’Binlog', position, 0);

mysql > CALL mysql.rds_start_replication;

MySQLからレプリケーション

• RDS for MySQLやMySQL on EC2、オンプレ環境のMySQLからAmazon Auroraにレプリケーション可能– バックアップからAuroraにインポートを行い、レプリケーションを実行

– 移行時にアプリケーションのメンテナンスを入れ、書き込みがなくなり、レプリケーションが追いついたタイミングでアプリケーションの書き込み先などをAuroraに変更

Amazon Auroraの使いどころ

クエリ同時実行数やテーブルサイズが大きい

• Amazon Auroraに移行することで、クエリスループットの向上などが見込まれる– マルチコア環境でCPUを効率的に利用

– 分散ロック機構やquery cacheの改善による性能向上

• ディスク– データ量の増加に応じてディスク容量を気にする必要が無い

– 性能に影響を及ばさずバックアップ

複数のサーバにシャーディングしている

• 複数の小さいDBを1つにまとめる– コスト効果増大と管理コストの軽減

– シャーディングをするデータベースを減らすことでアプリケーションの設計を簡略化出来る

– 障害時の影響を考慮する必要はある

まとめ

Amazon Aurora

• クラウド時代にAmazonが再設計したRDBMS– MySQL5.6と互換があり既存の資産を活かしやすい

• 高いクエリ実行並列度・データサイズが大きい環境で性能を発揮– Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮

• 高可用性・高速なフェイルオーバ・PITRを実現するための多くのチャレンジ– Log Structured Storage

– SOA

Q&A

次回Webinarのお申し込み

http://aws.amazon.com/jp/event_schedule/

http://aws.amazon.com/jp/event_schedule/

Webinar資料の配置場所

• AWS クラウドサービス活用資料集– http://aws.amazon.com/jp/aws-jp-introduction/

http://aws.amazon.com/jp/aws-jp-introduction/

公式Twitter/FacebookAWSの最新情報をお届けします

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

ご参加ありがとうございました。