Using Amazon Aurora for Enterprise Workloads
•
12 likes•2,288 views
2015/11/10に開催したAurora東京ローンチ記念セミナーの資料です。
Using Amazon Aurora for Enterprise Workloads
- 1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Debanjan Saha, GM, Amazon Aurora Jun Okubo, Business Development Manager November 2015 Using Amazon Aurora for Enterprise Workloads Amazon Aurora 東京ローンチ記念セミナー
- 2. エンタープライズ顧客の要望リスト …. が出来るデータベース コンポーネント障害が発生しても動き続ける …. エンタープライズ規模で安定した性能を発揮する … 専門家部隊がいなくても運用・管理できる … 大金をはたかずともよい; ライセンスを管理しなくてよい …
- 3. Amazon Aurora: クラウド向けのエンタープライズ級データベース 私たちはエンタープライズ向けの要件から入り、クラウド向けの リレーショナルデータベースとはどうあるべきか、を再考しました …. エンタープライズ級の可用性とパフォーマンス 完全なマネージドサービスとして提供 ライセンス不要; 商用データベースの1/10のコスト
- 4. MySQL互換のリレーショナルデータベース 商用データベース並みの パフォーマンス と 可用性 オープンソースデータベース並みの 使いやすさ と コスト効果 マネージドサービスとして提供 Amazon Aurora とは?
- 5. Aurora at a glance AZ 1 AZ 2 AZ 3 Amazon S3 Master Read Replica Read Replica Read Replica Read Replica Massively scale-out storage distributed across 3 AZs
- 6. エンタープライズに最適 3箇所のデータセンターに6つの複製を保持 30秒以内でフェイルオーバー ほぼ即時に行われるクラッシュリカバリー 最大50万回/秒の読込、10万回/秒の書込性能 15個までの低遅延(10 ms)リードレプリカ 64TBまで拡張できる、DBに最適化したストレージ すぐに行えるプロビジョニングとデプロイ 自動化されたパッチとソフトウェアアップグレード バックアップとポイント・イン・タイム・リカバリー コンピュートとストレージのスケーラビリティー パフォーマンスとスケール エンタープライズ級の可用性 完全マネージドサービス
- 9. Expedia: オンライン旅行販売 成長を続けるオンライン旅行販売データに対するリア ルタイムなビジネス・インテリジェンスと分析 現行の SQL Server ベースのアーキテクチャは非常 に高価であった。また、データボリュームの増加と共 にパフォーマンスの低下が見られた。 Cassandra と Solr を組み合わせたインデックスは 大きなメモリー空間を必要とし、コストを押し上げた Auroraがもたらしたメリット： Aurora はスケーラビリティーとパフォーマンス要件 を満たし、コストもずっと低かった 平常時25,000インサート/秒 （ピーク時70,000） 平均レスポンスタイムは書込30ミリ秒、読込17ミリ秒 世界をリードするオンライン旅行業者、 70カ国で150以上の旅行関連サイト を運営
- 10. PG&E: 大手公益企業 電力関係のイベントが起きた際に突発的なトラフィック を処理することに常に課題を抱えていた データベースが落ちた時の影響が甚大; 結果的に顧 客に対するガスと電力の供給へ影響が出る Auroraがもたらしたメリット： 遅延のほとんどない（ミリ秒級）リードレプリカを複数持 つことが出来るため、電力関係のイベントが起きた際 でも突発的なトラフィックを処理し、顧客に最新の情報 をタイムリーに提供できるようになった 6ヶ所にデータを複製し、ストレージやインスタンス障害 時に自動復旧するAmazon Auroraにより、ミッション クリティカルなアプリケーションが要求する可用性と信 頼性がもたらされた 天然ガス＋電力の公益企業において米国最 大手の1社で、北部および中央カリフォルニア で1,600万の顧客と70,000平方マイルのサー ビスエリアを持つ
- 11. ISCS: 保険請求処理 Oracle と SQL Server を通常業務ならびにウェアハウ スデータ用に使用 伝統的な商用データベースのコストが最も大きな支出 となり、また維持管理に頭を悩ませていた Auroraがもたらしたメリット： 「余裕を持たせた」Auroraのデプロイ構成のコストが、 ISCSのSQL Serverの構成よりも70%安価であること が分かった Auroraの連続的なバックアップ機能により、バックアッ プ処理ウィンドウを廃止 接続数が増えた際のリニアなスケールを実現 Auroraのリードレプリカを利用したAmazon Redshiftへ の連続的なアップロード ポリシー管理、請求、ビリングソ リューションを災害・損害保険企業向 けに提供
- 12. Alfresco: エンタープライズコンテンツ管理 Alfrescoのドキュメントリポジトリを数十億ドキュメン ト級までスケール 1秒未満のレスポンス時間を要求するユーザーアプ リケーションへの対応 Auroraがもたらしたメリット： 10億ドキュメントに対し300万リクエスト/時までス ケールし、現行環境の10倍の高速化を実現 巨大なデータセンターから、コスト効果に優れた AWSと Auroraへ移行 エンタープライズコンテンツ管理とビジネスプロ セス管理の集約をリードする。金融サービス・ヘ ルスケア・公共のリーダーを含む195カ国1,800 以上の組織がAlfrescoを利用。
- 13. Earth Networks: モノのインターネット Earth Networksは25TB以上のリアルタイムでー たを毎日処理しており、増え続ける分析のニーズ とともに迅速に成長できるスケーラブルなデータ ベースを必要としていた Auroraがもたらしたメリット： Auroraのパフォーマンスとスケーラビリティー（ス ケールアップ／リードレプリカによるスケールアウ ト） が、日々増えるデータをうまく処理した SQL ServerからAuroraへの移行は難しくなく、か つ大きなコスト節約につながった 独立した10,000以上の地域レベルのセ ンサーにより、 天候状況の正確なレ ポート、地域の予測、いつ／どこでの災 害警報を人々が最も必要とする時に提 供
- 14. ThreatStack: 連続的なセキュリティ監視 脅威分析のために非常に大きく連続したデー タストリームを扱う およそ50万インサート(書込)/秒、1日の生デー タは約10TB Auroraがもたらしたメリット： Amazon Auroraを時系列データを扱うメインの データベースとして採用し、ThreatStackが必 要とするパフォーマンス要件を実現 AWS顧客に対し連続的なセキュリティ 監視を提供し、不正侵入やデータ損失、 内部の脅威から保護 .
- 15. 高可用性のためのデザイン
- 16. ストレージノードの可用性 3つのAZにまたがり6つの複製を保持 データの読み書きにクオーラムを採用し、レイテンシーを 軽減 Peer-to-peer gossipレプリケーション S3への継続的バックアップ (イレブンナインの可用性) 継続的なデータブロックの検査 継続的なノードやディスクの障害検知 クオーラムに参加するデータノードの変化の影響を受け ない AZ 1 AZ 2 AZ 3 Amazon S3
- 17. 2つのストレージノード障害、あるいはAZ障害が起きても読み書きに影響がない 3つのストレージノード障害があっても読み込みは可能 自動的に障害を検出し、複製と修復を実行 SQL Transaction AZ 1 AZ 2 AZ 3 Caching SQL Transaction AZ 1 AZ 2 AZ 3 Caching Read and write availabilityRead availability 障害に強く自己回復可能
- 18. トラディショナルなDB 最後のチェックポイントからのログを適用する 必要がある 一般的にチェックポイントの間隔は5分 MySQLではシングルスレッドで行われる; ディスクアクセスが多く発生する Amazon Aurora Disk readの一環として、オンデマンドでredo logの適用を行う 並列、分散、非同期で行われる 起動時に実行する必要がない Checkpointed data Redo log T0 でクラッシュが発生する と最後のチェックポイントか らのログを適用する必要が ある T0 T0 T0 でクラッシュが発生するとredo を並列で分散して非同期でログの適用を行う 高速なクラッシュリカバリ
- 19. 高速で予測可能なフェイルオーバー時間 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 - 3 0 s e c 5 - 2 0 s e c
- 20. 連続的なバックアップ Segment snapshot Log records Recovery point Segment 1 Segment 2 Segment 3 Time 各セグメントのスナップショットを定期的かつ並列で取得し、REDOログをAmazon S3へ転送 バックアップは連続的に行われ、パフォーマンスや可用性への影響はない リストア時は、該当するセグメントスナップショットとログストリームをストレージノードに復元 セグメントスナップショットへのログストリーム適用は並列・非同期に実行される
- 22. • 4 client machines with 1,000 threads each WRITE PERFORMANCE READ PERFORMANCE • Single client with 1,000 threads • MySQL SysBench • R3.8XL with 32 cores and 244 GB RAM SQLベンチマーク結果
- 23. テーブル数に応じたスケール Tables Amazon Aurora MySQL I2.8XL local SSD MySQL I2.8XL RAM disk RDS MySQL 30K IOPS (single AZ) 10 60,000 18,000 22,000 25,000 100 66,000 19,000 24,000 23,000 1,000 64,000 7,000 18,000 8,000 10,000 54,000 4,000 8,000 5,000 • Write-only workload • 1,000 connections • Query cache (default on for Amazon Aurora, off for MySQL) 11x U P TO FA STER
- 24. DBサイズに応じたスケール 67x U P TO FA STER DB Size Amazon Aurora RDS MySQL 30K IOPS (single AZ) 1GB 107,000 8,400 10GB 107,000 2,400 100GB 101,000 1,500
- 25. 接続数に応じたスケール • OLTP Workload • Variable connection count • 250 tables • Query cache (default on for Amazon Aurora, off for MySQL) Connections Amazon Aurora RDS MySQL 30K IOPS (single AZ) 50 40,000 10,000 500 71,000 21,000 5,000 110,000 13,000 8x U P TO FA STER
- 26. I/Oを減らす ネットワークパケットを最小限にする 結果をキャッシュしておく データベースエンジンをオフロードする DO LESS WORK 非同期で処理する レイテンシーの通り道を減らす ロックフリーなデータ構造を使う バッチ操作を同時に行う BE MORE EFFICIENT これらの結果をどう達成したか？ データベースは I/O が全て ネットワーク接続したストレージは PACKETS/SECOND が全て 高スループットの処理に コンテキストスイッチ は許されない
- 27. RDS MySQLのI/Oトラフィック BINLOG DATA DOUBLE-WRITELOG FRM FILES T Y P E O F W R IT E MYSQL WITH STANDBY EBSに書き込み – EBSがミラーへ複製し、両方終了後ack DRBD経由でスタンバイインスタンスへ書き込みを伝播 スタンバイインスタンス側のEBSに書き込み IO FLOW ステップ1, 3, 5はシーケンシャルかつ同期 それによりレイテンシーもパフォーマンスのゆらぎも増加 各ユーザー操作には様々な書き込みタイプがある 書き込み破損を避けるためにデータブロックを2回書く必要性 OBSERVATIONS 780K トランザクション 7,388K I/Os (ミラー, スタンバイを除く) 1トランザクション当たり平均9.5 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
- 28. AuroraのI/Oトラフィック(データベース) 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 IT E 30 minute SysBench write-only workload, 100 GB data set IO FLOW REDOログレコードのみ書き込む; 全てのステップは非同期 データブロックは書かない(チェックポイント, キャッシュ置換時) 6倍のログ書き込みだが, 1/9のネットワークトラフィック ネットワークとストレージのレイテンシー異常時の耐性 OBSERVATIONS 27,378K トランザクション 35X MORE 950K I/Os (includes 6X amplification) 7.7X LESS 1トランザクション当たり平均0.035 I/Os 270X LESS PERFORMANCE REDOログレコードをまとめる – 完全にLSN順に並ぶ 適切なセグメントに分割する – 部分ごとに並ぶ ストレージノードへまとめて書き込む
- 29. アクティブなスレッドに複数のコネクションを収容 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 適応型スレッドプール
- 30. 非同期グループコミット 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のポイントまで
- 32. Advanced monitoring 50+ system/OS metrics | sorted process list view | 1-60 sec granularity alarms on specific metrics | egress to CloudWatch Logs | integration with 3rd-party tools coming soon ALARM
- 33. 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
- 35. Cost of ownership: Aurora vs. MySQL MySQL configuration hourly cost Primary r3.8XL Standby r3.8XL Replica r3.8XL Replica r3.8XL Storage 6 TB / 10 K PIOP Storage 6 TB / 10 K PIOP Storage 6 TB / 5 K PIOP Storage 6 TB / 5 K PIOP $4.54/hr $4.54/hr $4.54/hr $4.54/hr $2.91/hr $2.08/hr $2.08/hr Instance cost: $18.16 / hr Storage cost: $ 9.98 / hr Total cost: $28.14 / hr $2.91/hr
- 36. Cost of ownership: Aurora vs. MySQL Aurora configuration hourly cost Instance cost: $16.80 / hr Storage cost: $ 5.32 / hr Total cost: $22.12 / hr Primary r3.8XL Replica r3.8XL Replica R3.8XL Storage / 6 TB $5.60 / hr $5.60 / hr $5.60 / hr $5.32 / hr 21.4% Savings No idle standby instance Single shared storage volume No POIPs – pay for use I/O Reduction in overall IOP
- 37. Cost of ownership: Aurora vs. MySQL Further opportunity for saving Instance cost: $8.40 / hr Storage cost: $5.32 / hr Total cost: $13.72/ hr 51.3% Savings Primary r3.8XL Replica r3.8XL Replica r3.8XL Storage / 6TB $2.80 / hr $2.80 / hr $2.80 / hr $5.32 / hr r3.4XL r3.4XL r3.4XL Use smaller instance size Pay-as-you-go storage