[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャパン株式会社 星野豊

Transcript

• 1. Amazon Aurora Deep Dive Yutaka Hoshino Amazon Data Services Japan K.K.
• 2. Amazon Auroraは現在Preview中のため、頻繁に更新 が行われています 今回お話する内容は2015/6/12現在の情報となっている 点ご注意下さい
• 3. 自己紹介 • 星野 豊 (ほしの ゆたか) – @con_mame – facebook.com/conmame – ソリューションアーキテクト • 経歴 – 全てオンプレ環境のインフラエンジニア – 全てAWS環境のインフラエンジニア • 担当 – Webサービス / game / Video・Live Streamingなどのメディア系のお客様
• 4. Amazon Aurora
• 5. データベース管理を簡単に • データベースを数分で作成可能 • 自動でパッチの適用 • 数クリックするだけでスケールアウト可能 • S3への継続的なバックアップ • 障害の自動検知と自動フェールオーバ Amazon RDS
• 6. Amazon Aurora • re:Invent 2014で発表されたRDSの新しいエンジ ン • Amazonがクラウド時代にリレーショナル・データ ベースを作るとどうなるかを1から考え構築 – 新しい技術的チャレンジを盛り込んでいる • エンタープライズグレードの可用性とOSSレベルの コストを両立
• 7. Amazon Aurora • Amazon AuroraはRDSが提供するエンジンのうち の1つ – RDSでは現在、MySQL / PostgreSQL / Oracle / MS SQL Server が選択可能
• 8. Amazon Aurora • 現在はLimited Preview中 • Virginia / Oregon / Irelandリージョン • 2015/5/20 よりpreviewがプロダクション環境へ移行 – Beta環境はクローズ – Beta環境のSnapshotから起動可能 – 活発に開発・デプロイが行われている
• 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. Amazon Auroraの特徴 クエリ性能の向上 コストパフォーマンスが良い 高可用性・高耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
• 11. Amazon Auroraの特徴 • MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行 可能 • ストレージが10GBから64TBまでシームレスに拡張 • 3AZに2つずつ、計6つのデータのコピーを保持 – S3にストリーミングバックアップを実施 • VPC内に起動 – Security GroupやNACLを使用してアクセスコントロール可能 • Amazon Auroraは99.99%の可用性を実現するように設計されている
• 12. なぜAmazonがデータベースを再考したか
• 13. 現在のモノリシックなDB 複数の機能レイヤーが1 つのアプリケーションに なっている SQL Transactions Caching Logging
• 14. 現在のモノリシックなデータベース スケールアウトする 場合は、このセット を増やしていく必要 がある SQL Transactions Caching Logging SQL Transactions Caching Logging Application
• 15. コスト・可用性・柔軟性の面で問題
• 16. リレーショナルデータベースをもう一度考える • 今、データベースを再度実装するならどうするか？ – 少なくとも1970年代の方法で実装はしない – AWSサービスを活かすことができ、スケールアウトが簡単で、セルフ ヒーリングが出来るようなデータベースを作りたいと考えた
• 17. クラウド時代に適したリレーショナルデータベース • ハイエンドデータベースの様なスピード と 可用性 • オープンソースデータベースのシンプルさとコスト効果の高さ • MySQLと互換性を保つ • 利用した分だけお支払いいただく課金モデル • AWSサービスと簡単に連携 マネージド・サービスとしてご提供
• 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. アーキテクチャ
• 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. キャッシュレイヤの分離 • キャッシュをデータベースプロセス外 に移動させた • データベースプロセスのリスタートが 発生してもキャッシュが残った状態を 維持可能 • サービスにすぐデータベースを戻す ことが出来る SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching キャッシュプロセスをDBプロセス外におくことで DBプロセスの再起動でもキャッシュが残る
• 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. Auroraのストレージ • Amazon Auroraは6本全てのディスクへの書き込みを 待たずに、少なくとも4つのディスクに書き込みが完了す るとすぐに次の処理を実行 • ホットスポットの影響を取り除き、非常に高い並列度を 実現 • ストレージはSSDベースのディスクに10GBずつのブ ロック内に分散して書き込まれる
• 24. Auroraのストレージの特徴 • リードレプリカもマスタと同じストレージを参照 • Log Structured Storage • 継続的なS3へ増分バックアップ – パフォーマンスへの影響なし • 64TBまで自動でストレージがシームレスにスケールアップ – パフォーマンスや可用性に影響無し・利用開始時のプロビジョニング不要 • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化
• 25. Log Structured Storage • 追記型のストレージ・システム – ログの様に常に末尾にデータを追加していくだけ – データが書き込まれているブロックを上書いたりはしない – GCによりデータを効率的に格納する • シーケンシャルに読み出すことが出来る • 常に最新のデータが末尾にある • これらの特徴によりS3への継続バックアップや高速なリカバリ、書き込み性能 の向上を実現 空きスペース data data 先頭 data data data 新規データは末尾に追記される ↓
• 26. ディスク障害検知と修復 • 2つのコピーに障害が起こっても、読み書きに影響は無い • 3つのコピーに障害が発生しても読み込みは可能 • 自動検知、修復 SQL Transaction AZ 1 AZ 2 AZ 3 Caching SQL Transactio n AZ 1 AZ 2 AZ 3 Caching 読み書き可能読み込み可能
• 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. レプリケーション ページキャッシュ パージ 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. レプリケーション • Amazon Auroraは、15台のリードレプリカを作成可 能 – リードレプリカはマスタサーバとストレージを共有しており、低負荷で 粒度の高いほぼ同期型のレプリケーションを行う – 最大100ミリ秒オーダーの遅延でレプリケーションされる – RDS for MySQLではリードレプリカは5つまで (孫リードレプリカを入 れて30)
• 30. セキュリティ • データの暗号化 – AES-256 (ハードウエア支援) – ディスクとAmazon S3に置かれている全ブロックを暗号化 – AWS KMSを利用したキー管理 • SSLを利用したデータ通信の保護 • 標準でAmazon VPCを使ったネットワークの分離 • ノードへ直接アクセスは不可能 • 業界標準のセキュリティとデータ保護の認証をサ ポート Storage SQL Transactions Caching Amazon S3 Application
• 31. DBクラスタ • Amazon AuroraはDBクラスタという概念を持っている – マスタ (Writer)とリードレプリカ(Reader)をひとまとめにしたもの – Parameter GroupやMaintenance WindowもDBクラスタと各ノードそろ ぞれに存在する • フェイルオーバが発生しても常にマスタを参照するエン ドポイントがクラスタ毎に1つ存在する – アプリケーションからのWriteクエリは常にこのエンドポイントを参照する ように設定
• 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. 新しいメトリクス画面 • Throughput – Select – Commit – DML/DDL • Latency – Select – Commit – DML/DDL • Cache Hit Ratio – Buffer Cache – Result Set • Deadlocks • Login Failures • Blocked Transactions
• 34. フェイルオーバとリカバリ
• 35. フェイルオーバ と リプレース • リードレプリカが存在する場合は1分程でフェイルオーバ可能 – RDS for MySQLよりも高速にフェイルオーバ可能 – リードレプリカが存在しない場合は10分程 • 優先的にフェイルオーバさせるノードを1つ指定可能 – Multi-AZ配置として別AZで起動する – RDS for MySQLと違いリードアクセス可能 • ノードリプレース時に新Auroraノードを起動するAZを指定可能 – 指定したAZ – 問題のないAZの中から自動で選択
• 36. クラスタエンドポイント • WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエン ドポイントが存在する • 各Auroraノードは個別にエンドポイントを持っている
• 37. クラスタエンドポイント 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
• 38. クラスタエンドポイント • フェイルオーバが発 生すると、Aurora ノードの昇格が行わ れ、クラスタエンド ポイントの指し先が 変わる Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンド ポイント Write
• 39. 高速なデータ修復 既存のデータベース • 最後のチェックポイントからログを 適用していく • MySQLではシングルスレッドなた め適用完了までの時間が増加 Amazon Aurora • Disk readの一環として、オンデマ ンドでredo logの適用を行う • 並列、分散、非同期で行われる Checkpointed Data Redo Log T0 でクラッシュが発生すると 最後のチェックポイントからの ログを適用する必要がある T0 T0 T0 でクラッシュが発生するとredo を並列で分散して非同期でログの適用を行う
• 40. Streaming snapshotとPITR • Amazon Auroraでは各セグメント毎にAmazon S3へ継 続的に増分バックアップを取得している – Backup retention periodでバックアップを残す期間を指定可能 • Amazon Auroraが使用しているディスクの仕組みによ りパフォーマンスへ影響を与えない • PITRで5分前からBackup Retention Periodまでの任 意の位置に秒単位で復元可能
• 41. 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 ]; • 他にも – ディスク障害をシュミレート – ディスク障害(遅延)をシュミレート – ネットワーク障害をシュミレート
• 42. パフォーマンス
• 43. Auroraのパフォーマンスを引き出すために • クエリ並列度が高い、データサイズが大きいケース で効果を発揮 • ロック機構やQuery cacheなどに手を入れて性能向 上を行っている – write heavyな環境ではoffをおすすめ – CPUを効率的に利用する改善により、CPU利用率がMySQLと比較 して高くなるが、性能が落ちにくくなっている
• 44. パフォーマンス測定 Availability Zone A VPC subnet VPC subnet Aurora Writer • 複数のインスタンスから同時に負荷 をかけ並列度を上げる – NWの影響を抑えるために同一リー ジョンで行う • 単一のインスタンスからだけでは、イ ンスタンス毎のNW帯域の制限に達 する可能性がある • 高負荷環境でもスループット低下を 抑える改善が入っているためCPU/メ モリ利用率がRDS for MySQLと比 較して高くなるケースがある
• 45. パフォーマンス • 性能が5倍というのはどのようなケースか – 性能⾯は最⼤5倍 – re:Invent で発表された5倍という性能はSysbenchを4インスタンスか らr3.8xlargeのAuroraインスタンスに実行した場合の結果 • TPC-C をr3.8xlargeに実行した場合は約2.5倍の 性能を観測している
• 46. Amazon Auroraへの移行
• 47. RDS for MySQLからマイグレーション • マネージメントコンソールから数クリックでAmazon Auroraへ 移行可能 – RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション可能 – RDS for MySQLは5.6を使う必要がある
• 48. マイグレーション時の注意 • RDS for MySQLとParameter Groupで設定出来る 項目や規定値などが異なる – 例: max_connection / innodb_buffer_pool_size / query_cache_* など • マイグレーションに必要なディスクスペース – スナップショットをインポートする場合、インポート前にEBSボリューム を使用しデータをフォーマットする – データをフォーマットするための追加容量が必要になる場合がある
• 49. マイグレーション時の注意 • MyISAM形式のテーブルが含まれない場合 – 移行前のディスクで3TBまで容量を利用可能 • MyISAM形式のテーブルが含まれる場合 – マイグレーションを行うテーブルで1.5TBを超えるものが無いことを確 認する
• 50. マイグレーション時の注意 • Amazon AuroraはInnoDBのみサポート – MyISAMなどのストレージエンジンは非対応
• 51. MySQLからレプリケーション • MySQL5.6からAmazon Auroraへレプリケーションを行うこ とが可能 – Amazon AuroraからMySQLへは現状未対応 • 専用の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;
• 52. MySQLからレプリケーション • RDS for MySQLやMySQL on EC2、オンプレ環境 のMySQLからAmazon Auroraにレプリケーション 可能 – バックアップからAuroraにインポートを行い、レプリケーションを実行 – 移行時にアプリケーションのメンテナンスを入れ、書き込みがなくなり、 レプリケーションが追いついたタイミングでアプリケーションの書き込 み先などをAuroraに変更
• 53. Amazon Auroraの使いどころ
• 54. クエリ同時実行数やテーブルサイズが大きい • Amazon Auroraに移行することで、クエリスルー プットの向上などが見込まれる – マルチコア環境でCPUを効率的に利用 – 分散ロック機構やquery cacheの改善による性能向上 • ディスク – データ量の増加に応じてディスク容量を気にする必要が無い – 性能に影響を及ばさずバックアップ
• 55. 複数のサーバにシャーディングしている • 複数の小さいDBを1つにまとめる – コスト効果増大と管理コストの軽減 – シャーディングををするデータベースを減らすことでアプリケーション の設計を簡略化出来る – 障害時の影響を考慮する必要はある
• 56. まとめ
• 57. Amazon Aurora • クラウド時代にAmazonが再設計したRDBMS – MySQL5.6と互換があり既存の資産を活かしやすい • 高いクエリ実行並列度・データサイズが大きい環境で性 能を発揮 • 高可用性・高速なフェイルオーバ・PITRを実現するため の多くのチャレンジ – Log Structured Storage – SOA