エンタープライズワークロードにおけるAmazon Auroraの活用
•
7 gostaram•2,808 visualizações
2015/12/18 Amazon RDS for Aurora セミナー in 関西での発表資料です。
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a エンタープライズワークロードにおけるAmazon Auroraの活用
Semelhante a エンタープライズワークロードにおけるAmazon Auroraの活用 (20)
Mais de Amazon Web Services Japan
Mais de Amazon Web Services Japan (20)
Último
Último (11)
エンタープライズワークロードにおけるAmazon Auroraの活用
- 1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾン ウェブ サービス ジャパン株式会社 事業開発本部 大久保 順 2015年12月18日 エンタープライズワークロードにおける Amazon Auroraの活用
- 4. 自社構築 vs. RDS Power, HVAC, net Rack & stack Server maintenance OS patches DB s/w patches Database backups Scaling High availability DB s/w installs OS installation App optimization Power, HVAC, net Rack & stack Server maintenance OS patches DB s/w patches Database backups Scaling High availability DB s/w installs OS installation App optimization Power, HVAC, net Rack & stack Server maintenance OS patches DB s/w patches Database backups Scaling High availability DB s/w installs OS installation App optimization オンプレミス On EC2 RDS お客様がご担当する作業 AWSが提供するマネージド機能
- 5. Amazon Aurora re:Invent 2014で発表されたRDSの新しいエンジン Amazonがクラウド時代にリレーショナル・データベースを作る とどうなるかを1から考え構築 • 新しい技術的チャレンジを盛り込んでいる エンタープライズグレードの可用性とOSSレベルのコストを両立
- 6. Amazon Aurora Amazon AuroraはRDSが提供するエンジンのうちの1つ • RDSでは現在、MySQL / MariaDB / PostgreSQL / Oracle / MS SQL Serverが選択可能
- 8. Amazon Auroraの特徴 MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能 ストレージが10GBから64TBまでシームレスに拡張 3AZに2つずつ、計6つのデータのコピーを保持 • S3にストリーミングバックアップを実施 VPC内に起動 • Security GroupやNACLを使用してアクセスコントロール可能 Amazon Auroraは99.99%の可用性を実現するように設計されている
- 11. Establishing our ecosystem “Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性 の心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを 加速させるために一緒に働くことを楽しみにしています。” — Roger Levy, VP Products, MariaDB
- 13. エンタープライズ顧客の要望リスト …. が出来るデータベース コンポーネント障害が発生しても動き続ける …. エンタープライズ規模で安定した性能を発揮する … 専門家部隊がいなくても運用・管理できる … 大金をはたかずともよい; ライセンスを管理しなくてよい …
- 14. Amazon Aurora: クラウド向けのエンタープライズ級データベース 私たちはエンタープライズ向けの要件から入り、クラウド向けの リレーショナルデータベースとはどうあるべきか、を再考しました …. エンタープライズ級の可用性とパフォーマンス 完全なマネージドサービスとして提供 ライセンス不要; 商用データベースの1/10のコスト
- 15. MySQL互換のリレーショナルデータベース 商用データベース並みの パフォーマンス と 可用性 オープンソースデータベース並みの 使いやすさ と コスト効果 マネージドサービスとして提供 Amazon Aurora とは?
- 16. 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
- 17. エンタープライズに最適 3箇所のデータセンターに6つの複製を保持 30秒以内でフェイルオーバー ほぼ即時に行われるクラッシュリカバリー 最大50万回/秒の読込、10万回/秒の書込性能 15個までの低遅延(10 ms)リードレプリカ 64TBまで拡張できる、DBに最適化したストレージ すぐに行えるプロビジョニングとデプロイ 自動化されたパッチとソフトウェアアップグレード バックアップとポイント・イン・タイム・リカバリー コンピュートとストレージのスケーラビリティー パフォーマンスとスケール エンタープライズ級の可用性 完全マネージドサービス
- 20. Expedia: オンライン旅行販売 成長を続けるオンライン旅行販売データに対するリア ルタイムなビジネス・インテリジェンスと分析 現行の SQL Server ベースのアーキテクチャは非常 に高価であった。また、データボリュームの増加と共 にパフォーマンスの低下が見られた。 Cassandra と Solr を組み合わせたインデックスは 大きなメモリー空間を必要とし、コストを押し上げた Auroraがもたらしたメリット： Aurora はスケーラビリティーとパフォーマンス要件 を満たし、コストもずっと低かった 平常時25,000インサート/秒 （ピーク時70,000） 平均レスポンスタイムは書込30ミリ秒、読込17ミリ秒 世界をリードするオンライン旅行業者、 70カ国で150以上の旅行関連サイト を運営
- 21. PG&E: 大手公益企業 電力関係のイベントが起きた際に突発的なトラフィック を処理することに常に課題を抱えていた データベースが落ちた時の影響が甚大; 結果的に顧 客に対するガスと電力の供給へ影響が出る Auroraがもたらしたメリット： 遅延のほとんどない（ミリ秒級）リードレプリカを複数持 つことが出来るため、電力関係のイベントが起きた際 でも突発的なトラフィックを処理し、顧客に最新の情報 をタイムリーに提供できるようになった 6ヶ所にデータを複製し、ストレージやインスタンス障害 時に自動復旧するAmazon Auroraにより、ミッション クリティカルなアプリケーションが要求する可用性と信 頼性がもたらされた 天然ガス＋電力の公益企業において米国最 大手の1社で、北部および中央カリフォルニア で1,600万の顧客と70,000平方マイルのサー ビスエリアを持つ
- 22. ISCS: 保険請求処理 Oracle と SQL Server を通常業務ならびにウェアハウ スデータ用に使用 伝統的な商用データベースのコストが最も大きな支出 となり、また維持管理に頭を悩ませていた Auroraがもたらしたメリット： 「余裕を持たせた」Auroraのデプロイ構成のコストが、 ISCSのSQL Serverの構成よりも70%安価であること が分かった Auroraの連続的なバックアップ機能により、バックアッ プ処理ウィンドウを廃止 接続数が増えた際のリニアなスケールを実現 Auroraのリードレプリカを利用したAmazon Redshiftへ の連続的なアップロード ポリシー管理、請求、ビリングソ リューションを災害・損害保険企業向 けに提供
- 23. Alfresco: エンタープライズコンテンツ管理 Alfrescoのドキュメントリポジトリを数十億ドキュメン ト級までスケール 1秒未満のレスポンス時間を要求するユーザーアプ リケーションへの対応 Auroraがもたらしたメリット： 10億ドキュメントに対し300万リクエスト/時までス ケールし、現行環境の10倍の高速化を実現 巨大なデータセンターから、コスト効果に優れた AWSと Auroraへ移行 エンタープライズコンテンツ管理とビジネスプロ セス管理の集約をリードする。金融サービス・ヘ ルスケア・公共のリーダーを含む195カ国1,800 以上の組織がAlfrescoを利用。
- 24. Earth Networks: モノのインターネット Earth Networksは25TB以上のリアルタイムデー タを毎日処理しており、増え続ける分析のニーズ とともに迅速に成長できるスケーラブルなデータ ベースを必要としていた Auroraがもたらしたメリット： Auroraのパフォーマンスとスケーラビリティー（ス ケールアップ／リードレプリカによるスケールアウ ト） が、日々増えるデータをうまく処理した SQL ServerからAuroraへの移行は難しくなく、か つ大きなコスト節約につながった 独立した10,000以上の地域レベルのセ ンサーにより、 天候状況の正確なレ ポート、地域の予測、いつ／どこでの災 害警報を人々が最も必要とする時に提 供
- 25. ThreatStack: 連続的なセキュリティ監視 脅威分析のために非常に大きく連続したデー タストリームを扱う およそ50万インサート(書込)/秒、1日の生デー タは約10TB Auroraがもたらしたメリット： Amazon Auroraを時系列データを扱うメインの データベースとして採用し、ThreatStackが必 要とするパフォーマンス要件を実現 AWS顧客に対し連続的なセキュリティ 監視を提供し、不正侵入やデータ損失、 内部の脅威から保護 .
- 26. 高可用性のためのデザイン
- 27. ストレージノードの可用性 3つのAZにまたがり6つの複製を保持 データの読み書きにクオーラムを採用し、レイテンシーを 軽減 Peer-to-peer gossipレプリケーション S3への継続的バックアップ (イレブンナインの可用性) 継続的なデータブロックの検査 継続的なノードやディスクの障害検知 クオーラムに参加するデータノードの変化の影響を受け ない AZ 1 AZ 2 AZ 3 Amazon S3
- 28. 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 障害に強く自己回復可能
- 29. トラディショナルなDB 最後のチェックポイントからのログを適用する 必要がある 一般的にチェックポイントの間隔は5分 MySQLではシングルスレッドで行われる; ディスクアクセスが多く発生する Amazon Aurora Disk readの一環として、オンデマンドでredo logの適用を行う 並列、分散、非同期で行われる 起動時に実行する必要がない Checkpointed data Redo log T0 でクラッシュが発生する と最後のチェックポイントか らのログを適用する必要が ある T0 T0 T0 でクラッシュが発生するとredo を並列で分散して非同期でログの適用を行う 高速なクラッシュリカバリ
- 30. 高速で予測可能なフェイルオーバー時間 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
- 31. 連続的なバックアップ Segment snapshot Log records Recovery point Segment 1 Segment 2 Segment 3 Time 各セグメントのスナップショットを定期的かつ並列で取得し、REDOログをAmazon S3へ転送 バックアップは連続的に行われ、パフォーマンスや可用性への影響はない リストア時は、該当するセグメントスナップショットとログストリームをストレージノードに復元 セグメントスナップショットへのログストリーム適用は並列・非同期に実行される
- 33. • 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ベンチマーク結果
- 34. テーブル数に応じたスケール 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
- 35. 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
- 36. 接続数に応じたスケール • 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
- 37. I/Oを減らす ネットワークパケットを最小限にする 結果をキャッシュしておく データベースエンジンをオフロードする DO LESS WORK 非同期で処理する レイテンシーの通り道を減らす ロックフリーなデータ構造を使う バッチ操作を同時に行う BE MORE EFFICIENT これらの結果をどう達成したか？ データベースは I/O が全て ネットワーク接続したストレージは PACKETS/SECOND が全て 高スループットの処理に コンテキストスイッチ は許されない
- 38. 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
- 39. 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順に並ぶ 適切なセグメントに分割する – 部分ごとに並ぶ ストレージノードへまとめて書き込む
- 41. アドバンスト・モニタリング 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 近日登場 ALARM
- 42. 主要なシステムとOSのメトリクスを網羅 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
- 44. TCO比較：Aurora vs. MySQL MySQL構成の1時間あたりコスト 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 インスタンス費用: $18.16 / hr ストレージ費用： $ 9.98 / hr 総費用： $28.14 / hr $2.91/hr
- 45. TCO比較：Aurora vs. MySQL Aurora構成の1時間あたりコスト 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 アイドル状態のスタンバイがない 1つの共有ストレージボリューム プロビジョンドIOPSではなく、 実際に使用したI/Oに対して課金
- 46. TCO比較：Aurora vs. MySQL 更なるコストセービング インスタンス費用： $8.40 / hr ストレージ費用： $5.32 / hr 総費用： $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 より小さなインスタンスで賄う 実際に格納したデータ量に応じた ストレージ料金