【jaws days 2016】ランサーズを支えるaurora
TRANSCRIPT
「クラウドソーシングLancers」 を支えるAurora
http://www.lancers.jp/
「時間と場所にとらわれない、新しい働き方を創る」
[2016/03/12 JAWS DAYS]
ランサーズ株式会社 インフラエンジニア 金澤 裕毅 [Kanazawa Yuki]
© 2016 for LANCERS, inc All Rights Reserved
自己紹介
• 金澤 裕毅 • ランサーズ株式会社 インフラエンジニア
• 2013/11 入社 • JAWS-UG 山形支部所属
• 仙台市出身 • 山形大学大学院修了
• 最近の業務内容
• AWSのサポート体制
Aurora検証にもご協力いただきました。
ビジネスプランに加入
Aurora RDS
MySQL
© 2016 for LANCERS, inc All Rights Reserved
本日お話しさせていただく内容
ランサーズ(株)のご紹介
ランサーズのAurora運用
RDS→Auroraに移行した経緯
Auroraのフェイルオーバーについて
RDS→Aurora移行後の状況
不具合報告と対応状況(2016/3/12)
© 2016 for LANCERS, inc All Rights Reserved
ランサーズ(株)のご紹介
RDS→Auroraに移行した経緯
Auroraのフェイルオーバーについて
RDS→Aurora移行後の状況
不具合報告と対応状況(2016/3/12)
ランサーズのAurora運用
© 2016 for LANCERS, inc All Rights Reserved
会社概要
従業員 約 150 名
資本金 12 億 4904 万 4254 円 ( 資本準備金を含む )
株主
創業者、KDDI、インテリジェンス、グロービス・
キャピタル・パートナーズ、GMO
VenturePartners、グリーグループ、コロプラ、
オプト
本社所在地
会社名 ランサーズ株式会社 (LANCERS,INC.)
所在地
〒150-0002 東京都渋谷区渋谷 3-10-13
渋谷 R TOKYU REIT 渋谷Rビル 9F
設立 2008 年 4 月
事業
クラウドソーシング事業
http://www.lancers.jp/
© 2016 for LANCERS, inc All Rights Reserved
ランサーズの事業・ビジネスモデル
フ リ ー ラ ン ス な ど
仕事をしたい人
仕事を依頼・発注
ホームページ制作 / アプリ・システム制作 / ロゴ・イラスト制作 / ライティング / タスク・作業など
大手・中小企業など
仕事を依頼したい人
日本初、国内最大級の「仕事を依頼したい人」と「仕事をしたい人」
が出会う、仕事マーケットプレイス。
W E B 上 で マ ッ チ ン グ
141 のカテゴリ
仕事を提案・受注
L a n c e r s 仕 事 マ ー ケ ッ ト プ レ イ ス ( 仕 事 デ ー タ ベ ー ス )
© 2016 for LANCERS, inc All Rights Reserved
ランサーズの稼働環境
• 2012/5にAWS化
• App:EC2(ランサーズ本体) • Apache + PHP
• WebSocket:EC2(メッセージサービス)
• node.js
• DB:MySQL 5.6(Aurora)
• Memcahed(ErastiCache) • セッション情報
• Redis(ErastiCache)
• Pub/SubでWebSocketと連動
• 全文検索:CloudSearch • SQSで連動
• ストレージ:S3
• アップロードファイル保存用
• CDN:CloudFront • サムネイルや静的ファイルをキャッシュ • OriginはEC2(Appサーバー)
EC2
App S3
Aurora
Reader
ELB
CloudFront
SQS
Cloud Search
Route53
EC2 instance
WebSocket
ErastiCache
Memcached
ErastiCache
Redis
Aurora
Reader
© 2016 for LANCERS, inc All Rights Reserved
ランサーズのAurora運用
RDS→Auroraに移行した経緯
Auroraのフェイルオーバーについて
RDS→Aurora移行後の状況
不具合報告と対応状況(2016/3/12)
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
RDS時代(2013/12~2015/12)
RDS
Master
RDS
Read Replica
• バージョン:MySQL 5.6.21 • 2013/12にEC2 → RDS化
• ストレージタイプ:SSD
• 2014/10にSSD化
• クエリキャッシュ:有効 • ヒット率は50%前後
• バイナリログ保持期間:7日間(上限値)
• デフォルトは5分
• MultiAZで冗長化
• HAProxyで負荷分散 • 参照系クエリを2台のリードレプリカに
分散 • 2つのAZにそれぞれ配置
EC2
RDS
MultiAZ
App
データ 取得用DB
HAProxyで分散
© 2016 for LANCERS, inc All Rights Reserved
Aurora移行後(2016/1~)
Aurora
Writer
Aurora
Reader
• バージョン:Aurora 5.6.10a • Auroraは5.6のみサポート
• ストレージタイプ:SSD
• デフォルトでSSD
• クエリキャッシュ:有効 • デフォルトで有効
• バイナリログ保持期間:30日間(上限値)
• デフォルトは5分 • フェイルオーバー機能で冗長化
• HAProxyで負荷分散
• 参照系クエリを2台のReaderに分散 • 2つのAZにそれぞれ配置
EC2
App
データ 取得用DB
HAProxyで分散
© 2016 for LANCERS, inc All Rights Reserved
スロークエリの監視
• 1分毎にスロークエリをチェック • 以下のSQLで取得
• 取得結果をchatworkに通知
SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'
© 2016 for LANCERS, inc All Rights Reserved
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_categ
o…
20141225_categ
o…
20141225_categ
o…
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…
myp
age_
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_e
arl…
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_a
ll_…
1回目
RDS:r3.xlarge
1回目
Aurora:r3.xlarge
1回目
参考:RDSとAuroraでスクリプトを流したときのレスポンス比較
© 2016 for LANCERS, inc All Rights Reserved
SSH TunnelingでReader接続
EC2
Aurora Reader
SSH Tunnelingサーバー
• SSH Tunnelingサーバー経由でPrivate VPCの参照用Readerに接続 • エンジニア以外の社員もSQLでデータ取得
・SQLクライアント ・接続先:社内サーバー ・接続ポート:8025(任意に設定)
$ ssh -N -f -p 22 -i /home/mysqluser/.ssh/ec2.id_rsa ec2-user@EC2のIPアドレス -g -L 8025:lancers001.xxx.ap-northeast-1.rds.amazonaws.com:3306
Lancers
EC2 instance
© 2016 for LANCERS, inc All Rights Reserved
RDS→Auroraに移行した経緯
ランサーズのAurora運用
Auroraのフェイルオーバーについて
RDS→Aurora移行後の状況
不具合報告と対応状況(2016/3/12)
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
パフォーマンスの向上
• レプリケーションの効率化
• Log structured Storage
• 他多数…
RDS Aurora
MasterとReplicaのストレージが共有されている
© 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;
MasterとReplicaのストレージが共有されている
© 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台
© 2016 for LANCERS, inc All Rights Reserved
サーバー費用の削減
• RDSのMulti AZ 1台分費用削減できる • Auroraは障害時にReaderの1台がWriterに昇格する仕組み
17
WebServer Master
Read Replica
Multi AZ
EC2 instance
Read Replica Read Replica
RDS
WebServer
Reader Reader Reader
Aurora
Writer
EC2 instance
EC2 instance
MultiAZ分の費用がかからない
© 2016 for LANCERS, inc All Rights Reserved
Auroraのフェイルオーバーについて
RDS→Auroraに移行した経緯
ランサーズのAurora運用
RDS→Aurora移行後の状況
不具合報告と対応状況(2016/3/12)
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
RDSとのフェイルオーバーの違い
WebServer Master
Read Replica
Multi AZ
EC2 instance
Read Replica Read Replica
RDS:待機系Multi AZがMasterに切り替わる
WebServer
Reader Reader Reader
Aurora:リードレプリカの1台が昇格
Writer
停止時間:2分~7分
停止時間:1分以内
EC2 instance
EC2 instance
WebServer Master
Read Replica
EC2 instance
Read Replica Read Replica
EC2 instance
WebServer
Reader Reader Writer
EC2 instance
© 2016 for LANCERS, inc All Rights Reserved
RDSとのエンドポイントの違い
• 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 • lancers.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers000.xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers001xxxxx.ap-northeast-1.rds.amazonaws.com • lancers002.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers003.xxxxx.ap-northeast-1.rds.amazonaws.com
• Auroraは通常のエンドポイントに加え、クラスター用のエンドポイントが存在する
• Master(Writer)に指定するエンドポイント • フェイルオーバーすると別なインスタンスに移動する
クラスターエンドポイント
エンドポイント
エンドポイント
AuroraではMaster、Slaveを意識しないエンドポイント名に変更しました。 (フェイルオーバーを想定)
© 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に切り替え エンドポイントは変更なし
lancers001がWriter(Master)になる
• Aurora • lancers.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers000.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers001.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers002.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers003.xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers000.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers001.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers002.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers003.xxxxx.ap-northeast-1.rds.amazonaws.com
© 2016 for LANCERS, inc All Rights Reserved
フェイルオーバー先の選定ロジック
• Readerノードのインスタンスサイズが異なる場合 • 現在稼働中のReaderノードの中で最も大きいインスタンスを選出
• Readerノードのインスタンスサイズが同じ場合
• フェイルオーバー前のPrimaryと同一AZのReaderの中から優先して選出
WebServer
db.r3.xlarge db.r3.2xlarge db.r3.xlarge
db.r3.2xlarge
EC2 instance
WebServer
db.r3.xlarge db.r3.2xlarge db.r3.xlarge
EC2 instance
WebServer
db.r3.2xlarge db.r3.2xlarge db.r3.2xlarge
db.r3.2xlarge
EC2 instance
WebServer
db.r3.2xlarge db.r3.2xlarge db.r3.2xlarge
EC2 instance
db.r3.2xlarge
db.r3.2xlarge
© 2016 for LANCERS, inc All Rights Reserved
フェイルオーバーの注意点
23
• Writerインスタンスの再起動処理が、ある一定時間を超えると、フェイルオーバーしてしまう
• Writerインスタンスのインスタンスタイプを変更 • →高い確率でフェイルオーバー
• Writerインスタンスのエンドポイント名を変更
• →たまにフェイルオーバー
© 2016 for LANCERS, inc All Rights Reserved 24
フェイルオーバー前に戻す方法
• 1.障害が発生したインスタンスを削除 • lancers000.xxxxx.ap-northeast-1.rds.amazonaws.com
• 2.現在のWriterインスタンスを選択
• lancers.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com • lancers001.xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers002.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers003.xxxxx.ap-northeast-1.rds.amazonaws.com
• 3.DBインスタンス識別子をlancers000に変更
• lancers.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com • lancers000.xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers002.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers003.xxxxx.ap-northeast-1.rds.amazonaws.com
• 4.リードレプリカをlancers001で作成
• lancers000.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com • lancers000.xxxxx.ap-northeast-1.rds.amazonaws.com
• lancers001.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers002.xxxxx.ap-northeast-1.rds.amazonaws.com • lancers003.xxxxx.ap-northeast-1.rds.amazonaws.com
再起動発生 ここで再度フェイルオーバーする可能性
© 2016 for LANCERS, inc All Rights Reserved
フェイルオーバー先の選定ロジック
• 新しく追加されたロジック • 2回目のフェイルオーバーが発生した場合
• 直近でWriterであったインスタンスを選出
WebServer
ap-northeast-1a db.r3.2xlarge
ap-northeast-1c db.r3.2xlarge db.r3.2xlarge
db.r3.2xlarge
EC2 instance
WebServer
ap-northeast-1a db.r3.2xlarge db.r3.2xlarge
EC2 instance
db.r3.2xlarge
ap-northeast-1c db.r3.2xlarge
直近のWriter
© 2016 for LANCERS, inc All Rights Reserved
RDS→Aurora移行後の状況
RDS→Auroraに移行した経緯
Auroraのフェイルオーバーについて
不具合報告と対応状況(2016/3/12)
ランサーズのAurora運用
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
レスポンス(New Relic)
• リードレプリカ(2台)切替直後
© 2016 for LANCERS, inc All Rights Reserved
リソース利用率(CloudWatch)
• リードレプリカ(2台)切替直後
© 2016 for LANCERS, inc All Rights Reserved
Replica Lag
RDS Aurora
• Auroraはほぼ30ms以下
© 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
• 大きなテーブルでも遅延は2秒以下 • メンテナンスなしのカラム追加が可能に
© 2016 for LANCERS, inc All Rights Reserved
インスタンス作成時間
インスタンスタイプ リードレプリカ作成時間(45GB)
ポイントタイムリカバリ作成時間 (45GB)
RDS:r3.xlarge 約10分 約60分
Aurora:r3.xlarge 約5分 約25分
• Auroraのリードレプリカの作成時間は約5分 • TV放映対応の準備時間が短縮
• 作成後にウォームアップが必要なのはRDSと同じ • クエリキャッシュもストレージ同様に共通化してほしい
© 2016 for LANCERS, inc All Rights Reserved
パフォーマンスが向上しなかったことの考察
• RDS時代から既にクエリキャッシュを利用していた
• RDS時代から既にSSDを採用していた
• クエリが全体的に重い • CakePHPが発行するクエリが、パフォーマンス面において適
切になっていない(技術的負債) • シングルクエリでの読み出し性能については、RDSと
Auroraで大きな差はない
• Auroraの性能が発揮できる局面 • 同時に多数のRead、Writeが起こる場合 • 少ないリードレプリカで多くのリクエストを処理する場合
• →多数のクエリを同時実行するようにアプリケーションを実装
するとパフォーマンスを発揮しやすい
© 2016 for LANCERS, inc All Rights Reserved
パフォーマンスが向上しなかったことの考察
Master (Writer)
Slave (Reader)
query_cache_size
RDS 約46% 約52% 536870912
Aurora 約48% 約16% {DBInstanceClassMemory/24} ≒2460900352
• クエリキャッシュヒット率 • Slave(Reader)のヒット率が大幅に低下
• →原因調査中
mysql> show global status like 'QCache%'; +-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | Qcache_free_blocks | 14148 | | Qcache_free_memory | 487994896 | | Qcache_hits | 386960716 | | Qcache_inserts | 349469450 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 14322309 | | Qcache_queries_in_cache | 25903 | | Qcache_total_blocks | 66099 | +-------------------------+-----------+ 8 rows in set (0.00 sec)
mysql> show global status like 'QCache%'; +-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | Qcache_free_blocks | 198057 | | Qcache_free_memory | 918230248 | | Qcache_hits | 19044065 | | Qcache_inserts | 2083800 | | Qcache_lowmem_prunes | 299833 | | Qcache_not_cached | 102441443 | | Qcache_queries_in_cache | 501645 | | Qcache_total_blocks | 1903967 | +-------------------------+-----------+ 8 rows in set (0.00 sec)
RDS (Slave) Aurora(Reader)
© 2016 for LANCERS, inc All Rights Reserved
パフォーマンスが向上しなかったことの考察
Master (Writer)
Slave (Reader) ※1台あたり
バージョン
RDS 109 780 MySQL 5.6.21
Aurora 253 5681 Aurora 5.6.10a
• スローログの発生回数(1日あたり)
• Master(Writer)は約2倍に増加 • 以前のスロークエリが復活
• 5.6.13 → 5.6.21 アップデート後に消えたスロークエリ • 一部のクエリの実行計画が変化
• 適切なインデックスを選択してくれなくなった • →調査継続中
• Slave(Reader)は約7倍に増加
• ↑に加え、クエリキャッシュのヒット率低下も関連
MySQL換算ではもっと新しい状態
© 2016 for LANCERS, inc All Rights Reserved
不具合報告と対応状況(2016/3/12)
RDS→Auroraに移行した経緯
Auroraのフェイルオーバーについて
RDS→Aurora移行後の状況
ランサーズのAurora運用
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
カラム追加時にリブート
36
• ALTER TABLEでカラム追加やインデックス更新を行うとリブートがかかる
• →修正済。次回のアップデートで解消予定
© 2016 for LANCERS, inc All Rights Reserved
バイナリログPurge時の負荷
37
• バイナリログ保持期間を30日(上限値)に設定した場合 • Purge時に「Init DB」という高負荷のクエリが頻発し、サ
ービスが瞬断する • →修正済。次回のアップデートで解消予定
© 2016 for LANCERS, inc All Rights Reserved
接続数の増加
38
• MySQLクライアントで接続後、Stateが「cleaned up」のまま残留することがある
• →AWS側でも一部現象再現。継続調査中。
手動で掃除
EC2
App
データ取得用DBのSQLクライアント接続で発生中
Aurora
Writer
Aurora
Reader
PHP経由では発生せず
mysql> SHOW PROCESSLIST; +-------+----------------+------------------+---------+---------+--------+------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +-------+----------------+------------------+---------+---------+--------+------------+------------------+ | 5944 | lancers_office | 10.0.4.126:36256 | lancers | Sleep | 668490 | cleaned up | NULL | | 6309 | lancers_office | 10.0.4.126:59914 | lancers | Sleep | 602504 | cleaned up | NULL | | 6310 | lancers_office | 10.0.4.126:59925 | NULL | Sleep | 602472 | cleaned up | NULL | | 6311 | lancers_office | 10.0.4.126:60049 | lancers | Sleep | 628090 | cleaned up | NULL | | 6317 | lancers_office | 10.0.4.126:60666 | lancers | Sleep | 625344 | cleaned up | NULL | …
© 2016 for LANCERS, inc All Rights Reserved
ランサーズ勉強会のご案内(3/30)
ご清聴ありがとうございました!
ランサーズ株式会社 インフラエンジニア 金澤 裕毅 [Kanazawa Yuki]
「時間と場所にとらわれない、新しい働き方を創る」
[2016/03/12 JAWS DAYS]
http://www.lancers.jp/