jaws-ug kansai-special_aurora_20150207

Post on 18-Jul-2015

1.245 views 0 download

Transcript of jaws-ug kansai-special_aurora_20150207

Amazon RDS for Aurora2015.02.07

#jawsug で色々tweetしてもらえると 喜びます

金春利幸(Toshiyuki Konparu)

R3 institute Ltd.Manager, Solution Architect

JAWS-UG Osaka Core Member

Work

Community

Official kintone Evangelist

SocialFacebook: t.konparuTwitter: t_konparu

JOIN US!

R3 instituteのご紹介

2000年創業のシステムによる問題解決会社

2012年からAWSのパートナー

2014年からサイボウズ(kintone)のパートナー

業務設計 仕様検討 設計 開発 教育 運用

すべてをワンストップで提供

http://www.r3it.com/

アールスリー 検索

Amazon RDS for Aurora は現在プレビュー中です

Amazon RDS for Aurora プレビュー来た人?

私は間に合いませんでした

今回の内容はAuroraのドキュメントをベースにしていますが私の個人的推測が含まれています

Auroraをざっと説明すると

• MySQL5.6互換で • MySQL5.6よりも最大5倍高速で • 可用性が高く • ストレージ容量が自動的に拡張する • Amazon RDSの5番目のDBエンジン

Auroraの設計思想

• サービス指向で分散型のアーキテクチャ • AWSの既存サービスを活用する • 従来のDBでは密結合されていた構成要素(SQL、Transaction、Logging、Storage)を分離し、マルチテナント化し疎結合にする

従来のDBでのアプローチ

SQL

Transaction

Caching

Logging

Storage

モノリシックなアーキテクチャ

従来のDBでのアプローチ

SQL

Transaction

Caching

Logging

Storage

レプリケーション (同期型と非同期型がある)

SQL

Transaction

Caching

Logging

Storage

モノリシックなアーキテクチャ

従来のDBでのアプローチ2

SQL

Transaction

Caching

Logging

Storage

従来のDBでのアプローチ2

SQL

Transaction

Caching

Logging

Storage

SQL

Transaction

Caching

Logging

Storage

シャーディング(Shared Nothing) (データの種類や特定のキーによって読み書き先を切り替える)

従来のDBでのアプローチ

SQL

Transaction

Caching

Logging

Storage

従来のDBでのアプローチ

SQL

Transaction

Caching

Logging

共有ストレージ型分散

SQL

Transaction

Caching

Logging

Storage

Auroraの設計思想

SQL

Transaction

Caching

Logging

Storage

Auroraの設計思想

SQL

Transaction

Caching

Logging

Storage

Amazon S3

DynamoDB

Route53

SimpleWorkFlow

処理をする機能

データを保存する機能

Auroraをざっと説明すると

• MySQL5.6互換で • MySQL5.6よりも最大5倍高速で • 可用性が高く • ストレージ容量が自動的に拡張する • Amazon RDSの5番目のDBエンジン

MySQL5.6互換

EC2 Instance

RDS for MySQL

MySQL5.6互換

EC2 Instance

RDS for Aurora

アプリケーションの修正なく移行できる

MySQL5.6より最大5倍高速

• 600万 insert /分 • 3000万 select / 分 • RDS for MySQLの最高性能よりも最大5倍高速 • EC2の最高インスタンスで稼働させるMySQLよりも最大5倍高速

なぜ速いと言えるのか???

なぜ速いと言えるのか???

DBの性能で一番のボトルネックはI/O

なぜ速いと言えるのか???

DBの性能で一番のボトルネックはI/O

I/Oを分散できれば速くできる

なぜ速いと言えるのか???

DBの性能で一番のボトルネックはI/O

I/Oを分散できれば速くできる

I/Oを非同期にできればさらにいい

なぜ速いと言えるのか???

DBの性能で一番のボトルネックはI/O

I/Oを分散できれば速くできる

非同期分散I/Oでは、データの一貫性・安全性が問題になる

I/Oを非同期にできればさらにいい

なぜ速いと言えるのか???

DBの性能で一番のボトルネックはI/O

I/Oを分散できれば速くできる

非同期分散I/Oでは、データの一貫性・安全性が問題になる

分散I/Oの鍵はQuorum

I/Oを非同期にできればさらにいい

AuroraでのQuorum(書込)

Auroraエンジン

Storage Storage Storage Storage Storage Storage

AvailavilityZone A AvailavilityZone B AvailavilityZone C

AuroraでのQuorum(書込)

Auroraエンジン

Storage Storage Storage Storage Storage Storage

AvailavilityZone A AvailavilityZone B AvailavilityZone C

書き込みは6台のうち4台のディスクに書き込めば完了

AuroraでのQuorum(書込)

Auroraエンジン

Storage Storage Storage Storage Storage Storage

AvailavilityZone A AvailavilityZone B AvailavilityZone C

書き込みは6台のうち4台のディスクに書き込めば完了

AuroraでのQuorum(読込)

Auroraエンジン

Storage Storage Storage Storage Storage Storage

AvailavilityZone A AvailavilityZone B AvailavilityZone C

AuroraでのQuorum(読込)

Auroraエンジン

Storage Storage Storage Storage Storage Storage

AvailavilityZone A AvailavilityZone B AvailavilityZone C

読み込みは6台のうち3台のディスクから読み込めれば完了

AuroraでのQuorum(読込)

Auroraエンジン

Storage Storage Storage Storage Storage Storage

AvailavilityZone A AvailavilityZone B AvailavilityZone C

読み込みは6台のうち3台のディスクから読み込めれば完了

AuroraでのQuorum(書込と読込の関係)

Storage Storage Storage Storage Storage Storage

4台で書き込めていれば

AuroraでのQuorum(書込と読込の関係)

Storage Storage Storage Storage Storage Storage

4台で書き込めていれば

3台から同じデータが来れば正しいと言える

AuroraでのQuorum(書込と読込の関係)

Storage Storage Storage Storage Storage Storage

4台で書き込めていれば

3台から同じデータが来れば正しいと言える

AuroraでのQuorum

分散ストレージを利用し、Quorum原理を適用することでI/Oを6台のストレージに分散しつつDBの一貫性、データの安全性を確保している

しかし、常にAZをまたいだ読み書きとなるのになぜ速いのか?????

キャッシュが肝ではないか?(推測)

AuroraでのRead Replica

Storage

Master Read Replica

ストレージを共有しているのでレプリカラグはほとんどない フェイルオーバー時にデータのロスがない

15台まで作成可能

Storageの自動拡張

• Storageはマルチテナント化されている • 特定のDBに対して特定の容量が確保されているわけではない • Storageの容量はリージョンごとにAWS全体としてサイジングされ十分な空きが用意されている(推測)

• 10GBから開始し、10GB単位で最大64TBまで自動的に拡張していく

• ストレージが分散していること動的リサイズが可能になっている

その他の特徴

• データキャッシュはプロセスが分離されておりDB再起動時にもデータキャッシュが存在する形でスタートできる

• キャッシュもSSDに書き込まれておりこれが速さの肝かも(推測)

• S3へ自動的にバックアップが取られる • 1秒単位でのデータ復元 • 従来のRDS for MySQLの約1.2倍の価格

個人的な注意点

• 5倍の性能は鵜呑みにせず、性能特性をちゃんとみたほうがよさそう

• MySQLとの互換性についても単純なSQL以外を使っているアプリでは検証したほうがよさそう

• ただ、素晴らしいプロダクトと言えそう!

Save The Date!

3月22日 新宿でJAWS-UGの全国イベントがあります。私、実行委員長なので来てください。お願いします。

JAWS DAYS 2015 Road Trip

3月21日(土)大阪から東京まで無料のバスが出ます(行きだけ。帰りは自費で)

大阪 名古屋 東京

Thank you