【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

EC2instance

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

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


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




MySQLのRDS化

CloudFrontでCDN化




コストパフォーマンスの高いインスタンスを探す

• AWS Price List API から価格データを取得• 月額日本円に換算

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/price-changes.html



オンデマンド月額 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等の利用を検討• mod_phpではなくphp-fpmの利用を検討

EC2

ELB

https://www.lancers.jp/ http://www.lancers.jp/

SSLTerminate


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>

プロセスをこまめに削除してメモリを確保

移行前移行後


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.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


MySQLのRDS化



CloudFrontでCDN化



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


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のエクスポート結果もここに格納

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



• 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

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


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

EC2instance

Read ReplicaRead Replica

RDS

WebServer

ap-northeast-1aReader

ap-northeast-1cReaderReader

Aurora

Writer

EC2instance

EC2instance

MultiAZ分の費用がかからない


インスタンスタイプ

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


CloudFrontでCDN化


MySQLのRDS化





CDN(Content Delivery Network)とは

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

CDNなし CDNあり

エッジロケーション


CloudFrontの導入前の画像アクセスフロー

EC2instance

EC2

App

User

S3

NFS

Route531.サムネイル要求

2.サムネイル存在チェック→なし

3.元画像を要求4.サムネイル作成

1回目 2回目

EC2instance

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


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


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 山形]


Engineering

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