Contenu connexe
Similaire à 【JAWS UG 山形】ランサーズでのAWS活用事例 (20)
【JAWS UG 山形】ランサーズでのAWS活用事例
- 2. © 2016 for LANCERS, inc All Rights Reserved
自己紹介
• 氏名:金澤 裕毅
• 出身:宮城県仙台市
• 学歴:山形大学大学院理工学研究科
• 平中研究室(ネットワーク専攻)
• 職歴:
• 第一期(2002年~2010年)
• Windowsパッケージ開発
• ASP開発、インフラ担当
• 札幌に2年間転勤
• 第二期(2010年~2013年11月)
• 不動産ポータル、地域SNS
• 第三期(2013年11月~現在)
• ランサーズ株式会社 インフラエンジニア
• 所属:JAWS-UG 山形支部
- 3. © 2016 for LANCERS, inc All Rights Reserved
本日お話しさせていただく内容
ランサーズ(株)のご紹介
AWS移行とVPC設計
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
- 4. © 2016 for LANCERS, inc All Rights Reserved
ランサーズ(株)のご紹介
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
AWS移行とVPC設計
- 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/
- 11. © 2016 for LANCERS, inc All Rights Reserved 10
AWS移行とVPC設計
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
ランサーズ(株)のご紹介
- 12. © 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
EC2
instance
WebSocket
ErastiCache
Memcached
ErastiCache
Redis
Aurora
Writer
- 13. © 2016 for LANCERS, inc All Rights Reserved
なぜAWSに移行しようと思ったのか
12
HDD圧迫(大容量プランにするか???)
Appサーバメモリ逼迫(4GBだったため、不足。。。)
スケールしない(AP2台 DB2台の構成 DNSラウンドロビンだった)
⇒契約したプラン上、1台だけ増やす、HDD増量が出来ない
移行を考え出した「きっかけ」
2012年からサービス拡大期へ
TV紹介も狙い出す
AWS移行前の「問題例」
どれぐらいアクセス
が増えるのか?
TV効果は一時的?
- 14. © 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ラウンド
ロビン
- 15. © 2016 for LANCERS, inc All Rights Reserved
AZを分散して冗長化(2014/5)
- 16. © 2016 for LANCERS, inc All Rights Reserved
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
- 17. © 2016 for LANCERS, inc All Rights Reserved
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
- 18. © 2016 for LANCERS, inc All Rights Reserved
ランサーズのEC2運用
AWS移行とVPC設計
MySQLのRDS化
CloudFrontでCDN化
CloudSearchで全文検索化
ランサーズ(株)のご紹介
- 19. © 2016 for LANCERS, inc All Rights Reserved
コストパフォーマンスの高いインスタンスを探す
• AWS Price List API から価格データを取得
• 月額日本円に換算
- 20. © 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クレジット数は違うので注意
- 21. © 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最適化
メモリ最適化
現行世代
旧世代
- 22. © 2016 for LANCERS, inc All Rights Reserved
メモリを節約するテクニック
• 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
- 23. © 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 10
MinSpareServers 10
MaxSpareServers 20
ServerLimit 190
MaxClients 190
MaxRequestsPerChild 50
</IfModule>
プロセスをこまめに削
除してメモリを確保
移行前 移行後
- 24. © 2016 for LANCERS, inc All Rights Reserved
EC2インスタンスの料金体系
• オンデマンドインスタンス
• 時間単位
• リザーブドインスタンス
• 1年、または3年単位でまとめ買い
• No Upfront (前払い無し)
• Partial Upfront (一部前払い)
• All Upfront (全額前払い)
• →50%~75%の割引
• スポットインスタンス
• 入札方式のインスタンス
• 入札価格より高くなると削除される
• →最大90%割引
• ※t2系はサポートしていない
- 25. © 2016 for LANCERS, inc All Rights Reserved
リザーブドインスタンスの損益分岐点(c4.large)
オンデマンド
リザーブド3年
一括払い
リザーブド1年
一括払い
スポット(目安)
リザーブド1年
損益分岐点(8ヶ月)
リザーブド3年
損益分岐点(17ヶ月)
- 26. © 2016 for LANCERS, inc All Rights Reserved
スポットインスタンスの活用
• t1.microの料金
• オンデマンドインスタンス
• $0.026/h(¥1,935/月)
• スポットインスタンス(時価目安)
• 約$0.0031/h(約¥231/月)
• スポットインスタンスのPricing History
• c系インスタンスは競争が激しい
• t1.microは平和な傾向
時々高騰して削除される
- 27. © 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
- 28. © 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.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
- 29. © 2016 for LANCERS, inc All Rights Reserved
MySQLのRDS化
ランサーズのEC2運用
AWS移行とVPC設計
CloudFrontでCDN化
CloudSearchで全文検索化
ランサーズ(株)のご紹介
- 30. © 2016 for LANCERS, inc All Rights Reserved
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化後
- 31. © 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
- 32. © 2016 for LANCERS, inc All Rights Reserved
RDS(MySQL)のメリット
• リードレプリカ(参照専用スレーブ)を手軽に作成できる
• メニューから選択するだけ
- 33. © 2016 for LANCERS, inc All Rights Reserved 32
RDS(MySQL)のメリット
• ポイントタイムリカバリ
• 任意の時間にDBを戻すことが可能
• 35日前まで保管可能(要設定)
- 34. © 2016 for LANCERS, inc All Rights Reserved
RDS(MySQL)のメリット
• ClowdWatch
• EC2よりも豊富(空きメモリ、空きHDDも確認可)
- 35. © 2016 for LANCERS, inc All Rights Reserved 34
RDS(MySQL)のメリット
• スナップショット機能
• Manual Snapshot
• 手動スナップショット
• インスタンス削除時に取得するか訊かれる
• Automated Snapshot
• 毎日自動的に取得される差分スナップショット
• 35日間まで取得可能
• マスターDBが消えると削除される
- 36. © 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
バックアップ専用
利用不可
- 37. © 2016 for LANCERS, inc All Rights Reserved 36
RDS(MySQL)のデメリット
• 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
- 38. © 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)
- 39. © 2016 for LANCERS, inc All Rights Reserved
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
- 40. © 2016 for LANCERS, inc All Rights Reserved
Auroraの登場
• クラウドを前提にMySQLを再構築
• 2014/11に発表
• 2015/10 より東京リージョンでも利用可能に
• →ランサーズでは、2016/1にAuroraに移行
- 41. © 2016 for LANCERS, inc All Rights Reserved
Auroraのメリット:パフォーマンス
• レプリケーションの効率化
• Log structured Storage
• 他多数…
RDS Aurora
MasterとReplicaのストレージが共有されている
- 42. © 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のストレージが共有されている
- 43. © 2016 for LANCERS, inc All Rights Reserved
Aurora移行後のReplica Lag
RDS Aurora
• Auroraはほぼ30ms以下
- 44. © 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秒以下
• メンテナンスなしのカラム追加が可能に
- 45. © 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台
- 46. © 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
EC2
instance
Read ReplicaRead Replica
RDS
WebServer
ap-northeast-1a
Reader
ap-northeast-1c
ReaderReader
Aurora
Writer
EC2
instance
EC2
instance
MultiAZ分の
費用がかから
ない
- 47. © 2016 for LANCERS, inc All Rights Reserved
インスタンスタイプ
• インスタンスクラスはdb.r3.large以上(2016/11/5現在)
• t2系のインスタンスが今後サポートされる予定
- 48. © 2016 for LANCERS, inc All Rights Reserved
CloudFrontでCDN化
ランサーズのEC2運用
MySQLのRDS化
CloudSearchで全文検索化
AWS移行とVPC設計
ランサーズ(株)のご紹介
- 49. © 2016 for LANCERS, inc All Rights Reserved
CDN(Content Delivery Network)とは
• Web配信のために最適化されたネットワーク
• 世界の各地にキャッシュサーバ(エッジロケーション)を配置
• 一番近いエッジロケーションがキャッシュしたコンテンツを返す
CDNなし CDNあり
エッジロケーション
- 50. © 2016 for LANCERS, inc All Rights Reserved
CloudFrontの導入前の画像アクセスフロー
EC2
instance
EC2
App
User
S3
NFS
Route531.サムネイル要求
2.サムネイル存在チェック
→なし
3.元画像を要求4.サムネイル作成
1回目 2回目
EC2
instance
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
- 51. © 2016 for LANCERS, inc All Rights Reserved
CloudFrontの導入後の画像アクセスフロー
EC2
App
User
S3
Route531.サムネイル要求
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
- 52. © 2016 for LANCERS, inc All Rights Reserved
CloudFrontの適用
• Distributionの設定
• Route53でDNSのレコードを変更
• Webサーバーの設定変更
<VirtualHost *:80>
- ServerName img.lancers.jp
+ ServerName img-origin.lancers.jp
- 53. © 2016 for LANCERS, inc All Rights Reserved
CloudSearchで全文検索化
ランサーズのEC2運用
MySQLのRDS化
CloudFrontでCDN化
AWS移行とVPC設計
ランサーズ(株)のご紹介
- 54. © 2016 for LANCERS, inc All Rights Reserved
全文検索とは
• SQLのLIKEは前方一致しかインデックスが効かない
SELECT * FROM users WHERE user_name LIKE '金澤%' -- 前方一致インデックスで検索可能
SELECT * FROM users WHERE user_name LIKE '%金澤%' -- 中間一致、後方一致はインデックス不可
- 55. © 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
- 56. © 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では未サポート
- 57. © 2016 for LANCERS, inc All Rights Reserved
CloudSearchのメリット
• EC2でSolrを構築するのに比べて
• インストール作業不要
• Dashboardから新規ドメインを作成
• 自動スケールアウト
• 自動スケールアップ
• Multi AZ機能をサポート
• 冗長性を確保可能
スケールの設定
MultiAZの設定
Indexの設定