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

ランサーズでの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 山形支部

本日お話しさせていただく内容
ランサーズ(株)のご紹介
AWS移行とVPC設計
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化

MySQLのRDS化
CloudFrontでCDN化

会社概要
従業員
約 150 名
資本金
12 億 4904 万 4254 円 ( 資本準備金を含む )
株主
創業者、KDDI、インテリジェンス、グロービス・
キャピタル・パートナーズ、GMO
VenturePartners、グリーグループ、コロプラ、オ
プト
本社所在地
会社名
ランサーズ株式会社 (LANCERS,INC.)
所在地
〒150-0002 東京都渋谷区渋谷 3-10-13
渋谷 R TOKYU REIT 渋谷Rビル 9F
設立
2008 年 4 月
事業
クラウドソーシング事業

ランサーズが提供する「クラウドソーシング」
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
MySQLのRDS化
CloudFrontでCDN化

ランサーズの稼働環境
• 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
EC2
instance
WebSocket
ErastiCache
Memcached
ErastiCache
Redis
Aurora
Writer

なぜAWSに移行しようと思ったのか
12
 HDD圧迫（大容量プランにするか？？？）
 Appサーバメモリ逼迫（4GBだったため、不足。。。）
 スケールしない（AP2台 DB2台の構成 DNSラウンドロビンだった）
⇒契約したプラン上、1台だけ増やす、HDD増量が出来ない
移行を考え出した「きっかけ」
 2012年からサービス拡大期へ
 TV紹介も狙い出す
AWS移行前の「問題例」
どれぐらいアクセス
が増えるのか？
TV効果は一時的？

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ラウンド
ロビン

AZを分散して冗長化（2014/5）

AppとDBを2つのAZに分散する意味
RDS Master RDS Read Replica
App
ap-northeast-1a
EC2
instance
ELB
App
EC2
instance
App
EC2
instance
RDS Multi AZ RDS Read Replica
App
ap-northeast-1c
EC2
instance
ELB
App
EC2
instance
App
EC2
instance
AZ間の通信遅延は
数ミリ〜数十ミリ
secレベル
• AZレベルの障害を想定
Route53

RDS Multi AZ
AppとDBを2つのAZに分散する意味
RDS MasterRDS Read Replica
App
ap-northeast-1a
EC2
instance
ELB
App
EC2
instance
App
EC2
instance
RDS Read Replica
App
ap-northeast-1c
EC2
instance
ELB
App
EC2
instance
App
EC2
instance
• AZレベルの障害を想定
Route53

MySQLのRDS化
CloudFrontでCDN化

コストパフォーマンスの高いインスタンスを探す
• AWS Price List API から価格データを取得
• 月額日本円に換算

オンデマンド月額 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クレジット数は違うので注意

オンデマンド月額 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最適化
メモリ最適化
現行世代
旧世代

メモリを節約するテクニック
• ELBのSSL Terminate機能を利用
• EC2内ではhttpのみで通信する
• Apacheのmod_sslをやめるとメモリ使用量が半減
• プロセスをこまめに切る
• Apacheのmod_phpのGCをアテにしない
• 早めに切ってメモリを確保
• プロセスの起動回数が増えるのでCPU消費は増える
• プロセスモデルではなくスレッドモデルを採用する
• Apacheならpreforkではなくworker等の利用を検討
EC2
ELB
https://www.lancers.jp/ http://www.lancers.jp/
SSL
Terminate

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 10
MinSpareServers 10
MaxSpareServers 20
ServerLimit 190
MaxClients 190
MaxRequestsPerChild 50
</IfModule>
プロセスをこまめに削
除してメモリを確保
移行前移行後

EC2インスタンスの料金体系
• オンデマンドインスタンス
• 時間単位
• リザーブドインスタンス
• 1年、または3年単位でまとめ買い
• No Upfront (前払い無し)
• Partial Upfront (一部前払い)
• All Upfront (全額前払い)
• →50%～75%の割引
• スポットインスタンス
• 入札方式のインスタンス
• 入札価格より高くなると削除される
• →最大90%割引
• ※t2系はサポートしていない

リザーブドインスタンスの損益分岐点(c4.large)
オンデマンド
リザーブド3年
一括払い
リザーブド1年
一括払い
スポット（目安）
リザーブド1年
損益分岐点（8ヶ月）
リザーブド3年
損益分岐点（17ヶ月）

スポットインスタンスの活用
• t1.microの料金
• オンデマンドインスタンス
• $0.026/h(¥1,935/月)
• スポットインスタンス（時価目安）
• 約$0.0031/h(約¥231/月)
• スポットインスタンスのPricing History
• c系インスタンスは競争が激しい
• t1.microは平和な傾向
時々高騰して削除される

Amazon Linux
• AWSがCentOS 6をベースに独自にチューニングしたLinux
• 最新のカーネルとAWS独自のパッケージを用意
• AWS用に最適化
• すべてのインスタンスクラスに対応
• インスタンスクラスに応じてパラメータを自動チューニング
• RDSのParamater Groupと同様
• AWS SDKインストール済
• cloud-init機能
• EC2インスタンス起動時に様々なパラメータを渡したり、ソフト
ウェアをインストールしたりできる
• セキュリティ脆弱性への対応が早い
• 大事！
Red Hat LinuxのクローンOS

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.8
2.4.23-1.66
Nginx 1.10.1-1.28
MySQL 5.1.73-7 mariadb 5.5.50-1 5.5-1.6
5.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.8
5.4.45-1.75
5.5.38-2.118
5.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

MySQLのRDS化
CloudFrontでCDN化

29
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化後

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

• リードレプリカ（参照専用スレーブ）を手軽に作成できる
• メニューから選択するだけ

• ポイントタイムリカバリ
• 任意の時間にDBを戻すことが可能
• 35日前まで保管可能（要設定）

• ClowdWatch
• EC2よりも豊富（空きメモリ、空きHDDも確認可）

• スナップショット機能
• Manual Snapshot
• 手動スナップショット
• インスタンス削除時に取得するか訊かれる
• Automated Snapshot
• 毎日自動的に取得される差分スナップショット
• 35日間まで取得可能
• マスターDBが消えると削除される

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
バックアップ専用
利用不可

• SSHログインできない
• RDS接続用のEC2サーバーを用意
• mysqldumpのエクスポート結果もここに格納
MySQL
Client
EC2
RDS
db-master.xxx.ap-northeast-1.rds.amazonaws.com
$ mysql -h db-master.xxx.ap-northeast-1.rds.amazonaws.com -u mysqluser –p

• 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)

SSH Tunnelingで外部からMySQL接続
EC2
Aurora
Reader
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
EC2
instance

Auroraの登場
• クラウドを前提にMySQLを再構築
• 2014/11に発表
• 2015/10 より東京リージョンでも利用可能に
• →ランサーズでは、2016/1にAuroraに移行

Auroraのメリット：パフォーマンス
• レプリケーションの効率化
• Log structured Storage
• 他多数…
RDS Aurora
MasterとReplicaのストレージが共有されている

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

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

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台

Auroraのメリット：MultiAZ費用の削減
• RDSのMulti AZ 1台分費用削減できる
• Auroraは障害時にReaderの1台がWriterに昇格する仕組み
45
WebServer
ap-northeast-1a
Master
Read Replica
Multi AZ
ap-northeast-1c
EC2
instance
Read ReplicaRead Replica
RDS
WebServer
ap-northeast-1a
Reader
ap-northeast-1c
ReaderReader
Aurora
Writer
EC2
instance
EC2
instance
MultiAZ分の
費用がかから
ない

インスタンスタイプ
• インスタンスクラスはdb.r3.large以上（2016/11/5現在）
• t2系のインスタンスが今後サポートされる予定

CloudFrontでCDN化
MySQLのRDS化

CDN(Content Delivery Network)とは
• Web配信のために最適化されたネットワーク
• 世界の各地にキャッシュサーバ（エッジロケーション）を配置
• 一番近いエッジロケーションがキャッシュしたコンテンツを返す
CDNなし CDNあり
エッジロケーション

CloudFrontの導入前の画像アクセスフロー
EC2
instance
EC2
App
User
S3
NFS
Route531.サムネイル要求
2.サムネイル存在チェック
→なし
3.元画像を要求4.サムネイル作成
1回目 2回目
EC2
instance
EC2
App
User
S3
NFS
2.サムネイル存在チェック
→あり
4.NFSのキャッシュ
を返す
5. NFSに保存
NFSのHDDが
逼迫
img.lancers.jp img.lancers.jp
img.lancers.jp img.lancers.jp

CloudFrontの導入後の画像アクセスフロー
EC2
App
User
S3
2. Edge Locationの
キャッシュを返す
1回目 2回目
EC2
App
User
S3
Route53
1.サムネイル要求
2.元画像を要求
3.サムネイル作成
&Edge Locationに保存
2.キャッシュチェック
→なし
2.キャッシュチェック
→あり
EC2
instance
EC2
instance
NFS NFS
img.lancers.jp
img-origin.lancers.jp img-origin.lancers.jp
img.lancers.jp
img.lancers.jp
img.lancers.jp

CloudFrontの適用
• Distributionの設定
• Route53でDNSのレコードを変更
• Webサーバーの設定変更
<VirtualHost *:80>
- ServerName img.lancers.jp
+ ServerName img-origin.lancers.jp

MySQLのRDS化
CloudFrontでCDN化

全文検索とは
• SQLのLIKEは前方一致しかインデックスが効かない
SELECT * FROM users WHERE user_name LIKE '金澤%' -- 前方一致インデックスで検索可能
SELECT * FROM users WHERE user_name LIKE '%金澤%' -- 中間一致、後方一致はインデックス不可

全文検索エンジン
• 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

日本語の形態素解析器
• JUMAN
• 形態素解析器の先駆け
• 京大で開発
• Kakashi
• Namazuで主に採用
• Chasen
• JUMANから派生した
• Namazuで主に採用
• Mecab
• C++実装（各言語の派生バージョンあり）
• Namazu、Lucene、Solr等で幅広く採用
• MySQL 5.7ではMecabプラグインをサポート
• Kuromoji
• Java実装
• Solr、Erasticsearchで主に採用
SQLのMATCH〜AGEINST
構文で検索可能
RDSでは未サポート

CloudSearchのメリット
• EC2でSolrを構築するのに比べて
• インストール作業不要
• Dashboardから新規ドメインを作成
• 自動スケールアウト
• 自動スケールアップ
• Multi AZ機能をサポート
• 冗長性を確保可能
スケールの設定
MultiAZの設定
Indexの設定

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

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

More Related Content

What's hot

Viewers also liked

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

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