Amazon RDS for Aurora 東京ローンチ記念セミナーにいってきた

概要

Auroraのセミナーにいってきたので気になったところをメモしました。
時々メモとして自分の意見も書きました。

特に気になったところ

• RDSでアドバンスド・モニタリングが提供される
  • 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
• 大きなテーブルへのAlter Table系の時間はおおきくは改善していない

Amazon Web Services: 13:30-

• データベースについて顧客の話を聞いて以下が重要な事だとわかった
  • 障害があっても動き続ける
  • スケールできる
  • 専門家がいなくても援用・管理できる
  • ライセンス管理しなくてもいい
• Auroraはエンタープライズ級データベースとして前述の顧客からの要求を考慮して作った
• Auroraの概要
  • ストレージは３つのAZにまたがっている
  • 変更はS3にバックアップ
  • 1つのMasterはAZの１つにある
  • 15 read replicaが作れる
  • Masterが障害のとき、どのread replicaでもfail overできる
• エンタープライズに最適
  • 30秒以内にファイルオーバー
  • 最大50万回/秒, 10万回/秒の書き込み性能が最大サイズのマスタ１台あたりさばける
  • read replicaは15個までで10[ms]のシンク遅延
  • サイズは64TBまで拡張できる、DBに最適化したストレージ
• AWSの歴史上最も早く成長しているサービス. 以下は利用している企業
  • Expedia
  • GE
  • Pacific Gas and Electric Company
  • 国連
  • etc.
• Expediaの例
  • SQL Server => Auroraへ乗り換え
  • 25,000インサート/秒 (ピーク時70,000)
  • 平均レスポンスタイムは書き込み30[ms], 読み込み17[ms]
  • コストも安くなった
• Pacific Gas and Electric Company
  • 突発的なトラフィックにもread replicaでさばける
    => メモ: IOベースの課金があるので上記のような目的でもよさそう
• ISCS
  • SQL Serverの構成よりAuroraのほうが70%安価
  • S3に連続的にバックアップをとっているので、バックアップを取る時間を削除できた
  • Auroraのread replica => Redshiftへの連続的なアップデート
• Alfresco
  • 10億ドキュメントに対し、300万リクエスト/時までスケールし、現行環境の10倍の高速化を実現
• Earth Networks
  • 地域レベルのセンサーにより天候予測する会社
  • 25TB以上のリアルタイムデータを毎日処理している
• thread stack
  • 危機管理のためIoTから情報を受け取りデータを保存
  • 50万インサート/秒, 1日の生データは約10TB
  • Cassandra => Auroraに移行
• 高可用性のためのデザイン
  • すべてのデータが3つのAZにまたがり6つの複製を保持
  • クオーラムを採用
    • 6つのうち、4つから応答があれば書き込み完了
  • 耐障害性
    • 2ノードの障害、または１つのAZ全体が落ちても読み込み・書き込みの可用性は大丈夫
    • 3つのノードが死んでも読み取りは可能
    • 復旧はバックグラウンドで行われる
• クラッシュリカバリ
  • Aurora
    • AuroraはDisk Readの一貫として、オンデマンドでredo logの適用を行う
    • redoログの適用は、並列、分散、非同期で行われる => MySQLはシーケンシャルなのでそれより非常に早くおわる
    • 1秒未満でクラッシュリカバリは終えれる
    • 起動時に実行する必要がない
    • 障害が起こってから1分以内で復帰できる
    • Auroraと一緒にMaria Driverを組み合わせると30秒未満でファイルオーバーを完了できる
• 連続的なバックアップ
  • 各セグメントのスナップショットを定期的かつ平行で取得し、RedoログをAmazon S3へ転送
  • リストア時には、該当するセグメントスナップショットとログストリームをストレージノードに復元
  • セグメントスナップショットへのログストリーム適用は並列・非同期に実行される
• SQLベンチマーク結果 (sysbench)
  • Write: 107,000 / sec
    • 4 client machine with 1000 threads each
  • Read: 585,000 / sec
    • single client with 1000 threads
• その他パフォーマンス
  • テーブルが10,00になっても性能が落ちにくい
  • データベースのサイズが1GB => 100GBになっても速度が落ちにくい
  • 接続数が5,000にしても速度が落ちにくい
• Auroraはパフォーマンスをどのように達成したか
  • DO less work
    • MySQLに比べI/Oを減らす => 1トランザクションあたり270倍少ない
      • Redoログレコードをまとめる
      • ストレージノードへまとめて書き込む
    • 適応型スレッドプール
      • アクティブなスレッドに複数のコネクションを収容
    • 非同期グループコミット => コミットをまとめてグループにしてコミットする(group commit)
• アドバンス・モニタリング => 近日登場
• コストメモ
  • POIPsがなく実際にIOを行った分を払うので、MySQLより安い場合がある => メモ: 場合によるのでは
  • パフォーマンスがいいので、インスタンスのサイズを下げる事ができコストがさらに節約できるかも: メモ: read replicaに関してはそうかもしれないがmasterに関しては自分たちで負荷試験した結果からもそうではないかも
• 質問
  • 大きなテーブルに対してカラム追加などの変更の時間はMySQLとくらべてどうなっているか
    • 多少の改善はしているがおおきくは改善してない
    • 今後の3-6ヶ月でこのようなOnline DDLを改善したい
  • モバイルのSDKから直接使えるか
    • 使えます
  • インスタンスタイプで小さいのは出す予定はあるのか
    • t2も足す予定
    • m, cはサポートする予定はない
  • メモリに乗らないような大きなテーブルのalter tableはしないほうがいいと言われているがどうか
    • 小さいサイズのインスタンスでalter tableするときはout of memoryの状況は起こっている => 大きなインスタンスタイプを使うべき
  • 数秒でのインスタンスのアップグレードは可能かどうか
    • MHAはサポートしていないので、大きいインスタンスでread replicaを作りそこにフェールオーバする

グラニ - MySQL => Aurora: 14:50-

• スライド: https://speakerdeck.com/guitarrapc/nice-to-meet-you-aurora
• インフラエンジニアの吉崎さん. インフラ全般を見ている
• すでにRDS for MySQL => Auroraに移行している
• 目的
  • Auroraへ移行しての変化の共有
  • MySQL for RDSからの移行で気をつけること
• ゴール
  • 移行したくなるか
• r3.4xlarge
  • 1 writer
  • 1 reader
• 計測
  • NewRelic: 全体としてみれる => メモ: というか50msくらいでアプリ返しているのですごい早い
    • Database ReportでUpdateの高速化が見れた:
      • Update - 5倍早い: 16-18ms => 3ms
      • Insert - 2倍早い:
      • Delete - 0.8倍で遅い: 遅いがもともとそんなに遅くない
    • Selectはほとんど違わない
  • BigQuery: アプリが発行したクエリをすべて計測. 同一クエリのAuroraによる変化を調査可能
• Auroraはレプリカの作成が6分で終わる。グラニはレプリカを二桁を超えるのを使っているが早い。
• 1TBくらいのデータの場合、停止が10時間超える。。。11時間のサービス停止
• 結果1TBを超えるデータベースはレプリケーションによるマイグレーションでやったほうがいい
  • オンラインでレプリケーションを実行していたので、30分のサービス停止で完了
• replication migrationでやったときのマスタの負荷はどうだったか
  • masterのfreeable memoryが消費していく. binlogがたまる分だけ減る => レプリケーションの再開でbinlogは減る
• Auroraに移行した後
  • パラメはなるべくデフォルトを使ったほうがいい。
    • cloud formationでの適用に時間がかかる
    • ただ、Query CacheはWrite Heavyな環境なら0(OFF)にしたほうがいい
• Security Groupがクラスターごとに適用されている
  • Public Accessible + Route Tableによる適用にした
• Auroraは100%近くになっても性能劣化も小さく動作し続ける => MySQLだと60%から大きくなると性能劣化
  • CPUが高い原因は6つのコピーを作成しているから
• これから期待すること
  • cache purge: キャッシュは自動で消せないので消したい

ドワンゴ - Aurora使ってみた

• 細川さん
  • ニコニコ事業統括本部
  • 開発部長
• LDR(国産RSSリーダ)が適用プロジェクト
  • いまAuroraを検証中
  • レガシーなプロジェクトだがMySQL on EC2からAuroraへ移行したい
  • 15台で10TBのデータ
  • mysqldump + replicationでデータ同期した
  • ディスクの使用特性
    • レコード削除しても一旦増えた使用領域はシュリンクしない
    • compressed row formatはサポートしていない
    • 空き容量の再利用は効率よく行われている
  • パフォーマンス
    • 5系統の記事DBをアプリケーションレイヤーで水平分割されていたが、移行後は1つのAuroraにおさめる
    • 過去の経験から並列数は800ほどなのでそれに耐えれるかどうかを検証した
      • 400QPSさばけた => メモ: Qの単位はなんだろうか。。。Queryだったら余裕でさばけそう
    • 数TBのデータセットにてクローリングした情報を追加しながら数週間の検証でも目立ったパフォーマンス劣化がみられない
    • 空き容量確保バッチ実行時はCPU100%に張り付く減少がみられた => 100%でもサービス側クエリ応答は問題なかった

アイレット

• 新谷 充さん
• cloudpack事業部MSPセクションリーダ
• cloudpackとは
  • AWSのSI
• バンナムと協力してサービスで使用しているデータで検証
• MySQLとAuroraで同じ環境を作る
  • 手順
    • メンテ中にsnapshotを作成
    • メンテ明けにWebAPIでtcpdumpでクエリ摘出
    • 4.5時間抽出
      • select: 10億
      • insert/update: 4-5千万くらい
    • ウォームアップは全テーブルにselectをシーケンシャルに実施
• これから期待すること
  • read replicaでファイルオーバーしたときに、read replicaが動的にマスターに変更されてしまう
  • readerのみにcloud end pointが発行されて所属しているreaderに振り分けられると使いやすい

ウルシステムズ

• 漆原社長

クラスメソッド

• 大栗 @maroon1st
• Developers.IOのRDS for MySQLをAuoraへ移行
  • Developers.IOについて
    • アクセス数: re:Invent等のイベントのときに負荷が高い
    • 投稿数: 4800本
    • 投稿者: 社員全員
    • ランク制: SNSポイントの集計
  • 環境
    • wordpress
    • Elastic Beanstalk + Wordpressが
    • eb clone
    • snapshotで移行
  • 移行結果
    • 更新早くなった
  • db.m3.medium (MySQL Multi-AZ) => db.r3.large (Aurora)へ移行
  • single-AZで十分と判断
  • $172.8 => $252になった
• その他の事例: SNSサイトのDB移行
  • サイズはr3.8xlarge
  • マスター1台でレプリカ9台
  • EC2-Classic環境
  • これから移行する上での期待
    • 高性能化による台数削減
    • 高可用性: 現在コスト的な面からSingle-AZだがAuroraで高可用性が期待できる
• New CDP(Cloud Design Pattern)の提案
  • DB Scheduled Scale Up: Auroraは高速なスケールアップが可能
    • 目的
      • 負荷のピーク前にスケールアップでスペックをあげ、ピーク後にスケールダウンコストダウン => やるには極めて高速なスケールアップ・ダウンが必要
    • 使用する技術
      • MariaDB Connector/Jを使うとファイルオーバーが高速になる・1-2秒くらいで切り替え
        • innodb_read_onlyでwriter, readerを判断する
      • 定時起動
        • 決まった時刻にAPIを実行したい: Lambdaでスケジュール実行
    • 実行手順
      • 小さいスペックのAuroraのみがある状態
      • 小さいスペックに大きいread replicaをつなぐ
      • 両方のAuroraへ向くようにMariaDBの接続を更新
      • 大きいスペックにフェイルオーバーさせる
      • 大きいインスタンスのみに接続情報を切り替える
      • 小さいインスタンスを削除
    • 制限
      • Javaのみ対応(JDBC)
      • フェイルオーバー先が選べないので、writerのみの環境でしかできない

システムサポート

• ScaleArcでmaster, read replicaへのリクエストを、接続側で意識せず分けれる
  • writeのクエリ、readのクエリを自動で見分けて、クエリを分ける

野村総合研究所

• 遠隔地保管
  • 他リージョンへのデータ保管を行う場合は、レプリケーション機能(MySQL)が使える
  • ただし、Aurora間で行う場合は暗号化されていない

その他ツールについて

以下データ連携のツール

• Talend
• DataSpider Servista