Mais conteúdo relacionado Mais de Amazon Web Services Japan (20) AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora2. 自己紹介
• 星野 豊 (ほしの ゆたか)
– @con_mame
– facebook.com/conmame
– ソリューションアーキテクト
• 経歴
– 全てオンプレ環境のインフラエンジニア
– 全AWS環境のインフラエンジニア
• 担当
– Webサービス / game / Video・Live Streamingなどのメディア系のお客
様
8. Amazon Aurora
• re:Invent 2014で発表されたRDSの新しいエンジン
• Amazonがクラウド時代にリレーショナル・データベース
を作るとどうなるかを1から考え構築
– 新しい技術的チャレンジを盛り込んでいる
• エンタープライズグレードの可用性とOSSレベルのコス
トを両立
9. Amazon Aurora
• Amazon AuroraはRDSが提供するエンジンのうち
の1つ
– RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Server
が選択可能
10. • ライセンス料金は不
要
• ロックインもない
• 使った分だけ課金
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
19. Establishing our ecosystem
“Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB
connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の
MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性の
心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを加
速させるために一緒に働くことを楽しみにしています。”
— Roger Levy, VP Products, MariaDB
21. 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
26. Log Structured Storage
• 追記型のストレージ・システム
– ログの様に常に末尾にデータを追加していくだけ
– データが書き込まれているブロックを上書いたりはしない
– GCによりデータを効率的に格納する
• シーケンシャルに読み出すことが出来る
• 常に最新のデータが末尾にある
• これらの特徴によりS3への継続バックアップや高速なリカバリ、書き込み性能
の向上を実現
空きスペース
data
data
先頭
data
data
data
新規データは末尾に追記される
↓
28. レプリケーション
AZ 1 AZ 2
Primary
Instance
Standby
Instance
EBS
Amazon S3
EBS
mirror
EBS
EBS
mirror
MySQL レプリケーション
PITR
シーケンシャ
ル・ライト
シーケンシャ
ル・ライト
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
改善点
• Consistency – 異常を修復
• Latency – 同期 vs 非同期レプリケーション
• network I/Oを効率的に行う
非同期 4/6クオーラム 分散書き込み
Amazon Aurora
ログレコード
Binlog
データ
Double-write buffer
metadata
書き込みの種類
29. レプリケーション
ページキャッシュ
パージ
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が必要
• レプリケーションはマスターへ負荷がかかる
• レプリケーション遅延が増加していくケースがある
• フェイルオーバでデータロスの可能性がある
31. セキュリティ
• データの暗号化
– AES-256 (ハードウエア支援)
– ディスクとAmazon S3に置かれている全ブロックを暗号化
– AWS KMSを利用したキー管理 (現在未サポート)
• SSLを利用したデータ通信の保護
• 標準でAmazon VPCを使ったネットワークの分離
• ノードへ直接アクセスは不可能
• 業界標準のセキュリティとデータ保護の認証をサ
ポート
Storage
SQL
Transactions
Caching
Amazon S3
Application
32. DBクラスタ
• Amazon AuroraはDBクラスタという概念を持っている
– マスタ (Writer)とリードレプリカ(Reader)をひとまとめにしたもの
– Parameter GroupやMaintenance WindowもDBクラスタと各ノードそろ
ぞれに存在する
• フェイルオーバが発生しても常にマスタを参照するエン
ドポイントがクラスタ毎に1つ存在する
– アプリケーションからのWriteクエリは常にこのエンドポイントを参照する
ように設定
33. DB Parameter GroupとDB Cluster Parameter Group
• RDS for MySQLではDB Parameter Groupのみ
• Auroraでは設定の適用範囲毎にグループを設定
– DB Cluster Parameter Group: Auroraクラスタ内全ノードで共通
– DB Parameter Group: 各Auroraノード個別の設定
34. 新しいメトリクス画面
• Throughput
– Select
– Commit
– DML/DDL
• Latency
– Select
– Commit
– DML/DDL
• Cache Hit Ratio
– Buffer Cache
– Result Set
• Deadlocks
• Login Failures
• Blocked Transactions
35. メトリクススキーマ
• 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 |
+-----------------+---------------------------------------+--------------------------------------------------------+
38. フェイルオーバ と リプレース
• リードレプリカが存在する場合は1分程でフェイルオー
バ可能
– RDS for MySQLよりも高速にフェイルオーバ可能
– リードレプリカが存在しない場合は10分程
• 優先的にフェイルオーバさせるノードを1つ指定可能
– Multi-AZ配置として別AZで起動する
– RDS for MySQLと違いリードアクセス可能
40. クラスタエンドポイント
Aurora Writer Aurora Reader
クラスタエンド
ポイント
• 各Auroraノードは個
別にエンドポイントを
持っている
• クラスタエンドポイン
トは、その時アクティ
ブなAurora Writer
ノードのCNAME
• Readは各Readerを参
照する
Write
42. Writer / Readerノードの識別
• innodb_read_onlyを参照
– SHOW GLOBAL VARIABLES LIKE 'innodb_read_only’;
– OFF: Writer
– ON: Reader
• アプリケーションやドライバでAuroraノードに対する
負荷分散やフェイルオーバーロジックの実装に利用
可能
– メトリクススキーマのSEESION_IDも利用可能
44. Streaming snapshotとPITR
• Amazon Auroraでは各セグメント毎にAmazon S3へ継
続的に増分バックアップを取得している
– Backup retention periodでバックアップを残す期間を指定可能
• Amazon Auroraが使用しているディスクの仕組みによ
りパフォーマンスへ影響を与えない
• PITRで5分前からBackup Retention Periodまでの任
意の位置に秒単位で復元可能
49. defaultパラメータの違い
• RDS for MySQLと比べるとbuffer / connection /
周りの値が少なめ
• query cacheがON
– ONの状態でも性能が出るようにAuroraでは性能向上が行われてい
る
– Write heavyな環境ではOFFも検討
51. 新規パラメータ
• thread_handling
– Default: multiple-connections-per-thread
– multiple-connections-per-thread, no-threads, one-thread-per-
connection, dynamically-loaded
– 接続を扱うAuroraのスレッドに関する設定
54. パフォーマンス
• 価格性能比5倍
– Amazon Auroraは高速でSSDベースのストレージにより高速に動作
するが、既存のどんなクエリでも5倍高速に実行出来ることを意味し
ているわけではない
– Amazon Auroraは他の製品よりも、より多くの書き込み・読み込みク
エリを同時に扱うことが出来るためデータベースの集約やスループッ
ト向上が見込める
– Amazon Aurora独自で高並列なストレージへのアクセスにより保存
されているデータへのコンテンションを解決し、クエリを効率よく処理
60. RDS for MySQLからマイグレーション
• マネージメントコンソールから数クリックでAmazon Auroraへ
移行可能
– RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能
– RDS for MySQLは5.6を使う必要がある
61. マイグレーション時の注意
• RDS for MySQLとParameter Groupで設定出来る
項目や規定値などが異なる
– 例: max_connection / innodb_buffer_pool_size / query_cache_*
など
• マイグレーションに必要なディスクスペース
– スナップショットをインポートする場合、インポート前にEBSボリューム
を使用しデータをフォーマットする
– データをフォーマットするための追加容量が必要になる場合がある
65. MySQLからレプリケーション
• RDS for MySQLやMySQL on EC2、オンプレ環境
のMySQLからAmazon Auroraにレプリケーション
可能
– バックアップからAuroraにインポートを行い、レプリケーションを実行
– 移行時にアプリケーションのメンテナンスを入れ、書き込みがなくなり、
レプリケーションが追いついたタイミングでアプリケーションの書き込
み先などをAuroraに変更
70. Amazon Aurora
• クラウド時代にAmazonが再設計したRDBMS
– MySQL5.6と互換があり既存の資産を活かしやすい
• 高いクエリ実行並列度・データサイズが大きい環境で性能を
発揮
– Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮
• 高可用性・高速なフェイルオーバ・PITRを実現するための多
くのチャレンジ
– Log Structured Storage
– SOA