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

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

2018/2/20 TechPlay 自己紹介

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

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

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

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

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

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

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

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

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

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

最新バージョン追従リソース管理新サービスローンチ支援キャパシティプランニングドメイン、SSL証明書、リポジトリ管理サーバー費用削減旧サービス、旧機能の削除効率化サーバーのコード化定型作業の自動化開発支援開発環境構築リリースシステム構築旧ソースの削除社内インフラ、情シス系社内サーバー社内LAN PC周り定型作業の委譲他 •SREとして認知されている業務

最新バージョン追従リソース管理新サービスローンチ支援キャパシティプランニングドメイン、SSL証明書、リポジトリ管理サーバー費用削減旧サービス、旧機能の削除効率化サーバーのコード化定型作業の自動化開発支援開発環境構築リリースシステム構築旧ソースの削除社内インフラ、情シス系社内サーバー社内LAN PC周り定型作業の委譲他 •ランサーズのインフラチームが重視している業務インフラチームを介さずに完結できる仕組みの構築

最新バージョン追従リソース管理新サービスローンチ支援キャパシティプランニングドメイン、SSL証明書、リポジトリ管理サーバー費用削減旧サービス、旧機能の削除効率化サーバーのコード化定型作業の自動化開発支援開発環境構築リリースシステム構築旧ソースの削除社内インフラ、情シス系社内サーバー社内LAN PC周り定型作業の委譲他 •スタートアップで必要とされる業務組織が拡大すれば管理部に委譲できるクラウド化も選択肢

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

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

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

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

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レベルの障害を想定

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以下

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

2018/2/20 TechPlay 27 アプリケーションサーバーのチューニング •AWSのサーバーサイズに合わせた設定が必要 ◦メモリ、CPU比率が固定されている •CPU最適化インスタンスの場合 ▪c4.large •2コア •3.75GB
▪c4.xlarge •4コア •7.5GB •CPUを利用してメモリを節約移行前移行後 <IfModule prefork.c> StartServers 10 MinSpareServers 10 MaxSpareServers 20 ServerLimit 190 MaxClients 190 MaxRequestsPerChild 50 </IfModule> デフォルトは3000 プロセスをこまめに削除してメモリを確保

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/

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

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

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

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

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 … インデックス削除後に悪化するクエリ

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

2018/2/20 TechPlay 37 SQLのCOUNT文をなくす • 旧TOPページの仕事カテゴリ一覧 ◦ 数十個のCOUNT文

2018/2/20 TechPlay 38 SQLのCOUNT文をなくす •日次バッチで更新しキャッシュするように修正 ◦DB1台削減できた

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

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

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

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

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

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

2018/2/20 TechPlay 47 ランサーズ開発環境の歴史（2011 ~ 2013） •開発人数：4人～10人 •PC環境 ◦Windowsデスクトップ ◦デザイナーはMac
•開発環境 ◦社内開発サーバー（VMWare ESXi） •開発ツール ◦ソース管理：SVN ◦直接ログインしてVimで開発 ◦ssh経由でIDEを使う人も

2018/2/20 TechPlay 48 ランサーズ開発環境の歴史（2014 ~ 2015） •開発人数：10人～20人 •PC環境 ◦Windowsデスクトップ ◦エンジニアもMacに移行し始める
•開発環境 ◦VirtualBox + Vagrant ◦Ansibleで個人PC内に開発環境を構築 ▪アプリチームで管理 •開発ツール ◦ソース管理：SVN→Githubに移行 ◦PC上のエディタで開発 ▪VirtualBox共有フォルダ ◦PHP Stormでデバッグする人も

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

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

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を作成

Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） 192.168.33.12 HDD 50GB メモリ 1GB メッセージ（チャット） Nginx（3443） node.js（3001） Redis（6379） •マシンリソース問題 ◦新規サービス開発の度にVMを作成

Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） 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） •マシンリソース問題 ◦新規サービス開発の度にVMを作成

2018/2/20 TechPlay 54 Dockerへ移行した理由 192.168.33.15 HDD 50GB メモリ 1GB 認証システム
192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） 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） •マシンリソース問題 ◦新規サービス開発の度にVMを作成

Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） •VMを1つにまとめる

Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211）メッセージ（チャット） Nginx（3443） node.js（3001） Redis（6379 •VMを1つにまとめる

Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211）メッセージ（チャット） Nginx（3443） node.js（3001） Redis（6379） WordPress Apache 2.4(80) PHP 5.5 MySQL 5.6(3306) •VMを1つにまとめる ◦バージョン混在の問題 ◦言語別、バージョン別に環境が欲しい

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ユーザーが激減

2018/2/20 TechPlay 59 VMをDockerに置き換え 192.168.33.15 HDD 50GB メモリ 1GB 認証システム
192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） 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 App（ランサーズ本体） 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に各種コンテナを配置

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 リバースプロキシデータ入り

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するだけ

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

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

Canaria App EC2 instance Developer •Webデプロイシステムからリリース

Canaria App EC2 instance Developer •DeployサーバーがGithubからpull

Canaria App EC2 instance composer install Developer •composer installの実行 ◦開発用Appコンテナを起動

Canaria App EC2 instance rsync Developer •カナリア環境にrsync ◦最終確認

Canaria App EC2 instance rsync Developer •本番環境にrsync

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のキャッシュクリア

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

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に更新イマココ

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

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

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

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

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

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

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

More Decks by Kanazawa Yuki

Other Decks in Technology

Featured

Transcript