Mais conteúdo relacionado
Semelhante a 【ヒカラボ】RDS for MySQL → Aurora (20)
【ヒカラボ】RDS for MySQL → Aurora
- 2. © 2016 for LANCERS, inc All Rights Reserved
自己紹介
• 氏名
• 金澤 裕毅
• 入社時期
• 2013年11月
• 業務内容
• ランサーズの運用監視
• AWS全般
• 開発支援
• 開発環境構築
• インフラ関連の支援
• 情報システム業務
• 社内LAN構築
• 社内サーバー運用
• PC関連
• その他
- 3. © 2016 for LANCERS, inc All Rights Reserved
本日お話しさせていただく内容
ランサーズ(株)のご紹介
ランサーズのRDS運用
Aurora移行の目的
RDSとの相違点
Aurora移行計画
Aurora移行結果
- 4. © 2016 for LANCERS, inc All Rights Reserved
ランサーズ(株)のご紹介
Aurora移行の目的
RDSとの相違点
Aurora移行計画
Aurora移行結果
ランサーズのRDS運用
- 5. © 2016 for LANCERS, inc All Rights Reserved
会社概要
従業員
約 120 名
資本金
12 億 4904 万 4254 円 ( 資本準備金を含む )
株主
創業者、KDDI、インテリジェンス、グロービス・
キャピタル・パートナーズ、GMO
VenturePartners、グリーグループ、コロプラ、
オプト
本社所在地
会社名
ランサーズ株式会社 (LANCERS,INC.)
所在地
〒150-0002 東京都渋谷区渋谷 3-10-13
渋谷 R TOKYU REIT 渋谷Rビル 9F
設立
2008 年 4 月
事業
クラウドソーシング事業
http://www.lancers.jp/
- 6. © 2016 for LANCERS, inc All Rights Reserved
ランサーズの事業・ビジネスモデル
フ リ ー ラ ン ス な ど
仕事をしたい人
仕事を依頼・発注
ホームページ制作 / アプリ・システム制作 /
ロゴ・イラスト制作 / ライティング / タスク・作業など
大手・中小企業など
仕事を依頼したい人
日本初、国内最大級の「仕事を依頼したい人」と「仕事をしたい人」
が出会う、仕事マーケットプレイス。
W E B 上 で マ ッ チ ン グ
141 のカテゴリ
仕事を提案・受注
L a n c e r s 仕 事 マ ー ケ ッ ト プ レ イ ス ( 仕 事 デ ー タ ベ ー ス )
- 7. © 2016 for LANCERS, inc All Rights Reserved
ランサーズを支える技術
- 8. © 2016 for LANCERS, inc All Rights Reserved
ランサーズのRDS運用
Aurora移行の目的
RDSとの相違点
Aurora移行計画
Aurora移行結果
ランサーズ(株)のご紹介
- 9. © 2016 for LANCERS, inc All Rights Reserved
ランサーズのRDS環境
RDS
Master
RDS
Read Replica
• バージョン:MySQL 5.6
• 2013/12にEC2 → RDS化
• ストレージタイプ:SSD
• 2014/10にSSD化
• クエリキャッシュ有効
• ヒット率は50%前後
• バイナリログ保持期間:1週間(上限値)
• デフォルトは5分
• MultiAZで冗長化
• HAProxyで負荷分散
• 参照系クエリを2台のリードレプリカに
分散
• 2つのAZにそれぞれ配置
EC2
RDS
MultiAZ
App
データ
取得用DB
HAProxyで
分散
- 10. © 2016 for LANCERS, inc All Rights Reserved
スロークエリの監視
• 1分毎にスロークエリをチェック
• 以下のSQLで取得
• 取得結果をchatworkに通知
SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'
- 11. © 2016 for LANCERS, inc All Rights Reserved
DBパフォーマンス計測
• ランサーズの各画面、各バッチで流れるクエリログをスクリプト化
• インデックスの変更前後でレスポンス値を比較
• 過去のスロークエリも流している
• リードレプリカ作成直後のウォームアップにも利用
• クエリキャッシュを蓄積
0
100
200
300
400
500
600
700
800
900
20140521_proposal
20140609_proposal
20141031_proposal
20141225_proposal
20141107_catego…
20141225_catego…
20141225_catego…
admin_payments…
admin_payments…
batch_mailqueue
batch_send_man…
batch_send_mess…
batch_send_task_…
batch_startcloser
batch_update_us…
mypage_experien…
mypage_profile
profile_search
profile_cpo_mn
profile_cpo_mn_f…
profile_cpo_mn_…
project_524433_i…
project_365520_c…
project_365520_…
skill
user_login
work_award_earl…
work_create_start
work_create_start2
work_competitio…
work_confirm_pr…
work_finish_com…
work_proposals_…
work_propose_co…
work_propose_st…
work_search_logo
work_search_all_…
1回目
RDS:r3.xlarge
1回目
Aurora:r3.xlarge
1回目
参考:RDSとAuroraでスクリプトを流したときのレスポンス比較
- 12. © 2016 for LANCERS, inc All Rights Reserved
SSH TunnelingでRDS接続
EC2
RDS
Read Replica
SSH Tunneling
サーバー
• SSH Tunnelingサーバー経由でPrivate VPCのRDSに接続
• エンジニア以外の社員もSQLでデータ取得
・MySQL WorkBench
・接続先:社内サーバー
・接続ポート:8025(任意に設定)
$ ssh -N -f -p 22 -i /home/mysqluser/.ssh/ec2.id_rsa ec2-
user@EC2のIPアドレス -g -L 8025:db-slave.xxx.ap-northeast-
1.rds.amazonaws.com:3306
Lancers
EC2
instance
- 13. © 2016 for LANCERS, inc All Rights Reserved
Aurora移行の目的
ランサーズのRDS運用
RDSとの相違点
Aurora移行計画
Aurora移行結果
ランサーズ(株)のご紹介
- 14. © 2016 for LANCERS, inc All Rights Reserved
パフォーマンスの向上
• レプリケーションの効率化
• Log structured Storage
• 他多数…
RDS Aurora
- 15. © 2016 for LANCERS, inc All Rights Reserved
メンテナンスの削減
• Auroraでメンテナンスなしでのカラム追加に
• MySQL 5.6はオンラインDDL機能がサポートされている
• →RDSではリードレプリカのReplica Lagが大きく、
稼働中のALTER TABLEができなかった
RDS Aurora
大きな
Replica Lag
が発生
Replica Lagは
msレベル
mysql> ALTER TABLE t1 ADD COLUMN c1 tynyint(1) NOT NULL DEFAULT 0; mysql> ALTER TABLE t1 ADD COLUMN c1 tynyint(1) NOT NULL DEFAULT 0;
- 16. © 2016 for LANCERS, inc All Rights Reserved
TV放映負荷対策
• RDS
• 1マスターにつき5台まで
• TV放映用に予備2台分確保
• 作成時間:約10~40分
• リードレプリカの上限値が増加
• Aurora
• 1マスターにつき15台まで
• TV放映用に13台確保できる
• 作成時間:約5分
データ取得用
1台
App用
2台
TV放映用
2台(予備)
多層構成にすれば
2台以上可能だが
Replica Lagが
大きくなる
データ取得用
1台
App用
2台
TV放映用
13台
- 17. © 2016 for LANCERS, inc All Rights Reserved
サーバー費用の削減
• RDSのMulti AZ 1台分費用削減できる
• Auroraは障害時にReaderの1台がWriterに昇格する仕組み
16
WebServer
ap-northeast-1a
Master
Read Replica
Multi AZ
ap-northeast-1c
EC2
instance
Read ReplicaRead Replica
RDS
WebServer
ap-northeast-1a
Reader
ap-northeast-1c
ReaderReader
Aurora
Writer
EC2
instance
EC2
instance
MultiAZ分の
費用がかから
ない
- 18. © 2016 for LANCERS, inc All Rights Reserved
RDSとの相違点
Aurora移行の目的
ランサーズのRDS運用
Aurora移行計画
Aurora移行結果
ランサーズ(株)のご紹介
- 19. © 2016 for LANCERS, inc All Rights Reserved
インスタンスタイプ
• インスタンスクラスはdb.r3.large以上(2016/1/28現在)
• t2系のインスタンスが今後サポートされる予定
- 20. © 2016 for LANCERS, inc All Rights Reserved
パラメータグループの違い
• RDS:1つのパラメータグループ
• Aurora:2つのパラメータグループに分離
• パラメータグループ
• max_allowed_packet
• tx_isolation
• 他
• DBクラスターのパラメータグループ
• binlog_format
• character_set_database
• 他RDS Aurora
- 21. © 2016 for LANCERS, inc All Rights Reserved
フェイルオーバーの違い
WebServer
ap-northeast-1a
Master
Read Replica
Multi AZ
ap-northeast-1c
EC2
instance
Read ReplicaRead Replica
RDS:待機系Multi AZがMasterに切り替わる
WebServer
ap-northeast-1a
Reader
ap-northeast-1c
ReaderReader
Aurora:リードレプリカの1台が昇格
Writer
停止時間:2分~7分
停止時間:1分以内
EC2
instance
EC2
instance
WebServer
ap-northeast-1a
Master
Read Replica
ap-northeast-1c
EC2
instance
Read ReplicaRead Replica
EC2
instance
WebServer
ap-northeast-1a
Reader
ap-northeast-1c
ReaderWriter
EC2
instance
- 22. © 2016 for LANCERS, inc All Rights Reserved
エンドポイントの違い
• RDS
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
• Aurora
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
• Auroraは通常のエンドポイントに加え、クラスター用のエンドポイン
トが存在する
• Master(Writer)に指定するエンドポイント
• フェイルオーバーすると別なインスタンスに移動する
クラスターエンドポイント
エンドポイント
エンドポイント
- 23. © 2016 for LANCERS, inc All Rights Reserved
フェイルオーバー後のエンドポイント
• RDS
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
MultiAZに切り替え
エンドポイントは変更なし
db-slave001が
Writer(Master)になる
• Aurora
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
- 24. © 2016 for LANCERS, inc All Rights Reserved
フェイルオーバー先の選定ロジック
• Readerノードのインスタンスサイズが異なる場合
• 現在稼働中のReaderノードの中で最も大きいインスタンスを選出
• Readerノードのインスタンスサイズが同じ場合
• フェイルオーバー前のPrimaryと同一AZのReaderの中から優先して選出
WebServer
ap-northeast-1a
db.r3.xlarge
ap-northeast-1c
db.r3.2xlargedb.r3.xlarge
db.r3.2xlarge
EC2
instance
WebServer
ap-northeast-1a
db.r3.xlarge
ap-northeast-1c
db.r3.2xlargedb.r3.xlarge
EC2
instance
WebServer
ap-northeast-1a
db.r3.2xlarge
ap-northeast-1c
db.r3.2xlargedb.r3.2xlarge
db.r3.2xlarge
EC2
instance
WebServer
ap-northeast-1a
db.r3.xlarge
ap-northeast-1c
db.r3.2xlargedb.r3.xlarge
EC2
instance
- 25. © 2016 for LANCERS, inc All Rights Reserved
フェイルオーバーの注意点
• Writerインスタンスに再起動がかかる処理を行うとフェイルオー
バーしてしまうことがある
• Writerインスタンスをスケールアップ
• →高い確率でフェイルオーバー
• Writerインスタンスの名前変更
• →たまにフェイルオーバー
• Auroraに今後欲しい機能
• フェイルオーバー先の選択機能
• フェイルオーバーしないReaderの機能
- 26. © 2016 for LANCERS, inc All Rights Reserved 25
フェイルオーバー前に戻す方法
• 1.障害が発生したインスタンスを削除
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• 2.現在Writerとなっているインスタンスを選択
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
• 3.Writerインスタンスで[インスタンスの操作]-[変更]を実施
• 4.DBインスタンス識別子をdb-masterに変更
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
• 5.リードレプリカをdb-slave001で作成
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave002.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave003.xxxxx.ap-northeast-1.rds.amazonaws.com
再起動発生
ここでフェイルオーバー
したら失敗
- 27. © 2016 for LANCERS, inc All Rights Reserved
Aurora移行計画
Aurora移行の目的
RDSとの相違点
ランサーズのRDS運用
Aurora移行結果
ランサーズ(株)のご紹介
- 28. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行準備
• エンドポイント名
• フェイルオーバー時のマスタ昇格を想定した命名にする
• master、slaveを明示しない
• RDS
• db-master
• db-slave000(データ取得用)
• db-slave001(App参照用)
• db-slave002(App参照用)
• Aurora
• lancers000(Writer)
• lancers001(Reader:データ取得用)
• lancers002(Reader:App参照用)
• lancers003(Reader:App参照用)
- 29. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行準備
• セキュリティグループの変更
• RDS
• Master、Slaveにそれぞれセキュリティグループを設定
• Aurora
• セキュリティグループを1つに統合
• ReaderがWriterに昇格した場合を想定
• Aurora用のパラメータグループを新規に作成
• RDSパラメータグループの内容が以下の2つに分かれる
• Auroraパラメータグループ
• Auroraクラスターパラメータグループ
- 30. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行方法の検討
• スナップショットによる移行
• Auroraインスタンスの作成時間
• 見積時間:約2時間(約45GB)
• Aurora → RDSはできない
• エクスポート→インポートが必要
• 見積時間:約5時間(約45GB)
• RDS→Auroraレプリケーションを組み合わせた移行
• メンテナンスなしで可能な作業
• Auroraインスタンスの作成
• RDS → Auroraへのレプリケーション設定
• 問題発生時にRDSへ切戻し可能
• Slave(Reader)の切替
• メンテナンス時に行う作業
• Master(Writer)の切替
• 見積時間:1時間以内
- 31. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順
• 移行前
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
- 32. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• リードレプリカを一台作成
• スナップショット取得用
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Read
Replica
- 33. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• リードレプリカを一台作成
• レプリケーションを停止
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Read
Replica
mysql> call mysql.rds_stop_replication;
+---------------------------+
| Message |
+---------------------------+
| Slave is down or disabled |
+---------------------------+
1 row in set (1.02 sec)
Query OK, 0 rows affected (1.02 sec)
mysql>
- 34. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• バイナリログポジションを確認しておく
• Aurora にレプリケーションを設定するときに指定する
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Read
Replica
mysql> SHOW SLAVE STATUS ¥G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 172.23.1.86
Master_User: rdsrepladmin
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.225262
Read_Master_Log_Pos: 422
Relay_Log_File: relaylog.000053
Relay_Log_Pos: 595
Relay_Master_Log_File: mysql-bin-changelog.225262
Slave_IO_Running: No
Slave_SQL_Running: No
…
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
mysql>
- 35. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• 停止したリードレプリカからAuroraインスタンスを作成
• RDSスナップショットを取得
• 取得したスナップショットからAuroraに移行
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Read
Replica
Writer
- 36. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• RDS → Auroraにレプリケーションを設定
• 先ほど確認したバイナリログポジションを指定する
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Writer
mysql> call mysql.rds_set_external_master (
-> "RDS Masterのエンドポイント"
-> , “3306"
-> , "ユーザー"
-> , "パスワード"
-> , "mysql-bin-changelog.225262"
-> , 422
-> , 0
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> call mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.01 sec)
Query OK, 0 rows affected (1.01 sec)
mysql>
- 37. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• Auroraリードレプリカを作成
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Writer
Reader Reader Reader
- 38. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• 参照系をRDS→Auroraに切り替え
• HAProxyの設定を変更
• 問題発生時にRDSに戻すことが可能
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Writer
Reader Reader Reader
listen mysql
bind 0.0.0.0:3306
mode tcp
option mysql-check user haproxy
balance roundrobin
server master db-master.xxxxx.ap-northeast-1.rds…
#server read1 db-slave001.xxxxx.ap-northeast-1.rds…
#server read2 db-slave002.xxxxx.ap-northeast-1.rds…
server read1 lancers002.xxxxx.ap-northeast-1.rds…
server read2 lancers003.xxxxx.ap-northeast-1.rds…
- 39. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(参照系)
• 問題がなければ、RDSのリードレプリカを削除
App
MasterMulti AZ
EC2
Writer
Reader Reader Reader
- 40. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(更新系)
• ※メンテナンス中に行う
• RDS Masterにロックをかける
• パラメータグループのread_only変数を変更
App
MasterMulti AZ
EC2
Writer
Reader Reader Reader
- 41. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(更新系)
• ※メンテナンス中に行う
• RDS Master→Auroraのレプリケーションを解除する
App
MasterMulti AZ
EC2
Writer
Reader Reader Reader
mysql> call mysql.rds_stop_replication;
+---------------------------+
| Message |
+---------------------------+
| Slave is down or disabled |
+---------------------------+
1 row in set (1.02 sec)
Query OK, 0 rows affected (1.02 sec)
mysql>
- 42. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(更新系)
• ※メンテナンス中に行う
• バイナリログポジションを確認しておく
• Aurora → RDS レプリケーションを設定するときに指定する
App
MasterMulti AZ
EC2
Writer
Reader Reader Reader
mysql> SHOW MASTER STATUS ¥G
*************************** 1. row ***********************
File: mysql-bin-changelog.000001
Position: 9366
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.01 sec)
mysql>
- 43. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(更新系)
• ※メンテナンス中に行う
• Aurora→RDSのレプリケーションを設定
• 問題発生時にRDSに戻すことが可能
App
MasterMulti AZ
EC2
Writer
Reader Reader Reader
mysql> call mysql.rds_set_external_master (
-> " Aurora Writerのエンドポイント"
-> , "13333"
-> , "ユーザー"
-> , "パスワード"
-> , "mysql-bin-changelog. 000001"
-> , 9366
-> , 0
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> call mysql.rds_start_replication;
- 44. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(更新系)
• ※メンテナンス中に行う
• 更新系をRDS→Auroraに切り替え
App
MasterMulti AZ
EC2
Writer
Reader Reader Reader
listen mysql
bind 0.0.0.0:3306
mode tcp
option mysql-check user haproxy
balance roundrobin
#server master db-master.xxxxx.ap-northeast-1.rds…
#server read1 db-slave001.xxxxx.ap-northeast-1.rds…
#server read2 db-slave002.xxxxx.ap-northeast-1.rds…
server master lancers.cluster-xxxxx.ap-northeast-…
server read1 lancers002.xxxxx.ap-northeast-1.rds…
server read2 lancers003.xxxxx.ap-northeast-1.rds…
- 45. © 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行手順(更新系)
• 問題がなければ、RDS Masterを削除
App
EC2
Writer
Reader Reader Reader
- 46. © 2016 for LANCERS, inc All Rights Reserved
Aurora移行結果
Aurora移行の目的
RDSとの相違点
Aurora移行計画
ランサーズのRDS運用
ランサーズ(株)のご紹介
- 47. © 2016 for LANCERS, inc All Rights Reserved
レスポンス(New Relic)
• リードレプリカ(2台)切替直後
- 48. © 2016 for LANCERS, inc All Rights Reserved
リソース利用率(CloudWatch)
• リードレプリカ(2台)切替直後
- 49. © 2016 for LANCERS, inc All Rights Reserved
Replica Lag
RDS Aurora
- 50. © 2016 for LANCERS, inc All Rights Reserved
カラム追加時のReplica Lag
24.5GB、1000万件のテーブルにカラム追加したときの計測結果
インスタンスタイプ 処理時間 Replica Lagの時間 CPU使用率
RDS: r3.xlarge 4時間32分 最大15000秒 Master:約10%
Slave: 約1%
Aurora:r3.xlarge 2時間12分 最大2秒 Writer:約47%
Reader: 約17%
RDS Aurora
- 51. © 2016 for LANCERS, inc All Rights Reserved
インスタンス作成時間
• 約45GBのインスタンスで検証
インスタンス
タイプ
リードレプリカ
作成時間
ポイントタイムリカバリ
作成時間
RDS:r3.xlarge 約10分 約60分
Aurora:r3.xlarge 約5分 約25分
- 52. © 2016 for LANCERS, inc All Rights Reserved
移行結果まとめ
• 際立つほどのパフォーマンス向上はしていない
• 継続ウォッチします
• アクセス数が大きく増えた場合のパフォーマンスも確認したい
• 運用面での大きな変更はなし
• フェイルオーバーの想定は必要
• メンテナンス回数は減らせそう
• ある程度大きなテーブルでもメンテナンスなしでカラム追加が
できそう
• DBインスタンス1台分のコスト削減
• インスタンス作成時間の短縮
• リードレプリカの作成時間は約5分
• 作成後にウォームアップが必要なのはRDSと同じ
• クエリキャッシュもストレージ同様に共通化してほしい