11/10 Amazon RDS for Aurora 東京ローンチ記念セミナーに行ってきました
タイトルの通り、
「Amazon RDS for Aurora 東京ローンチ記念セミナー」
に参加してまいりました。
AmazonWebServicesの皆さまはAuroraTシャツ着てました。かっくいー。
さて、とてもタメになったので、講演内容を速報したいと思います。
Auroraとは
ステキなまとめ資料があったのでそのままシェア。
(けして書くのがめんどくさかったわけではありません。キリ)
以下、AmazonWebService安田さんからのトピックです。
- TalendがAurora対応したとのこと!
- DataSpiderもAurora対応したとのこと!
- SVFクラウドもAuroraを採用しているとのこと!
高い堅牢性・拡張性・リーズナブルといった部分が評価されているとのことです。
講演一覧
- 「Amazon Aurora のエンタープライズワークロードでの活用」
- Debanjan Saha(Amazon Web Services, Inc. GM, Amazon Aurora & MySQL)
- 「MySQL から Amazon Aurora への移行事例」
- 株式会社グラニ様
- 「ドワンゴが Aurora 使ってみた(仮)」
- 株式会社ドワンゴ様
- 「APNパートナー各社によるAmazon Aurora 評価・検証結果発表」
そうそうたる企業様が並んでいますね。
今回すごく注目?していたのは、基幹業務のフルクラウド化といったところでした。(Aurora関係ねー)
経営にITが貢献するための環境(AWS等)は整ってきていて、
これからはエンジニアの腕の見せ所ですよ、といった内容と受け止めました。
# もちろん組織も変わらないといけないけど。
mysql5.7への追随はどうなるのか?など非常に気になりますね。
講演内容
「Amazon Aurora のエンタープライズワークロードでの活用」
講演者様:Debanjan Saha(Amazon Web Services, Inc. GM, Amazon Aurora & MySQL)
「less than 10ms replica lag」
■サマリ
■エンタープライズ向けシステムに必要な要件をもとにAuroraを開発
- 高い障害性
- 安定した性能(あらゆるケースにおいて安定した性能を発揮)
- 専門家を必要としない
- 低コスト、かつライセンス不要
■クラウド向けのRDBMSを、1から再設計することにより、下記を実現
- エンタープライズ級の可用性とパフォーマンス
- 3箇所のデータセンタに6つの複製
- 30秒以内にF/O!!!
- クラッシュリカバリは即時に実施可能!!!
- 50万read/sec,10万回write/sec(8xlarge)
- 15個までのリードレプリカ、低遅延10ms
- 64TBまで自動スケール可能(mysqlは6TBまで。)
- マネージドサービス
- 高速プロビジョン&デプロイ
- 自動化されたパッチ&アップグレード
- バックアップ・PITR
- コンピュートノード・ストレージのスケーリング
- 商用DBMSと比べて1/10のコスト
- Mysqlとの完全互換
- OSSのような使いやすさ、コスト効果
■Auroraのアーキテクチャ概要
- ストレージは3AZを跨いでデータを保持
- S3に透過的にバックアップされる
- 1つのマスタ、15個までのリードレプリカを持つことができる。
- マスタが故障した場合、15個のリードレプリカのいずれにもFO可能
■利用顧客について
ex:)Expedia/GE/PG&E,Earth nEtworks,ISCS,Alfresco,United Nation
Expedia事例
- SQLServer,Casandra,SolrからAuroraへの移行
- スケーラビリティ&パフォーマンス要件を満たし、コストも低減できた。
- 平常時25,000(up to 70,000)insert/sec
- 平均レスポンス:read 30msec,write 17msec
PG&E事例
- 1,600万人の顧客、70,000平方マイルのサービスエリア
- 低遅延のリードレプリカを使って、顧客アクセスに対応
- 電力関係のイベントが起きた際に突発的にトラフィック増加
- 高速にリードレプリカを作成できることがよかった
- MCシステムの実現性をAuroraは持っていた
ISCS事例
Alfresco事例
- 195ヵ国,1,800以上の組織が利用
- 数十億ドキュメント級までスケールしていた。
- 1秒未満のレスポンス時間を要求されていた。
- 10億ドキュメントに対し、300万リクエスト/時までスケール
- 現行システムの10倍の高速化
- 巨大なDCからコスト効果に優れたAWSとAuroraへ移行した
EarthNetwork
- 25TB以上のデータを毎日処理,分析ニーズが日々高まっていた
- SQLServerからAuroraへの移行、パフォーマンス・スケーラビリティを実現
threat stack
- 脅威分析のために非常に大きく連続したデータストリームを扱う
- 約50万Insert/Sec,1日の生データは10TB
- CassandraからAuroraへの移行、時系列データを扱うメインのデータべースにした
■高可用性のためのデザイン
- 3AZ,6複製
- データの読み書きにクォーラムを採用
- 書き込みは4/6,読み込みは3/6
- peer to peer goshipレプリケーション
- ストレージとコンピュートノードが常に連携
- ストレージノードでは常にブロック検査を実施、問題がある場合すぐさま復旧
- クォーラムの実現により、AZ障害、ストレージの2重障害にも対応
- 障害の検知・復旧・複製についてはバックグラウンドで自動的に実施
- 高速なクラッシュリカバリ
- 伝統的なDBでは最後のチェックポイントからのログを適用
- Mysqlではシングルスレッドで行われ、ディスクアクセスが非常に多い
- Auroraではストレージノード側で実施
- 並列・分散・非同期に実施
- 必要になったタイミングで、DiskReadの一環として、オンデマンドでredo logの適用を実施
- 結果として、クラッシュ時のリカバリ処理は1秒以内に実現
- 伝統的なDBでは最後のチェックポイントからのログを適用
- Auroraのフェイルオーバは非常に速い
- 連続的なバックアップに関して
- 従来のDBではバックアップ中に何もできない問題があった
- Auroraでは多数のストレージがあるため、各ノードで定期的にS3に送ることで、連続的なバックアップを実現
- PITRについても、必要なセグメントのスナップショットをS3から並列で持ってこれる
- 通常のDBと比べて非常に高速
■エンタープライズ級のパフォーマンス
- AuroraのページにWhitePaperがある。
- テーブル数に応じたスケールを実現
- データ数の増加に対してもスケールを実現
- 接続数の増加に対してもスケールを実現
■なぜMysqlより早いか?
- IO FLOWが非常にシンプル
- REDOレコードをまとめる。LSNが並ぶ。
- Mysqlではそれぞれのスレッドが処理
- Auroraではキューイングシステム
- 非同期で行われるグループコミット
- まずはBuffer、4/6のストレージからAckが帰ってきたらcommit
■アドバンスト・モニタリングがそのうち実現される。
顧客からOSのモニタリングをしたいというオーダーが多い
- 50以上のシステム/OSメトリクスを見えるように実現。
- 画面からプロセスリストを並べ替えることも可能
- データ取得単位を1秒単位に!!!!
■Don't be constrained by licenses, cost, or capacity
一部のケースにおいてAuroraはMysqlと比べても低コスト。
- Idle状態のリードレプリカが不要
- リードレプリカごとにストレージを切り出す必要がない
- IO担保にではなく、使用IOに対して課金
- 全体として、ストレージコストの最適化を進めることもできる。
■QA
- mysqlだとテーブルサイズが大きいカラムの変更などに非常に時間がかかる,Auroraにおいて改善があるか
- いくつかは改善が加えられている、まだすべてではない
- 現在オンラインDDL処理に向けて改良を行っている、3-6ヵ月程度でのリリースを目指している
- モバイルSDKにおけるコールは実現可能か
- もちろん可能
- 小さいインスタンスタイプをサポートする予定があるか
- 巨大テーブルに対するAlterでOOMが起きがち
- MHAなどのような、数秒でのアップグレードを実現する予定はあるか
- サポートは考えていない,別インスタンスを立ち上げて切り替えることを検討してほしい。(?)
「MySQL から Amazon Aurora への移行事例」
講演者様:吉崎様(株式会社グラニ様)
■Nice to meet you, Aurora!
発表スライドはこちら
https://speakerdeck.com/guitarrapc/nice-to-meet-you-aurora
目的1:RDS for Mysql からAuroraへ移行してみての変化
目的2:Auroraへの移行での注意点
■環境について
- New Relicを使った計測
- AP,DB,Redis,xternalの監視・通知
- APが発行したクエリをすべてBigqueryに移行
■パフォーマンスについて
- Mysql:15-22msec
- Aurora:5.5msec
- updateの高速化が顕著
- 16msec→2.2msec
■DeepDown
- select:グラニさんの環境ではあまり変わらなかった。0.98倍程度(query cache : off)
- update:5倍程度の高速化を実現
- insert:2倍程度の高速化を実現
- delete:グラニさんの環境では若干遅くなった。0.8倍程度
■性能に関する考察
- Multi-AZでの転送高速化
- 非同期のグループコミット
- スレッドプール・ロックハンドリングの改善
■移行に関して
- まずはAWSサポート資料を見ればOK!
- 移行に関しては2パターン考えられる
- snapshot移行
- レプリケーション移行
- 500GB-1TB程度の現実案がコレ(サービスへの影響を考慮)
- 注意点
- Snapshot移行について
■上記のような場合にレプリケーションマイグレーション
- レプリケーション移行について
■注意点
- セキュリティグループの設定がDBインスタンス単位からクラスタ単位へ
- RouteTableによる制御を実現
- 本番マスター:IGWと繋がらないPrivateRouteTableにAZアサイン
- 本番レプリカ:IGWと繋がっているPublicRouteTableにAZアサイン
- ルーティング時点で接続を制御
- RouteTableによる制御を実現
- High CPU/Memory/QueueDepth
- RDS fro MysqlはCPU60%程度から明らかな性能劣化
- AuroraではCPU100%近くでも堅調に動作している
- tmp_dirのサイズはインスタンスタイプに依存
- FailOver先のレプリカ指定は未実装
- 将来的な実装を想定しているとのこと
- CachePurgeは未実装
■サマリ
- 特にマルチAZを使用している場合に性能向上、ノード構成数低減にも寄与
- 耐障害性の向上
- コスト低減にも寄与
「ドワンゴが Aurora 使ってみた(仮)」
講演者様:細川様(株式会社ドワンゴ様)
■経緯
- 多数エンジニアあり
- 各種機器多数保持
- クラウド利用はあまり進んでいなかった
■新機能の積極的検証・導入を実施
■適用プロジェクト
■メリット
- Mysqlと完全互換である点
- 現行のコードセットで動作することの検証が完了
- 運用上必要な設定値がそのまま流用することが可能
- なじんだ手順でのデータ移行が可能
- ディスクの使用特性
- ディスクの使用効率や運用面で現時点ではマイナスポイントもある
- 一度拡張した領域はシュリンクされない(=課金対象となる)
- 空き領域の再利用はわりと効率よく行われている
- ディスクの使用効率や運用面で現時点ではマイナスポイントもある
- パフォーマンスに関して
- 5系統の記事DBをAPレイヤで水平分割
- 並列数を1系統に集中する
- クローラおよび空き容量確保バッチが裏で実現される
- 実環境を模した環境で試験を実施
- 目標をクリアし、サービス運用上ピークとなるクエリをさばけた
- 数TBのデータセットでクローリングした情報を追加した長期安定試験を実施
- 目立った性能劣化は見られなかった
- 最大64TBまでシームレスにサポートされる点は安心できる
- CPUが100%に張り付くケースがある
- ただし、上記はAuroraの特性なので心配視していない
- 5系統の記事DBをAPレイヤで水平分割
- フルマネージドであることによる運用負荷の削減
「APNパートナー各社によるAmazon Aurora 評価・検証結果発表」
データを使用した Amazon RDS for MySQL と Amazon Aurora の検証
講演者様:新谷 充 様(アイレット株式会社(CloudPack))
■バンダイナムコ様との共同検証
- 検証にあたっては、下記の前提とした
- 測定結果
- 1回目:waitあり、エラー処理無し
- 特に差分なし。処理にエラーあり
- 2回目:wait無し、エラー処理無し
- 特に差分なし。処理にエラーあり
- 3回目:wait無し、エラー処理あり
- mysql:8.5hr,Aurora:4.5hr
- 1回目:waitあり、エラー処理無し
- 考察
- AuroraのほうがCPUを使用している
- AuroraのほうがQueueDepthが圧倒的に高い
- Auroraは並列処理に特化しているため、自然な振る舞い
- Read/WriteThroughputに問題なければ良い
- 追加検証
- まとめ
- 今後のAuroraに期待すること
Amazon Auroraはこう使おう!~基幹業務をフルクラウド化するポイント~
講演者様:漆原 茂 様(ウルシステムズ株式会社)
■「待ってました!クラウド型RDBMS~Aurora~」
■やはり基幹業務にはRDBMS
- わかりやすいプログラミングモデル
- データの一貫性
- トランザクション管理
- 分散処理
- 耐障害性
■移行を支援するツール
■~AP業務移行をどのようにして実現すればよいか?~
→APアーキテクチャが全てを邪魔している
■MicroServiceArchitectureを実現したい!
AWSはマイクロサービスに相性よし
作り上げたモノリシックなものをブレークダウンすると良い
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
参照元:http://martinfowler.com/bliki/MonolithFirst.html
何が必要か?~TeamとDevops文化~
MicroService用のフレームワーク
Aurora活用のステップ
- リファクタリングマイクロサービス化
- Aurora移行
- IT組織改革
New Cloud Design Pattern using Amazon Aurora
講演者様:大栗様(クラスメソッド株式会社様)
発表スライドはこちら
→http://www.slideshare.net/maroon1st/new-cloud-design-pattern-using-amazon-aurora?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+slideshare%2FUARV+%28Why+China+will+over+take+India+as+the+world+Leader+with+Gold%29
■developpers.ioのシステム構成
- Elastic beanstalk + WordPressが基本構成
- eb cloneで新環境構築
- データについてはSnapshot
■移行後
- だいたい倍程度のパフォーマンスが得られた
- データが6重化されているため、Single-AZで十分と判断
- コスト1.5倍程度で性能が2-5倍程度
■システム移行事例
- Mysql(8x.large)のレプリカ9台→Aurora移行を想定
- 高性能化による台数削減を期待
- 高可用性を実現
- 現在鋭意移行検証中
■new cloud design patternを設計
- Auroraは高速FOが可能!
- サービス中に高速FOを駆使し、インスタンスタイプを変更できないか
DBScheduledScaleupと名付けた!
- MariaDB Connector/jを使用
- Lambdaを使用してスケジュール起動
- 大きなインスタンスタイプのノードを立ち上げておき、小さいノードと瞬間的に切り替えを実施
- 定期的なスケールアップを実現
Amazon Aurora+ScaleArc による Amazon Aurora のデータベース分散処理技術の最大活用
講演者様:山口様(株式会社システムサポート様)
■~一般的なDB処理の大部分がreadである~説
- 一般的には、read90%,write10%を言われている
- Auroraでは数クリックで参照処理の改善を実施することができる
- ReadReplicaの構築によって参照処理の負荷を分散
readreplicaの追加に対するAP改修をScaleArcが吸収
- read/write split という機能を持つ
- AP側はScaleArcに投げるだけでよく、ScaleArcがマスター・スレーブを投げ分けてくれる
- 検証結果
構成 | 実行時間 |
---|---|
構成1:AP1台,Master1台,Slave1台 | 470.37sec |
構成2:AP1台,Master1台,Slave2台 | 233.13sec |
構成3:AP1台,Master1台,Slave3台 | 155.62sec |
※SelectQueryのみを発行
■その他Auroraに関する取組
- OracleDatabaseからAuroraへのマイグレーションを積極的に実施
- 一部AP改修は必須だが、コスト的に非常に有用と考える
エンタープライズシステムにおける Amazon RDS for Aurora 活用ノウハウ
講演者様:西岡様(株式会社野村総合研究所様)
■Aurora検証
- コスト観点
- Oracleと比較して33%のコスト削減
- アプリ開発への影響を少なく
- スケーラビリティの確保
- 高可用性に関して
■エンタープライズシステムで活用するうえでのポイント
- コスト削減できる点は大きなメリット
- 性能に関して、基礎数値の確保などのために、実機検証が必要
- Aurora単体では更新スケーラビリティを確保できないため、シャーディングなどの工夫が必要
- 99.999%の可用性が確保されているわけではない
■Auroraに対する期待
- 更新処理をスケールアウト構成にできないか
- リージョン間のAuroraレプリケーションの暗号化
上記を受けての今後の展望は別途書きますかね。
とりあえず以上ということで。