【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検証にも
ご協力いただき
ました。
ビジネスプラン
に加入
AuroraRDS
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パフォーマンス計測
• ランサーズの各画面、各バッチで流れるクエリログをスクリプト化
• インデックスの変更前後でレスポンス値を比較
• 過去のスロークエリも流している
• リードレプリカ作成直後のウォームアップにも利用
• クエリキャッシュを蓄積
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で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
WebServerMaster
Read Replica
Multi AZ
EC2
instance
Read ReplicaRead Replica
RDS
WebServer
Reader ReaderReader
Aurora
Writer
EC2
instance
EC2
instance
MultiAZ分の
費用がかから
ない

RDSとのフェイルオーバーの違い
WebServerMaster
Read Replica
Multi AZ
EC2
instance
RDS:待機系Multi AZがMasterに切り替わる
WebServer
Reader ReaderReader
Aurora:リードレプリカの1台が昇格
Writer
停止時間：2分～7分
停止時間：1分以内
EC2
instance
EC2
instance
WebServer Master
Read Replica
EC2
instance
EC2
instance
WebServer
Reader ReaderWriter
EC2
instance

RDSとのエンドポイントの違い
• RDS
• db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
• db-slave001.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
• Auroraは通常のエンドポイントに加え、クラスター用のエンドポイン
トが存在する
• Master（Writer）に指定するエンドポイント
• フェイルオーバーすると別なインスタンスに移動する
クラスターエンドポイント
エンドポイント
エンドポイント
AuroraではMaster、Slaveを意識しない
エンドポイント名に変更しました。
（フェイルオーバーを想定）

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

フェイルオーバー先の選定ロジック
• Readerノードのインスタンスサイズが異なる場合
• 現在稼働中のReaderノードの中で最も大きいインスタンスを選出
• Readerノードのインスタンスサイズが同じ場合
• フェイルオーバー前のPrimaryと同一AZのReaderの中から優先して選出
WebServer
db.r3.xlarge db.r3.2xlargedb.r3.xlarge
db.r3.2xlarge
EC2
instance
WebServer
db.r3.xlarge db.r3.2xlargedb.r3.xlarge
EC2
instance
WebServer
db.r3.2xlarge db.r3.2xlargedb.r3.2xlarge
db.r3.2xlarge
EC2
instance
WebServer
db.r3.2xlarge db.r3.2xlargedb.r3.2xlarge
EC2
instance
db.r3.2xlarge
db.r3.2xlarge

フェイルオーバーの注意点
• Writerインスタンスの再起動処理が、ある一定時間を超えると、
フェイルオーバーしてしまう
• Writerインスタンスのインスタンスタイプを変更
• →高い確率でフェイルオーバー
• Writerインスタンスのエンドポイント名を変更
• →たまにフェイルオーバー

© 2016 for LANCERS, inc All Rights Reserved 24
フェイルオーバー前に戻す方法
• 1.障害が発生したインスタンスを削除
• 2.現在のWriterインスタンスを選択
• 3.DBインスタンス識別子をlancers000に変更
• 4.リードレプリカをlancers001で作成
• lancers000.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
再起動発生
ここで再度フェイルオーバーする可能性

フェイルオーバー先の選定ロジック
• 新しく追加されたロジック
• 2回目のフェイルオーバーが発生した場合
• 直近でWriterであったインスタンスを選出
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.2xlargedb.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換算では
もっと新しい状態

カラム追加時にリブート
• ALTER TABLEでカラム追加やインデックス更新を行うと
リブートがかかる
• →修正済。次回のアップデートで解消予定

バイナリログPurge時の負荷
• バイナリログ保持期間を30日（上限値）に設定した場合
• Purge時に「Init DB」という高負荷のクエリが頻発し、サ
ービスが瞬断する
• →修正済。次回のアップデートで解消予定

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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

Similar to 【JAWS DAYS 2016】ランサーズを支えるAurora (20)

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