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.

AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora

68,057 views

Published on

2015年7月31日に開催したAWS Black Belt Tech Webinar シリーズ 2015 - Amazon Auroraの資料です。

Black Beltの予定は以下のURLで公開されています。
http://aws.amazon.com/jp/about-aws/events/#webinar

Published in: Travel
  • Be the first to comment

AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora

  1. 1. Amazon Aurora AWS Black Belt Tech Webinar 2015 (旧マイスターシリーズ) アマゾン データ サービス ジャパン株式会社 星野 豊
  2. 2. 自己紹介 • 星野 豊 (ほしの ゆたか) – @con_mame – facebook.com/conmame – ソリューションアーキテクト • 経歴 – 全てオンプレ環境のインフラエンジニア – 全AWS環境のインフラエンジニア • 担当 – Webサービス / game / Video・Live Streamingなどのメディア系のお客 様
  3. 3. 今回お話する内容は2015/7/28現在の情報です
  4. 4. Amazon Aurora
  5. 5. データベース管理を簡単に • データベースを数分で作成可能 • 自動でパッチの適用 • 数クリックするだけでスケールアウト可能 • S3への継続的なバックアップ • 障害の自動検知と自動フェールオーバ Amazon RDS
  6. 6. 2015/7/28 GAリリース! Virginia / Oregon / Irelandリージョン
  7. 7. Amazon Aurora • re:Invent 2014で発表されたRDSの新しいエンジン • Amazonがクラウド時代にリレーショナル・データベース を作るとどうなるかを1から考え構築 – 新しい技術的チャレンジを盛り込んでいる • エンタープライズグレードの可用性とOSSレベルのコス トを両立
  8. 8. Amazon Aurora • Amazon AuroraはRDSが提供するエンジンのうち の1つ – RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Server が選択可能
  9. 9. • ライセンス料金は不 要 • ロックインもない • 使った分だけ課金 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. Amazon Auroraの特徴 クエリ性能の向上 コストパフォーマンスが良い 高可用性・高耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
  11. 11. Amazon Auroraの特徴 • MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行 可能 • ストレージが10GBから64TBまでシームレスに拡張 • 3AZに2つずつ、計6つのデータのコピーを保持 – S3にストリーミングバックアップを実施 • VPC内に起動 – Security GroupやNACLを使用してアクセスコントロール可能 • Amazon Auroraは99.99%の可用性を実現するように設計されている
  12. 12. なぜAmazonがデータベースを再考したか
  13. 13. 現在のモノリシックなDB 複数の機能レイヤーが1 つのアプリケーションに なっている SQL Transactions Caching Logging
  14. 14. 現在のモノリシックなデータベース スケールアウトする 場合は、このセット を増やしていく必要 がある SQL Transactions Caching Logging SQL Transactions Caching Logging Application
  15. 15. コスト・可用性・柔軟性の面で問題
  16. 16. リレーショナルデータベースをもう一度考える • 今、データベースを再度実装するならどうするか? – 少なくとも1970年代の方法で実装はしない – AWSサービスを活かすことができ、スケールアウトが簡単で、セルフ ヒーリングが出来るようなデータベースを作りたいと考えた
  17. 17. クラウド時代に適したリレーショナルデータベース • ハイエンドデータベースの様なスピード と 可用性 • オープンソースデータベースのシンプルさとコスト効果の高さ • MySQLと互換性を保つ • 利用した分だけお支払いいただく課金モデル • AWSサービスと簡単に連携 マネージド・サービスとしてご提供
  18. 18. 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. アーキテクチャ
  20. 20. 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. キャッシュレイヤの分離 • キャッシュをデータベースプロセス外 に移動させた • データベースプロセスのリスタートが 発生してもキャッシュが残った状態を 維持可能 • サービスにすぐデータベースを戻す ことが出来る SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching キャッシュプロセスをDBプロセス外におくことで DBプロセスの再起動でもキャッシュが残る
  22. 22. Auroraのストレージ • SSDを利用したシームレスにスケールす るストレージ – 10GBから64TBまでシームレスに自動でスケール アップ – 実際に使った分だけ課金 • 標準でHighly availableを実現 – 3AZに6つのデータのコピーを作成 – 2つのディスクが利用不能でも読み書き可能 • 万が一1つのAZが利用不能になっても3本で読み 書き可能な状態で稼働 – 3つのディスクが利用不能の場合読み込みのみ可能 • Log structured Storage – redo logを複数の小さなセグメントに分割 – Log pageによってData pageを作成 SQL Transactions AZ 1 AZ 2 AZ 3 Caching Amazon S3
  23. 23. Auroraのストレージ • Amazon Auroraは6本全てのディスクへの書き込みを 待たずに、少なくとも4つのディスクに書き込みが完了す るとすぐに次の処理を実行 • ホットスポットの影響を取り除き、非常に高い並列度を 実現 • ストレージはSSDベースのディスクに10GBずつのブ ロック内に分散して書き込まれる
  24. 24. Auroraのストレージの特徴 • リードレプリカもマスタと同じストレージを参照 • Log Structured Storage • 継続的なS3へ増分バックアップ – パフォーマンスへの影響なし • 64TBまで自動でストレージがシームレスにスケールアップ – パフォーマンスや可用性に影響無し・利用開始時のプロビジョニング不要 • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化
  25. 25. Log Structured Storage • 追記型のストレージ・システム – ログの様に常に末尾にデータを追加していくだけ – データが書き込まれているブロックを上書いたりはしない – GCによりデータを効率的に格納する • シーケンシャルに読み出すことが出来る • 常に最新のデータが末尾にある • これらの特徴によりS3への継続バックアップや高速なリカバリ、書き込み性能 の向上を実現 空きスペース data data 先頭 data data data 新規データは末尾に追記される ↓
  26. 26. ディスク障害検知と修復 • 2つのコピーに障害が起こっても、読み書きに影響は無い • 3つのコピーに障害が発生しても読み込みは可能 • 自動検知、修復 SQL Transaction AZ 1 AZ 2 AZ 3 Caching SQL Transactio n AZ 1 AZ 2 AZ 3 Caching 読み書き可能読み込み可能
  27. 27. レプリケーション 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 書き込みの種類
  28. 28. レプリケーション ページキャッシュ パージ 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が必要 • レプリケーションはマスターへ負荷がかかる • レプリケーション遅延が増加していくケースがある • フェイルオーバでデータロスの可能性がある
  29. 29. レプリケーション • Amazon Auroraは、15台のリードレプリカを作成可 能 – リードレプリカはマスタサーバとストレージを共有しており、低負荷で 粒度の高いほぼ同期型のレプリケーションを行う – 10-20msのレイテンシーでレプリケーションされる – RDS for MySQLではリードレプリカは5つまで (孫リードレプリカを入 れて30)
  30. 30. セキュリティ • データの暗号化 – AES-256 (ハードウエア支援) – ディスクとAmazon S3に置かれている全ブロックを暗号化 – AWS KMSを利用したキー管理 (現在未サポート) • SSLを利用したデータ通信の保護 • 標準でAmazon VPCを使ったネットワークの分離 • ノードへ直接アクセスは不可能 • 業界標準のセキュリティとデータ保護の認証をサ ポート Storage SQL Transactions Caching Amazon S3 Application
  31. 31. DBクラスタ • Amazon AuroraはDBクラスタという概念を持っている – マスタ (Writer)とリードレプリカ(Reader)をひとまとめにしたもの – Parameter GroupやMaintenance WindowもDBクラスタと各ノードそろ ぞれに存在する • フェイルオーバが発生しても常にマスタを参照するエン ドポイントがクラスタ毎に1つ存在する – アプリケーションからのWriteクエリは常にこのエンドポイントを参照する ように設定
  32. 32. DB Parameter GroupとDB Cluster Parameter Group • RDS for MySQLではDB Parameter Groupのみ • Auroraでは設定の適用範囲毎にグループを設定 – DB Cluster Parameter Group: Auroraクラスタ内全ノードで共通 – DB Parameter Group: 各Auroraノード個別の設定
  33. 33. 新しいメトリクス画面 • Throughput – Select – Commit – DML/DDL • Latency – Select – Commit – DML/DDL • Cache Hit Ratio – Buffer Cache – Result Set • Deadlocks • Login Failures • Blocked Transactions
  34. 34. メトリクススキーマ • 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 | +-----------------+---------------------------------------+--------------------------------------------------------+
  35. 35. メトリクススキーマ
  36. 36. フェイルオーバとリカバリ
  37. 37. フェイルオーバ と リプレース • リードレプリカが存在する場合は1分程でフェイルオー バ可能 – RDS for MySQLよりも高速にフェイルオーバ可能 – リードレプリカが存在しない場合は10分程 • 優先的にフェイルオーバさせるノードを1つ指定可能 – Multi-AZ配置として別AZで起動する – RDS for MySQLと違いリードアクセス可能
  38. 38. クラスタエンドポイント • WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエン ドポイントが存在する • 各Auroraノードは個別にエンドポイントを持っている Reader Writer
  39. 39. クラスタエンドポイント Aurora Writer Aurora Reader クラスタエンド ポイント • 各Auroraノードは個 別にエンドポイントを 持っている • クラスタエンドポイン トは、その時アクティ ブなAurora Writer ノードのCNAME • Readは各Readerを参 照する Write
  40. 40. クラスタエンドポイント • フェイルオーバが発 生すると、Aurora ノードの昇格が行わ れ、クラスタエンド ポイントの指し先が 変わる Aurora Writer Aurora Reader クラスタエンド ポイント Write
  41. 41. Writer / Readerノードの識別 • innodb_read_onlyを参照 – SHOW GLOBAL VARIABLES LIKE 'innodb_read_only’; – OFF: Writer – ON: Reader • アプリケーションやドライバでAuroraノードに対する 負荷分散やフェイルオーバーロジックの実装に利用 可能 – メトリクススキーマのSEESION_IDも利用可能
  42. 42. 高速なデータ修復 既存のデータベース • 最後のチェックポイントからログを 適用していく • MySQLではシングルスレッドなた め適用完了までの時間が増加 Amazon Aurora • Disk readの一環として、オンデマ ンドでredo logの適用を行う • 並列、分散、非同期で行われる Checkpointed Data Redo Log T0 でクラッシュが発生すると 最後のチェックポイントからの ログを適用する必要がある T0 T0 T0 でクラッシュが発生するとredo を並列で分散して非同期でログの適用を行う
  43. 43. Streaming snapshotとPITR • Amazon Auroraでは各セグメント毎にAmazon S3へ継 続的に増分バックアップを取得している – Backup retention periodでバックアップを残す期間を指定可能 • Amazon Auroraが使用しているディスクの仕組みによ りパフォーマンスへ影響を与えない • PITRで5分前からBackup Retention Periodまでの任 意の位置に秒単位で復元可能
  44. 44. 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 ]; • 他にも – ディスク障害をシミュレート – ディスクコンジェスションをシミュレート
  45. 45. パフォーマンス
  46. 46. Auroraのパフォーマンスを引き出すために • クエリ並列度が高い、データサイズが大きいケース で効果を発揮 • ロック機構やQuery cache・スレッドプールなどに手 を入れて性能向上を行っている – write heavyな環境ではoffをおすすめ – CPUを効率的に利用する改善により、CPU利用率がMySQLと比較 して高くなるが、性能が落ちにくくなっている
  47. 47. パフォーマンス測定 Aurora Writer • 複数のインスタンスから同時に負荷 をかけ並列度を上げる – NWの影響を抑えるために同一リー ジョンで行う – 1-2時間など長時間行う • 単一のインスタンスからだけでは、イ ンスタンス毎のNW帯域の制限に達 する可能性がある • 高負荷環境でもスループット低下を 抑える改善が入っているためCPU/メ モリ利用率がRDS for MySQLと比 較して高くなるケースがある
  48. 48. defaultパラメータの違い • RDS for MySQLと比べるとbuffer / connection / 周りの値が少なめ • query cacheがON – ONの状態でも性能が出るようにAuroraでは性能向上が行われてい る – Write heavyな環境ではOFFも検討
  49. 49. defaultパラメータの違い • innodb_change_buffering – NONE – 今のところ変更不可 – Secondary indexへの更新などに影響が出そうだが、1-2時間など長 時間ベンチマークを行い、change bufferに収まらない量になってくる と、Auroraの優位性が出てくる • 数十分の短いベンチマークだと多少影響を受ける可能性がある
  50. 50. 新規パラメータ • thread_handling – Default: multiple-connections-per-thread – multiple-connections-per-thread, no-threads, one-thread-per- connection, dynamically-loaded – 接続を扱うAuroraのスレッドに関する設定
  51. 51. パフォーマンス • 性能が5倍というのはどのようなケースか – re:Invent で発表された5倍という性能はSysbenchを4インスタンス (r3.8xlarge + NW関連のkernelパラメータ調整済)からr3.8xlargeの Auroraインスタンスに実行した場合の結果 • TPC-C をr3.8xlargeに実行した場合は約2.5〜5倍 の性能を観測している
  52. 52. パフォーマンス • FAQとパフォーマンステストのガイドライン・テス ト用AMIを提供しています – http://aws.amazon.com/rds/aurora/faqs/ の Amazon Aurora Performance Benchmarking Guide
  53. 53. パフォーマンス • 価格性能比5倍 – Amazon Auroraは高速でSSDベースのストレージにより高速に動作 するが、既存のどんなクエリでも5倍高速に実行出来ることを意味し ているわけではない – Amazon Auroraは他の製品よりも、より多くの書き込み・読み込みク エリを同時に扱うことが出来るためデータベースの集約やスループッ ト向上が見込める – Amazon Aurora独自で高並列なストレージへのアクセスにより保存 されているデータへのコンテンションを解決し、クエリを効率よく処理
  54. 54. 参考 (re:Inventで発表された資料)
  55. 55. よく見ると • Auroraはデッドロックをがほんの少し出やすいがリ トライを行ってもMySQLよりスループットが出る • CPU / Memoryの利用率がMySQLより高いがス ループットが出ている – 分散ロック機構によりCPUリソースを使いきってスループットを出して いる
  56. 56. 何をみるのか? • よく聞かれる質問 – CPU利用率高いんだけど? – メモリ利用量多いんだけど? – Disk IOが多めなんだけど? • 見てほしいこと – Auroraはマシンリソースを最大限利用してスループットを出す設 計です – システムトータルでパフォーマンスが向上 – 管理コスト、障害耐性、データ保全性
  57. 57. 何をみるのか? • AuroraはMySQL互換ですが、マシンリソースの使 い方が根本的に違います • Auroraが得意な場面・状況を理解してパフォーマン スを測定 – マシンリソースを使い切りそうになりながらもMySQLと比べるとス ループットやレスポンスタイムの落ち方が緩やか
  58. 58. Amazon Auroraへの移行
  59. 59. RDS for MySQLからマイグレーション • マネージメントコンソールから数クリックでAmazon Auroraへ 移行可能 – RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能 – RDS for MySQLは5.6を使う必要がある
  60. 60. マイグレーション時の注意 • RDS for MySQLとParameter Groupで設定出来る 項目や規定値などが異なる – 例: max_connection / innodb_buffer_pool_size / query_cache_* など • マイグレーションに必要なディスクスペース – スナップショットをインポートする場合、インポート前にEBSボリューム を使用しデータをフォーマットする – データをフォーマットするための追加容量が必要になる場合がある
  61. 61. マイグレーション時の注意 • Amazon AuroraはInnoDBのみサポート – MyISAMなどのストレージエンジンは非対応 • マイグレーション時に自動でMyISAMからコンバート されますが、事前に手動でInnoDBへの変換を行っ ていただくことがオススメです
  62. 62. マイグレーション時の注意 • MyISAM形式のテーブルが含まれない場合 – 移行前のディスクで6TBまで容量を利用可能 • MyISAM形式のテーブルが含まれる場合 – マイグレーションを行うテーブルで3TBを超えるものが無いことを確 認する
  63. 63. MySQLからレプリケーション • MySQL5.6からAmazon Auroraへレプリケーションを行うことが可 能 • 専用のProcedureを使用 mysql > CALL mysql.rds_set_external_master (DB Hostname or IP address', 3306,’user', ‘password', ’Binlog', position, 0); mysql > CALL mysql.rds_start_replication;
  64. 64. MySQLからレプリケーション • RDS for MySQLやMySQL on EC2、オンプレ環境 のMySQLからAmazon Auroraにレプリケーション 可能 – バックアップからAuroraにインポートを行い、レプリケーションを実行 – 移行時にアプリケーションのメンテナンスを入れ、書き込みがなくなり、 レプリケーションが追いついたタイミングでアプリケーションの書き込 み先などをAuroraに変更
  65. 65. Amazon Auroraの使いどころ
  66. 66. クエリ同時実行数やテーブルサイズが大きい • Amazon Auroraに移行することで、クエリスルー プットの向上などが見込まれる – マルチコア環境でCPUを効率的に利用 – 分散ロック機構やquery cacheの改善による性能向上 • ディスク – データ量の増加に応じてディスク容量を気にする必要が無い – 性能に影響を及ばさずバックアップ
  67. 67. 複数のサーバにシャーディングしている • 複数の小さいDBを1つにまとめる – コスト効果増大と管理コストの軽減 – シャーディングをするデータベースを減らすことでアプリケーションの 設計を簡略化出来る – 障害時の影響を考慮する必要はある
  68. 68. まとめ
  69. 69. Amazon Aurora • クラウド時代にAmazonが再設計したRDBMS – MySQL5.6と互換があり既存の資産を活かしやすい • 高いクエリ実行並列度・データサイズが大きい環境で性能を 発揮 – Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮 • 高可用性・高速なフェイルオーバ・PITRを実現するための多 くのチャレンジ – Log Structured Storage – SOA
  70. 70. Q&A 次回Webinarのお申し込み http://aws.amazon.com/jp/event_schedule/
  71. 71. Webinar資料の配置場所 • AWS クラウドサービス活用資料集 – http://aws.amazon.com/jp/aws-jp-introduction/
  72. 72. 公式Twitter/Facebook AWSの最新情報をお届けします @awscloud_jp 検索 最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを 日々更新しています! もしくは http://on.fb.me/1vR8yWm
  73. 73. ご参加ありがとうございました。

×