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.

Amazon Aurora

4,104 views

Published on

Amazon Aurora for morning session at CTO Night and Day

Published in: Technology
  • Be the first to comment

Amazon Aurora

  1. 1. Amazon Aurora Amazon Web Services Japan K.K.
  2. 2. Amazon Aurora
  3. 3. データベース管理を簡単に •  データベースを数分で作成可能 •  ⾃動でパッチの適⽤ •  数クリックするだけでスケールアウト可能 •  S3への継続的なバックアップ •  障害の⾃動検知と⾃動フェールオーバ Amazon RDS
  4. 4. 2015/7/28 GAリリース! Virginia / Oregon / Ireland / Tokyoリージョン
  5. 5. Amazon Aurora •  re:Invent 2014で発表されたRDSの新しいエンジン •  Amazonがクラウド時代にリレーショナル・データ ベースを作るとどうなるかを1から考え構築 –  新しい技術的チャレンジを盛り込んでいる •  エンタープライズグレードの可⽤性とOSSレベルの コストを両⽴
  6. 6. Amazon Aurora •  Amazon AuroraはRDSが提供するエンジンのうちの1つ –  RDSでは現在、MySQL / MariaDB / PostgreSQL / Oracle / MS SQL Serverが選択可能
  7. 7. •  ライセンス料⾦は不 要 •  ロックインもない •  使った分だけ課⾦ 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
  8. 8. Amazon Auroraの特徴 クエリ性能の向上 コストパフォーマンスが良い ⾼可⽤性・⾼耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
  9. 9. Amazon Auroraの特徴 •  MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能 •  ストレージが10GBから64TBまでシームレスに拡張 •  3AZに2つずつ、計6つのデータのコピーを保持 –  S3にストリーミングバックアップを実施 •  VPC内に起動 –  Security GroupやNACLを使⽤してアクセスコントロール可能 •  Amazon Auroraは99.99%の可⽤性を実現するように設計されている
  10. 10. なぜAmazonがデータベースを再考したか
  11. 11. 現在のモノリシックなDB 複数の機能レイヤーが 1つのアプリケーショ ンになっている SQL Transactions Caching Logging
  12. 12. 現在のモノリシックなデータベース スケールアウトする場 合は、このセットを増や していく必要がある SQL Transactions Caching Logging SQL Transactions Caching Logging Application
  13. 13. コスト・可⽤性・柔軟性の⾯で問題
  14. 14. リレーショナルデータベースをもう⼀度考える •  今、データベースを再度実装するならどうする か? –  少なくとも1970年代の⽅法で実装はしない –  AWSサービスを活かすことができ、スケールアウトが簡単で、 セルフヒーリングが出来るようなデータベースを作りたいと考 えた
  15. 15. クラウド時代に適したリレーショナルデータベース •  ハイエンドデータベースの様なスピード と 可⽤性 •  オープンソースデータベースのシンプルさとコスト効果の⾼さ •  MySQLと互換性を保つ •  利⽤した分だけお⽀払いいただく課⾦モデル •  AWSサービスと簡単に連携 マネージド・サービスとしてご提供
  16. 16. Establishing our ecosystem “Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性 の⼼配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを 加速させるために⼀緒に働くことを楽しみにしています。” ̶ Roger Levy, VP Products, MariaDB
  17. 17. アーキテクチャ
  18. 18. 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
  19. 19. キャッシュレイヤの分離 •  キャッシュをデータベースプロセス外に 移動させた •  データベースプロセスのリスタート が発⽣してもキャッシュが残った状 態を維持可能 •  サービスにすぐデータベースを戻す ことが出来る •  ⾼速なクラッシュリカバリ + survivable cache = DB障害から⾼ 速に復帰可能 SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching キャッシュプロセスをDBプロセス外におくことで DBプロセスの再起動でもキャッシュが残る
  20. 20. Auroraのストレージ •  SSDを利⽤したシームレスにスケールするスト レージ –  10GBから64TBまでシームレスに⾃動でスケールアップ –  実際に使った分だけ課⾦ –  Peer-to-peer gossipレプリケーション •  標準で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
  21. 21. IO traffic in Aurora (ストレージノード) LOG RECORDS Primary instance INCOMING QUEUE STORAGE NODE S3 BACKUP 1 2 3 4 5 6 7 8 UPDATE QUEUE ACK HOT LOG DATA BLOCKS POINT IN TIME SNAPSHOT GC SCRUB COALESCE SORT GROUP PEER-TO-PEER GOSSIPPeer storage nodes 全てのステップは非同期 ステップ1と 2だけがフォアグラウンドのレイテンシーに影響 インプットキューはMySQLの1/46 (unamplified, per node) レイテンシーにセンシティブな操作に向く ディスク領域をバッファーに使ってスパイクに対処 OBSERVATIONS IO FLOW ①  レコードを受信しインメモリのキューに追加 ②  レコードを永続化してACK ③  レコードを整理してギャップを把握 ④  ピアと通信して穴埋め ⑤  ログレコードを新しいバージョンのデータブロックに合体 ⑥  定期的にログと新しいバージョンのブロックをS3に転送 ⑦  定期的に古いバージョンのガベージコレクションを実施 ⑧  定期的にブロックのCRCを検証
  22. 22. Auroraのストレージ •  Amazon Auroraは6本全てのディスクへの書き込み を待たずに、少なくとも4つのディスクに書き込み が完了するとすぐに次の処理を実⾏ •  ホットスポットの影響を取り除き、⾮常に⾼い並列 度を実現 •  ストレージはSSDベースのディスクに10GBずつの ブロック内に分散して書き込まれる
  23. 23. Auroraのストレージの特徴 •  リードレプリカもマスタと同じストレージを参照 •  Log Structured Storage •  継続的なS3へ増分バックアップ –  パフォーマンスへの影響なし •  64TBまで⾃動でストレージがシームレスにスケールアップ –  パフォーマンスや可⽤性に影響無し・利⽤開始時のプロビジョニング不要 •  ⾃動で再ストライピング、ミラー修復、ホットスポット管理、 暗号化
  24. 24. Log Structured Storage •  追記型のストレージ・システム –  ログの様に常に末尾にデータを追加していくだけ –  データが書き込まれているブロックを上書いたりはしない –  GCによりデータを効率的に格納する •  シーケンシャルに読み出すことが出来る •  常に最新のデータが末尾にある •  これらの特徴によりS3への継続バックアップや⾼速なリカバリ、書き込 み性能の向上を実現 空きスペース data data 先頭 data data data 新規データは末尾に追記される ↓
  25. 25. ディスク障害検知と修復 •  2つのコピーに障害が起こっても、読み書きに影響は無い •  3つのコピーに障害が発⽣しても読み込みは可能 •  ⾃動検知、修復 SQL Transaction AZ 1 AZ 2 AZ 3 Caching SQL Transaction AZ 1 AZ 2 AZ 3 Caching 読み書き可能読み込み可能
  26. 26. レプリケーション 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. レプリケーション 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が必要 •  レプリケーションはマスターへ負荷がかかる •  レプリケーション遅延が増加していくケースが ある •  フェイルオーバでデータロスの可能性がある PAGE CACHE UPDATE
  28. 28. レプリケーション •  Amazon Auroraは、15台のリードレプリカを 作成可能 –  リードレプリカはマスタサーバとストレージを共有しており、 低負荷で粒度の⾼いほぼ同期型のレプリケーションを⾏う –  10-20msのレイテンシーでレプリケーションされる –  RDS for MySQLではリードレプリカは5つまで (孫リードレプ リカを⼊れて30)
  29. 29. IO traffic in RDS MySQL BINLOG DATA DOUBLE-WRITELOG FRM FILES T Y P E O F W R I T E MYSQL WITH STANDBY EBSに書き込み – EBSがミラーへ複製し、両方終了後ack DRBD経由でスタンバイインスタンスへ書き込みを伝播 スタンバイインスタンス側のEBSに書き込み IO FLOW ステップ1, 3, 5はシーケンシャルかつ同期 それによりレイテンシーもパフォーマンスのゆらぎも増加 各ユーザー操作には様々な書き込みタイプがある 書き込み破損を避けるためにデータブロックを2回書く必要性 OBSERVATIONS 780K トランザクション 100万トランザクション当たり7,388K I/Os (ミラー, スタンバイを除く) 平均1トランザクション当たり7.4 I/Os PERFORMANCE 30 minute SysBench write-only workload, 100 GB data set, RDS SingleAZ, 30K PIOPS EBS mirrorEBS mirror AZ 1 AZ 2 Amazon S3 EBS Amazon Elastic Block Store (EBS) Primary instance Standby instance 1 2 3 4 5
  30. 30. IO traffic in Aurora (データベース) AZ 1 AZ 3 Primary instance Amazon S3 AZ 2 Replica instance AMAZON AURORA ASYNC 4/6 QUORUM DISTRIBUTED WRITES BINLOG DATA DOUBLE-WRITELOG FRM FILES T Y P E O F W R I T E 30 minute SysBench write-only workload, 100 GB data set IO FLOW REDOログレコードのみ書き込む; 全てのステップは非同期 データブロックは書かない(チェックポイント, キャッシュ置換時) 6倍のログ書き込みだが, 1/9のネットワークトラフィック ネットワークとストレージのレイテンシー異常時の耐性 OBSERVATIONS 27,378K トランザクション 35X MORE 100万トランザクション当たり950K I/Os 7.7X LESS (6X amplification) PERFORMANCE REDOログレコードをまとめる – 完全にLSN順に並ぶ 適切なセグメントに分割する – 部分ごとに並ぶ ストレージノードへまとめて書き込む
  31. 31. セキュリティ •  データの暗号化 –  AES-256 (ハードウエア⽀援) –  ディスクとAmazon S3に置かれている全ブロックを暗号化 –  AWS KMSを利⽤したキー管理 (現在未サポート) •  SSLを利⽤したデータ通信の保護 •  標準でAmazon VPCを使ったネットワークの分離 •  ノードへ直接アクセスは不可能 •  業界標準のセキュリティとデータ保護の認証をサ ポート Storage SQL Transactions Caching Amazon S3 Application
  32. 32. スレッドプール •  Amazon Auroraはスレッドプールが実装されてい る –  MariaDBやMySQL EEで提供されているような機能だが、Amazon Auroraに実装されているものはオリジナル実装 –  パラメータグループに項⽬があるが、設定変更は不可能 Client Thread Thread Thread Thread Client MySQL Client Thread Thread Thread Thread Client Aurora Thread Pool
  33. 33. •  アクティブなスレッドに複数のコネクションを収容 •  Kernel空間の epoll() がラッチフリーキューにコネクションをアサイン •  スレッドプールの数は動的に調整される •  r3.8xlインスタンスのAmazon Auroraで5,000コンカレントコネク ションを扱える •  Standard MySQL – コネクション毎に1 •  コネクション数に応じてスケールしない •  MySQL EE – スレッドプール毎にコネクションをアサイン •  閾値を慎重に設定する必要がある CLIENTCONNECTION CLIENTCONNECTION LATCH FREE TASK QUEUE epoll() MYSQL THREAD MODEL AURORA THREAD MODEL Adaptive thread pool
  34. 34. ⾮同期グループコミット Read Write Commit Read Read T1 Commit (T1) Commit (T2) Commit (T3) LSN 10 LSN 12 LSN 22 LSN 50 LSN 30 LSN 34 LSN 41 LSN 47 LSN 20 LSN 49 Commit (T4) Commit (T5) Commit (T6) Commit (T7) Commit (T8) LSN GROWTH Durable LSN at head-node COMMIT QUEUE Pending commits in LSN order TIME GROUP COMMIT TRANSACTIONS Read Write Commit Read Read T1 Read Write Commit Read Read Tn TRADITIONAL APPROACH AMAZON AURORA ディスクへ書き込むためののログバッファを管理 バッファが一杯になるか書き込み待ち時間を超過すると書き込みを実行 書き込み頻度が少ない場合は最初の書き込みが遅くなる 最初の書き込みと同時にI/Oリクエストを実行。書き込みが実行されるまでバッファ を埋める 6つの内4つのストレージノードからACKが返ってきた時点で堅牢性のある書き込み が完了 先行するDB durableポイントは最新のペンディングACKのポイントまで
  35. 35. Faster, more predictable failover App runningFailure detection DNS propagation Recovery Recovery DB failure MYSQL App running Failure detection DNS propagation Recovery DB failure AURORA WITH MARIADB DRIVER 1 5 - 2 0 s e c 3 - 2 0 s e c
  36. 36. DBクラスタ •  Amazon AuroraはDBクラスタという概念を持って いる –  マスタ (Writer)とリードレプリカ(Reader)をひとまとめにしたも の –  Parameter GroupとMaintenance WindowもDBクラスタと各ノー ドそろぞれに存在する •  フェイルオーバが発⽣しても常にマスタを参照する エンドポイントがクラスタ毎に1つ存在する –  アプリケーションからのWriteクエリは常にこのエンドポイントを 参照するように設定
  37. 37. DB Parameter GroupとDB Cluster Parameter Group •  RDS for MySQLではDB Parameter Groupのみ •  Auroraでは設定の適⽤範囲毎にグループを設定 –  DB Cluster Parameter Group: Auroraクラスタ内全ノードで共通 –  DB Parameter Group: 各Auroraノード個別の設定
  38. 38. 新しいメトリクス画⾯ •  Throughput –  Select –  Commit –  DML/DDL •  Latency –  Select –  Commit –  DML/DDL •  Cache Hit Ratio –  Buffer Cache –  Result Set •  Deadlocks •  Login Failures •  Blocked Transactions
  39. 39. 新しいメトリクス •  課⾦に関わるディスク利⽤量やIOPS –  Billed storage –  Billed read operations –  Billed write operations
  40. 40. メトリクススキーマ •  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 | +-----------------+---------------------------------------+--------------------------------------------------------+
  41. 41. メトリクススキーマ
  42. 42. 過去数ヶ⽉で改善したこと 書き込みバッチサイズのチューニング read/write I/O要求送信の非同期化 パージスレッドのパフォーマンス バルクインサートのパフォーマンス バッチ操作 フェイルオーバー時間の短縮 mallocの削減 システムコールの削減 Undoスロットのキャッシュパターン 協調したログ適用 その他 binlogと分散トランザクション ロックの圧縮 先読み(read-ahead) 顧客フィードバック ホットな行競合 ディクショナリ統計 小さなトランザクションのコードパス クエリーキャッシュのread/write競合 ディクショナリシステムのmutex ロック競合
  43. 43. フェイルオーバとリカバリ
  44. 44. フェイルオーバ と リプレース •  リードレプリカが存在する場合は1分程でフェ イルオーバ可能 –  RDS for MySQLよりも⾼速にフェイルオーバ可能 –  リードレプリカが存在しない場合は15分程 •  Multi-AZ配置として別AZで起動する –  RDS for MySQLと違いリードアクセス可能
  45. 45. クラスタエンドポイント •  WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラス タエンドポイントが存在する •  各Auroraノードは個別にエンドポイントを持っている(⾍眼鏡タブ内のEndpointで確認可 能) Reader Writer
  46. 46. クラスタエンドポイント 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
  47. 47. クラスタエンドポイント •  フェイルオーバが発 ⽣すると、Aurora ノードの昇格が⾏わ れ、クラスタエンド ポイントの指し先が 変わる Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンドポイント Write
  48. 48. Writer / Readerノードの識別 •  innodb_read_onlyを参照 –  SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ; –  OFF: Writer –  ON: Reader •  アプリケーションやドライバでAuroraノードに 対する負荷分散やフェイルオーバーロジックの 実装に利⽤可能 –  メトリクススキーマのSEESION_IDも利⽤可能
  49. 49. Continuous backup Segment snapshot Log records Recovery point Segment 1 Segment 2 Segment 3 Time 各セグメントの定期的なSnapshotは並列で⾏われ、redo logはストリームで継続バックアップのために S3に送られる。パフォーマンスや可⽤性に対する影響は無し。 リストアでは、適切なセグメントのSnapshotとログストリームをストレージノードに転送し、並列で⾮ 同期で適⽤していく
  50. 50. 高速なデータ修復 既存のデータベース •  最後のチェックポイントからログを適 用していく •  MySQLではシングルスレッドなため 適用完了までの時間が増加 Amazon Aurora •  Disk readの⼀環として、オンデ マンドでredo logの適⽤を⾏う •  並列、分散、⾮同期で⾏われる Checkpointed Data Redo Log T0 でクラッシュが発⽣すると 最後のチェックポイントからの ログを適⽤する必要がある T0 T0 T0 でクラッシュが発⽣するとredo を並列で分散して⾮同期でログの適⽤を⾏う
  51. 51. Streaming snapshotとPITR •  Amazon Auroraでは各セグメント毎にAmazon S3へ継続 的に増分バックアップを取得している –  Backup retention periodでバックアップを残す期間を指定可能 •  Amazon Auroraが使用しているディスクの仕組みにより パフォーマンスへ影響を与えない •  PITRで5分前からBackup Retention Periodまでの任意 の位置に秒単位で復元可能
  52. 52. 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 ]; •  他にも –  ディスク障害をシミュレート –  ディスクコンジェスションをシミュレート
  53. 53. パフォーマンス
  54. 54. Auroraのパフォーマンスを引き出すために •  クエリ並列度が⾼い、データサイズが⼤きい ケースで効果を発揮 •  ロック機構やQuery cache・スレッドプールな どに⼿を⼊れて性能向上を⾏っている –  write heavyな環境ではoffをおすすめ –  CPUを効率的に利⽤する改善により、CPU利⽤率がMySQLと⽐ 較して⾼くなるが、性能が落ちにくくなっている
  55. 55. パフォーマンス測定 Availability Zone A VPC subnet VPC subnet Aurora Writer •  複数のインスタンスから同時に負荷 をかけ並列度を上げる –  NWの影響を抑えるために同⼀リー ジョンで⾏う –  1-2時間など⻑時間⾏う •  単⼀のインスタンスからだけでは、 インスタンス毎のNW帯域の制限に 達する可能性がある •  ⾼負荷環境でもスループット低下を 抑える改善が⼊っているためCPU/ メモリ利⽤率がRDS for MySQLと ⽐較して⾼くなるケースがある
  56. 56. defaultパラメータの違い •  RDS for MySQLと⽐べるとbuffer / connection / 周りの値が少なめ •  query cacheがON –  ONの状態でも性能が出るようにAuroraでは性能向上が⾏われ ている –  Write heavyな環境ではOFFも検討
  57. 57. defaultパラメータの違い •  innodb_change_buffering –  Default: NONE –  変更不可 –  Secondary indexへの更新などに影響が出そうだが、1-2時間など長 時間ベンチマークを行い、change bufferに収まらない量になってくる と、Auroraの優位性が出てくる •  数十分の短いベンチマークだと多少影響を受ける可能性がある
  58. 58. 新規パラメータ •  thread_handling –  Default: multiple-connections-per-thread –  変更不可 –  multiple-connections-per-thread, no-threads, one-thread- per-connection, dynamically-loaded –  Clientからの接続を扱うAuroraのスレッドに関する設定
  59. 59. パフォーマンス指針 •  まずはデフォルトのパラメータグループを使用 –  Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できるよ うにチューニング済み •  適切なインスタンスタイプを選択することが大切 –  それでも性能が出ない場合にパラメータグループの変更を検討
  60. 60. パフォーマンス •  性能が5倍というのはどのようなケースか –  re:Invent で発表された5倍という性能はSysbenchを4インスタンス (r3.8xlarge + NW関連のkernelパラメータ調整済)からdb.r3.8xlargeの Auroraインスタンスに実行した場合の結果 •  TPC-C をdb.r3.8xlargeに実行した場合は約2.5〜5 倍の性能を観測している –  https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql
  61. 61. パフォーマンス •  FAQとパフォーマンステストのガイドライン・テスト用AMI を提供しています –  http://aws.amazon.com/rds/aurora/faqs/ の Amazon Aurora Performance Benchmarking Guide
  62. 62. パフォーマンス •  価格性能⽐5倍 –  Amazon Auroraは⾼速でSSDベースのストレージにより⾼速に動 作するが、既存のどんなクエリでも5倍⾼速に実⾏出来ることを意 味しているわけではない –  Amazon Auroraは他の製品よりも、より多くの書き込み・読み込 みクエリを同時に扱うことが出来るためデータベースの集約やス ループット向上が⾒込める –  Amazon Aurora独⾃で⾼並列なストレージへのアクセスにより保 存されているデータへのコンテンションを解決し、クエリを効率よ く処理
  63. 63. 参考 (re:Inventで発表された資料)
  64. 64. よく⾒ると •  Auroraはデッドロックがほんの少し出やすいが リトライを⾏ってもMySQLよりスループット が出る •  CPU / Memoryの利⽤率がMySQLより⾼いがス ループットが出ている –  分散ロック機構によりCPUリソースを使いきってスループット を出している
  65. 65. 何をみるのか? •  よく聞かれる質問 –  CPU利用率高いんだけど? –  メモリ利用量多いんだけど? –  Disk IOが多めなんだけど? •  見てほしいこと –  Auroraはマシンリソースを最大限利用してスループットを出す設 計です –  システムトータルでパフォーマンスが向上 –  管理コスト、障害耐性、データ保全性
  66. 66. 何をみるのか? •  AuroraはMySQL互換ですが、マシンリソース の使い⽅が根本的に違います •  Auroraが得意な場⾯・状況を理解してパフォー マンスを測定 –  マシンリソースを使い切りそうになりながらもMySQLと⽐べる とスループットやレスポンスタイムの落ち⽅が緩やか
  67. 67. Amazon Auroraへの移⾏
  68. 68. RDS for MySQLからマイグレーション •  マネージメントコンソールから数クリックでAmazon Auroraへ移⾏可能 –  RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション 可能 –  RDS for MySQLは5.6を使う必要がある
  69. 69. マイグレーション時の注意 •  RDS for MySQLとParameter Groupで設定出来る 項⽬や規定値などが異なる –  例: max_connection / innodb_buffer_pool_size / query_cache_*など •  マイグレーションに必要なディスクスペース –  スナップショットをインポートする場合、インポート前にEBSボ リュームを使⽤しデータをフォーマットする –  データをフォーマットするための追加容量が必要になる場合がある
  70. 70. マイグレーション時の注意 •  Amazon AuroraはInnoDBのみサポート –  MyISAMなどのストレージエンジンは⾮対応 •  マイグレーション時に⾃動でMyISAMからコン バートされますが、事前に⼿動でInnoDBへの 変換を⾏っていただくことがオススメです
  71. 71. マイグレーション時の注意 •  MyISAM形式のテーブルが含まれない場合 –  移⾏前のディスクで6TBまで容量を利⽤可能 •  MyISAM形式のテーブルが含まれる場合 –  マイグレーションを⾏うテーブルで3TBを超えるものが無いこ とを確認する
  72. 72. 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;
  73. 73. MySQLからレプリケーション •  RDS for MySQLやMySQL on EC2、オンプレ環 境のMySQLからAmazon Auroraにレプリケー ション可能 –  バックアップからAuroraにインポートを⾏い、レプリケーショ ンを実⾏ –  移⾏時にアプリケーションのメンテナンスを⼊れ、書き込みが なくなり、レプリケーションが追いついたタイミングでアプリ ケーションの書き込み先などをAuroraに変更
  74. 74. Data Export and Import guide •  Data Export and Import guideを公開してい ます –  https://d0.awsstatic.com/product-marketing/Aurora/ Aurora_Export_Import_Best_Practices_v1-3.pdf
  75. 75. Amazon Aurora Driver
  76. 76. Aurora Driver •  MariaDB Connector/J 1.2.0に既に含まれている –  https://mariadb.com/kb/en/mariadb/mariadb-connector-j-120- release-notes/ –  リリースノートには明確にAuroraの記述は無いがドキュメントはある •  https://mariadb.com/kb/en/mariadb/about-mariadb-connector-j/ •  https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with- mariadb-connector-j/#specifics-for-amazon-aurora –  2015.09 Amazon Linuxでrpmが提供予定 •  現在の提供機能 –  Fast failover
  77. 77. Aurora Driver
  78. 78. Amazon Auroraの使いどころ
  79. 79. クエリ同時実⾏数やテーブルサイズが⼤きい •  Amazon Auroraに移行することで、クエリスループッ トの向上などが見込まれる –  マルチコア環境でCPUを効率的に利用 –  分散ロック機構やquery cacheの改善による性能向上 •  ディスク –  データ量の増加に応じてディスク容量を気にする必要が無い –  性能に影響を及ばさずバックアップ
  80. 80. 複数のサーバにシャーディングしている •  複数の⼩さいDBを1つにまとめる –  コスト効果増⼤と管理コストの軽減 –  シャーディングをするデータベースを減らすことでアプリケー ションの設計を簡略化出来る –  障害時の影響を考慮する必要はある
  81. 81. Advanced monitoring 50+ system/OS metrics | sorted process list view | 1–60 sec granularity alarms on specific metrics | egress to Amazon CloudWatch Logs | integration with third-party tools coming soon ALARM
  82. 82. Important systems and OS metrics User System Wait IRQ Idle CPU Utilization Rx per declared ethn Tx per declared ethn Network Num processes Num interruptible Num non-interruptible Num zombie Processes Process ID Process name VSS Res Mem % consumed CPU % used CPU time Parent ID Process List MemTotal MemFree Buffers Cached SwapCached Active Inactive SwapTotal SwapFree Dirty Writeback Mapped Slab Memory TPS Blk_read Blk_wrtn read_kb read_IOs read_size write_kb write_IOs write_size avg_rw_size avg_queue_len Device IO Free capacity Used % Used File System
  83. 83. 利⽤事例 •  re:Invent 2015 Keynoteで発表
  84. 84. まとめ
  85. 85. Amazon Aurora •  クラウド時代にAmazonが再設計したRDBMS –  MySQL5.6と互換があり既存の資産を活かしやすい •  高いクエリ実行並列度・データサイズが大きい環境で性能を 発揮 –  Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮 •  高可用性・高速なフェイルオーバ・PITRを実現するための多 くのチャレンジ –  Log Structured Storage –  SOA

×