【jaws ug 山形】ランサーズでのaws活用事例
TRANSCRIPT
ランサーズでのAWS活用事例
http://www.lancers.jp/
「時間と場所にとらわれない、新しい働き方を創る」
[2016/11/12 JAWS UG 山形]
ランサーズ株式会社インフラエンジニア金澤 裕毅 [Kanazawa Yuki]
© 2016 for LANCERS, inc All Rights Reserved
自己紹介
• 氏名:金澤 裕毅
• 出身:宮城県仙台市
• 学歴:山形大学大学院理工学研究科• 平中研究室(ネットワーク専攻)
• 職歴:• 第一期(2002年~2010年)
• Windowsパッケージ開発• ASP開発、インフラ担当
• 札幌に2年間転勤• 第二期(2010年~2013年11月)
• 不動産ポータル、地域SNS• 第三期(2013年11月~現在)
• ランサーズ株式会社 インフラエンジニア
• 所属:JAWS-UG 山形支部
© 2016 for LANCERS, inc All Rights Reserved
本日お話しさせていただく内容
ランサーズ(株)のご紹介
AWS移行とVPC設計
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
© 2016 for LANCERS, inc All Rights Reserved
ランサーズ(株)のご紹介
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
AWS移行とVPC設計
© 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/
ランサーズが提供する「クラウドソーシング」
Crowd(群衆) Sourcing(外注)
Web上で個人等に 業務委託
※エスクロー決済※プラットフォーム Fee
受託者(ワーカー)
発注者(クライアント)
発注
作業納品
「時間と場所にとらわれない働き方」
141のカテゴリ
国内市場における仕事受給の流れ
1000億円以上の仕事流通
依頼額の54%が東京の企業
受注額の75%が地方の個人
3.2%3.5%5.0%
8.5%
12.0%
13.6%
54.3%
5.0%
7.8%
11.2%
11.5%
19.6%
20.2%
24.7%
東京
中部
関西
東京以外の関東
東京
関西
東京以外の関東
中部
九州
北海道、東北中四国九州
中四国北海道、東北
東京54.3%
東京以外75.3%
7
仕事の依頼例(一部のカテゴリを抜粋)
• コンペ方式
• プロジェクト方式
• タスク方式
ランサーからもスキル商品を出品可能
自分のスキルや得意を商品に見立てて出品、逆にできないことはお願いするスキルサービスECを4月より開始しました
スキルはもちろん「得意なこと」も
詳しくは「ランサーズストア」で検索
チラシ、ライティング、SEOコンサル、似顔絵作成、wordpress構築など個人が持つ多種多様な「スキルや得意」を相互に売り買いしています
© 2016 for LANCERS, inc All Rights Reserved 10
AWS移行とVPC設計
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
ランサーズの稼働環境
• App:EC2• Apache + PHP
• WebSocket:EC2• メッセージサービス• node.js
• DB:MySQL 5.6(Aurora)• MultiAZ配置• HAProxyで負荷分散
• Memcahed(ErastiCache)• セッション情報
• Redis(ErastiCache)• PubSubでWebSocketと連動
• 全文検索:CloudSearch• SQSで連動
• ストレージ:S3• アップロードファイル保存用
• CDN:CloudFront• サムネイルや静的ファイルをキャッシュ• OriginはEC2(Appサーバー)
EC2
App S3
Aurora
Reader
ELB
CloudFront
SQS
Cloud Search
Route53
EC2instance
WebSocket
ErastiCache
Memcached
ErastiCache
Redis
Aurora
Writer
© 2016 for LANCERS, inc All Rights Reserved
なぜAWSに移行しようと思ったのか
12
HDD圧迫(大容量プランにするか???)
Appサーバメモリ逼迫(4GBだったため、不足。。。)
スケールしない(AP2台 DB2台の構成 DNSラウンドロビンだった)
⇒契約したプラン上、1台だけ増やす、HDD増量が出来ない
移行を考え出した「きっかけ」
2012年からサービス拡大期へ
TV紹介も狙い出す
AWS移行前の「問題例」
どれぐらいアクセスが増えるのか?
TV効果は一時的?
© 2016 for LANCERS, inc All Rights Reserved
AWS移行後のシステム構成(2012/5)
S3
Bucket
Elastic
Load Balancer
EC2
WebServer
Elastic
Load Balancer
EC2
DB Slave
EC2
DB Slave
EC2
DB Master
ap-northeast-1a
移行後
App App
移行前
DB Master DB Slave
Internet
Internet
Data Center
DNSラウンドロビン
© 2016 for LANCERS, inc All Rights Reserved
AZを分散して冗長化(2014/5)
© 2016 for LANCERS, inc All Rights Reserved
AppとDBを2つのAZに分散する意味
RDS Master RDS Read Replica
App
ap-northeast-1a
EC2instance
ELB
App
EC2instance
App
EC2instance
RDS Multi AZ RDS Read Replica
App
ap-northeast-1c
EC2instance
ELB
App
EC2instance
App
EC2instance
AZ間の通信遅延は数ミリ〜数十ミリ
secレベル
• AZレベルの障害を想定
Route53
© 2016 for LANCERS, inc All Rights Reserved
RDS Multi AZ
AppとDBを2つのAZに分散する意味
RDS MasterRDS Read Replica
App
ap-northeast-1a
EC2instance
ELB
App
EC2instance
App
EC2instance
RDS Read Replica
App
ap-northeast-1c
EC2instance
ELB
App
EC2instance
App
EC2instance
• AZレベルの障害を想定
Route53
© 2016 for LANCERS, inc All Rights Reserved
ランサーズのEC2運用
AWS移行とVPC設計
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
コストパフォーマンスの高いインスタンスを探す
• AWS Price List API から価格データを取得• 月額日本円に換算
© 2016 for LANCERS, inc All Rights Reserved
コストパフォーマンスの高いインスタンスを探す
オンデマンド月額 CPU数 メモリ
t2.nano 約770円 1 0.5GB
t2.micro 約1540円 1 1GB
t2.small 約3080円 1 2GB
t2.medium 約6160円 2 4GB
t2.large 約12320円 2 8GB
価格は2倍単位で上昇
1コアで一番お得
2コアで一番お得
• t2系インスタンスの場合• t2.nanoがCPU的に一番お得
• t2.micro x 1 と t2.nano x 2は同じ費用• t2.mediumもお得
• 2コアのインスタンスでCPU的に一番安い• ※CPUクレジット数は違うので注意
© 2016 for LANCERS, inc All Rights Reserved
コストパフォーマンスの高いインスタンスを探す
オンデマンド月額 CPU数 ECU(CPU力) メモリ
m1.medium 約9350円 1 2 3.75GB
m1.large 約18700円 2 4 7.5GB
m3.large 約14900円 2 6.5 7.5GB
m4.large 約13400円 2 6.5 8GB
c3.large 約9850円 2 7 3.75GB
c4.large 約10230円 2 8 3.75GB
r3.large 約15400円 2 6.5 15.25GB
• コストパフォーマンスはm1 < m3 < m4 の順に高い• 新しいインスタンスの方が高くなる傾向にある
• m系よりもc系、r系の方がコストパフォーマンスが高め• 全体的にCPUよりもメモリのほうが割高
CPU最適化
メモリ最適化
現行世代
旧世代
© 2016 for LANCERS, inc All Rights Reserved
メモリを節約するテクニック
• ELBのSSL Terminate機能を利用• EC2内ではhttpのみで通信する• Apacheのmod_sslをやめるとメモリ使用量が半減
• プロセスをこまめに切る• Apacheのmod_phpのGCをアテにしない
• 早めに切ってメモリを確保• プロセスの起動回数が増えるのでCPU消費は増える
• プロセスモデルではなくスレッドモデルを採用する• Apacheならpreforkではなくworker等の利用を検討• mod_phpではなくphp-fpmの利用を検討
EC2
ELB
https://www.lancers.jp/ http://www.lancers.jp/
SSLTerminate
© 2016 for LANCERS, inc All Rights Reserved
Appをm1.medium→c3.largeに移行(2014/5)
• c3.largeに合わせてチューニング• CPUはm1.mediumの3.5倍
• 2CPU• メモリはm1.mediumと同じ
• 3.75GB
•CPUを利用してメモリを節約
•結果• レスポンス時間が1/3に短縮• サーバー台数を4台削減
• 費用も削減
<IfModule prefork.c>StartServers 10MinSpareServers 10MaxSpareServers 20ServerLimit 190MaxClients 190MaxRequestsPerChild 50</IfModule>
プロセスをこまめに削除してメモリを確保
移行前 移行後
© 2016 for LANCERS, inc All Rights Reserved
EC2インスタンスの料金体系
• オンデマンドインスタンス• 時間単位
• リザーブドインスタンス• 1年、または3年単位でまとめ買い
• No Upfront (前払い無し)• Partial Upfront (一部前払い)• All Upfront (全額前払い)
• →50%~75%の割引
• スポットインスタンス• 入札方式のインスタンス
• 入札価格より高くなると削除される• →最大90%割引• ※t2系はサポートしていない
© 2016 for LANCERS, inc All Rights Reserved
リザーブドインスタンスの損益分岐点(c4.large)
オンデマンド
リザーブド3年一括払い
リザーブド1年一括払い
スポット(目安)
リザーブド1年損益分岐点(8ヶ月)
リザーブド3年損益分岐点(17ヶ月)
© 2016 for LANCERS, inc All Rights Reserved
スポットインスタンスの活用
• t1.microの料金• オンデマンドインスタンス
• $0.026/h(¥1,935/月)
• スポットインスタンス(時価目安)• 約$0.0031/h(約¥231/月)
• スポットインスタンスのPricing History• c系インスタンスは競争が激しい• t1.microは平和な傾向
時々高騰して削除される
© 2016 for LANCERS, inc All Rights Reserved
Amazon Linux
• AWSがCentOS 6をベースに独自にチューニングしたLinux
• 最新のカーネルとAWS独自のパッケージを用意
• AWS用に最適化• すべてのインスタンスクラスに対応• インスタンスクラスに応じてパラメータを自動チューニング
• RDSのParamater Groupと同様
• AWS SDKインストール済
• cloud-init機能• EC2インスタンス起動時に様々なパラメータを渡したり、ソフト
ウェアをインストールしたりできる
• セキュリティ脆弱性への対応が早い• 大事!
Red Hat LinuxのクローンOS
© 2016 for LANCERS, inc All Rights Reserved
Amazon LinuxとCentOSの違い
CentOS 6.8 CentOS 7.2 Amazon Linux 2016.09
カーネル 2.6.32-642.6.1 3.10.0-327.36.3 4.4.19-29.55
glibc 2.12-1.192 2.17-106 2.17-106
Apache 2.2.15-54 2.4.6-40 2.2.31-1.82.4.23-1.66
Nginx 1.10.1-1.28
MySQL 5.1.73-7 mariadb 5.5.50-1 5.5-1.65.6.33-1.21
PostgreSQL 8.4.20-6 9.2.15-1 9.2.18-1.59
PHP 5.3.3-48 5.4.16-36 5.3.29-1.85.4.45-1.755.5.38-2.1185.6.26-1.128
OpenSSL 1.0.1e-48 1.0.1e-51 1.0.1k-15.96
nkf 2.0.8b-6.2
Git 1.7.1-4 1.8.3.1-6 2.7.4-1.47
ImageMagick 6.7.2.7-5 6.7.8.9-15 6.7.8.9-15.2
© 2016 for LANCERS, inc All Rights Reserved
MySQLのRDS化
ランサーズのEC2運用
AWS移行とVPC設計
CloudFrontでCDN化
CloudSearchで全文検索化
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved29
RDS化後のシステム構成(2013/12)
S3
Bucket
Elastic
Load Balancer
EC2
WebServer
Elastic
Load Balancer
EC2
DB Slave
EC2
DB Slave
EC2
DB Master
ap-northeast-1a
S3
Bucket
Elastic
Load Balancer
EC2
WebServer
ap-northeast-1a
RDS
Master
RDS Read Replica
RDS
Multi AZ
ap-northeast-1c
RDS化前 RDS化後
© 2016 for LANCERS, inc All Rights Reserved 30
RDS(MySQL)のメリット
• Multi AZ配置• マスタDBと異なるAZにスタンバイを用意• 障害時に自動フェイルオーバー
• 停止時間は2分~7分(計測値)
S3
Bucket
Elastic
Load Balancer
EC2
WebServer
ap-northeast-1a
RDS
Master
RDS Read Replica
RDS
Multi AZ
ap-northeast-1c
db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
© 2016 for LANCERS, inc All Rights Reserved
RDS(MySQL)のメリット
• リードレプリカ(参照専用スレーブ)を手軽に作成できる• メニューから選択するだけ
© 2016 for LANCERS, inc All Rights Reserved 32
RDS(MySQL)のメリット
• ポイントタイムリカバリ• 任意の時間にDBを戻すことが可能
• 35日前まで保管可能(要設定)
© 2016 for LANCERS, inc All Rights Reserved
RDS(MySQL)のメリット
• ClowdWatch• EC2よりも豊富(空きメモリ、空きHDDも確認可)
© 2016 for LANCERS, inc All Rights Reserved 34
RDS(MySQL)のメリット
• スナップショット機能• Manual Snapshot
• 手動スナップショット• インスタンス削除時に取得するか訊かれる
• Automated Snapshot• 毎日自動的に取得される差分スナップショット• 35日間まで取得可能• マスターDBが消えると削除される
© 2016 for LANCERS, inc All Rights Reserved 35
RDS(MySQL)のデメリット
• EC2に比べて割高• r3.large:$0.2/h(東京リージョン)• db.r3.large:$0.285/h(東京リージョン)
• MultiAZスタンバイ機は使えない• でも料金は2台分
S3
Bucket
Elastic
Load Balancer
EC2
WebServer
ap-northeast-1a
RDS
Master
RDS Read Replica
RDS
Multi AZ
ap-northeast-1c
バックアップ専用利用不可
© 2016 for LANCERS, inc All Rights Reserved 36
RDS(MySQL)のデメリット
• SSHログインできない• RDS接続用のEC2サーバーを用意• mysqldumpのエクスポート結果もここに格納
MySQLClient
EC2
RDSdb-master.xxx.ap-northeast-1.rds.amazonaws.com
$ mysql -h db-master.xxx.ap-northeast-1.rds.amazonaws.com -u mysqluser –p
© 2016 for LANCERS, inc All Rights Reserved 37
RDS(MySQL)のデメリット
• Tritonn、Mroongaが使えない• 日本語全文検索ができるMySQLパッケージ
• RDSを選択したら全文検索は自前で構築する必要がある• Groongaとか• Solrとか• ErasticSearchとか
mysql> SELECT * FROM timetable WHERE MATCH(title) AGAINST("クラウド");+----+-----------------------------------------------------+---------------------+| id | title | start |+----+-----------------------------------------------------+---------------------+| 35 | 「クラウドソーシングLancers」を支えるRDS for MySQL | 2014-03-15 17:00:00 |+----+-----------------------------------------------------+---------------------+1 row in set (0.00 sec)
© 2016 for LANCERS, inc All Rights Reserved
SSH Tunnelingで外部からMySQL接続
EC2
AuroraReader
SSH Tunnelingサーバー
• SSH Tunnelingサーバー経由でPrivate VPCの参照用MySQLに接続• エンジニア以外の社員も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
EC2instance
© 2016 for LANCERS, inc All Rights Reserved
Auroraの登場
• クラウドを前提にMySQLを再構築• 2014/11に発表• 2015/10 より東京リージョンでも利用可能に
• →ランサーズでは、2016/1にAuroraに移行
© 2016 for LANCERS, inc All Rights Reserved
Auroraのメリット:パフォーマンス
• レプリケーションの効率化
• Log structured Storage
• 他多数…
RDS Aurora
MasterとReplicaのストレージが共有されている
© 2016 for LANCERS, inc All Rights Reserved
Auroraのメリット:レプリカ遅延の解消
• 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
Aurora移行後の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
Auroraのメリット:RRが15台まで可能
• 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
Auroraのメリット:MultiAZ費用の削減
• RDSのMulti AZ 1台分費用削減できる• Auroraは障害時にReaderの1台がWriterに昇格する仕組み
45
WebServer
ap-northeast-1a
Master
Read Replica
Multi AZ
ap-northeast-1c
EC2instance
Read ReplicaRead Replica
RDS
WebServer
ap-northeast-1aReader
ap-northeast-1cReaderReader
Aurora
Writer
EC2instance
EC2instance
MultiAZ分の費用がかからない
© 2016 for LANCERS, inc All Rights Reserved
インスタンスタイプ
• インスタンスクラスはdb.r3.large以上(2016/11/5現在)• t2系のインスタンスが今後サポートされる予定
© 2016 for LANCERS, inc All Rights Reserved
CloudFrontでCDN化
ランサーズのEC2運用
MySQLのRDS化
CloudSearchで全文検索化
AWS移行とVPC設計
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
CDN(Content Delivery Network)とは
• Web配信のために最適化されたネットワーク• 世界の各地にキャッシュサーバ(エッジロケーション)を配置• 一番近いエッジロケーションがキャッシュしたコンテンツを返す
CDNなし CDNあり
エッジロケーション
© 2016 for LANCERS, inc All Rights Reserved
CloudFrontの導入前の画像アクセスフロー
EC2instance
EC2
App
User
S3
NFS
Route531.サムネイル要求
2.サムネイル存在チェック→なし
3.元画像を要求4.サムネイル作成
1回目 2回目
EC2instance
EC2
App
User
S3
NFS
Route531.サムネイル要求
2.サムネイル存在チェック→あり
4.NFSのキャッシュを返す
5. NFSに保存
NFSのHDDが逼迫
img.lancers.jp img.lancers.jp
img.lancers.jp img.lancers.jp
© 2016 for LANCERS, inc All Rights Reserved
CloudFrontの導入後の画像アクセスフロー
EC2
App
User
S3
Route531.サムネイル要求
2. Edge Locationのキャッシュを返す
1回目 2回目
EC2
App
User
S3
Route531.サムネイル要求
2.元画像を要求
3.サムネイル作成&Edge Locationに保存
2.キャッシュチェック→なし
2.キャッシュチェック→あり
EC2instance
EC2instance
NFS NFS
img.lancers.jp
img-origin.lancers.jp img-origin.lancers.jp
img.lancers.jp
img.lancers.jpimg.lancers.jp
© 2016 for LANCERS, inc All Rights Reserved
CloudFrontの適用
• Distributionの設定
• Route53でDNSのレコードを変更
• Webサーバーの設定変更
<VirtualHost *:80>- ServerName img.lancers.jp+ ServerName img-origin.lancers.jp
© 2016 for LANCERS, inc All Rights Reserved
CloudSearchで全文検索化
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
AWS移行とVPC設計
ランサーズ(株)のご紹介
© 2016 for LANCERS, inc All Rights Reserved
全文検索とは
• SQLのLIKEは前方一致しかインデックスが効かないSELECT * FROM users WHERE user_name LIKE '金澤%' -- 前方一致インデックスで検索可能SELECT * FROM users WHERE user_name LIKE '%金澤%' -- 中間一致、後方一致はインデックス不可
© 2016 for LANCERS, inc All Rights Reserved
全文検索エンジン
• Namazu• 日本で古くから普及していた全文検索エンジン
• Lucene系• Lucene
• Java実装の全文検索ライブラリ• Solr
• Luceneで構築された全文検索エンジン• AWS CloudSearchで採用
• Erasticsearch• Lucene基盤の分散検索エンジン• AWS Erastisearch Serviceで採用
• Senna系• Senna
• Tritton(MySQLバインディング)• Groonga
• Sennaの後継検索エンジン• Mroonga(MySQLバインディング)
SQLのMATCH〜AGEINST構文で検索可能
RDSでは未サポート
ログ分析のプラットフォームとして主に利用されている
Amazon
CloudSearch
Amazon
Elasticsearch Service
© 2016 for LANCERS, inc All Rights Reserved
日本語の形態素解析器
• JUMAN• 形態素解析器の先駆け• 京大で開発
• Kakashi• Namazuで主に採用
• Chasen• JUMANから派生した• Namazuで主に採用
• Mecab• C++実装(各言語の派生バージョンあり)• Namazu、Lucene、Solr等で幅広く採用• MySQL 5.7ではMecabプラグインをサポート
• Kuromoji• Java実装• Solr、Erasticsearchで主に採用
SQLのMATCH〜AGEINST構文で検索可能
RDSでは未サポート
© 2016 for LANCERS, inc All Rights Reserved
CloudSearchのメリット
• EC2でSolrを構築するのに比べて• インストール作業不要
• Dashboardから新規ドメインを作成• 自動スケールアウト• 自動スケールアップ• Multi AZ機能をサポート
• 冗長性を確保可能
スケールの設定
MultiAZの設定
Indexの設定
ご清聴ありがとうございました!
ランサーズ株式会社インフラエンジニア金澤 裕毅 [Kanazawa Yuki]
「時間と場所にとらわれない、新しい働き方を創る」
[2016/11/12 JAWS UG 山形]
http://www.lancers.jp/