Auroraの検討を導入していることもあり、11/10のAmazon RDS for Aurora 東京ローンチ記念セミナーに行ってきたのでそのメモ書きと感想。
Debanjan Saha, GM, Amazon Aurora
Auroraチームの人。AuroraはAWS史上最速で成長しているサービスと言っていた。
エンタープライズ顧客の要望リスト
- 専門家部隊がいなくても運用・管理できる
- ライセンス管理しなくてもいい
MySQL互換のリレーショナル・データベース
- 商用DB並のパフォーマンスと可用性
- OSS DBの使いやすさとコスト効果
- 3箇所のデータセンターに6つの複製を保持
- 30秒以内でフェールオーバー
- 50万 Read IOPS
- 10万 Write IOPS
- 64TB Storage - DBに最適化したストレージ
Aurora使っている会社
- Expedia
- GE Oil & Gas
- Alfresco
などなど。
Expedia
- 現行のSQL Serverベースのアーキテクチャはデータボリュームの増加と共にパフォーマンスの低下が見られた
- Cassandra + Solrを組み合わせたインデックスは大きなメモリー空間を必要としてコストを押し上げた
- Auroraはスケーラビリティとパフォーマンス要件を満たし、コストもずっと低かった
- 平常時25K INSERT/sec (Peak 70K)
- 平均レスポンスタイムはWrite 30ms, Read 17ms
PG&E
- 天然ガス＋電力の公益企業
- 電力関係のイベントが起きた際に突発的なトラフィックを処理しなくてはいけないという課題
- データベースが落ちた時の影響が大きい
- 遅延のほとんどないRead Replicaを複数持つことができるため、電力化kん京のイベントが起きた際の突発的なトラフィックを処理し、顧客に最新の情報をタイムリーに提供できるようになった
ISCS
- 保険請求処理
- Oracle + SQL Serverを通常業務ならびにウェアハウスデータ用に使用
- コストが大きな支出となっていた
- 余裕をもたせた状態のAuroraのコストがSQLServerの構成よりも70%やすかった
- Auroraの連続的なバックアップ機能により、バックアップ処理ウインドウを廃止できた
ThreatStack
- AWS顧客に対し連続的なセキュリティ監視を提供
- 脅威分析のために大きく連続したデータストリームを扱う
- 50万INSERT/sec, 1日の生データは10TB
- Cassandraからの移行
- Auroraを時系列データを扱うDBとして使用
Architecture
- Three AZ and 6 data replica
- Quoram
- Peer-to-peer gossip Replication
- Continuous S3 backup
- Storage node check and failure and repair
高速なクラッシュリカバリ
- 最後のチェックポイントからのログを適用する必要がある
- AuroraはDisk readの一環としてオンデマンドでredo logの適用を行う
- 並列・分散・非同期で行われる
- 起動時に実行する必要がない
フェイルオーバー時間
- Failure Detection(15-30sec), DNS Propagation(5-20sec)
- Aurora + MariaDB Driverを組み合わせることにより30秒未満でフェイルオーバーできる
バックアップ
- 通常のデータベースはバックアップウィンドウの時間があるが、Auroraは継続的にバックアップしている
- DBサイズが大きければ大きいほど時間がかかる
なぜAuroraは速いのか
- IOを減らす
- ネットワークパケットを最小限にする
- 結果をキャッシュしておく
Advanced Monitoring
- より詳しいOSの統計情報がとれるようになる予定
- 1秒単位でメトリクス取得可能
お金の話
- No idle standby instance
- Single shared storage volume
- NO POIPs - pay for use I/O (Provisioned IOPSが不要)
- 21.4% Savings
- さらにパフォーマンスがいいので、MySQLおり小さいインスタンスでもいいかも
質疑応答
- MySQLだとデータ量が多いとAlter tableが遅い問題
- Online DDLについては改善予定(3-6ヶ月以内)
- r3以外のインスタンスについて
- t2 instanceについては検討中
- mやcのタイプはあまり検討していない
- メモリに乗らないAlter tableはOOMが出る？
- 大体の問題は対応済み
- MHAのような数秒単位でのインスタンス入れ替えは可能？
- できないので、Read replica作ってそこにフェイルオーバーさせる
RDS for MySQLからAuroraへの移行
グラニ吉崎さん
どのような変化があったか
- UPDATEの高速化(16.2ms -> 2.84ms)
- INSERT(2.9ms -> 1.3ms)
- DELETE(0.8ms -> 1ms)
- SELECTはあまり変わってない
Migration
SNAPSHOT Migration
- 120GB: db.r3.4xlarge
- マイグレーション素養時間：01:37h
- レプリカ作成所要時間 ：00:06h(これは常に6分！！)
- 1100GB: db.r3.8xlarge
- マイグレーション素養時間：10:42h
- レプリカ作成所要時間 ：00:06h(これは常に6分！！)
Replication Migration Summary
Cluster & DB Parameters
High CPU / Memory / QueueDepth
- RDS for MySQL: 60%声から著しい性能劣化
- Connnection拒否や応答しないなど
今後に期待したいこと
- Failover order
- Mandatory Cache purge
ドワンゴがAurora使ってみた(仮)
ドワンゴでの開発
- 多数のサーバーやネットワーク機器
- サーバーはHWから自作しようとしてる
AWS導入サービスの増加
- Dwango Reader
- アプリケーションレイヤーで水平分割
- 大量の記事データ
Aurora
ウルシステムズの漆原さん
Oracle使ってるようなエンプラからの移行
- モノリシックなアーキテクチャ
- 顧客テーブルをみんな参照しているとかｗ
- DB変更に弱い。何箇所も影響あり
- マイクロサービス化でさらなる効果を
- 特定の技術にロックインされない(でもカオスになる可能性もある)
マイクロサービスについて
Aurora活用のステップ
- リファクタリング・マイクロサービス化
- Aurora移行
- IT組織改革
感想
現在開発環境でAuroraを試していて、アプリケーションは一切いじらずに普通に稼働していてMySQLとの互換性の高さを感じている。あとはALTER TABLEした時の挙動とか負荷試験をして問題なければ導入する予定。
Auroraを導入するメリットとしては
- 事前にディスク容量やIOPSを考える必要がない(勝手に拡張されていく)
- Master/Slaveは同じデータを見ているので運用が楽になる
- レプリケーションを考えなくていいので、精神的にもストレスがなさそう
- Slave(Read Replica)を作るのが一定の時間で終わる
- コストメリット
- 事前にEBS容量を確保しなくていいので無駄がない
- 書き込みが速くなる
などかなぁと思ってる。でで、特にAuroraへの移行の話は参考になって、データ容量が少なければスナップショットからの移行が一番楽そうだなと思っているところ。
とにかくMySQLを利用するような値段でWrite10万IOPS出るようなDBが使えるのはすごい。これはもうFusionIOとかいらなくなる予感がしている。
