【JAWS DAYS 2016】ランサーズを支えるAurora

「クラウドソーシング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


本日お話しさせていただく内容

ランサーズ(株)のご紹介

ランサーズのAurora運用

RDS→Auroraに移行した経緯

Auroraのフェイルオーバーについて

RDS→Aurora移行後の状況

不具合報告と対応状況（2016/3/12）









会社概要

従業員約 150 名

資本金 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 仕事マーケットプレイス ( 仕事データベース )


ランサーズの稼働環境

• 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









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で分散


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で分散


スロークエリの監視

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


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









パフォーマンスの向上

• レプリケーションの効率化

• Log structured Storage

• 他多数…

RDS Aurora

MasterとReplicaのストレージが共有されている


メンテナンスの削減

• 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のストレージが共有されている


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に昇格する仕組み

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分の費用がかからない









RDSとのフェイルオーバーの違い

WebServer Master

Read Replica

Multi AZ

EC2 instance


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

WebServer

Reader Reader Reader

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

Writer

停止時間：2分～7分

停止時間：1分以内

EC2 instance

EC2 instance

WebServer Master

Read Replica

EC2 instance


EC2 instance

WebServer

Reader Reader Writer

EC2 instance


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を意識しないエンドポイント名に変更しました。（フェイルオーバーを想定）


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

• 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


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

• 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


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

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

再起動発生ここで再度フェイルオーバーする可能性


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

• 新しく追加されたロジック • 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









レスポンス（New Relic）

• リードレプリカ（2台）切替直後


リソース利用率（CloudWatch)

• リードレプリカ（2台）切替直後


Replica Lag

RDS Aurora

• Auroraはほぼ30ms以下


カラム追加時の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秒以下 • メンテナンスなしのカラム追加が可能に


インスタンス作成時間

インスタンスタイプリードレプリカ作成時間（45GB）

ポイントタイムリカバリ作成時間（45GB）

RDS:r3.xlarge 約10分約60分

Aurora：r3.xlarge 約5分約25分

• Auroraのリードレプリカの作成時間は約5分 • TV放映対応の準備時間が短縮

• 作成後にウォームアップが必要なのはRDSと同じ • クエリキャッシュもストレージ同様に共通化してほしい


パフォーマンスが向上しなかったことの考察

• RDS時代から既にクエリキャッシュを利用していた

• RDS時代から既にSSDを採用していた

• クエリが全体的に重い • CakePHPが発行するクエリが、パフォーマンス面において適

切になっていない（技術的負債） • シングルクエリでの読み出し性能については、RDSと

Auroraで大きな差はない

• Auroraの性能が発揮できる局面 • 同時に多数のRead、Writeが起こる場合 • 少ないリードレプリカで多くのリクエストを処理する場合

• →多数のクエリを同時実行するようにアプリケーションを実装

するとパフォーマンスを発揮しやすい



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)



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換算ではもっと新しい状態









カラム追加時にリブート

36

• ALTER TABLEでカラム追加やインデックス更新を行うとリブートがかかる

• →修正済。次回のアップデートで解消予定


バイナリログPurge時の負荷

37

• バイナリログ保持期間を30日（上限値）に設定した場合 • Purge時に「Init DB」という高負荷のクエリが頻発し、サ

ービスが瞬断する • →修正済。次回のアップデートで解消予定


接続数の増加

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 | …


ランサーズ勉強会のご案内（3/30）

ご清聴ありがとうございました！

ランサーズ株式会社インフラエンジニア金澤裕毅 [Kanazawa Yuki]

「時間と場所にとらわれない、新しい働き方を創る」

[2016/03/12 JAWS DAYS]


Engineering

【JAWS DAYS 2016】ランサーズを支えるAurora