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

「クラウドソーシングLancers」を支えるAurora

http://www.lancers.jp/

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

[2016/03/12 JAWS DAYS]

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

自己紹介

• 金澤裕毅 • ランサーズ株式会社インフラエンジニア

• 2013/11 入社 • JAWS-UG 山形支部所属

• 仙台市出身 • 山形大学大学院修了

• 最近の業務内容

• AWSのサポート体制

Aurora検証にもご協力いただきました。

ビジネスプランに加入

Aurora RDS

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

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

ランサーズの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サーバー)

App S3

Aurora

Reader

CloudFront

Cloud Search

Route53

EC2 instance

WebSocket

ErastiCache

Memcached

ErastiCache

Aurora

Reader

RDS時代（2013/12～2015/12）

Master

Read Replica

• バージョン：MySQL 5.6.21 • 2013/12にEC2 → RDS化

• ストレージタイプ：SSD

• 2014/10にSSD化

• クエリキャッシュ：有効 • ヒット率は50%前後

• バイナリログ保持期間：7日間（上限値）

• デフォルトは5分

• MultiAZで冗長化

• HAProxyで負荷分散 • 参照系クエリを2台のリードレプリカに

分散 • 2つのAZにそれぞれ配置

MultiAZ

データ取得用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にそれぞれ配置

データ取得用DB

HAProxyで分散

スロークエリの監視

• 1分毎にスロークエリをチェック • 以下のSQLで取得

• 取得結果をchatworkに通知

SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'

DBパフォーマンス計測

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

• リードレプリカ作成直後のウォームアップにも利用

• クエリキャッシュを蓄積

0100200300400500600700800900

20141107_categ

20141225_categ

admin_p

ayments…

admin_p

ayments…

batch_send_man

batch_send_mess…

batch_send_task_…

batch_u

pdate_u

experien

profile_cpo_m

n_f…

profile_cpo_m

project_524433_i…

project_365520_c…

project_365520_…

work_aw

arl…

work_competitio…

work_confirm

_pr…

work_finish_com…

work_proposals_…

work_propose_co…

work_propose_st…

work_search_a

ll_…

1回目

RDS:r3.xlarge

1回目

Aurora:r3.xlarge

1回目

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

SSH TunnelingでReader接続

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

WebServer Master

Read Replica

Multi AZ

EC2 instance

Read Replica Read Replica

WebServer

Reader Reader Reader

Aurora

Writer

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

WebServer Master

Read Replica

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

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

• Writerインスタンスの再起動処理が、ある一定時間を超えると、フェイルオーバーしてしまう

• Writerインスタンスのインスタンスタイプを変更 • →高い確率でフェイルオーバー

• Writerインスタンスのエンドポイント名を変更

• →たまにフェイルオーバー

フェイルオーバー前に戻す方法

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

カラム追加時にリブート

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

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

バイナリログPurge時の負荷

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

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

接続数の増加

• MySQLクライアントで接続後、Stateが「cleaned up」のまま残留することがある

• →AWS側でも一部現象再現。継続調査中。

手動で掃除

データ取得用DBのSQLクライアント接続で発生中

Aurora

Writer

Aurora

Reader

PHP経由では発生せず

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

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

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

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

[2016/03/12 JAWS DAYS]

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

Engineering

- SMW AUTOBLOKWrench, jaws, Sintergrip inserts. Type Id. No. Weight IMG 160 - 420 with SinterGrip jaws STD IMG 160 - 420 with SinterGrip jaws ALU IMG 160 - 420 with SinterGrip jaws

DR.SHAHZADI TAYYABA HASHMI DNT 243. MAJOR INFECTIONS OF JAWS CYSTS OF JAWS ODONTOGENIC and NON- ODONTOGENIC TUMOURS OF JAWS

【ランサーズ】コンテンツマーケティングセミナーコンテンツマーケティング活用に向けて 2016.10.12

Jaws multimedia class

Jaws days2017-ops jaws-2

BROACH HOLDERS/ARBOR PRESSES B - CHUCK JAWS - SOFT CHUCK JAWS

Inserts Dies Jaws

20160520-awskrug & jaws-ug meetup day ＃01 navigating jaws days 2016

Osteomyelitis of jaws

JAWS-UG Meets Windows (JAWS Days 2017)

Jaws festa 20130928

The First Jaws

Learning JAWS

Jaws (film)

【JAWS UG 山形】ランサーズでのAWS活用事例

20130310 jaws tokai2013

Cysts of Jaws

jaws Documentation

20130831 JAWS Chiba

Jaws interview analysis