Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,274 views

Published on

JAWS DAYS 2016で発表させて頂きました、ランサーズのAurora移行に関する資料です。

Published in: Engineering
  • Be the first to comment

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

  1. 1. 「クラウドソーシングLancers」 を支えるAurora http://www.lancers.jp/ 「時間と場所にとらわれない、新しい働き方を創る」 [2016/03/12 JAWS DAYS] ランサーズ株式会社 インフラエンジニア 金澤 裕毅 [Kanazawa Yuki]
  2. 2. © 2016 for LANCERS, inc All Rights Reserved 自己紹介 • 金澤 裕毅 • ランサーズ株式会社 インフラエンジニア • 2013/11 入社 • JAWS-UG 山形支部所属 • 仙台市出身 • 山形大学大学院修了 • 最近の業務内容 • AWSのサポート体制 Aurora検証にも ご協力いただき ました。 ビジネスプラン に加入 AuroraRDS MySQL
  3. 3. © 2016 for LANCERS, inc All Rights Reserved 本日お話しさせていただく内容 ランサーズ(株)のご紹介 ランサーズのAurora運用 RDS→Auroraに移行した経緯 Auroraのフェイルオーバーについて RDS→Aurora移行後の状況 不具合報告と対応状況(2016/3/12)
  4. 4. © 2016 for LANCERS, inc All Rights Reserved ランサーズ(株)のご紹介 RDS→Auroraに移行した経緯 Auroraのフェイルオーバーについて RDS→Aurora移行後の状況 不具合報告と対応状況(2016/3/12) ランサーズのAurora運用
  5. 5. © 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/
  6. 6. © 2016 for LANCERS, inc All Rights Reserved ランサーズの事業・ビジネスモデル フ リ ー ラ ン ス な ど 仕事をしたい人 仕事を依頼・発注 ホームページ制作 / アプリ・システム制作 / ロゴ・イラスト制作 / ライティング / タスク・作業など 大手・中小企業など 仕事を依頼したい人 日本初、国内最大級の「仕事を依頼したい人」と「仕事をしたい人」 が出会う、仕事マーケットプレイス。 W E B 上 で マ ッ チ ン グ 141 のカテゴリ 仕事を提案・受注 L a n c e r s 仕 事 マ ー ケ ッ ト プ レ イ ス ( 仕 事 デ ー タ ベ ー ス )
  7. 7. © 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
  8. 8. © 2016 for LANCERS, inc All Rights Reserved ランサーズのAurora運用 RDS→Auroraに移行した経緯 Auroraのフェイルオーバーについて RDS→Aurora移行後の状況 不具合報告と対応状況(2016/3/12) ランサーズ(株)のご紹介
  9. 9. © 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で 分散
  10. 10. © 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で 分散
  11. 11. © 2016 for LANCERS, inc All Rights Reserved スロークエリの監視 • 1分毎にスロークエリをチェック • 以下のSQLで取得 • 取得結果をchatworkに通知 SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'
  12. 12. © 2016 for LANCERS, inc All Rights Reserved 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でスクリプトを流したときのレスポンス比較
  13. 13. © 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
  14. 14. © 2016 for LANCERS, inc All Rights Reserved RDS→Auroraに移行した経緯 ランサーズのAurora運用 Auroraのフェイルオーバーについて RDS→Aurora移行後の状況 不具合報告と対応状況(2016/3/12) ランサーズ(株)のご紹介
  15. 15. © 2016 for LANCERS, inc All Rights Reserved パフォーマンスの向上 • レプリケーションの効率化 • Log structured Storage • 他多数… RDS Aurora MasterとReplicaのストレージが共有されている
  16. 16. © 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のストレージが共有されている
  17. 17. © 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台
  18. 18. © 2016 for LANCERS, inc All Rights Reserved サーバー費用の削減 • 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分の 費用がかから ない
  19. 19. © 2016 for LANCERS, inc All Rights Reserved Auroraのフェイルオーバーについて RDS→Auroraに移行した経緯 ランサーズのAurora運用 RDS→Aurora移行後の状況 不具合報告と対応状況(2016/3/12) ランサーズ(株)のご紹介
  20. 20. © 2016 for LANCERS, inc All Rights Reserved RDSとのフェイルオーバーの違い WebServerMaster Read Replica Multi AZ EC2 instance Read ReplicaRead Replica RDS:待機系Multi AZがMasterに切り替わる WebServer Reader ReaderReader Aurora:リードレプリカの1台が昇格 Writer 停止時間:2分~7分 停止時間:1分以内 EC2 instance EC2 instance WebServer Master Read Replica EC2 instance Read ReplicaRead Replica EC2 instance WebServer Reader ReaderWriter EC2 instance
  21. 21. © 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を意識しない エンドポイント名に変更しました。 (フェイルオーバーを想定)
  22. 22. © 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
  23. 23. © 2016 for LANCERS, inc All Rights Reserved フェイルオーバー先の選定ロジック • 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
  24. 24. © 2016 for LANCERS, inc All Rights Reserved フェイルオーバーの注意点 • Writerインスタンスの再起動処理が、ある一定時間を超えると、 フェイルオーバーしてしまう • Writerインスタンスのインスタンスタイプを変更 • →高い確率でフェイルオーバー • Writerインスタンスのエンドポイント名を変更 • →たまにフェイルオーバー
  25. 25. © 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 再起動発生 ここで再度フェイルオーバーする可能性
  26. 26. © 2016 for LANCERS, inc All Rights Reserved フェイルオーバー先の選定ロジック • 新しく追加されたロジック • 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
  27. 27. © 2016 for LANCERS, inc All Rights Reserved RDS→Aurora移行後の状況 RDS→Auroraに移行した経緯 Auroraのフェイルオーバーについて 不具合報告と対応状況(2016/3/12) ランサーズのAurora運用 ランサーズ(株)のご紹介
  28. 28. © 2016 for LANCERS, inc All Rights Reserved レスポンス(New Relic) • リードレプリカ(2台)切替直後
  29. 29. © 2016 for LANCERS, inc All Rights Reserved リソース利用率(CloudWatch) • リードレプリカ(2台)切替直後
  30. 30. © 2016 for LANCERS, inc All Rights Reserved Replica Lag RDS Aurora • Auroraはほぼ30ms以下
  31. 31. © 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秒以下 • メンテナンスなしのカラム追加が可能に
  32. 32. © 2016 for LANCERS, inc All Rights Reserved インスタンス作成時間 インスタンスタイプ リードレプリカ作成時間 (45GB) ポイントタイムリカバリ作成時間 (45GB) RDS:r3.xlarge 約10分 約60分 Aurora:r3.xlarge 約5分 約25分 • Auroraのリードレプリカの作成時間は約5分 • TV放映対応の準備時間が短縮 • 作成後にウォームアップが必要なのはRDSと同じ • クエリキャッシュもストレージ同様に共通化してほしい
  33. 33. © 2016 for LANCERS, inc All Rights Reserved パフォーマンスが向上しなかったことの考察 • RDS時代から既にクエリキャッシュを利用していた • RDS時代から既にSSDを採用していた • クエリが全体的に重い • CakePHPが発行するクエリが、パフォーマンス面において適 切になっていない(技術的負債) • シングルクエリでの読み出し性能については、RDSと Auroraで大きな差はない • Auroraの性能が発揮できる局面 • 同時に多数のRead、Writeが起こる場合 • 少ないリードレプリカで多くのリクエストを処理する場合 • →多数のクエリを同時実行するようにアプリケーションを実装 するとパフォーマンスを発揮しやすい
  34. 34. © 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)
  35. 35. © 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換算では もっと新しい状態
  36. 36. © 2016 for LANCERS, inc All Rights Reserved 不具合報告と対応状況(2016/3/12) RDS→Auroraに移行した経緯 Auroraのフェイルオーバーについて RDS→Aurora移行後の状況 ランサーズのAurora運用 ランサーズ(株)のご紹介
  37. 37. © 2016 for LANCERS, inc All Rights Reserved カラム追加時にリブート • ALTER TABLEでカラム追加やインデックス更新を行うと リブートがかかる • →修正済。次回のアップデートで解消予定
  38. 38. © 2016 for LANCERS, inc All Rights Reserved バイナリログPurge時の負荷 • バイナリログ保持期間を30日(上限値)に設定した場合 • Purge時に「Init DB」という高負荷のクエリが頻発し、サ ービスが瞬断する • →修正済。次回のアップデートで解消予定
  39. 39. © 2016 for LANCERS, inc All Rights Reserved 接続数の増加 • 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 | …
  40. 40. © 2016 for LANCERS, inc All Rights Reserved ランサーズ勉強会のご案内(3/30)
  41. 41. ご清聴ありがとうございました! ランサーズ株式会社 インフラエンジニア 金澤 裕毅 [Kanazawa Yuki] 「時間と場所にとらわれない、新しい働き方を創る」 [2016/03/12 JAWS DAYS] http://www.lancers.jp/

×