狠狠撸

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

More Related Content

What's hot (20)

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

【ヒカラボ】RDS for MySQL → Aurora