ランサーズで積み重ねたSRE的取り組みとこれから

2018/2/20 TechPlay
ランサーズ株式会社
インフラエンジニア／金澤裕毅
ランサーズで積み重ねた
SRE的取り組みとこれから

View Slide

2018/2/20 TechPlay
自己紹介

View Slide

2018/2/20 TechPlay
自己紹介 3
氏名：金澤裕毅
出身：宮城県仙台市
入社時期：2013年11月
略歴：
大学時代はネットワークを専攻
Windowsパッケージ開発(C++)
ASP開発(Java)&インフラ(オンプレ)
SNS開発(PHP)&インフラ(オンプレ)
ランサーズのインフラ(AWS)

View Slide

2018/2/20 TechPlay
ランサーズの提供サービス
インフラチーム
サービス安定化の取り組み
負荷、レスポンス対策（アプリ）
負荷、レスポンス対策（DB）
定型作業の自動化と委譲
定型作業の自動化と委譲（開発環境）
定型作業の自動化と委譲（リリース）
削除
今後の計画

View Slide

2018/2/20 TechPlay
6
デジタルマーケティング
クラウドソーシングシェアリングエコノミー
2016/4
サービス開始
2017/6末
サービス開始
2017夏
サービス開始
2016/4
サービス開始
2008/12
サービス開始

View Slide

2018/2/20 TechPlay
7
APIシステム
コーポレートサイト
お知らせ
Quantトップページ
認証システム
広告システム
メールシステム
管理画面
電話確認システム
分析システム
クラウドソーシング

View Slide

2018/2/20 TechPlay
8
ランサーズを支える技術

View Slide

2018/2/20 TechPlay
9
ランサーズのサーバー構成図（2012/5 – ）AWS移行初期
App
S3
ELB App
Route53
EC2
instance
WebSocket
Memcached
DB
Slave
DB
Master
EC2
EC2
instance
EC2
instance
EC2
instance
EC2
instance
EC2
instance
NFS
EC2
instance

View Slide

2018/2/20 TechPlay
10
ランサーズのサーバー構成図（現在）
App
S3
ELB App
CloudFront Cloud Search
Route53
EC2
instance
WebSocket
ErastiCache
Memcached
ErastiCache
Redis
Aurora
Reader
Aurora
Writer
Api
ELB Api
EC2
EC2
instance
ErastiCache
Redis
EC2

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
インフラメンバーとサービス数 12
アプリエンジニアが兼任
インフラ専任1名 + アプリエンジニア
2008 / 12
2013 / 11
2016 / 3
2017 / 10
インフラ専任2名 + アプリエンジニア
インフラ専任2名 + 新卒1名 + インターン1名 + アプリエンジニア
5
10
15
25
20

View Slide

2018/2/20 TechPlay
インフラチームの方針 13
●最新のサービス、最新バージョンに追従する
○変化を恐れず、競争力を確保する
○旧バージョンをカスタマイズしない
■最新バージョンを維持し、OSSに貢献する
○新サービスのノウハウを社外にも共有する
●インフラチームをボトルネックにしない
○差し込みの依頼は即対応
●サーバー運用に留まらず、事業の加速を支援する
○開発環境の支援
○リリースの支援
○分析環境の支援

View Slide

2018/2/20 TechPlay
インフラチームの業務 14
サーバー運用
安定化
レスポンス改善
負荷改善
冗長化
セキュリティ対策
最新バージョン追従
リソース管理
新サービスローンチ支援
キャパシティプランニング
ドメイン、SSL証明書、リポジトリ管理
サーバー費用削減
旧サービス、旧機能の削除
効率化
サーバーのコード化
定型作業の自動化
開発支援
開発環境構築
リリースシステム構築
旧ソースの削除
社内インフラ、情シス系
社内サーバー
社内LAN
PC周り
定型作業の委譲
他

View Slide

2018/2/20 TechPlay
サーバー運用
安定化
負荷改善
冗長化
リソース管理
効率化
開発支援
開発環境構築
社内サーバー
社内LAN
PC周り
他
●SREとして認知されている業務

View Slide

2018/2/20 TechPlay
サーバー運用
安定化
負荷改善
冗長化
リソース管理
効率化
開発支援
開発環境構築
社内サーバー
社内LAN
PC周り
他
●ランサーズのインフラチームが重視している業務
インフラチームを介さずに
完結できる仕組みの構築

View Slide

2018/2/20 TechPlay
サーバー運用
安定化
負荷改善
冗長化
リソース管理
効率化
開発支援
開発環境構築
社内サーバー
社内LAN
PC周り
他
●スタートアップで必要とされる業務
組織が拡大すれば
管理部に委譲できる
クラウド化も選択肢

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
MyIsam→InnoDBに移行 19
●MySQLのFULLTEXT インデックスが度々壊れ、サービスが全停止
○MySQL5.1ではMyISAMでしか利用できなかった
■トランザクション未対応
●RDSに移行し、MySQL5.6にバージョンアップ
○InnoDBでFULLTEXT インデックスが利用できるように
■トランザクション対応
DB
Master
DB
Slave001
DB
Slave002
DB
Slave003
DB
Slave004
DB
MultiAZ
DB
Master
DB
Slave001
EC2 EC2
DB
Slave002
EC2
DB
Slave003
EC2
DB
Slave004
EC2
MySQL5.1
MySQL5.6

View Slide

2018/2/20 TechPlay
CakePHP Viewキャッシュの廃止（NFSの廃止） 20
●TOPページが真っ白になる障害が度々発生
○NFSに格納したCakePHPのビューキャッシュが原因
■複数台の同時書き込み時に発生していた
●Memcachedに移行してViewキャッシュを廃止
○開発スピードも向上
■アプリ側のビューキャッシュ処理がなくなり処理がシンプルに
●NFSも廃止
○SPOF（単一障害点）の解消
EC2
EC2
instanc
e
NFS
App
MemCached
EC2
instance
View
Cache
EC2
App

View Slide

2018/2/20 TechPlay
21
VPCの細分化、MultiAZ化
AWS Cloud
Virtual Private Cloud
ap-northeast-1c
Master Slave001
Slave003
Batch1
KPI
EC2
instance
EC2
App
ap-northeast-1a
Asterisk
EC2
instance
PrivateApp
EC2
instance EC2
App
Route53
10.0.151.0/24
10.0.52.0/24 10.0.152.0/24
EC2
10.0.51.0/24
Slave002
Mail
Websocket
EC2
instance
EC2
instance
LJP
EC2
instance
Gateway
LJPPrivate LJP
10.0.104.0/24
10.0.106.0/24
10.0.150.0/24
10.0.6.0/24
10.0.4.0/24
10.0.1.0/24 10.0.101.0/24
NAT
10.0.50.0/24
S3 Bucket
EC2
instance
NAT
EC2
instance
MultiAZ
Master Slave001
Batch KPI
EC2
instance
EC2
Ap
ap-northeast-1b
Asterisk
EC2
instance
PrivateApp
EC2
instance
EC2
10.0.1.0/24
Mail
Websocket
EC2
instance
EC2
instance
LJP LJPPrivate
NAT
10.0.0.0/24
EC2
instance
Slave002
Slave003
●新インスタンスが使えるAZに引っ越し
○2つのAZに分散し、サブネットを細分化
新インスタンスが
使えないAZ

View Slide

2018/2/20 TechPlay
2つのAZに分散する意味 22
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レベル
Route53

View Slide

2018/2/20 TechPlay
2つのAZに分散する意味 23
RDS Multi AZ RDS Master
RDS 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
Route53
●AZレベルの障害を想定

View Slide

2018/2/20 TechPlay
Auroraへの移行 24
●レプリカ遅延対策
○10sを超えることもあり、データ齟齬の原因となっていた
○Aurora移行後、30ms以下に改善
●ストレージが自動拡張されるようになり、管理性も向上
RDS Aurora
lancers000 lancers001 lancers002 lancers003
DB
Master
DB
Slave001
DB
Slave002
DB
Slave003
DB
MultiAZ
10sを超えることも
ほぼ30ms以下

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
26
負荷、レスポンス対策
●サーバー負荷、レスポンスは継続的に改善が必要
○放っておくと悪化する一方
●負荷、レスポンスの悪化要因
○アクセス数の増加
○データ数の増加
○サービスの機能追加
●レスポンスの種類
○サーバーレスポンス
■極端に遅いページが1つでもあるとユーザーは不快に感じる
●DBが原因であることがほとんど
○ブラウザレスポンス
■CDN等で対策
■フロントエンジニアやデザイナーと協力して改善

View Slide

2018/2/20 TechPlay
27
アプリケーションサーバーのチューニング
●AWSのサーバーサイズに合わせた設定が必要
○メモリ、CPU比率が固定されている
●CPU最適化インスタンスの場合
■c4.large
●2コア
●3.75GB
■c4.xlarge
●4コア
●7.5GB
●CPUを利用してメモリを節約
移行前移行後

StartServers 10
MinSpareServers 10
MaxSpareServers 20
ServerLimit 190
MaxClients 190
MaxRequestsPerChild 50

デフォルトは3000
プロセスをこまめに削除
してメモリを確保

View Slide

2018/2/20 TechPlay
28
アプリケーションサーバーの負荷、レスポンス対策
●ELBのSSL Terminationの利用
○EC2内はhttpで処理
■SSL機能を使わなくなり、メモリ使用量が半減
●CDN（CloudFront）の利用
○静的ファイルをCloudFrontにキャッシュ
■ブラウザレスポンスの改善
■リクエスト削減によるサーバー負荷の改善
EC2
ELB
https://www.lancers.jp/ http://www.lancers.jp/
SSL
Terminate
EC2
ELB
EC2
ELB
https://static.lancers.jp/
CloudFront
https://static.lancers.jp/

View Slide

2018/2/20 TechPlay
29
サーバーのスケールアップ
●M1系インスタンス時代（サーバーレスポンス1000ms超）
●M1系→ C3系インスタンスへ移行

View Slide

2018/2/20 TechPlay
30
サーバーのスケールアップ
●C3系→C4系インスタンスへの移行
○PV → HVM AMIへ移行
■Ansibleでコード化
●CentOS6 → Amazon Linuxで再構築
○ミドルウェアのバージョンが最新に
○EBS最適化
○拡張ネットワーキング
○Magnetic → SSD
負荷、レスポンス改善の取り組み
アプリケーションサーバー

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
32
スロークエリの監視
●1分毎にスロークエリをチェック
○以下のSQLで取得
●取得結果をChatWorkに通知
SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'

View Slide

2018/2/20 TechPlay
33
インデックスチューニング
●無計画に作成されたインデックスの見直し
○MySQLは1テーブルにつき1インデックスしか使えない
○MySQLは常に最適なインデックスを選択してくれるとは限らない
■適切でない複合インデックスを選択する場合も
●インデックスの掃除から開始
○適切でないインデックスの削除
■概ね改善するが、一部のクエリが悪化する場合も
●事前に悪化するクエリを検出しておく必要がある

View Slide

2018/2/20 TechPlay
34
インデックス変更前後のクエリ速度比較スクリプト
●ランサーズの各画面で流れるクエリログをスクリプト化
○インデックスの変更前後でレスポンス値を比較
$ ./sql_measure.sh
help_beginner 62
mypage_experience 19
mypage_menu 18
mypage_profile 752
mypage_portfolio_lists 118
…
profile_search 38
skill 69
top 17168
…
user_login 63
work_create_expert 13
work_create_start 30
work_competition_logo 14
work_search 45
work_search_logo 107
work_search_all_budgetfrom 118
work_search_all_deadline 47
work_search_all_started 49
work_search_business 253
work_search_design 341
work_search_media 131
work_search_system 195
work_search_task 312
work_search_translation 94
work_search_web 270
work_search_writer 187
…
インデックス削除後に
悪化するクエリ

View Slide

2018/2/20 TechPlay
36
SQLのCOUNT文をなくす
● 旧TOPページの仕事カテゴリ一覧

View Slide

2018/2/20 TechPlay
37
● 旧TOPページの仕事カテゴリ一覧
○ 数十個のCOUNT文

View Slide

2018/2/20 TechPlay
38
●日次バッチで更新しキャッシュするように修正
○DB1台削減できた

View Slide

2018/2/20 TechPlay
39
全文検索への移行
●ランサー検索をCloudSearchに移行
○DB負荷が半減
lancers
000
lancers
001
lancers
002
lancers
003
Cloud
Search
App
EC2
ランサー検索

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
サーバーのコード化 41
●PV AMI→HVM AMI移行のタイミングで導入
○AMIでの移行が困難なため新規に構築する必要があった
○現サーバー仕様を把握することから始まった。。。
■漏れなく再現しないと障害に
●新規サービスを新VPCに作成するタイミングで導入
●インフラの構成変更も管理

View Slide

2018/2/20 TechPlay
42
データ取得作業の委譲
●SSH Tunnelingサーバー経由でPrivate VPCの参照用Readerに接続
○エンジニア以外の社員もSQLでデータ取得
EC2
Aurora
Reader
SSH
Tunneling
SQLクライアント
接続先：SSH Tunnelingサーバー
接続ポート：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

View Slide

2018/2/20 TechPlay
43
アクセスログのAthena対応
App
S3
ELB App
EC2
instance
Log
EC2
EC2
instance
Amazon
Athena
time:2018-02-15T11:38:53+09:00
server_addr:10.0.6.11
host:xxx.xxx.xxx.xxx
method:GET
reqsize:1624
uri:/mypage/
query:
status:200
size:83
referer:https://www.lancers.jp/mypage/?ref=header_text
ua:Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
forwardedfor:180.63.228.57
reqtime:0.080
apptime:0.080
user_id:1701012
alternative_id:-
timecard_env:-
{
"time":"2018-02-15T11:38:53+09:00 ",
"server_addr":"10.0. 6.11",
"host":"xxx.xxx.xxx.xxx",
"method":"GET",
"reqsize":"1624",
"uri":"/mypage/ ",
"query":"",
"status":"200",
"size":“83",
"referer":"https://www.lancers.jp/mypage/?ref=header_text ",
"ua":"Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
forwardedfor:180.63.228.57 reqtime:0.278 ",
"forwardedfor":"111.239.118.99",
"reqtime":"0.080",
"apptime":"0.080",
"user_id":"1701012",
"alternative_id":"-",
"timecard_env":"-"
}
●Nginxログをタグ付きのフォーマットに
○解析しやすい形式に変更
●td-agentでlogサーバーに変更
○JSON形式でS3に格納
■AthenaでSQLアクセス可能に
SQLでアクセス可能
User Analyst

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
開発環境構築の自動化と委譲 45
●Dockerで常に最新の開発環境を提供（後述）
●GitHub Wikiに構築手順を集約
○リモートでも構築しやすい環境に

View Slide

2018/2/20 TechPlay
46
ランサーズ開発環境の歴史（2008 ~ 2010）
●開発人数：2人
●PC環境
○Windowsデスクトップ
●開発環境
○Linuxサーバーに直接ログイン
■CentOS
●開発ツール
○ソース管理：SVN
○直接ログインしてVimで開発

View Slide

2018/2/20 TechPlay
47
●開発人数：4人～10人
●PC環境
○デザイナーはMac
●開発環境
○社内開発サーバー（VMWare ESXi）
●開発ツール
○ソース管理：SVN
○直接ログインしてVimで開発
○ssh経由でIDEを使う人も

View Slide

2018/2/20 TechPlay
48
●開発人数：10人～20人
●PC環境
○エンジニアもMacに移行し始める
●開発環境
○VirtualBox + Vagrant
○Ansibleで個人PC内に開発環境を構築
■アプリチームで管理
●開発ツール
○ソース管理：SVN→Githubに移行
○PC上のエディタで開発
■VirtualBox共有フォルダ
○PHP Stormでデバッグする人も

View Slide

2018/2/20 TechPlay
49
●開発人数：20人以上
●PC環境
○ほとんどMac
○Windowsは数人
●開発環境
○VirtualBox + Docker Toolbox
○Dockerfile + Ansibleでコンテナ構築
■インフラチームで管理
■開発者は構築済のコンテナをpullするだけ
●開発ツール
○ソース管理：Github
■VirtualBox共有フォルダ Dockerマウント
○PHP Stormのデバッグも可能

View Slide

2018/2/20 TechPlay
50
ランサーズ開発環境の歴史（2017 ~ ）
●開発人数：20人以上
●PC環境
○Mac
○Windows
○Linux
●開発環境
○Docker For Mac(Windows)
○Dockerfile + Ansibleでコンテナ構築
○インフラチームで管理
■開発者は構築済のコンテナをpullするだけ
●開発ツール
○ソース管理：Github
■Dockerマウント or Docker Sync
○PHP Stormのデバッグも可能

View Slide

2018/2/20 TechPlay
51
Dockerへ移行した理由
192.168.33.11
HDD 50GB
メモリ 2GB
App（ランサーズ本体）
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
Memcached（11211）
●マシンリソース問題
○新規サービス開発の度にVMを作成

View Slide

2018/2/20 TechPlay
52
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
192.168.33.12
HDD 50GB
メモリ 1GB
メッセージ（チャット）
Nginx（3443）
node.js（3001）
Redis（6379）

View Slide

2018/2/20 TechPlay
53
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
192.168.33.13
HDD 50GB
メモリ 1GB
WordPress
（コーポレート、ブログ等）
Apache 2.4(80)
PHP 5.5
MySQL 5.6(3306)
192.168.33.12
HDD 50GB
メモリ 1GB
Nginx（3443）
node.js（3001）
Redis（6379）

View Slide

2018/2/20 TechPlay
54
192.168.33.15
HDD 50GB
メモリ 1GB
認証システム
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
192.168.33.13
HDD 50GB
メモリ 1GB
WordPress
Apache 2.4(80)
PHP 5.5
MySQL 5.6(3306)
192.168.33.12
HDD 50GB
メモリ 1GB
Nginx（3443）
node.js（3001）
Redis（6379）

View Slide

2018/2/20 TechPlay
55
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
●VMを1つにまとめる

View Slide

2018/2/20 TechPlay
56
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
Nginx（3443）
node.js（3001）
Redis（6379

View Slide

2018/2/20 TechPlay
57
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
Nginx（3443）
node.js（3001）
Redis（6379）
WordPress
Apache 2.4(80)
PHP 5.5
MySQL 5.6(3306)
○バージョン混在の問題
○言語別、バージョン別に環境が欲しい

View Slide

2018/2/20 TechPlay
58
Vagrant + Ansible時代の問題点
●構築に時間がかかる
○PHP、MySQLのビルド時間：1.5時間
○MySQLのインポート時間：2.5時間以上
●構成更新時の問題
○Appサーバーに新しいミドルウェアを追加
■Ansible PlaybookにPRを投げる
●誰が検証するの？
○検証中は開発できない
○再構築も時間がかかる（元に戻らないリスクも）
●誰もPlaybookを更新しなくなる
○更新差分は手動でカバー
○原因不明のエラーがさらに増える
●Windows環境での構築が不安定
○Virtualbox、Vagrant、Ansibleのバージョン相性がシビア
■成功率50%以下
○Windowsユーザーが激減

View Slide

2018/2/20 TechPlay
59
VMをDockerに置き換え
192.168.33.15
HDD 50GB
メモリ 1GB
認証システム
192.168.33.11
HDD 50GB
メモリ 2GB
Apache 2.2 (80)
PHP 5.3
MySQL 5.6 (3306)
192.168.33.13
HDD 50GB
メモリ 1GB
WordPress
Apache 2.4(80)
PHP 5.5
MySQL 5.6(3306)
192.168.33.12
HDD 50GB
メモリ 1GB
Nginx（3443）
node.js（3001）
Redis（6379）
HDD 20GB
メモリ 2GB
172.17.6.11
Apache 2.2 (80)
PHP 5.3
172.17.4.51
コーポレート、ブログ等）
Apache 2.4(80)
PHP 5.5
172.17.4.152
Nginx（3443）
node.js （3001）
172.17.106.55
認証システム
新サービス開発の度に
VMを作成
1つのVMに
各種コンテナを配置

View Slide

2018/2/20 TechPlay
60
Docker移行の方針
●本番環境と極力同じ構成を再現
○AWSのマネージド系のサービス
■Dockerfileで作成
○AWSのEC2で構築しているサーバー
■Dockerfile + Ansibleで作成
■Ansibleを実行するコンテナを用意
●本番と同じPlaybookで構築
App
ELB
ErastiCache
Memcached
ErastiCache
Redis
Aurora
EC2
instance
Wordpress
EC2
instance WebSocket App
Redis MySQL
ELB
WordPress
Memcached
WebSocket
EC2
instance
ELB
RDS
ELB
SSL Terminate
リバースプロキシ
データ入り

View Slide

2018/2/20 TechPlay
61
Docker移行の方針
EC2
MySQLデータ
開発用データ
App
Ansible
WordPress MySQL
WebSocket
WordPress
App WebSocket
MySQL
Playbook
docker
push
docker
pull
docker
build
Amazon ECR
●構築に時間をかけない
○コンテナをpullするだけで完了
コンテナは
インフラチームが構築
アプリチームは
コンテナをpullするだけ

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
63
リリースの自動化と委譲
●Webからリリース可能なシステムを構築
○アプリエンジニアやデザイナーでもリリース可能

View Slide

2018/2/20 TechPlay
64
リリースフロー
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
Developer
●Githubにpush

View Slide

2018/2/20 TechPlay
65
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
Developer
●Webデプロイシステムからリリース

View Slide

2018/2/20 TechPlay
66
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
Developer
●DeployサーバーがGithubからpull

View Slide

2018/2/20 TechPlay
67
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
composer
install
Developer
●composer installの実行
○開発用Appコンテナを起動

View Slide

2018/2/20 TechPlay
68
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
rsync
Developer
●カナリア環境にrsync
○最終確認

View Slide

2018/2/20 TechPlay
69
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
rsync
Developer
●本番環境にrsync

View Slide

2018/2/20 TechPlay
70
リリースシステム
EC2
App
Deploy
EC2
instance
EC2
Canaria App
EC2
instance
S3
Cloud Front
rsync
静的
ファイル
キャッシュ
クリア
composer
install
node
install
go
build
Wordpress
EC2
instance
EC2
Api
Developer
●ランサーズ以外のサービスにも拡張
○unicornの再起動
○S3への配置
○CloudFrontのキャッシュクリア

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
72
不要なサービス、ソースコードの削除
●不要サービス、機能の削除
○更新されず、効果の薄いサービスや機能の削除
■残しておくとセキュリティ面のリスクを抱える
○ほとんど交渉作業
■オーナー不在の場合が多い
●何のために作ったのかもはや理由が曖昧なことも
●ソースコードの削除
○一時的に残しておいてそのまま放置されたソースなど
○使われないソースが検索でヒットすると初見の開発者が混乱
■生産性低下の原因に

View Slide

2018/2/20 TechPlay
削除
今後の計画

View Slide

2018/2/20 TechPlay
74
新バージョンへの対応
●PHP、CakePHPのバージョンアップ
○2017年から本格的に開始
■現在：PHP 5.3 + CakePHP 1.3
○バージョンアップ手順
■Apache + mod_php → Nginx + PHP-FPM
■CakePHP 1.3 → CakePHP 2.8
■PHP 5.3 → PHP 5.6
■CakePHP 2.8 → CakePHP 2.9
■PHP 5.6 → PHP 7
■CakePHP 2.9 → CakePHP 3
●MySQLのバージョンアップ
○Aurora MySQL 5.6 → 5.7
■開発環境で検証中
●MySQLコンテナを5.7に更新
イマココ

View Slide

2018/2/20 TechPlay
75
分析基盤の構築
●ログのリアルタイム解析
●DBやZendeskの問い合わせログも集約したDHWの作成
●過去ログのAthena対応
App
S3
ELB App
EC2
instance
Log
EC2
EC2
instance
Athena
User Analyst
Aurora
Elasticserch
Service

View Slide

2018/2/20 TechPlay
76
本番環境のDocker化、API化、マイクロサービス化、サーバーレス化
●本番環境のDocker化
○アプリエンジニアが開発、リリース、運用を全て行える仕組み
○リリース時間の短縮が課題
●API化の促進
○言語に依存しないサービス運用環境
○開発スピードの改善
○アプリチームの責任範囲を明確にする
●マイクロサービス化
○モノリシックのまま膨れ上がったプロダクトを分割
●サーバーレスで済む機能は積極的にサーバーレス化
○運用工数の削減
○サーバー費用の削減
Amazon ECR Amazon ECS
Amazon API
Gateway
AWS
Lambda

View Slide

2018/2/20 TechPlay
77
SREチームの設立
●チーム体制でSREを行う
○事業横断チーム
●初期サービスのPDCAサイクルのスピードアップ
○アプリエンジニアで運用まで完結する仕組みの構築
●各サービスのSREの促進
○ランサーズで培ったノウハウを他サービスにも適用していく
○軌道に乗ったサービス全てにSREを適用したい

View Slide

2018/2/20 TechPlay
78
SREエンジニア採用中！
https://www.wantedly.com/projects/178494

View Slide

2018/2/20 TechPlay
御静聴ありがとうございました！

View Slide

ランサーズで積み重ねたSRE的取り組みとこれから

ランサーズで積み重ねたSRE的取り組みとこれから

Kanazawa Yuki

More Decks by Kanazawa Yuki

Other Decks in Technology

Featured

Transcript