Download as PDF, PPTX
![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 ];
• 他にも
– ディスク障害をシミュレート
– ディスクコンジェスションをシミュレート](https://image.slidesharecdn.com/20150910dbtssapporoaurorav1-150911043238-lva1-app6892/75/Amazon-Aurora-38-2048.jpg)
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
![[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ～AlwaysOn＋Qシステムで完全無停止運用～ by Nobuyuki Sa...](https://cdn.slidesharecdn.com/ss_thumbnails/c33sqlserversasaki-131128193643-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[PGConf.ASIA 2018]Deep Dive on Amazon Aurora with PostgreSQL Compatibility](https://cdn.slidesharecdn.com/ss_thumbnails/20181212pgconfasiaaurorapostgresql-181212055637-thumbnail.jpg?width=640&height=640&fit=bounds)
![[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015a34amazon-auroraamazondataservicejapan-150623010528-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://cdn.slidesharecdn.com/ss_thumbnails/auroradeep-150322203758-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[MANABIYA] 20180323 Amazon Aurora with PostgreSQL Compatibility](https://cdn.slidesharecdn.com/ss_thumbnails/20180323manabiyaaurorapostgresql-180323071750-thumbnail.jpg?width=640&height=640&fit=bounds)
はじめてのAmazon Aurora
- 1. 1 @awscloud_jp はじめてのAmazon Aurora dbtech showcase Sapporo 2015 アマゾン データ サービス ジャパン株式会社 事業開発部マネージャー 大久保 順
- 2.
- 3.
- 4. 4 @awscloud_jp データベース管理を簡単に • データベースを数分で作成可能 •自動でパッチの適用 • 数クリックするだけでスケールアウト可能 • S3への継続的なバックアップ • 障害の自動検知と自動フェールオーバ Amazon RDS
- 5.
- 6. 6 @awscloud_jp 2015/7/28 GAリリース！ Virginia/ Oregon / Irelandリージョン
- 7. 7 @awscloud_jp Amazon Aurora •re:Invent 2014で発表されたRDSの新しいエンジン • Amazonがクラウド時代にリレーショナル・データベース を作るとどうなるかを1から考え構築 – 新しい技術的チャレンジを盛り込んでいる • エンタープライズグレードの可用性とOSSレベルのコス トを両立
- 8. 8 @awscloud_jp Amazon Aurora •Amazon AuroraはRDSが提供するエンジンのうち の1つ – RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Server が選択可能
- 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 @awscloud_jp Amazon Auroraの特徴 クエリ性能の向上 コストパフォーマンスが良い高可用性・高耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
- 11. 11 @awscloud_jp Amazon Auroraの特徴 •MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行 可能 • ストレージが10GBから64TBまでシームレスに拡張 • 3AZに2つずつ、計6つのデータのコピーを保持 – S3にストリーミングバックアップを実施 • VPC内に起動 – Security GroupやNACLを使用してアクセスコントロール可能 • Amazon Auroraは99.99%の可用性を実現するように設計されている
- 12.
- 13.
- 14.
- 15.
- 16. 16 @awscloud_jp リレーショナルデータベースをもう一度考える • 今、データベースを再度実装するならどうするか？ –少なくとも1970年代の方法で実装はしない – AWSサービスを活かすことができ、スケールアウトが簡単で、セルフ ヒーリングが出来るようなデータベースを作りたいと考えた
- 17. 17 @awscloud_jp クラウド時代に適したリレーショナルデータベース • 商用データベースの様なスピードと可用性 •オープンソースデータベースのシンプルさとコスト効果の高さ • MySQLと互換性を保つ • 利用した分だけお支払いいただく課金モデル • AWSサービスと簡単に連携 マネージド・サービスとして提供
- 18. 18 @awscloud_jp Establishing ourecosystem “Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性の 心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを加 速させるために一緒に働くことを楽しみにしています。” — Roger Levy, VP Products, MariaDB
- 19.
- 20. 20 @awscloud_jp Service OrientedArchitecture • ログとストレージレイヤを シームレスにスケールする ストレージサービスに移動 • 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 @awscloud_jp キャッシュレイヤの分離 • キャッシュをデータベースプロセス外 に移動させた •データベースプロセスのリスタートが 発生してもキャッシュが残った状態を 維持可能 SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching キャッシュプロセスをDBプロセス外におくことで DBプロセスの再起動でもキャッシュが残る
- 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 @awscloud_jp Auroraのストレージ • AmazonAuroraは6本全てのディスクへの書き込みを 待たずに、少なくとも4つのディスクに書き込みが完了す るとすぐに次の処理を実行 • ホットスポットの影響を取り除き、非常に高い並列度を 実現 • ストレージはSSDベースのディスクに10GBずつのブ ロック内に分散して書き込まれる
- 24. 24 @awscloud_jp Auroraのストレージの特徴 • リードレプリカもマスタと同じストレージを参照 •Log Structured Storage • 継続的なS3へ増分バックアップ – パフォーマンスへの影響なし • 64TBまで自動でストレージがシームレスにスケールアップ – パフォーマンスや可用性に影響無し・利用開始時のプロビジョニング不要 • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化
- 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 @awscloud_jp レプリケーション AZ 1AZ 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 @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 @awscloud_jp レプリケーション • AmazonAuroraは、15台のリードレプリカを作成可 能 – リードレプリカはマスタサーバとストレージを共有しており、低負荷で 粒度の高いほぼ同期型のレプリケーションを行う – 10-20msのレイテンシーでレプリケーションされる – RDS for MySQLではリードレプリカは5つまで (孫リードレプリカを入 れて30)
- 29. 29 @awscloud_jp セキュリティ • データの暗号化 –AES-256 (ハードウエア支援) – ディスクとAmazon S3に置かれている全ブロックを暗号化 – AWS KMSを利用したキー管理 (現在未サポート) • SSLを利用したデータ通信の保護 • 標準でAmazon VPCを使ったネットワークの分離 • ノードへ直接アクセスは不可能 • 業界標準のセキュリティとデータ保護の認証をサ ポート Storage SQL Transactions Caching Amazon S3 Application
- 30.
- 31. 31 @awscloud_jp フェイルオーバーとリプレース • リードレプリカが存在する場合は1分程でフェイルオー バー可能 –RDS for MySQLよりも高速にフェイルオーバー可能 – リードレプリカが存在しない場合は10分程 • 優先的にフェイルオーバーさせるノードを1つ指定可能 – Multi-AZ配置として別AZで起動する – RDS for MySQLと違いリードアクセス可能
- 32. 32 @awscloud_jp クラスタエンドポイント • WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエン ドポイントが存在する •各Auroraノードは個別にエンドポイントを持っている Reader Writer
- 33. 33 @awscloud_jp クラスタエンドポイント Availability ZoneA Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンド ポイント • 各Auroraノードは個 別にエンドポイントを 持っている • クラスタエンドポイン トは、その時アクティ ブなAurora Writer ノードのCNAME • Readは各Readerを参 照する Write
- 34. 34 @awscloud_jp クラスタエンドポイント • フェイルオーバーが 発生すると、Aurora ノードの昇格が行わ れ、クラスタエンド ポイントの指し先が 変わる AvailabilityZone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンド ポイント Write
- 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 @awscloud_jp 高速なデータ修復 既存のデータベース • 最後のチェックポイントからログを 適用していく •MySQLではシングルスレッドなた め適用完了までの時間が増加 Amazon Aurora • Disk readの一環として、オンデマ ンドでredo logの適用を行う • 並列、分散、非同期で行われる Checkpointed Data Redo Log T0 でクラッシュが発生すると 最後のチェックポイントからの ログを適用する必要がある T0 T0 T0 でクラッシュが発生するとredo を並列で分散して非同期でログの適用を行う
- 37. 37 @awscloud_jp 継続バックアップとポイント・イン・タイムリカバリー(PITR) • AmazonAuroraでは各セグメント毎にAmazon S3へ継 続的に増分バックアップを取得している – Backup retention periodでバックアップを残す期間を指定可能 • Amazon Auroraが使用しているディスクの仕組みによ りパフォーマンスへ影響を与えない • PITRで5分前からBackup Retention Periodまでの任 意の位置に秒単位で復元可能
- 38. 38 @awscloud_jp SQLによるフェイルオーバーのテスト SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能 • データベースノードのクラッシュをシミュレート: ALTERSYSTEM 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.
- 40. 40 @awscloud_jp Auroraのパフォーマンスを引き出すために • クエリ並列度が高い、データサイズが大きいケース で効果を発揮 •ロック機構やQuery Cache・スレッドプールなどに手 を入れて性能向上を行っている – write heavyな環境ではoffをおすすめ – CPUを効率的に利用する改善により、CPU利用率がMySQLと比較 して高くなるが、性能が落ちにくくなっている
- 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 @awscloud_jp パフォーマンス • FAQとパフォーマンステストのガイドライン、テスト用 AMIを提供しています –http://aws.amazon.com/rds/aurora/faqs/ の Amazon Aurora Performance Benchmarking Guide
- 43. 43 @awscloud_jp パフォーマンス • 価格性能比5倍 –Amazon Auroraは高速でSSDベースのストレージにより高速に動作 するが、既存のどんなクエリでも5倍高速に実行出来ることを意味し ているわけではない – Amazon Auroraは他の製品よりも、より多くの書き込み・読み込みク エリを同時に扱うことが出来るためデータベースの集約やスループッ ト向上が見込める – Amazon Aurora独自で高並列なストレージへのアクセスにより保存 されているデータへのコンテンションを解決し、クエリを効率よく処理
- 44.
- 45. 45 @awscloud_jp よく見ると • Auroraではデッドロックがほんの少し出やすいがリ トライを行ってもMｙSQLよりスループットが出る •CPU / Memoryの利用率がMySQLより高いがス ループットが出ている – 分散ロック機構によりCPUリソースを使いきってスループットを出して いる
- 46. 46 @awscloud_jp 何をみるのか？ • よく聞かれる質問 –CPU利用率高いんだけど? – メモリ利用量多いんだけど？ – Disk IOが多めなんだけど？ • 見てほしいこと – Auroraはマシンリソースを最大限利用してスループットを出す設 計です – システムトータルでパフォーマンスが向上 – 管理コスト、障害耐性、データ保全性
- 47. 47 @awscloud_jp 何をみるのか？ • AuroraはMySQL互換ですが、マシンリソースの使 い方が根本的に違います •Auroraが得意な場面・状況を理解してパフォーマン スを測定 – マシンリソースを使い切りそうになりながらもMySQLと比べるとス ループットやレスポンスタイムの落ち方が緩やか
- 48.
- 49. 49 @awscloud_jp RDS forMySQLからマイグレーション • マネージメントコンソールから数クリックでAmazon Auroraへ 移行可能 – RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能 – RDS for MySQLは5.6を使う必要がある
- 50. 50 @awscloud_jp マイグレーション時の注意 • RDSfor MySQLとParameter Groupで設定出来る 項目や規定値などが異なる – 例: max_connection / innodb_buffer_pool_size / query_cache_* など • マイグレーションに必要なディスクスペース – スナップショットをインポートする場合、インポート前にEBSボリューム を使用しデータをフォーマットする – データをフォーマットするための追加容量が必要になる場合がある
- 51. 51 @awscloud_jp マイグレーション時の注意 • AmazonAuroraはInnoDBのみサポート – MyISAMなどのストレージエンジンは非対応 • マイグレーション時に自動でMyISAMからコンバート されますが、事前に手動でInnoDBへの変換を行っ ていただくことがオススメです
- 52. 52 @awscloud_jp マイグレーション時の注意 • MyISAM形式のテーブルが含まれない場合 –移行前のディスクで6TBまで容量を利用可能 • MyISAM形式のテーブルが含まれる場合 – マイグレーションを行うテーブルで3TBを超えるものが無いことを確 認する
- 53. 53 @awscloud_jp MySQLからレプリケーション • MySQL5.6からAmazonAuroraへレプリケーションを行うことが可 能 • 専用のプロシージャを使用 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 @awscloud_jp MySQLからレプリケーション • RDSfor MySQLやMySQL on EC2、オンプレ環境 のMySQLからAmazon Auroraにレプリケーション 可能 – バックアップからAuroraにインポートを行い、レプリケーションを実行 – 移行時にアプリケーションのメンテナンスを入れ、書き込みがなくなり、 レプリケーションが追いついたタイミングでアプリケーションの書き込 み先などをAuroraに変更
- 55.
- 56. 56 @awscloud_jp クエリ同時実行数やテーブルサイズが大きい • AmazonAuroraに移行することで、クエリスルー プットの向上などが見込まれる – マルチコア環境でCPUを効率的に利用 – 分散ロック機構やquery cacheの改善による性能向上 • ディスク – データ量の増加に応じてディスク容量を気にする必要が無い – 性能に影響を及ばさずバックアップ
- 57. 57 @awscloud_jp 複数のサーバにシャーディングしている • 複数の小さいDBを1つにまとめる –コスト効果増大と管理コストの軽減 – シャーディングをするデータベースを減らすことでアプリケーションの 設計を簡略化出来る – 障害時の影響を考慮する必要はある
- 58.
- 59. 59 @awscloud_jp Amazon Aurora •クラウド時代にAmazonが再設計したRDBMS – MySQL5.6と互換があり既存の資産を活かしやすい • 高いクエリ実行並列度・データサイズが大きい環境で性能を 発揮 – Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮 • 高可用性・高速なフェイルオーバー・PITRを実現するための 多くのチャレンジ – Log Structured Storage – SOA
- 60.
- 61. AWS Cloud Roadshow2015 札幌のご案内 日時・会場： 2015年11月12日 10:00スタート（ニューオータニイン札幌） 主催：アマゾンデータサービスジャパン株式会社／インテル株式会社 申込：事前登録制・無料（現在、Save the dateを受付中。配布チラシをご確認ください。） 概要：基調講演を含む、充実の11のセッション。セルフペースラボ設置、パートナー展示も実施予定。 対象： –今後クラウドの導入をご検討中の方 –アプリケーション開発・運用をもっと効率的に行いたい方 –既存のデータセンター環境とクラウドの併用をご検討の方 –国内の著名企業におけるクラウド活用事例について参考にしたいという方 –メディア・エンターテインメント業界におけるサービス提供手法について参考にしたいという方 –より深い技術を学び、クラウドを活用したいとお考えの方
- 62.
- 63.