Amazon Aurora (MySQL-compatible edition) Deep Diveスケーラブル MySQL5.6互換 ... Aurora MySQL...
Transcript of Amazon Aurora (MySQL-compatible edition) Deep Diveスケーラブル MySQL5.6互換 ... Aurora MySQL...
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon Web Services Japan K.K.Yutaka Hoshino, Database Specialist SA
Amazon Aurora(MySQL-compatible edition)
Deep Dive
内容についての注意点
本資料では2017年6⽉1⽇時点のサービス内容および価格についてご説明しています。最新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。
• 資料作成には⼗分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。
• 価格は税抜表記となっています。⽇本居住者のお客様が東京リージョンを使⽤する場合、別途消費税をご請求させていただきます。
AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.
ライセンス料⾦は不要ロックインもない使った分だけ課⾦
vCPU Mem HourlyPrice
db.t2.small 1 2 $0.063db.t2.medium 2 4 $0.125db.r3.large 2 15.25 $0.35db.r3.xlarge 4 30.5 $0.70db.r3.2xlarge 8 61 $1.40db.r3.4xlarge 16 122 $2.80db.r3.8xlarge 32 244 $5.60 • ストレージ: $0.120/GB/月
• IO課金: $0.240/100万リクエスト• 東京リージョンの価格
Amazon Auroraの価格
*NEW*
*NEW*
Auroraのストレージ
SSDを利⽤したシームレスにスケールするストレージ
• 10GBから64TBまでシームレスに⾃動でスケールアップ
• 実際に使った分だけ課⾦
標準で⾼可⽤性を実現• 3AZに6つのデータのコピーを作成
Log structured Storage
SQLTransactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3
ストレージノードクラスタ• Protection Group毎に6つのストレージノードを使⽤• 各ログレコードはLog Sequence Number(LSN)を持っており不⾜・重複
しているレコードを判別可能• 不⾜している場合はストレージノード間でgossip protocolを利⽤し補完を⾏う
ディスク障害検知と修復• 2つのコピーに障害が起こっても、読み書きに影響は無い• 3つのコピーに障害が発⽣しても読み込みは可能• ⾃動検知、修復
SQLTransaction
AZ 1 AZ 2 AZ 3
Caching
SQLTransactio
n
AZ 1 AZ 2 AZ 3
Caching
読み書き可能読み込み可能
IO traffic in Aurora (ストレージノード)
LOG RECORDS
Primary instance
INCOMING QUEUE
STORAGE NODE
S3 BACKUP
1
2
3
4
5
6
7
8UPDATE QUEUE
ACK
HOTLOG
DATABLOCKS
POINT IN TIMESNAPSHOT
GC
SCRUBCOALESCE
SORTGROUP
PEER-TO-PEER GOSSIPPeerstoragenodes
全てのステップは⾮同期ステップ1と 2だけがフォアグラウンドのレイテンシーに影響インプットキューはMySQLの1/46 (unamplified, per node)レイテンシーにセンシティブな操作に向くディスク領域をバッファーに使ってスパイクに対処
OBSERVATIONS
IO FLOW
① レコードを受信しインメモリのキューに追加② レコードを永続化してACK ③ レコードを整理してギャップを把握④ ピアと通信して⽳埋め⑤ ログレコードを新しいバージョンのデータブロックに
合体⑥ 定期的にログと新しいバージョンのブロックをS3に
転送⑦ 定期的に古いバージョンのガベージコレクションを実
施⑧ 定期的にブロックのCRCを検証
セキュリティデータの暗号化
• AES-256 (ハードウエア⽀援)• ディスクとAmazon S3に置かれている全ブロックを暗号化• AWS KMSを利⽤したキー管理
SSLを利⽤したデータ通信の保護
標準でAmazon VPCを使ったネットワークの分離
ノードへ直接アクセスは不可能
業界標準のセキュリティとデータ保護の認証をサポート
Storage
SQL
Transactions
Caching
Amazon S3
Application
フェイルオーバ と リプレース
リードレプリカが存在する場合は1分程でフェイルオーバ可能
• RDS for MySQLよりも⾼速にフェイルオーバ可能• リードレプリカが存在しない場合は10-15分程
Multi-AZ配置として別AZで起動可能• RDS for MySQLと違いリードアクセス可能
⾼速でより予測可能なフェイルオーバー時間
ApprunningFailure detection DNS propagation
Recovery Recovery
DBfailure
MYSQL
Apprunning
Failure detection DNS propagation
Recovery
DBfailure
AURORA WITH MARIADB DRIVER
1 5 - 2 0 s e c
3 - 2 0 s e c
0.00% 5.00%
10.00% 15.00% 20.00% 25.00% 30.00% 35.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0 - 5s – 30% of fail-overs
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
5 - 10s – 40% of fail-overs
0% 10% 20% 30% 40% 50% 60%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
10 - 20s – 25% of fail-overs
0%
5%
10%
15%
20%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
20 - 30s – 5% of fail-overs
Database fail-over time
Streaming backupとPITR
Amazon Auroraでは各セグメント毎にAmazon S3へ継続的に増分バックアップを取得している
• Backup retention periodでバックアップを残す期間を指定可能
Amazon Auroraが使⽤しているディスクの仕組みによりパフォーマンスへ影響を与えない
PITRで5分前からBackup Retention Periodまでの任意の位置に秒単位で復元可能
Streaming backupSegment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
各セグメントの定期的なSnapshotは並列で⾏われ、redo logはストリームで継続バックアップのためにS3に送られる。パフォーマンスや可⽤性に対する影響は無し
リストアでは、適切なセグメントのSnapshotとログストリームをストレージノードに転送し、並列で⾮同期で適⽤していく
Writer / Readerノードの識別
innodb_read_onlyを参照• SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ;• OFF: Writer• ON: Reader
アプリケーションやドライバでAuroraノードに対する負荷分散やフェイルオーバーロジックの実装に利⽤可能
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 Driver
MariaDB Connector/J 1.2.0以降に含まれている• https://mariadb.com/kb/en/mariadb/mariadb-connector-j-120-release-
notes/• リリースノートには明確にAuroraの記述は無いがドキュメント中に記載
• https://mariadb.com/kb/en/mariadb/about-mariadb-connector-j/• https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-
mariadb-connector-j/#specifics-for-amazon-aurora• 2015.09 Amazon Linuxよりrpmを提供
現在の提供機能• Fast failover• Auto node discovery
Aurora Driver
https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/
WRITE PERFORMANCE READ PERFORMANCE
インスタンスサイズによるスケール
AuroraはRead/Writeパフォーマンス共にインスタンスサイズに⽐例してスケール
Aurora MySQL 5.6 MySQL 5.7
チューニング指針
Amazon AuroraはMySQLと⽐較してインスタンスリソースを効率的に最⼤限利⽤する設計
• CPUやメモリの利⽤率が⾼めだが、パフォーマンスに影響が出ない限りは過度な⼼配は必要ない
Amazon Auroraは実際のワークロードで性能が発揮できるように開発・チューニングが⾏われている
• 監視項⽬はインスタンスリソースでは無く、実際のパフォーマンステストを元にクエリレイテンシやスループット・buffer poolのcache hitレートに注⽬
チューニング指針
まずはデフォルトのパラメータグループを使⽤• Amazon Auroraはデフォルトの設定でパフォーマンスを
発揮できるようにチューニング済み
適切なインスタンスタイプを選択することが⼤切• それでも性能が出ない場合にパラメータグループの変更
を検討
チューニングTips
1トランザクションで⼤量の更新や削除を⾏ったり、⼤量データのシーケンシャルリードを⾏う場合
• 1トランザクションで⼤量の更新・削除やシーケンシャルリードを⾏う場合Amazon Auroraのアーキテクチャに合わせてクエリを実⾏することで性能を向上させることが可能
チューニングTips
#1> SELECT * FROM Table;
#1> SELECT * FROM Table WHERE id BETWEEN 1 AND 10000;
#2> SELECT * FROM Table WHERE id BETWEEN 10001 AND 20000;
#3> SELECT * FROM Table WHERE id BETWEEN 20001 AND 30000;
#4> .........
• SELECT (Parallel Read Aheadで大幅性能改善)
• DELETE / UPDATE
#1> DELETE * FROM Table WHERE id >= 100000;
#1> DELETE FROM Table WHERE id BETWEEN 10000 AND 20000;
#2> DELETE FROM Table WHERE id BETWEEN 20001 AND 30000;
#3> DELETE FROM Table WHERE id BETWEEN 300001AND 40000;
#4> .........
新しいメトリクス画⾯Throughput
• Select• Commit• DML/DDL
Latency• Select• Commit• DML/DDL
Cache Hit Ratio• Buffer Cache• Result Set
DeadlocksLogin FailuresBlocked Transactions
メトリクススキーマINFORMATION_SCHEMA.REPLICA_HOST_STATUSmysql.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 |+-----------------+---------------------------------------+--------------------------------------------------------+
拡張モニタリング
User System Wait IRQ Idle
CPU Utilization
Rx per declared ethnTx per declared ethn
Network
Num processes Num interruptibleNum non-interruptible Num zombie
Processes
Process ID Process name VSS Res Mem % consumed CPU % used CPU time Parent ID
Process List
MemTotalMemFreeBuffers Cached SwapCachedActive Inactive SwapTotalSwapFreeDirty WritebackMapped Slab
MemoryTPS Blk_readBlk_wrtnread_kbread_IOsread_sizewrite_kbwrite_IOswrite_sizeavg_rw_sizeavg_queue_len
Device IO
Free capacity Used % Used
File System
これらのメトリクスを最短1秒間隔で取得可能
拡張モニタリングCloudWatch Logsにメトリクス送信可能
CloudWatch logs->Lambda->Elasticsearch Service連携も容易
• Kibanaを使ってアプリケーション・DBサーバメトリクス・クエリのパフォーマンスを⼀箇所で閲覧可能
マイグレーション時の注意
Amazon AuroraはInnoDB / ROW_FORMAT=Dynamicのみサポート
• InnoDB以外のストレージエンジンやROW_FORMAT=COMPRESSは⾮対応
マイグレーション時に⾃動でからコンバートされるが、事前に⼿動で対応ストレージエンジンやROW FORMATへの変換を推薦
White paper: http://bit.ly/2qjQzBc
RDS for MySQLからマイグレーションマネージメントコンソールから数クリックでAmazon Auroraへ移⾏可能
• RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能
• RDS for MySQLは5.6を使う必要がある
RDS MySQL DBインスタンスからAmazon Aurora Read Replica を作成
RDS MySQLインスタンスからAmazon Auroraにダウンタイムを最⼩限に移⾏する場合、SnapshotからAuroraクラスタを起動し、⼿動でレプリケーションを設定する必要があった
この機能を利⽤することによって、ワンクリックでRDS MySQLのSnapshotからAurora Read Replicaを起動し、レプリケーションの設定まで⾃動で⾏われる
RDS MySQL DBインスタンスからAmazon Aurora Read Replica を作成
RDS MySQL5.6(Master)
Aurora(Writer)
Aurora(Reader)
Application
Write
Read
RDS MySQLのRRを作る感覚でAuroraクラスタへレプリケーション環境を自動で作成
MySQLスナップショットバックアップからの移⾏
Percona Xtrabackupを利⽤して作成したバックアップデータを利⽤してオンプレミス環境やAmazon EC2上のMySQLからAmazon Auroraクラスへ移⾏可能
• mysqldumpと⽐較したテストで約20倍⾼速に移⾏可能
S3にアップロードしたバックアップデータを利⽤• アップロードにはManagement ConsoleやCLI tools、データサイズが⼤
きい場合はAWS Import/Export Snowballを利⽤してS3へ転送する
Reader Endpointの追加Amazon Aurora cluster内のReaderに単⼀のエンドポイントを提供
• ReaderがFailoverした場合は、再接続を⾏うことで新しいReaderに接続が可能• Round Robinで接続
メリット• Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリード
レプリカ間でコネクションのロードバランシングが可能
• Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが可能
• 今までHAproxyなどで分散されていた⽅は置き換えることでシンプルに負荷分散
注意点• DNSベースなのでアプリケーションやドライバ側でIPアドレスのキャッシュ周りの
設定の確認やfailoverのテストを推薦• Readerが1インスタンスもいなくなった場合はWriterへfailbackを⾏う
Reader Endpoint
• クラスタ内のReaderにラウンドロビンで接続
• 常にReaderに接続されるが、Readerが1インスタンスもいなくなった場合はWriterにfailback
• Readerの追加・削除は⾃動で⾏われる
Availability Zone A Availability Zone B
VPC subnet VPC subnet
VPC subnet VPC subnetAurora Reader Aurora Reader
リーダエンドポイント
Read
Aurora Writer
IAM Authentication Integration
Amazon Auroraへログインするための認証にIAMが利⽤可能に(1.10以降)
• IAMのリソース制限を利⽤可能
• パスワードとしてSignature Version 4 を利⽤ (15分間有効の⼀時token)
• SSL接続が必須
• データベースアクセスに必要な認証情報をEC2インスタンスなどに配置しなくても良い
• AWS SDKやAWS CLI Tools対応
IAM Authentication Integration
SSL接続
CREATE USER iam-database-user IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS';
server
Lambda Function Integration
Amazon Aurora内からAWS Lambdaを呼び出せる• ストアードプロシジャーとして実⾏ (mysql.lambda_async)• ⾮同期でLambdaを実⾏する• IAM Roleで事前にAuroraへ権限を付与しておく
DELIMITER ;; CREATE PROCEDURE SNS_Publish_Message (IN subject VARCHAR(255), IN message TEXT) LANGUAGE SQL BEGIN CALL mysql.lambda_async(’Lambda ARN', CONCAT('{ "subject" : "', subject, '", "message" : "', message, '" }') ); END ;; DELIMITER ;
Load Data From S3
S3バケットに保存されたデータを直接Auroraにインポート可能• テキスト形式(LOAD DATA FROM S3)・XML形式(LOAD XML FROM S3)• LOAD DATA INFILEとほぼ同様のオプションをサポート (圧縮形式のデータ
は現在未サポート)• Manifestによる⼀括ロードにも対応 (Version 1.11以降)
<row column1="value1" column2="value2" /><row column1="value1" column2="value2" />
<row> <column1>value1</column1> <column2>value2</column2>
</row>
<row> <field name="column1">value1</field> <field name="column2">value2</field>
</row>
spatial index
空間インデックスサポート• Amazon Auroraは今までもGEOMETRY型や、
ST_Contains, ST_CrossesやST_Distanceといったspatial queryが利⽤可能
• ⼤きなデータセットに対してスケールするには不⼗分な点や制限があった
• Amazon Auroraではdimensionally ordered space-filling curveを利⽤しスケールし、⾼速かつ正確に情報を取得できる改善を⾏った
• MySQL5.7と⽐較して最⼤2倍のパフォーマンス
Spatial Index BenchmarksSysbench – points and polygons
• r3.8xlarge using Sysbench on <1GB dataset• Write Only: 4000 clients, Select Only: 2000
clients, ST_EQUALS
0
20000
40000
60000
80000
100000
120000
140000
Select-only(reads/sec) Write-only(writes/sec)
Aurora
MySQL5.7
R-Tree MySQL 5.7
Z-index / Aurora(dimensionally ordered space filling curve)
Advanced Auditing
MariaDB server_audit plugin Aurora native audit support
We can sustain over 500K events/sec
Create event string
DDL
DML
Query
DCL
Connect
DDL
DML
Query
DCL
Connect
Write to File
Create event string
Create event string
Create event string
Create event string
Create event string
Latch-free queue
Write to File
Write to File
Write to File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance
Zero downtime patch (ZDP)
コネクションを切断すること無くオンラインでパッチを適⽤• 5秒程度スループットの低下が起こるが、アプリケーションとの接続を維持
したままパッチを適⽤可能に (1.10以降)
• ベストエフォート• 既に開かれているSSLコネクション、アクティブなロック、トランザクション
の完了やテンポラリテーブルの削除を待機し、パッチ適⽤可能なウインドウが出来た場合、ゼロダウンタイムパッチとして適⽤
• ゼロダウンタイムパッチで適⽤出来るウインドウがなかった場合、通常のパッチ適⽤プロセスを実⾏
• 以下の条件では通常通りのパッチ適⽤プロセスを実施• バイナリログを有効にしている• SSLを利⽤した接続を⾏っており、ZDPのリトライ回数内に接続が終了しない
Zero downtime patch (ZDP)
Net
wor
king
stat
e
Appl
icat
ion
stat
e
Storage ServiceApp state
Net state
App state
Net stat
e
Befo
re Z
DP
New DB
Engine
Old DB Engine
New DB
Engine
Old DB Engine
With
ZDP
セッションはパッチ適⽤時に切断される
パッチ適⽤中でもセッションは維持される
Storage Service
Cached read performanceCatalog concurrency: データ・ディクショナリの同期とキャッシュ破棄の効率化
NUMA aware scheduler: NUMA を考慮したスケジューラへ変更すること、複数CPUが搭載されているインスタンスで性能向上
Read views: read viewを作成する際にラッチフリーなread viewを作成するアルゴリズムに変更
0
100
200
300
400
500
600
700
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
1,000 read requests/sec* R3.8xlarge instance, <1GB dataset Sysbench25% Throughput gain
Smart scheduler: IOヘビー・CPUヘビーなワークロードそれぞれに動的に処理スレッドを割り当てるスケジューラに変更
Smart selector: 最も良いパフォーマンスのストレージノードにあるデータを選択することでリードレイテンシーを軽減
Logical read ahead (LRA): btreeの順序に応じて事前にpageを読み込んで置くことで、IO waitを軽減
0
20
40
60
80
100
120
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
1,000 requests/sec* R3.8xlarge instance, 1TB dataset Sysbench
10% Throughput gain
Non-cached read performance
§ プライマリーキーでソートされているデータのバッチインサートの速度を改善。インデックス⾛査を⾏う際のカーソル位置をキャッシュ
§ データパターンに応じて動的に機能を有効・無効化
§ ツリーを下⽅向に⾛査する際のラッチロックの競合を軽減
§ 双⽅向で全てのINSERTワークロードで有効• LOAD INFILE, INSERT INTO SELECT,
INSERT INTO REPLACE, Multi-value inserts.
Insert performanceIndex
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
MySQL:全てのINSERTがrootからB-treeをトラバースする
Aurora: indexトラバースを抑制
Faster index build§ MySQL 5.6 はLinuxの先読みを活⽤して
いるため、btreeに連続したブロックアドレスが必要。そのためエントリーをトップダウンで新しいbtreeに挿⼊する際に、分割と多くオンロギングが発⽣
§ Auroraはtree内のポジションを元にブロックをスキャンしてプリフェッチし、リーフブロックを作製してからブランチを作製していく• 分割が発⽣しない
• 各ページは1度のみ参照される
• 1ページに1ログレコード
2-4X better thanMySQL 5.6 or MySQL 5.7
0
2
4
6
8
10
12
r3.large on 10GB dataset
r3.8xlarge on 10GB dataset
r3.8xlarge on 100GB dataset
Hou
rsRDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016
Lab mode
今後提供予定の機能を試すことが可能• DBパラメータグループ aurora_lab_mode 変数で設定可能• 開発中の機能なので本番適⽤ではなく検証⽬的でお使い下さい
• GAクオリティですが、全てのワークロードで性能が発揮出来るか検証を⾏っている段階です
• フィードバックをお待ちしています!
現在ご提供中• Lock compression
• ロックマネージャーが利⽤するメモリを最⼤66%削減• OOMを起こさず、更に多くの⾏ロックを同時に取得することが可能に
• Fast DDL• nullableカラムをテーブルの最後に追加する場合にデータ件数によらず
⾼速に変更が⾏なえます
Fast DDL: Aurora vs. MySQL
§ フルテーブルコピー: 全てのインデックスを再構築 - 数時間から数⽇かかることも
§ DMLクエリ実⾏のために⼀時領域が必要
§ DDLクエリがDMLクエリスループットに影響
§ DMLクエリ実⾏中にテーブル・ロックが発⽣
Index
LeafLeafLeaf Leaf
Index
Root table name operation column-name time-stamp
Table 1Table 2Table 3
add-coladd-coladd-col
column-abccolumn-qprcolumn-xyz
t1t2t3
§ メタデータテーブルにエントリーを追加し、スキーマバージョニングを利⽤
§ 変更を適⽤するために最新のスキーマへブロックをアップグレードする際はmodify-on-write
§ 現在はテーブルの最後にNullableなカラムを追加する場合に対応
MySQL Amazon Aurora
Fast DDL performance
On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
50GB table 0.25 sec 23,400 sec 5,040 sec
100GB table 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec
50GB table 0.08 sec 4,680 sec 5,040 sec
100GB table 0.15 sec 14,400 sec 9,720 sec
DBの⼀貫した状態を提供するためにログストリーム中のログを、LSNツリー内のブランチを元に可視・不可視にする§ 最初のt2からt1へのrewindは、紫⾊のログを不可視にする§ 次のt4からt3へDBをrewindする場合、⾚と紫のログを不可視にする
How does it work?
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible
Database backtrack vs Offline Point in Time Restore (PiTR)Database backtrack Offline PiTR
Database backtrackは現在のデータベースの状態を変更
PITRは現在のDBのバックアップから所望の時点の新しいDBを作成
数テラバイトのテータベースでも数秒で利⽤可能になる
数テラバイトのデータベースをリストアするのに数時間かかる
追加のストレージの料⾦は発⽣しない リストアされた、それぞれのDB毎にストレージ料⾦がかかる
複数回のPITRのイテレーションの実施も現実的
複数回のオフラインPITRは時間を消費する
購⼊したrewind ストレージを元にしたrewind period内の範囲で実⾏可能
オフラインPITRはスナップショットか設定したバックアップウインドウ内で実⾏可能
Cross-region online PiTR は未サポート AuroraはCross-region PITRをサポート
Database cloningストレージコストを増やすことなくデータベースのコピーを作成
• データをコピーするわけではないため、クローンの作成はほぼ即座に完了
• データのコピーはオリジナルボリュームとコピー先のボリュームのデータが異なる場合の書き込み時のみ発⽣
ユースケース• プロダクションデータを使⽤したテスト• データベースの再構成• プロダクションシステムに影響を及ばさずに
分析⽬的で特定の時点でのスナップショットを保存
Production database
Clone Clone
CloneDev/test
applications
Benchmarks
Production applications
Production applications
Amazon Aurora
クラウド時代にAmazonが再設計したRDBMS• MySQL5.6と互換があり既存の資産を活かしやすい
⾼いクエリ実⾏並列度・データサイズが⼤きい環境で性能を発揮• Amazon Auroraはコネクション数やテーブル数が多い環境で優位
⾼可⽤性・実環境での性能向上を実現するための多くのチャレンジを継続して⾏っている