Más contenido relacionado La actualidad más candente (20) Similar a AWS Black Belt Online Seminar 2017 Amazon Aurora (20) Más de Amazon Web Services Japan (20) AWS Black Belt Online Seminar 2017 Amazon Aurora1. Amazon Aurora
AWS Black Belt Online Seminar 2017
Yutaka Hoshino, Database Specialist Solutions Architect
Amazon Web Services Japan K.K.
2. ⾃⼰紹介
• 星野 豊 (ほしの ゆたか)
– Database Specialist Solutions Architect
@con_mame conmame
• メディア系のお客様や⼤規模なWebサービス企
業様を担当
4. AWS Black Belt Online Seminar とは
• AWSJのTechメンバがAWSに関する様々な事を紹介するオンラインセミナーです
【⽔曜 18:00~19:00】
主にAWSサービスの紹介や
アップデートの解説
(例:EC2、RDS、Lambda etc.)
【⽕曜 12:00~13:00】
主にAWSのソリューションや
業界カットでの使いどころなどを紹介
(例:ネットワーク、IoT、⾦融業界向け etc.)
※最新の情報は下記をご確認下さい。
オンラインセミナーのスケジュール&申し込みサイト
– http://aws.amazon.com/jp/about-aws/events/#webinar
7. • ライセンス料⾦は
不要
• ロックインもない
• 使った分だけ課⾦
vCPU Mem Hourly
Price
db.t2.small 1 2 $0.063
db.t2.medium 2 4 $0.125
db.r3.large 2 15.25 $0.35
db.r3.xlarge 4 30.5 $0.70
db.r3.2xlarge 8 61 $1.40
db.r3.4xlarge 16 122 $2.80
db.r3.8xlarge 32 244 $5.60
• ストレージ: $0.120/GB/月
• IO課金: $0.240/100万リクエスト
• 東京リージョンの価格
Amazon Auroraの価格
*NEW*
*NEW*
11. IO traffic in Aurora (ストレージノード)
LOG RECORDS
Primary
instance
INCOMING QUEUE
STORAGE NODE
S3 BACKUP
1
2
3
4
5
6
7
8
UPDATE
QUEUE
ACK
HOT
LOG
DATA
BLOCKS
POINT IN TIME
SNAPSHOT
GC
SCRUB
COALESCE
SORT
GROUP
PEER-TO-PEER GOSSIPPeer
storage
nodes
全てのステップは⾮同期
ステップ1と 2だけがフォアグラウンドのレイテンシーに
影響
インプットキューはMySQLの1/46 (unamplified, per
node)
レイテンシーにセンシティブな操作に向く
ディスク領域をバッファーに使ってスパイクに対処
OBSERVATIONS
IO FLOW
① レコードを受信しインメモリのキューに追加
② レコードを永続化してACK
③ レコードを整理してギャップを把握
④ ピアと通信して⽳埋め
⑤ ログレコードを新しいバージョンのデータブロックに
合体
⑥ 定期的にログと新しいバージョンのブロックをS3に
転送
⑦ 定期的に古いバージョンのガベージコレクションを実
施
⑧ 定期的にブロックのCRCを検証
13. セキュリティ
• データの暗号化
– AES-256 (ハードウエア⽀援)
– ディスクとAmazon S3に置かれている全ブロックを暗号化
– AWS KMSを利⽤したキー管理
• SSLを利⽤したデータ通信の保護
• 標準でAmazon VPCを使ったネットワークの分離
• ノードへ直接アクセスは不可能
• 業界標準のセキュリティとデータ保護の認証をサポート
Storage
SQL
Transactions
Caching
Amazon S3
Application
15. フェイルオーバ と リカバリ
• リードレプリカが存在する場合は1分程でフェイル
オーバ可能
– RDS for MySQLよりも⾼速にフェイルオーバ可能
– リードレプリカが存在しない場合は10-15分程
• Multi-AZ配置として別AZで起動可能
– RDS for MySQLと違いリードアクセス可能
17. 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
フェイルオーバー時間
18. Streaming backupとPITR
• Amazon Auroraでは各セグメント毎にAmazon S3
へ継続的に増分バックアップを取得している
– Backup retention periodでバックアップを残す期間を指定可能
• Amazon Auroraが使⽤しているディスクの仕組み
によりパフォーマンスへ影響を与えない
• PITRで5分前からBackup Retention Periodまでの
任意の位置に秒単位で復元可能
21. マイグレーション時の注意
• Amazon AuroraはInnoDB /
ROW_FORMAT=Dynamicのみサポート
– InnoDB以外のストレージエンジンやROW_FORMAT=COMPRESSは
⾮対応
• マイグレーション時に⾃動でからコンバートされる
が、事前に⼿動で対応ストレージエンジンやROW
FORMATへの変換を推薦
• ホワイトペーパー: http://bit.ly/2xw8Uyl
22. RDS for MySQLからマイグレーション
• マネージメントコンソールから数クリックでAmazon Aurora
へ移⾏可能
– RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション
可能
– RDS for MySQLは5.6を使う必要がある
23. RDS MySQL DBインスタンスからAmazon
Aurora Read Replica を作成
• RDS MySQLインスタンスからAmazon Auroraにダウ
ンタイムを最⼩限に移⾏する場合、スナップショットか
らAuroraクラスタを起動し、⼿動でレプリケーション
を設定する必要があった
• この機能を利⽤することによって、ワンクリックでRDS
MySQLのスナップショットからAurora Read Replica
を起動し、レプリケーションの設定まで⾃動で⾏われる
24. RDS MySQL DBインスタンスからAmazon Aurora
Read Replica を作成
RDS MySQL5.6
(Master)
Aurora
(Writer)
Aurora
(Reader)
Application
Write
Read
Auroraクラスタへレプリケーション環境を自動で作成
27. 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を⾏う
28. Reader Endpoint
• クラスタ内のReader
にラウンドロビンで
接続
• 常にReaderに接続さ
れるが、Readerが1イ
ンスタンスもいなく
なった場合はWriterに
failback
• Readerの追加・削除
は⾃動で⾏われる
Availability Zone A Availability Zone B
VPC subnet VPC subnet
VPC subnet VPC subnet
Aurora Reader Aurora Reader
リーダエンドポイント
Read
Aurora Writer
29. IAM Authentication Integration
• Amazon Auroraへログインするための認証にIAMが利⽤可
能
• IAMのリソース制限を利⽤可能
• パスワードとしてSignature Version 4 を利⽤ (15分間有効の⼀時token)
• SSL接続が必須
• データベースアクセスに必要な認証情報をEC2インスタンスなどに配置しなく
ても良い
• AWS SDKやAWS CLI Tools対応
31. 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 ;
32. 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>
33. Export Data into S3
• S3バケットにデータを直接Auroraエクスポート可能
– LOAD DATA FROM S3で利⽤できるManifestファイルを⽣成可能
– 1ファイルは最⼤6GBずつ分割される
• 25GBを超えるようなデータをexportする場合は、複数のSQLに分割して
exportする領域をずらして実⾏する事を推薦
SELECT * FROM employees INTO OUTFILE S3 's3://bucket_name/prefixʼ
FIELDS TERMINATED BY ',ʼ
LINES TERMINATED BY 'nʼ
MANIFEST ON
OVERWRITE ON;
35. Advanced Auditing
MariaDB server_audit plugin Aurora native audit support
• 500K/sでイベントの
書き出しが可能
イベント情報の
書き出し
DDL
DML
Query
DCL
Connect
DDL
DML
Query
DCL
Connect
ログ
書き
出し
イベント情報の書
き出し
イベント情報の書
き出し
イベント情報の書
き出し
イベント情報の書
き出し
イベント情報の書
き出し
Latch-
free
queue
ログ書き出
し
ログ書き出
し
ログ書き出
し
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance
36. Zero Downtime Patch (ZDP)
• コネクションを切断すること無くオンラインでパッチを
適⽤
– 5秒程度スループットの低下が起こるが、アプリケーションとの接続を維持
したままパッチを適⽤可能
– ベストエフォート
• 既に開かれているSSLコネクション、アクティブなロック、トランザクション
の完了やテンポラリテーブルの削除を待機し、パッチ適⽤可能なウインドウが
出来た場合、ゼロダウンタイムパッチとして適⽤
• ゼロダウンタイムパッチで適⽤出来るウインドウがなかった場合、通常のパッ
チ適⽤プロセスを実⾏
– 以下の条件では通常通りのパッチ適⽤プロセスを実施
• バイナリログを有効にしている
• SSLを利⽤した接続を⾏っており、ZDPのリトライ回数内に接続が終了しない
37. Zero downtime patch (ZDP)
Networking
state
Application
state
Storage Service
App
state
Net
state
App
state
Net
state
BeforeZDP
New
DB
Engine
Old DB
Engine
New
DB
Engine
Old DB
Engine
WithZDP
セッションはパッチ
適⽤時に切断される
パッチ適⽤中でも
セッションは維持される
Storage Service
38. Database Cloning
• ストレージコストを増やすことなく
データベースのコピーを作成
• データをコピーするわけではないため、
クローンの作成はほぼ即座に完了
• データのコピーはオリジナルボリュームと
コピー先のボリュームのデータが異なる
場合の書き込み時のみ発⽣
ユースケース
• プロダクションデータを使⽤したテスト
• データベースの再構成
• プロダクションシステムに影響を及ばさずに
分析⽬的で特定の時点での
スナップショットを保存
本番データベース
Clone Clone
Clone
開発/テスト
アプリケーション
ベンチマーク
本番
データベース
本番
データベース
39. Lab Mode
• 今後提供予定の機能を試すことが可能
– DBパラメータグループ aurora_lab_mode 変数で設定可能
– 開発中の機能なので本番適⽤ではなく検証⽬的でお使い下さい
• GAクオリティですが、全てのワークロードで性能が発揮出来るか検証
を⾏っている段階です
– フィードバックをお待ちしています!
• 現在ご提供中
– Lock compression
• ロックマネージャーが利⽤するメモリを最⼤66%削減
• OOMを起こさず、更に多くの⾏ロックを同時に取得することが可能に
– Fast DDL
• nullableカラムをテーブルの最後に追加する場合にデータ件数によらず
⾼速に変更が⾏なえます
40. Fast DDL: Aurora vs. MySQL
§ フルテーブルコピー: 全てのインデックスを
再構築 - 数時間から数⽇かかることも
§ DMLクエリ実⾏のために⼀時領域が必要
§ DDLクエリがDMLクエリスループットに影響
§ DMLクエリ実⾏中にテーブル・ロックが発⽣
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
§ メタデータテーブルにエントリーを追加し、
スキーマバージョニングを利⽤
§ 変更を適⽤するために最新のスキーマへブロックを
アップグレードする際はmodify-on-write
§ 現在はテーブルの最後にNullableなカラムを
追加する場合に対応
MySQL Amazon Aurora
41. Fast DDLのパフォーマンス
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
45. 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をサポート
46. P o s t g r e S Q L F o r A u r o r a
Aurora is now fully compatible with
both PostgreSQL and MySQL
47. 1/10th The Cost Of
Commercial Grade
Databases
Fully PostgreSQL
Compatible
Several times better
performance than typical
PostgreSQL database
Scalable,
Durable and Secure
Migrate From
RDS For PostgreSQL
Amazon Aurora PostgreSQL-Compatible Edition
52. 参考資料
• Amazon Aurora SIGMOD論⽂
– http://www.allthingsdistributed.com/files/p1041-verbitski.pdf
• Amazon Auroraストレージエンジン
– https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/
• Amazon Auroraストレージのquorumに関する実装について
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-reads-and-
mutating-state/
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and-
correlated-failure/
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-reducing-costs-
using-quorum-sets/
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-
membership/
• AWS Database Blog (Amazon Aurora)
– https://aws.amazon.com/blogs/database/category/aurora/
53. Webinar資料の配置場所
• AWS クラウドサービス活⽤資料集
– 過去の資料が分かりやすくまとめられています
– http://aws.amazon.com/jp/aws-jp-introduction/
• AWS Solutions Architect ブログ
– 最新の情報、セミナー中のQ&A等が掲載されています
– http://aws.typepad.com/sajp/
58. AWS Black Belt Online Seminar
• 9⽉の配信予定
– 9⽉19⽇(⽕) 18:00〜19:00 AWS DMS
• 開催⽇時が通常と異なりますのでご注意ください
– 9⽉27⽇(⽔) 18:00〜19:00 Amazon
CloudFront + AWS Lambda@Edge
• 申し込みサイト
– https://aws.amazon.com/jp/about-
aws/events/webinars/
– (もしくは「AWS セミナー」で検索)