【ヒカラボ】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パフォーマンス計測

• ランサーズの各画面、各バッチで流れるクエリログをスクリプト化• インデックスの変更前後でレスポンス値を比較• 過去のスロークエリも流している

• リードレプリカ作成直後のウォームアップにも利用• クエリキャッシュを蓄積

0100200300400500600700800900

20

14

05

21

_pro

po

sal

20

14

06

09

_pro

po

sal

20

14

10

31

_pro

po

sal

20

14

12

25

_pro

po

sal

20141107_catego…

20141225_catego…

20141225_catego…

admin_p

ayments…

admin_p

ayments…

bat

ch_m

ailq

ueu

e

batch_send_man

…

batch_send_mess…

batch_send_task_…

bat

ch_s

tart

clo

ser

batch_u

pdate_u

s…

mypage_experien

…

myp

age_

pro

file

pro

file

_se

arch

pro

file

_cp

o_m

n

profile_cpo_m

n_f…

profile_cpo_m

n_…

project_524433_i…

project_365520_c…

project_365520_…

skill

use

r_lo

gin

work_aw

ard_earl…

wo

rk_

crea

te_

star

t

wo

rk_

crea

te_

star

t2

work_competitio…

work_confirm

_pr…

work_finish_com…

work_proposals_…

work_propose_co…

work_propose_st…

wo

rk_

sear

ch_l

ogo

work_search_all_…

1回目

RDS:r3.xlarge

1回目

Aurora:r3.xlarge

1回目

参考：RDSとAuroraでスクリプトを流したときのレスポンス比較


SSH TunnelingでRDS接続

EC2

RDSRead 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

EC2instance




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

EC2instance

Read ReplicaRead Replica

RDS

WebServer

ap-northeast-1aReader

ap-northeast-1cReaderReader

Aurora

Writer

EC2instance

EC2instance

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

EC2instance


RDS:待機系Multi AZがMasterに切り替わる

WebServer


ap-northeast-1cReaderReader

Aurora:リードレプリカの1台が昇格

Writer

停止時間：2分～7分

停止時間：1分以内

EC2instance

EC2instance

WebServer

ap-northeast-1a

Master

Read Replica

ap-northeast-1c

EC2instance


EC2instance

WebServer


ap-northeast-1cReaderWriter

EC2instance


エンドポイントの違い

• 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）に指定するエンドポイント• フェイルオーバーすると別なインスタンスに移動する

クラスターエンドポイント

エンドポイント

エンドポイント


フェイルオーバー後のエンドポイント

• 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.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


フェイルオーバー先の選定ロジック

• Readerノードのインスタンスサイズが異なる場合• 現在稼働中のReaderノードの中で最も大きいインスタンスを選出

• Readerノードのインスタンスサイズが同じ場合• フェイルオーバー前のPrimaryと同一AZのReaderの中から優先して選出

WebServer

ap-northeast-1adb.r3.xlarge

ap-northeast-1cdb.r3.2xlargedb.r3.xlarge

db.r3.2xlarge

EC2instance

WebServer



EC2instance

WebServer

ap-northeast-1adb.r3.2xlarge

ap-northeast-1cdb.r3.2xlargedb.r3.2xlarge

db.r3.2xlarge

EC2instance

WebServer



EC2instance


フェイルオーバーの注意点

24

• Writerインスタンスに再起動がかかる処理を行うとフェイルオーバーしてしまうことがある

• Writerインスタンスをスケールアップ• →高い確率でフェイルオーバー

• Writerインスタンスの名前変更• →たまにフェイルオーバー

• Auroraに今後欲しい機能

• フェイルオーバー先の選択機能

• フェイルオーバーしないReaderの機能

© 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


再起動発生ここでフェイルオーバーしたら失敗


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.86Master_User: rdsrepladminMaster_Port: 3306

Connect_Retry: 60Master_Log_File: mysql-bin-changelog.225262

Read_Master_Log_Pos: 422Relay_Log_File: relaylog.000053Relay_Log_Pos: 595

Relay_Master_Log_File: mysql-bin-changelog.225262Slave_IO_Running: NoSlave_SQL_Running: No

…Retrieved_Gtid_Set:Executed_Gtid_Set:

Auto_Position: 01 row in set (0.00 sec)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-> );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>



• 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 mysqlbind 0.0.0.0:3306mode tcpoption mysql-check user haproxybalance roundrobinserver 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…



• 問題がなければ、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 |+---------------------------+1 row in set (1.02 sec)Query OK, 0 rows affected (1.02 sec)mysql>



• ※メンテナンス中に行う• バイナリログポジションを確認しておく

• Aurora → RDS レプリケーションを設定するときに指定する

App

MasterMulti AZ

EC2

Writer


mysql> SHOW MASTER STATUS ¥G*************************** 1. row ***********************

File: mysql-bin-changelog.000001Position: 9366

Binlog_Do_DB:Binlog_Ignore_DB:

Executed_Gtid_Set:1 row in set (0.01 sec)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-> );Query OK, 0 rows affected (0.03 sec)

mysql> call mysql.rds_start_replication;



• ※メンテナンス中に行う• 更新系をRDS→Auroraに切り替え

App

MasterMulti AZ

EC2

Writer


listen mysqlbind 0.0.0.0:3306mode tcpoption mysql-check user haproxybalance 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…



• 問題がなければ、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 ヒカ☆ラボ]


Engineering

【ヒカラボ】RDS for MySQL → Aurora