日本のお客様におけるAmazon Auroraへの移行・検証事例と技術ポイント

日本のお客様におけるAmazon Auroraへの移行・検証事例と技術ポイント

1. 1. ⽇日本のお客様におけるAmazon  Aurora への移⾏行行・検証事例例と技術ポイント Amazon  Web  Services  Japan  K.K. Yutaka  Hoshino
2. 2. Amazon  Aurora
3. 3. 2015/7/28  GAリリース Virginia  /  Oregon  /  Ireland
4. 4. 2015/10/7  Tokyoリージョンリリース !
5. 5. Amazon  Auroraローンチイベント @東京
6. 6. リレーショナルデータベースをもう⼀一度度考える • 今、データベースを再度度実装するならどうする か？ – 少なくとも1970年年代の⽅方法で実装はしない – AWSサービスを活かすことができ、スケールアウトが簡単で、 セルフヒーリングが出来るようなデータベースを作りたいと考 えた
7. 7. Amazon  Auroraの特徴 クエリ性能の向上 コストパフォーマンスが良良い ⾼高可⽤用性・⾼高耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
8. 8. Amazon Auroraの特徴 • MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能 • ストレージが10GBから64TBまでシームレスに拡張 • 3AZに2つずつ、計6つのデータのコピーを保持 – S3にストリーミングバックアップを実施 • VPC内に起動 – Security  GroupやNACLを使⽤用してアクセスコントロール可能 • Amazon  Auroraは99.99%の可⽤用性を実現するように設計されている http://bit.ly/1LXB7Jq
9. 9. クラウド時代に適したリレーショナルデータベース • ハイエンドデータベースの様なスピード と 可⽤用性 • オープンソースデータベースのシンプルさとコスト効果の⾼高さ • MySQLと互換性を保つ • 利利⽤用した分だけお⽀支払いいただく課⾦金金モデル • AWSサービスと簡単に連携 マネージド・サービスとしてご提供
10. 10. Establishing  our  ecosystem “Amazon  AuroraがMySQL互換であることは素晴らしいことです。MariaDB connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise  の MariaDB MaxScaleドライバとコネクタを使ってAurora,  MariaDB,  そしてMySQLを互換性 の⼼心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを 加速させるために⼀一緒に働くことを楽しみにしています。” ̶— Roger  Levy,  VP  Products,  MariaDB
11. 11. キャッシュレイヤの分離離 • キャッシュをデータベースプロセス外に 移動させた • データベースプロセスのリスタート が発⽣生してもキャッシュが残った状 態を維持可能 • サービスにすぐデータベースを戻す ことが出来る • ⾼高速なクラッシュリカバリ +   survivable  cache  =  DB障害から⾼高 速に復復帰可能 SQL Transactions Caching SQL Transactions Caching SQL Transactions Caching キャッシュプロセスをDBプロセス外におくことで DBプロセスの再起動でもキャッシュが残る
12. 12. Auroraのストレージの特徴 • リードレプリカもマスタと同じストレージを参照 • Log  Structured  Storage • 継続的なS3へ増分バックアップ – パフォーマンスへの影響なし • 64TBまで⾃自動でストレージがシームレスにスケールアップ – パフォーマンスや可⽤用性に影響無し・利利⽤用開始時のプロビジョニング不不要 • ⾃自動で再ストライピング、ミラー修復復、ホットスポット管理理、 暗号化
13. 13. 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
14. 14. ディスク障害検知と修復復 • 2つのコピーに障害が起こっても、読み書きに影響は無い • 3つのコピーに障害が発⽣生しても読み込みは可能 • ⾃自動検知、修復復 SQL Transaction AZ  1 AZ  2 AZ  3 Caching SQL Transactio n AZ  1 AZ  2 AZ  3 Caching 読み書き可能読み込み可能
15. 15. レプリケーション 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 書き込みの種類
16. 16. レプリケーション 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
17. 17. 高速なデータ修復 既存のデータベース • 最後のチェックポイントからログを 適用していく • MySQLではシングルスレッドなため 適用完了までの時間が増加 Amazon  Aurora • Disk  readの⼀一環として、オンデ マンドでredo  logの適⽤用を⾏行行う • 並列列、分散、⾮非同期で⾏行行われる Checkpointed Data Redo Log T0  でクラッシュが発⽣生すると 最後のチェックポイントからの ログを適⽤用する必要がある T0 T0 T0  でクラッシュが発⽣生するとredo を並列列で分散して⾮非同期でログの適⽤用を⾏行行う
18. 18. Streaming  snapshotとPITR • Amazon  Auroraでは各セグメント毎にAmazon  S3 へ継続的に増分バックアップを取得している – Backup  retention  periodでバックアップを残す期間を指定可能 • Amazon  Auroraが使⽤用しているディスクの仕組み によりパフォーマンスへ影響を与えない • PITRで5分前からBackup  Retention  Periodまでの 任意の位置に秒単位で復復元可能
19. 19. クラスタエンドポイント 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
20. 20. 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  ]; • 他にも – ディスク障害をシミュレート – ディスクコンジェスションをシミュレート
21. 21. 過去数ヶ⽉月で改善したこと 書き込みバッチサイズのチューニング read/write  I/O要求送信の⾮非同期化 パージスレッドのパフォーマンス バルクインサートのパフォーマンス バッチ操作 フェイルオーバー時間の短縮 mallocの削減 システムコールの削減 Undoスロットのキャッシュパターン 協調したログ適⽤用 その他 binlogと分散トランザクション ロックの圧縮 先読み(read-‐‑‒ahead) 顧客フィードバック ホットな⾏行行競合 ディクショナリ統計 ⼩小さなトランザクションのコードパス クエリーキャッシュのread/write競合 ディクショナリシステムのmutex ロック競合
22. 22. Amazon  Aurora利利⽤用事例例
23. 23. 国外利利⽤用事例例 • re:Invent 2015  Keynoteで発表
24. 24. Amazon  Auroraへの移⾏行行事例例 • 既に⽇日本でも多くのシステムがAmazon  Aurora へ移⾏行行・検証が進んでいます – エンタープライズシステム・⼤大規模webサービス・スタート アップ・ソーシャルゲーム • Grani様 /  dwango様 /  毎⽇日新聞様の事例例を今 回お話します
25. 25. Grani様 移⾏行行事例例 http://bit.ly/1Qaq6e9
26. 26. Environment Before RDS for MySQL MultiAZ + Read Replica r3.4xlarge After Amazon Aurora 2 node (1 writer / 1 reader) r3.4xlarge
27. 27. Measure  Response  Time New Relic Application, Database, Redis, External の監視、通知 > データベース処理の所要時間が一目瞭然 BigQuery アプリケーションが発行したクエリを全て計測 > 同一クエリのAurora による変化を調査可能
28. 28. Before  :  RDS  for  MySQL Total Database Response : 15 ～ 22 ms (時間帯によって前後)
29. 29. After  :  Amazon  Aurora Total Database Response : 5.5 ms
30. 30. Aurora  3x  faster  than  MySQL  (Total)
31. 31. Query  Average  duration
32. 32. Select  :  1x  about  same
33. 33. Update  :  5x+  faster
34. 34. Insert  :  2x+  faster
35. 35. Delete  :  0.8x  slower
36. 36. Amazon  Auroraの性能改善:  MultiAZ RDS  for  MySQL  w/ MultiAZ 同期待ち遅延の解消 MultiAZ のスタンバイ側とAZ間の同期待ち時間がAuroraで改善
37. 37. Amazon  Auroraの性能改善:  Commit ⾮非同期グループコミットの採⽤用 コミットキューを⾮非同期に書き込み 4  /  6  のストレージノードACK応答で成功判定
38. 38. Amazon  Auroraの性能改善:  その他 スレッドプールの改善、ロックハンドリングの改善 多くの要素が改善されて、特にUPDATE   /  INSERT  に⼤大きく寄与している
39. 39. Amazon  Auroraへの移⾏行行 • Amazon  Aurora  DB  クラスターへのデータの 移⾏行行 – http://docs.aws.amazon.com/ja_̲jp/AmazonRDS/latest/U serGuide/Aurora.Migrate.html • Amazon  Aurora  とのレプリケーション – http://docs.aws.amazon.com/ja_̲jp/AmazonRDS/latest/U serGuide/Aurora.Replication.html
40. 40. Amazon  Auroraによるコスト削減効果 性能向上によるDB  統合でノード削減も期待できる Grani様の場合、DB統合も⾏行行い 年年間 2,200万円超 のコスト削減効果 RDS (db.r3.4xlarge / gp2 / OnDemand) Hourly Daily Yearly RDS for MySQL(MultiAZ + 1 ReadReplica) $4.54 + $2.27 = $6.81 $163.44 $59,655.60 Aurora (+ 1 Replica) $2.8 * 2 = $5.6 $134.40 $49,056.00 削減効果 ▲$1.21 ▲$29.04 ▲$10599.6
41. 41. 適⽤用プロジェクト • LDR – 国産RSSリーダー(Livedoor開発→Lineへ移⾏行行→Dwangoに譲受) – 3社に渡り約9年年間続いたサービス • その時々での負荷軽減策が実装されている • アプリケーションレイヤーで⽔水平分割を実装など • コードベースは古く、特定DC内で動くことを前提としたコードなど » プロセスに対応するソースコードが既に削除されていたり » アクセス先IPのサーバーが既に存在しなかったり • ⻑⾧長い歴史があるだけに、⼤大量量の記事情報がMySQL 上に存在
42. 42. LDR構成
43. 43. 適⽤用プロジェクト • LDR – 国産RSSリーダー(Livedoor開発→Lineへ移⾏行行→Dwangoに譲受) – 3社に渡り約9年年間続いたサービス • その時々での負荷軽減策が実装されている • アプリケーションレイヤーで⽔水平分割を実装など • コードベースは古く、特定DC内で動くことを前提としたコードなど » プロセスに対応するソースコードが既に削除されていたり » アクセス先IPのサーバーが既に存在しなかったり • ⻑⾧長い歴史があるだけに、⼤大量量の記事情報がMySQL上に存在 その数 15台 約10TB
44. 44. Aurora導⼊入検討での観点 • MySQLとの互換性 • ディスク使⽤用特性 • パフォーマンス
45. 45. MySQLとの互換性 • 古いコードベースということもあり、移⾏行行する際に安⼼心感が あるということは強いメリット – 実環境のデータとコードで検証し正常動作が確認できた • 運⽤用上必要な設定値がそのまま流流⽤用できる – RDSコンソール上のParameter  Groupに設定という形 – max_̲connections、wait_̲timeoutなど • 馴染んだ⼿手順でのデータ移⾏行行 – mysqldumpとreplicationでデータ同期できる – ダウンタイムを最⼩小限にする移⾏行行⽅方法が確⽴立立されている – https://docs.aws.amazon.com/ja_̲jp/AmazonRDS/latest/UserGuide/Aur ora.Replication.html
46. 46. ディスク使⽤用特性 • ディスク使⽤用効率率率や運⽤用⾯面で現時点ではマイナスポ イントもある – レコード削除しても⼀一旦増えた使⽤用領領域はシュリンクされない – Compressed  row  formatをサポートしていない • ⼀一⽅方で空き領領域の再利利⽤用は効率率率よく⾏行行われている • 各スキーマの“DATA_̲FREE  /  (DATA_̲LENGTH  +  INDEX_̲LENGTH)” の平均値をとったものを⽐比較
47. 47. パフォーマンス DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance DB on Instance • 5系統の記事DBをアプリケー ションレイヤーで⽔水平分割 • Auroraは「最⼤大 5  倍のス ループットを提供」とのこと • １系統のAuroraに集約して もいけるはず！ Aurora
48. 48. パフォーマンス • 最⼤大並列列数時でも実環境でのピーク時クエリを⼗十分捌くこと ができるパフォーマンスが確認できた • また数TBのデータセットにてクローリングした情報を追加し ながらの数週間の検証でも⽬目⽴立立ったパフォーマンス劣劣化⾒見見ら れない – RDS  MySQLでは6TBがEBSの限界、EC2ではLVM等がTBオーダーのディスク 構築に必要 – 最⼤大64TBまでシームレスにサポートされる点の安⼼心感 • 空き容量量確保バッチ実⾏行行時 CloudWatch上でCPU利利⽤用率率率が 100%に張り付く現象がみられた – サービス側クエリ応答時間では⼤大きな影響は⾒見見られない
49. 49. 最新の移⾏行行事例例 毎⽇日新聞社 様
50. 50. • 12/6からAWSにフルマイ グレーション • コンテンツを格納してい るデータベースは全て Amazon  Aurora • 当初RDS  MySQLで検討し ていたが⾼高速なフェイル オーバー、障害耐性⾯面、 MySQLより低コストとい う理理由でAmazon  Aurora を採⽤用 (本番移⾏行行2週間前 に決断・アプリケーショ ンの変更更は⼀一切切なし)
51. 51. まとめ
52. 52. Amazon  Aurora • クラウド時代にAmazonが再設計したRDBMS – MySQL5.6と互換があり既存の資産を活かしやすい • 高いクエリ実行並列度・データサイズが大きい環境で性能を 発揮 – Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮 • 高可用性・高速なフェイルオーバ・PITRを実現するための多 くのチャレンジ – Log StructuredStorage – SOA
53. 53. Amazon  Aurora • MySQL5.6と互換により過去資産を活かせる – データの移行が容易 – レプリケーションによりサービス停止時間を最小限に移行可能 • データベースサーバを集約することで管理コストを軽減 – アプリケーションやミドルウェアの設定を簡易化 – アプリケーションコードに注力できる • データの堅牢性や高速なリカバリにより障害時の復帰 時間を高速化出来、データロストの可能性も軽減可能