我参加了亚马逊RDS Aurora东京启动纪念研讨会

3 年 ago

科, 雅

2 minutes

简述

我参加了Aurora的研讨会，并记下了我感兴趣的地方。有时候还写下了自己的意见作为备忘录。

只看中某一个方面。

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系の時間はおおきくは改善していない

亚马逊网络服务: 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 => 紫外: 14:50-

インフラエンジニアの吉崎さん. インフラ全般を見ている
すでに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: キャッシュは自動で消せないので消したい

我试用了DWANGO – 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%でもサービス側クエリ応答は問題なかった

我不知道如何用中文准确地解释”Airet”。

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に振り分けられると使いやすい

优利系统

漆原社長

课程方法

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のみの環境でしかできない

系统支持

writeのクエリ、readのクエリを自動で見分けて、クエリを分ける

只需要一个选项，以下是对野村総合研究所的本土汉语释义：

野村総合研究所 – 该公司为野村控股株式会社旗下的研究机构。

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

关于其他工具

以下是数据集成工具的选择：
* Talend
* DataSpider Servista