【ヒカラボ】RDS for MySQL → Aurora

RDS for MySQL
↓
Aurora
http://www.lancers.jp/
「時間と場所にとらわれない、新しい働き方を創る」
[2016/01/28 ヒカ☆ラボ]
ランサーズ株式会社
インフラエンジニア
金澤裕毅 [Kanazawa Yuki]

© 2016 for LANCERS, inc All Rights Reserved
自己紹介
• 氏名
• 金澤裕毅
• 入社時期
• 2013年11月
• 業務内容
• ランサーズの運用監視
• AWS全般
• 開発支援
• 開発環境構築
• インフラ関連の支援
• 情報システム業務
• 社内LAN構築
• 社内サーバー運用
• PC関連
• その他

本日お話しさせていただく内容
ランサーズ(株)のご紹介
ランサーズのRDS運用
Aurora移行の目的
RDSとの相違点
Aurora移行計画
Aurora移行結果

RDSとの相違点
Aurora移行計画
Aurora移行結果

会社概要
従業員
約 120 名
資本金
12 億 4904 万 4254 円 ( 資本準備金を含む )
株主
創業者、KDDI、インテリジェンス、グロービス・
キャピタル・パートナーズ、GMO
VenturePartners、グリーグループ、コロプラ、
オプト
本社所在地
会社名
ランサーズ株式会社 (LANCERS,INC.)
所在地
〒150-0002 東京都渋谷区渋谷 3-10-13
渋谷 R TOKYU REIT 渋谷Rビル 9F
設立
2008 年 4 月
事業
クラウドソーシング事業

ランサーズの事業・ビジネスモデル
フリーランスなど
仕事をしたい人
仕事を依頼・発注
ホームページ制作 / アプリ・システム制作 /
ロゴ・イラスト制作 / ライティング / タスク・作業など
大手・中小企業など
仕事を依頼したい人
日本初、国内最大級の「仕事を依頼したい人」と「仕事をしたい人」
が出会う、仕事マーケットプレイス。
W E B 上でマッチング
141 のカテゴリ
仕事を提案・受注
L a n c e r s 仕事マーケットプレイス ( 仕事データベース )

ランサーズを支える技術

RDSとの相違点
Aurora移行計画
Aurora移行結果

ランサーズの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で
分散

スロークエリの監視
• 1分毎にスロークエリをチェック
• 以下のSQLで取得
• 取得結果をchatworkに通知
SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'

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でスクリプトを流したときのレスポンス比較

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

RDSとの相違点
Aurora移行計画
Aurora移行結果

パフォーマンスの向上
• レプリケーションの効率化
• Log structured Storage
• 他多数…
RDS Aurora

メンテナンスの削減
• 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;

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台

サーバー費用の削減
• 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分の
費用がかから
ない

RDSとの相違点
Aurora移行計画
Aurora移行結果

インスタンスタイプ
• インスタンスクラスはdb.r3.large以上（2016/1/28現在）
• t2系のインスタンスが今後サポートされる予定

パラメータグループの違い
• RDS：1つのパラメータグループ
• Aurora：2つのパラメータグループに分離
• パラメータグループ
• max_allowed_packet
• tx_isolation
• 他
• DBクラスターのパラメータグループ
• binlog_format
• character_set_database
• 他RDS Aurora

フェイルオーバーの違い
WebServer
ap-northeast-1a
Master
Read Replica
Multi AZ
ap-northeast-1c
EC2
instance
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
EC2
instance
WebServer
ap-northeast-1a
Reader
ap-northeast-1c
ReaderWriter
EC2
instance

エンドポイントの違い
• RDS
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.xxxxx.ap-northeast-1.rds.amazonaws.com
• Aurora
• db.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001xxxxx.ap-northeast-1.rds.amazonaws.com
• Auroraは通常のエンドポイントに加え、クラスター用のエンドポイン
トが存在する
• Master（Writer）に指定するエンドポイント
• フェイルオーバーすると別なインスタンスに移動する
クラスターエンドポイント
エンドポイント
エンドポイント

フェイルオーバー後のエンドポイント
• RDS
MultiAZに切り替え
エンドポイントは変更なし
db-slave001が
Writer(Master)になる
• Aurora

フェイルオーバー先の選定ロジック
• 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
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
EC2
instance

フェイルオーバーの注意点
• Writerインスタンスに再起動がかかる処理を行うとフェイルオー
バーしてしまうことがある
• Writerインスタンスをスケールアップ
• →高い確率でフェイルオーバー
• Writerインスタンスの名前変更
• →たまにフェイルオーバー
• Auroraに今後欲しい機能
• フェイルオーバー先の選択機能
• フェイルオーバーしないReaderの機能

© 2016 for LANCERS, inc All Rights Reserved 25
フェイルオーバー前に戻す方法
• 1.障害が発生したインスタンスを削除
• 2.現在Writerとなっているインスタンスを選択
• 3.Writerインスタンスで[インスタンスの操作]-[変更]を実施
• 4.DBインスタンス識別子をdb-masterに変更
• 5.リードレプリカをdb-slave001で作成
再起動発生
ここでフェイルオーバー
したら失敗

Aurora移行計画
RDSとの相違点
Aurora移行結果

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参照用）

RDS→Aurora移行準備
• セキュリティグループの変更
• RDS
• Master、Slaveにそれぞれセキュリティグループを設定
• Aurora
• セキュリティグループを1つに統合
• ReaderがWriterに昇格した場合を想定
• Aurora用のパラメータグループを新規に作成
• RDSパラメータグループの内容が以下の2つに分かれる
• Auroraパラメータグループ
• Auroraクラスターパラメータグループ

RDS→Aurora移行方法の検討
• スナップショットによる移行
• Auroraインスタンスの作成時間
• 見積時間：約2時間（約45GB）
• Aurora → RDSはできない
• エクスポート→インポートが必要
• 見積時間：約5時間（約45GB）
• RDS→Auroraレプリケーションを組み合わせた移行
• メンテナンスなしで可能な作業
• Auroraインスタンスの作成
• RDS → Auroraへのレプリケーション設定
• 問題発生時にRDSへ切戻し可能
• Slave（Reader）の切替
• メンテナンス時に行う作業
• Master（Writer）の切替
• 見積時間：１時間以内

RDS→Aurora移行手順
• 移行前
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica

RDS→Aurora移行手順（参照系）
• リードレプリカを一台作成
• スナップショット取得用
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Read
Replica

• リードレプリカを一台作成
• レプリケーションを停止
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>

• バイナリログポジションを確認しておく
• 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
mysql>

• 停止したリードレプリカからAuroraインスタンスを作成
• RDSスナップショットを取得
• 取得したスナップショットからAuroraに移行
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Read
Replica
Writer

• 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
-> );
mysql> call mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
mysql>

• Auroraリードレプリカを作成
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Writer
Reader Reader Reader

• 参照系をRDS→Auroraに切り替え
• HAProxyの設定を変更
• 問題発生時にRDSに戻すことが可能
App
Master
Read
Replica
Multi AZ
EC2
Read
Replica
Read
Replica
Writer
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 read1 lancers002.xxxxx.ap-northeast-1.rds…

• 問題がなければ、RDSのリードレプリカを削除
App
MasterMulti AZ
EC2
Writer

RDS→Aurora移行手順（更新系）
• ※メンテナンス中に行う
• RDS Masterにロックをかける
• パラメータグループのread_only変数を変更
App
MasterMulti AZ
EC2
Writer

• RDS Master→Auroraのレプリケーションを解除する
App
MasterMulti AZ
EC2
Writer
mysql> call mysql.rds_stop_replication;
+---------------------------+
| Message |
+---------------------------+
| Slave is down or disabled |
+---------------------------+
mysql>

• バイナリログポジションを確認しておく
• Aurora → RDS レプリケーションを設定するときに指定する
App
MasterMulti AZ
EC2
Writer
mysql> SHOW MASTER STATUS ¥G
*************************** 1. row ***********************
File: mysql-bin-changelog.000001
Position: 9366
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
mysql>

• Aurora→RDSのレプリケーションを設定
• 問題発生時にRDSに戻すことが可能
App
MasterMulti AZ
EC2
Writer
mysql> call mysql.rds_set_external_master (
-> " Aurora Writerのエンドポイント"
-> , "13333"
-> , "ユーザー"
-> , "パスワード"
-> , "mysql-bin-changelog. 000001"
-> , 9366
-> , 0
-> );
mysql> call mysql.rds_start_replication;

• 更新系をRDS→Auroraに切り替え
App
MasterMulti AZ
EC2
Writer
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 master lancers.cluster-xxxxx.ap-northeast-…

• 問題がなければ、RDS Masterを削除
App
EC2
Writer

Aurora移行結果
RDSとの相違点
Aurora移行計画

レスポンス（New Relic）
• リードレプリカ（2台）切替直後

リソース利用率（CloudWatch)
• リードレプリカ（2台）切替直後

Replica Lag
RDS Aurora

カラム追加時の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

インスタンス作成時間
• 約45GBのインスタンスで検証
インスタンス
タイプ
リードレプリカ
作成時間
ポイントタイムリカバリ
作成時間
RDS:r3.xlarge 約10分約60分
Aurora：r3.xlarge 約5分約25分

移行結果まとめ
• 際立つほどのパフォーマンス向上はしていない
• 継続ウォッチします
• アクセス数が大きく増えた場合のパフォーマンスも確認したい
• 運用面での大きな変更はなし
• フェイルオーバーの想定は必要
• メンテナンス回数は減らせそう
• ある程度大きなテーブルでもメンテナンスなしでカラム追加が
できそう
• DBインスタンス１台分のコスト削減
• インスタンス作成時間の短縮
• リードレプリカの作成時間は約5分
• 作成後にウォームアップが必要なのはRDSと同じ
• クエリキャッシュもストレージ同様に共通化してほしい

ご清聴ありがとうございました！
ランサーズ株式会社
インフラエンジニア
金澤裕毅 [Kanazawa Yuki]
「時間と場所にとらわれない、新しい働き方を創る」
[2016/01/28 ヒカ☆ラボ]

【ヒカラボ】RDS for MySQL → Aurora

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 【ヒカラボ】RDS for MySQL → Aurora

Similar to 【ヒカラボ】RDS for MySQL → Aurora (20)

【ヒカラボ】RDS for MySQL → Aurora