Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 @awscloud_jp
はじめてのAmazon Aurora
db tech showcase Sapporo 2015
アマゾン データ サービス ジャパン株式会社
事業開発部マネージャー
大久保 順
2 @awscloud_jp
今回お話する内容は2015/9/9現在の情報です
3 @awscloud_jp
Amazon Aurora
4 @awscloud_jp
データベース管理を簡単に
• データベースを数分で作成可能
• 自動でパッチの適用
• 数クリックするだけでスケールアウト可能
• S3への継続的なバックアップ
• 障害の自動検知と自動フェールオーバ
Amazon...
5 @awscloud_jp
6 @awscloud_jp
2015/7/28 GAリリース!
Virginia / Oregon / Irelandリージョン
7 @awscloud_jp
Amazon Aurora
• re:Invent 2014で発表されたRDSの新しいエンジン
• Amazonがクラウド時代にリレーショナル・データベース
を作るとどうなるかを1から考え構築
– 新しい技術的チャ...
8 @awscloud_jp
Amazon Aurora
• Amazon AuroraはRDSが提供するエンジンのうち
の1つ
– RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Server
が選択...
9 @awscloud_jp
• ライセンス料金は不
要
• ロックインもない
• 使った分だけ課金
vCPU Mem Hourly
Price
db.r3.large 2 15.25 $0.29
db.r3.xlarge 4 30.5 $0....
10 @awscloud_jp
Amazon Auroraの特徴
クエリ性能の向上
コストパフォーマンスが良い 高可用性・高耐久性セキュリティにも配慮
MySQL5.6互換スケーラブル
11 @awscloud_jp
Amazon Auroraの特徴
• MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行
可能
• ストレージが10GBから64TBまでシームレスに拡張
• 3AZに2つずつ、計6つのデータのコ...
12 @awscloud_jp
なぜAmazonがデータベースを再考したか
13 @awscloud_jp
現在のモノリシックなDB
複数の機能レイヤーが1
つのアプリケーションに
なっている
SQL
Transactions
Caching
Logging
14 @awscloud_jp
現在のモノリシックなデータベース
スケールアウトする
場合は、このセット
を増やしていく必要
がある
SQL
Transactions
Caching
Logging
SQL
Transactions
Cachi...
15 @awscloud_jp
コスト・可用性・柔軟性の面で問題
16 @awscloud_jp
リレーショナルデータベースをもう一度考える
• 今、データベースを再度実装するならどうするか?
– 少なくとも1970年代の方法で実装はしない
– AWSサービスを活かすことができ、スケールアウトが簡単で、セルフ...
17 @awscloud_jp
クラウド時代に適したリレーショナルデータベース
• 商用データベースの様なスピードと可用性
• オープンソースデータベースのシンプルさとコスト効果の高さ
• MySQLと互換性を保つ
• 利用した分だけお支払いい...
18 @awscloud_jp
Establishing our ecosystem
“Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB
connectorsはAuroraとシームレスに動作します。 Ma...
19 @awscloud_jp
アーキテクチャ
20 @awscloud_jp
Service Oriented Architecture
• ログとストレージレイヤを
シームレスにスケールする
ストレージサービスに移動
• EC2, Amazon DynamoDB,
Amazon SWFな...
21 @awscloud_jp
キャッシュレイヤの分離
• キャッシュをデータベースプロセス外
に移動させた
• データベースプロセスのリスタートが
発生してもキャッシュが残った状態を
維持可能
SQL
Transactions
Caching...
22 @awscloud_jp
Auroraのストレージ
• SSDを利用したシームレスにスケールす
るストレージ
– 10GBから64TBまでシームレスに自動でスケール
アップ
– 実際に使った分だけ課金
• 標準で高可用性を実現
– 3AZ...
23 @awscloud_jp
Auroraのストレージ
• Amazon Auroraは6本全てのディスクへの書き込みを
待たずに、少なくとも4つのディスクに書き込みが完了す
るとすぐに次の処理を実行
• ホットスポットの影響を取り除き、非常...
24 @awscloud_jp
Auroraのストレージの特徴
• リードレプリカもマスタと同じストレージを参照
• Log Structured Storage
• 継続的なS3へ増分バックアップ
– パフォーマンスへの影響なし
• 64TB...
25 @awscloud_jp
ディスク障害検知と修復
• 2つのコピーに障害が起こっても、読み書きに影響は無い
• 3つのコピーに障害が発生しても読み込みは可能
• 自動検知、修復
SQL
Transaction
AZ 1 AZ 2 AZ 3...
26 @awscloud_jp
レプリケーション
AZ 1 AZ 2
Primary
Instance
Standby
Instance
EBS
Amazon S3
EBS
mirror
EBS
EBS
mirror
MySQL レプリケーショ...
27 @awscloud_jp
レプリケーション
ページキャッシュ
更新
Aurora Master
30% Read
70% Write
Aurora Replica
100% New
Reads
Shared Multi-AZ Storag...
28 @awscloud_jp
レプリケーション
• Amazon Auroraは、15台のリードレプリカを作成可
能
– リードレプリカはマスタサーバとストレージを共有しており、低負荷で
粒度の高いほぼ同期型のレプリケーションを行う
– 10...
29 @awscloud_jp
セキュリティ
• データの暗号化
– AES-256 (ハードウエア支援)
– ディスクとAmazon S3に置かれている全ブロックを暗号化
– AWS KMSを利用したキー管理 (現在未サポート)
• SSLを...
30 @awscloud_jp
フェイルオーバーとリカバリ
31 @awscloud_jp
フェイルオーバーとリプレース
• リードレプリカが存在する場合は1分程でフェイルオー
バー可能
– RDS for MySQLよりも高速にフェイルオーバー可能
– リードレプリカが存在しない場合は10分程
• 優...
32 @awscloud_jp
クラスタエンドポイント
• WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエン
ドポイントが存在する
• 各Auroraノードは個別にエンドポイントを持って...
33 @awscloud_jp
クラスタエンドポイント
Availability Zone A Availability Zone B
VPC subnet VPC subnet
VPC subnet VPC subnet
Aurora Wri...
34 @awscloud_jp
クラスタエンドポイント
• フェイルオーバーが
発生すると、Aurora
ノードの昇格が行わ
れ、クラスタエンド
ポイントの指し先が
変わる
Availability Zone A Availability Zo...
35 @awscloud_jp
Writer / Readerノードの識別
• innodb_read_onlyを参照
– SHOW GLOBAL VARIABLES LIKE 'innodb_read_only’;
– OFF: Writer...
36 @awscloud_jp
高速なデータ修復
既存のデータベース
• 最後のチェックポイントからログを
適用していく
• MySQLではシングルスレッドなた
め適用完了までの時間が増加
Amazon Aurora
• Disk readの一...
37 @awscloud_jp
継続バックアップとポイント・イン・タイムリカバリー(PITR)
• Amazon Auroraでは各セグメント毎にAmazon S3へ継
続的に増分バックアップを取得している
– Backup retention...
38 @awscloud_jp
SQLによるフェイルオーバーのテスト
SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能
• データベースノードのクラッシュをシミュレート:
ALTER SYSTEM CRASH [{INSTA...
39 @awscloud_jp
パフォーマンス
40 @awscloud_jp
Auroraのパフォーマンスを引き出すために
• クエリ並列度が高い、データサイズが大きいケース
で効果を発揮
• ロック機構やQuery Cache・スレッドプールなどに手
を入れて性能向上を行っている
– w...
41 @awscloud_jp
パフォーマンス
• 性能が5倍というのはどのようなケースか
– re:Invent で発表された5倍という性能はSysbenchを4インスタンス
(r3.8xlarge + NW関連のkernelパラメータ調整済...
42 @awscloud_jp
パフォーマンス
• FAQとパフォーマンステストのガイドライン、テスト用
AMIを提供しています
– http://aws.amazon.com/rds/aurora/faqs/ の
Amazon Aurora ...
43 @awscloud_jp
パフォーマンス
• 価格性能比5倍
– Amazon Auroraは高速でSSDベースのストレージにより高速に動作
するが、既存のどんなクエリでも5倍高速に実行出来ることを意味し
ているわけではない
– Amaz...
44 @awscloud_jp
参考 (re:Inventで発表された資料)
45 @awscloud_jp
よく見ると
• Auroraではデッドロックがほんの少し出やすいがリ
トライを行ってもMySQLよりスループットが出る
• CPU / Memoryの利用率がMySQLより高いがス
ループットが出ている
– 分散...
46 @awscloud_jp
何をみるのか?
• よく聞かれる質問
– CPU利用率高いんだけど?
– メモリ利用量多いんだけど?
– Disk IOが多めなんだけど?
• 見てほしいこと
– Auroraはマシンリソースを最大限利用してスル...
47 @awscloud_jp
何をみるのか?
• AuroraはMySQL互換ですが、マシンリソースの使
い方が根本的に違います
• Auroraが得意な場面・状況を理解してパフォーマン
スを測定
– マシンリソースを使い切りそうになりながら...
48 @awscloud_jp
Amazon Auroraへの移行
49 @awscloud_jp
RDS for MySQLからマイグレーション
• マネージメントコンソールから数クリックでAmazon Auroraへ
移行可能
– RDS for MySQLのスナップショットからAmazon Auroraへ...
50 @awscloud_jp
マイグレーション時の注意
• RDS for MySQLとParameter Groupで設定出来る
項目や規定値などが異なる
– 例: max_connection / innodb_buffer_pool_s...
51 @awscloud_jp
マイグレーション時の注意
• Amazon AuroraはInnoDBのみサポート
– MyISAMなどのストレージエンジンは非対応
• マイグレーション時に自動でMyISAMからコンバート
されますが、事前に手...
52 @awscloud_jp
マイグレーション時の注意
• MyISAM形式のテーブルが含まれない場合
– 移行前のディスクで6TBまで容量を利用可能
• MyISAM形式のテーブルが含まれる場合
– マイグレーションを行うテーブルで3TBを...
53 @awscloud_jp
MySQLからレプリケーション
• MySQL5.6からAmazon Auroraへレプリケーションを行うことが可
能
• 専用のプロシージャを使用
mysql > CALL mysql.rds_set_exte...
54 @awscloud_jp
MySQLからレプリケーション
• RDS for MySQLやMySQL on EC2、オンプレ環境
のMySQLからAmazon Auroraにレプリケーション
可能
– バックアップからAuroraにインポ...
55 @awscloud_jp
Amazon Auroraの使いどころ
56 @awscloud_jp
クエリ同時実行数やテーブルサイズが大きい
• Amazon Auroraに移行することで、クエリスルー
プットの向上などが見込まれる
– マルチコア環境でCPUを効率的に利用
– 分散ロック機構やquery ca...
57 @awscloud_jp
複数のサーバにシャーディングしている
• 複数の小さいDBを1つにまとめる
– コスト効果増大と管理コストの軽減
– シャーディングをするデータベースを減らすことでアプリケーションの
設計を簡略化出来る
– 障害...
58 @awscloud_jp
まとめ
59 @awscloud_jp
Amazon Aurora
• クラウド時代にAmazonが再設計したRDBMS
– MySQL5.6と互換があり既存の資産を活かしやすい
• 高いクエリ実行並列度・データサイズが大きい環境で性能を
発揮
– A...
60 @awscloud_jp
Q&A
AWS Cloud Roadshow 2015 札幌のご案内
日時・会場: 2015年11月12日 10:00スタート(ニューオータニイン札幌)
主催:アマゾンデータサービスジャパン株式会社/インテル株式会社
申込:事前登録制・無料(現在...
62 @awscloud_jp
公式Twitter/Facebook
AWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを
日々更新しています!
もしくは
htt...
63 @awscloud_jp
ご参加ありがとうございました。
Upcoming SlideShare
Loading in …5
×

はじめてのAmazon Aurora

3,276 views

Published on

2015/09/10
db tech showcase Sapporo 2015のセッション資料です。

Published in: Travel
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

はじめてのAmazon Aurora

  1. 1. 1 @awscloud_jp はじめてのAmazon Aurora db tech showcase Sapporo 2015 アマゾン データ サービス ジャパン株式会社 事業開発部マネージャー 大久保 順
  2. 2. 2 @awscloud_jp 今回お話する内容は2015/9/9現在の情報です
  3. 3. 3 @awscloud_jp Amazon Aurora
  4. 4. 4 @awscloud_jp データベース管理を簡単に • データベースを数分で作成可能 • 自動でパッチの適用 • 数クリックするだけでスケールアウト可能 • S3への継続的なバックアップ • 障害の自動検知と自動フェールオーバ Amazon RDS
  5. 5. 5 @awscloud_jp
  6. 6. 6 @awscloud_jp 2015/7/28 GAリリース! Virginia / Oregon / Irelandリージョン
  7. 7. 7 @awscloud_jp Amazon Aurora • re:Invent 2014で発表されたRDSの新しいエンジン • Amazonがクラウド時代にリレーショナル・データベース を作るとどうなるかを1から考え構築 – 新しい技術的チャレンジを盛り込んでいる • エンタープライズグレードの可用性とOSSレベルのコス トを両立
  8. 8. 8 @awscloud_jp Amazon Aurora • Amazon AuroraはRDSが提供するエンジンのうち の1つ – RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Server が選択可能
  9. 9. 9 @awscloud_jp • ライセンス料金は不 要 • ロックインもない • 使った分だけ課金 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
  10. 10. 10 @awscloud_jp Amazon Auroraの特徴 クエリ性能の向上 コストパフォーマンスが良い 高可用性・高耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
  11. 11. 11 @awscloud_jp Amazon Auroraの特徴 • MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行 可能 • ストレージが10GBから64TBまでシームレスに拡張 • 3AZに2つずつ、計6つのデータのコピーを保持 – S3にストリーミングバックアップを実施 • VPC内に起動 – Security GroupやNACLを使用してアクセスコントロール可能 • Amazon Auroraは99.99%の可用性を実現するように設計されている
  12. 12. 12 @awscloud_jp なぜAmazonがデータベースを再考したか
  13. 13. 13 @awscloud_jp 現在のモノリシックなDB 複数の機能レイヤーが1 つのアプリケーションに なっている SQL Transactions Caching Logging
  14. 14. 14 @awscloud_jp 現在のモノリシックなデータベース スケールアウトする 場合は、このセット を増やしていく必要 がある SQL Transactions Caching Logging SQL Transactions Caching Logging Application
  15. 15. 15 @awscloud_jp コスト・可用性・柔軟性の面で問題
  16. 16. 16 @awscloud_jp リレーショナルデータベースをもう一度考える • 今、データベースを再度実装するならどうするか? – 少なくとも1970年代の方法で実装はしない – AWSサービスを活かすことができ、スケールアウトが簡単で、セルフ ヒーリングが出来るようなデータベースを作りたいと考えた
  17. 17. 17 @awscloud_jp クラウド時代に適したリレーショナルデータベース • 商用データベースの様なスピードと可用性 • オープンソースデータベースのシンプルさとコスト効果の高さ • MySQLと互換性を保つ • 利用した分だけお支払いいただく課金モデル • AWSサービスと簡単に連携 マネージド・サービスとして提供
  18. 18. 18 @awscloud_jp Establishing our ecosystem “Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性の 心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを加 速させるために一緒に働くことを楽しみにしています。” — Roger Levy, VP Products, MariaDB
  19. 19. 19 @awscloud_jp アーキテクチャ
  20. 20. 20 @awscloud_jp 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
  21. 21. 21 @awscloud_jp キャッシュレイヤの分離 • キャッシュをデータベースプロセス外 に移動させた • データベースプロセスのリスタートが 発生してもキャッシュが残った状態を 維持可能 SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching キャッシュプロセスをDBプロセス外におくことで DBプロセスの再起動でもキャッシュが残る
  22. 22. 22 @awscloud_jp Auroraのストレージ • SSDを利用したシームレスにスケールす るストレージ – 10GBから64TBまでシームレスに自動でスケール アップ – 実際に使った分だけ課金 • 標準で高可用性を実現 – 3AZに6つのデータのコピーを作成 – 2つのディスクが利用不能でも読み書き可能 • 万が一1つのAZが利用不能になっても読み書き可 能な状態で稼働し続ける – 3つのディスクが利用不能の場合読み込みのみ可能 • Log structured Storage – redo logを複数の小さなセグメントに分割 – Log pageによってData pageを作成 SQL Transactions AZ 1 AZ 2 AZ 3 Caching Amazon S3
  23. 23. 23 @awscloud_jp Auroraのストレージ • Amazon Auroraは6本全てのディスクへの書き込みを 待たずに、少なくとも4つのディスクに書き込みが完了す るとすぐに次の処理を実行 • ホットスポットの影響を取り除き、非常に高い並列度を 実現 • ストレージはSSDベースのディスクに10GBずつのブ ロック内に分散して書き込まれる
  24. 24. 24 @awscloud_jp Auroraのストレージの特徴 • リードレプリカもマスタと同じストレージを参照 • Log Structured Storage • 継続的なS3へ増分バックアップ – パフォーマンスへの影響なし • 64TBまで自動でストレージがシームレスにスケールアップ – パフォーマンスや可用性に影響無し・利用開始時のプロビジョニング不要 • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化
  25. 25. 25 @awscloud_jp ディスク障害検知と修復 • 2つのコピーに障害が起こっても、読み書きに影響は無い • 3つのコピーに障害が発生しても読み込みは可能 • 自動検知、修復 SQL Transaction AZ 1 AZ 2 AZ 3 Caching SQL Transactio n AZ 1 AZ 2 AZ 3 Caching 読み書き可能読み込み可能
  26. 26. 26 @awscloud_jp レプリケーション 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 書き込みの種類
  27. 27. 27 @awscloud_jp レプリケーション ページキャッシュ 更新 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が必要 • レプリケーションはマスターへ負荷がかかる • レプリケーション遅延が増加していくケースがある • フェイルオーバーでデータロスの可能性がある
  28. 28. 28 @awscloud_jp レプリケーション • Amazon Auroraは、15台のリードレプリカを作成可 能 – リードレプリカはマスタサーバとストレージを共有しており、低負荷で 粒度の高いほぼ同期型のレプリケーションを行う – 10-20msのレイテンシーでレプリケーションされる – RDS for MySQLではリードレプリカは5つまで (孫リードレプリカを入 れて30)
  29. 29. 29 @awscloud_jp セキュリティ • データの暗号化 – AES-256 (ハードウエア支援) – ディスクとAmazon S3に置かれている全ブロックを暗号化 – AWS KMSを利用したキー管理 (現在未サポート) • SSLを利用したデータ通信の保護 • 標準でAmazon VPCを使ったネットワークの分離 • ノードへ直接アクセスは不可能 • 業界標準のセキュリティとデータ保護の認証をサ ポート Storage SQL Transactions Caching Amazon S3 Application
  30. 30. 30 @awscloud_jp フェイルオーバーとリカバリ
  31. 31. 31 @awscloud_jp フェイルオーバーとリプレース • リードレプリカが存在する場合は1分程でフェイルオー バー可能 – RDS for MySQLよりも高速にフェイルオーバー可能 – リードレプリカが存在しない場合は10分程 • 優先的にフェイルオーバーさせるノードを1つ指定可能 – Multi-AZ配置として別AZで起動する – RDS for MySQLと違いリードアクセス可能
  32. 32. 32 @awscloud_jp クラスタエンドポイント • WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエン ドポイントが存在する • 各Auroraノードは個別にエンドポイントを持っている Reader Writer
  33. 33. 33 @awscloud_jp クラスタエンドポイント Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンド ポイント • 各Auroraノードは個 別にエンドポイントを 持っている • クラスタエンドポイン トは、その時アクティ ブなAurora Writer ノードのCNAME • Readは各Readerを参 照する Write
  34. 34. 34 @awscloud_jp クラスタエンドポイント • フェイルオーバーが 発生すると、Aurora ノードの昇格が行わ れ、クラスタエンド ポイントの指し先が 変わる Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンド ポイント Write
  35. 35. 35 @awscloud_jp Writer / Readerノードの識別 • innodb_read_onlyを参照 – SHOW GLOBAL VARIABLES LIKE 'innodb_read_only’; – OFF: Writer – ON: Reader • アプリケーションやドライバでAuroraノードに対する 負荷分散やフェイルオーバーロジックの実装に利用 可能 – メトリクススキーマのSEESION_IDも利用可能
  36. 36. 36 @awscloud_jp 高速なデータ修復 既存のデータベース • 最後のチェックポイントからログを 適用していく • MySQLではシングルスレッドなた め適用完了までの時間が増加 Amazon Aurora • Disk readの一環として、オンデマ ンドでredo logの適用を行う • 並列、分散、非同期で行われる Checkpointed Data Redo Log T0 でクラッシュが発生すると 最後のチェックポイントからの ログを適用する必要がある T0 T0 T0 でクラッシュが発生するとredo を並列で分散して非同期でログの適用を行う
  37. 37. 37 @awscloud_jp 継続バックアップとポイント・イン・タイムリカバリー(PITR) • Amazon Auroraでは各セグメント毎にAmazon S3へ継 続的に増分バックアップを取得している – Backup retention periodでバックアップを残す期間を指定可能 • Amazon Auroraが使用しているディスクの仕組みによ りパフォーマンスへ影響を与えない • PITRで5分前からBackup Retention Periodまでの任 意の位置に秒単位で復元可能
  38. 38. 38 @awscloud_jp 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 ]; • 他にも – ディスク障害をシミュレート – ディスクコンジェスションをシミュレート
  39. 39. 39 @awscloud_jp パフォーマンス
  40. 40. 40 @awscloud_jp Auroraのパフォーマンスを引き出すために • クエリ並列度が高い、データサイズが大きいケース で効果を発揮 • ロック機構やQuery Cache・スレッドプールなどに手 を入れて性能向上を行っている – write heavyな環境ではoffをおすすめ – CPUを効率的に利用する改善により、CPU利用率がMySQLと比較 して高くなるが、性能が落ちにくくなっている
  41. 41. 41 @awscloud_jp パフォーマンス • 性能が5倍というのはどのようなケースか – re:Invent で発表された5倍という性能はSysbenchを4インスタンス (r3.8xlarge + NW関連のkernelパラメータ調整済)からr3.8xlargeの Auroraインスタンスに実行した場合の結果 • TPC-C をr3.8xlargeで実行した場合は約2.5〜5倍 の性能を観測している
  42. 42. 42 @awscloud_jp パフォーマンス • FAQとパフォーマンステストのガイドライン、テスト用 AMIを提供しています – http://aws.amazon.com/rds/aurora/faqs/ の Amazon Aurora Performance Benchmarking Guide
  43. 43. 43 @awscloud_jp パフォーマンス • 価格性能比5倍 – Amazon Auroraは高速でSSDベースのストレージにより高速に動作 するが、既存のどんなクエリでも5倍高速に実行出来ることを意味し ているわけではない – Amazon Auroraは他の製品よりも、より多くの書き込み・読み込みク エリを同時に扱うことが出来るためデータベースの集約やスループッ ト向上が見込める – Amazon Aurora独自で高並列なストレージへのアクセスにより保存 されているデータへのコンテンションを解決し、クエリを効率よく処理
  44. 44. 44 @awscloud_jp 参考 (re:Inventで発表された資料)
  45. 45. 45 @awscloud_jp よく見ると • Auroraではデッドロックがほんの少し出やすいがリ トライを行ってもMySQLよりスループットが出る • CPU / Memoryの利用率がMySQLより高いがス ループットが出ている – 分散ロック機構によりCPUリソースを使いきってスループットを出して いる
  46. 46. 46 @awscloud_jp 何をみるのか? • よく聞かれる質問 – CPU利用率高いんだけど? – メモリ利用量多いんだけど? – Disk IOが多めなんだけど? • 見てほしいこと – Auroraはマシンリソースを最大限利用してスループットを出す設 計です – システムトータルでパフォーマンスが向上 – 管理コスト、障害耐性、データ保全性
  47. 47. 47 @awscloud_jp 何をみるのか? • AuroraはMySQL互換ですが、マシンリソースの使 い方が根本的に違います • Auroraが得意な場面・状況を理解してパフォーマン スを測定 – マシンリソースを使い切りそうになりながらもMySQLと比べるとス ループットやレスポンスタイムの落ち方が緩やか
  48. 48. 48 @awscloud_jp Amazon Auroraへの移行
  49. 49. 49 @awscloud_jp RDS for MySQLからマイグレーション • マネージメントコンソールから数クリックでAmazon Auroraへ 移行可能 – RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能 – RDS for MySQLは5.6を使う必要がある
  50. 50. 50 @awscloud_jp マイグレーション時の注意 • RDS for MySQLとParameter Groupで設定出来る 項目や規定値などが異なる – 例: max_connection / innodb_buffer_pool_size / query_cache_* など • マイグレーションに必要なディスクスペース – スナップショットをインポートする場合、インポート前にEBSボリューム を使用しデータをフォーマットする – データをフォーマットするための追加容量が必要になる場合がある
  51. 51. 51 @awscloud_jp マイグレーション時の注意 • Amazon AuroraはInnoDBのみサポート – MyISAMなどのストレージエンジンは非対応 • マイグレーション時に自動でMyISAMからコンバート されますが、事前に手動でInnoDBへの変換を行っ ていただくことがオススメです
  52. 52. 52 @awscloud_jp マイグレーション時の注意 • MyISAM形式のテーブルが含まれない場合 – 移行前のディスクで6TBまで容量を利用可能 • MyISAM形式のテーブルが含まれる場合 – マイグレーションを行うテーブルで3TBを超えるものが無いことを確 認する
  53. 53. 53 @awscloud_jp MySQLからレプリケーション • MySQL5.6からAmazon Auroraへレプリケーションを行うことが可 能 • 専用のプロシージャを使用 mysql > CALL mysql.rds_set_external_master (DB Hostname or IP address', 3306,’user', ‘password', ’Binlog', position, 0); mysql > CALL mysql.rds_start_replication;
  54. 54. 54 @awscloud_jp MySQLからレプリケーション • RDS for MySQLやMySQL on EC2、オンプレ環境 のMySQLからAmazon Auroraにレプリケーション 可能 – バックアップからAuroraにインポートを行い、レプリケーションを実行 – 移行時にアプリケーションのメンテナンスを入れ、書き込みがなくなり、 レプリケーションが追いついたタイミングでアプリケーションの書き込 み先などをAuroraに変更
  55. 55. 55 @awscloud_jp Amazon Auroraの使いどころ
  56. 56. 56 @awscloud_jp クエリ同時実行数やテーブルサイズが大きい • Amazon Auroraに移行することで、クエリスルー プットの向上などが見込まれる – マルチコア環境でCPUを効率的に利用 – 分散ロック機構やquery cacheの改善による性能向上 • ディスク – データ量の増加に応じてディスク容量を気にする必要が無い – 性能に影響を及ばさずバックアップ
  57. 57. 57 @awscloud_jp 複数のサーバにシャーディングしている • 複数の小さいDBを1つにまとめる – コスト効果増大と管理コストの軽減 – シャーディングをするデータベースを減らすことでアプリケーションの 設計を簡略化出来る – 障害時の影響を考慮する必要はある
  58. 58. 58 @awscloud_jp まとめ
  59. 59. 59 @awscloud_jp Amazon Aurora • クラウド時代にAmazonが再設計したRDBMS – MySQL5.6と互換があり既存の資産を活かしやすい • 高いクエリ実行並列度・データサイズが大きい環境で性能を 発揮 – Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮 • 高可用性・高速なフェイルオーバー・PITRを実現するための 多くのチャレンジ – Log Structured Storage – SOA
  60. 60. 60 @awscloud_jp Q&A
  61. 61. AWS Cloud Roadshow 2015 札幌のご案内 日時・会場: 2015年11月12日 10:00スタート(ニューオータニイン札幌) 主催:アマゾンデータサービスジャパン株式会社/インテル株式会社 申込:事前登録制・無料(現在、Save the dateを受付中。配布チラシをご確認ください。) 概要:基調講演を含む、充実の11のセッション。セルフペースラボ設置、パートナー展示も実施予定。 対象: –今後クラウドの導入をご検討中の方 –アプリケーション開発・運用をもっと効率的に行いたい方 –既存のデータセンター環境とクラウドの併用をご検討の方 –国内の著名企業におけるクラウド活用事例について参考にしたいという方 –メディア・エンターテインメント業界におけるサービス提供手法について参考にしたいという方 –より深い技術を学び、クラウドを活用したいとお考えの方
  62. 62. 62 @awscloud_jp 公式Twitter/Facebook AWSの最新情報をお届けします @awscloud_jp 検索 最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを 日々更新しています! もしくは http://on.fb.me/1vR8yWm
  63. 63. 63 @awscloud_jp ご参加ありがとうございました。

×