2018/7/3 SRE Lounge ランサーズ株式会社 SRE／金澤裕毅 ランサーズで積み重ねた SRE的取り組みとこれから

2018/7/3 SRE Lounge 自己紹介

2018/7/3 SRE Lounge 会社概要 会社名：ランサーズ株式会社 設立：2008年4月 従業員：約170名 事業：クラウドソーシング事業 https://www.lancers.jp/ 所在地： 〒150-0002 東京都渋谷区渋谷 3-10-13 TOKYU REIT 渋谷Rビル 9F

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

2018/7/3 SRE Lounge ランサーズの提供サービス SREチームの歴史 サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

2018/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

2018/7/3 SRE Lounge 7 ランサーズの提供サービス クラウドソーシング シェアリングエコノミー 2017/6 サービス開始 2008/12 サービス開始 2018/7 サービス開始 2017/9 サービス開始

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

2018/7/3 SRE Lounge 9 ランサーズを支える技術

2018/7/3 SRE Lounge ランサーズの提供サービス SREチームの歴史 サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

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

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

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

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

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

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

2018/7/3 SRE Lounge ランサーズの提供サービス SREチームの歴史 サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

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

2018/7/3 SRE Lounge 20 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/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

2018/7/3 SRE Lounge 計測ツール 22 ●レスポンス計測 ○サーバーレスポンス ○ブラウザレスポンス ●エラー分析 ●外形監視 ●サーバーのリソース監視 ○Nagios + Munin → mackerelに移行 ■AWS対応 ■長期間データを保存可能 ■サーバー増加の負荷を気にしなくて良い ■監視サーバーの監視が要らない ●外形監視 ●障害の自動復旧

2018/7/3 SRE Lounge 23 2014/4のサーバーレスポンス

2018/7/3 SRE Lounge 24 2018/5のサーバーレスポンス

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

2018/7/3 SRE Lounge 26 アプリケーションサーバーのチューニング ●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 プロセスをこまめに削除 してメモリを確保

2018/7/3 SRE Lounge 27 アプリケーションサーバーの負荷、レスポンス対策 ●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/7/3 SRE Lounge 28 サーバーのスケールアップ ●M1系インスタンス時代（サーバーレスポンス1000ms超） ●M1系→ C3系インスタンスへ移行

2018/7/3 SRE Lounge 29 サーバーのスケールアップ ●C3系→C4系インスタンスへの移行 ○PV → HVM AMIへ移行 ■Ansibleでコード化 ●CentOS6 → Amazon Linuxで再構築 ○ミドルウェアのバージョンが最新に ○EBS最適化 ○拡張ネットワーキング ○Magnetic → SSD

2018/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

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

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

2018/7/3 SRE Lounge 33 インデックス変更前後のクエリ速度比較スクリプト ●ランサーズの各画面で流れるクエリログをスクリプト化 ○インデックスの変更前後でレスポンス値を比較 $ ./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/7/3 SRE Lounge 34 インデックスチューニングの具体例 ●インデックス対象カラムの置き換え ○作成日時（created）でのソートをidソートに置き換え ■CakePHPは各テーブルにidがつく（Primary Key） ■createdのソート順とidのソート順は基本的に一致する ●カーディナリティの低いインデックスの見直し ○例えば削除フラグ（deleted）（カーディナリティ2） ■deleted = 0のレコードが大多数 ■deleted = 1の検索は滅多に行われない ○複合インデックス ■カーディナリティの低いカラムが先に来ているパターン ●FORCE INDEXの利用 ○一時的な手段として ■定期的に観測が必要 +-----------------+---------------------------------------+--------------+---------------------+-------------+ | Table | Key_name | Seq_in_index | Column_name | Cardinality | +-----------------+---------------------------------------+--------------+---------------------+-------------+ | categorizations | PRIMARY | 1 | id | 12672606 | | categorizations | category_id | 1 | category_id | 29402 | | categorizations | categorization_type | 1 | categorization_type | 3600 | | categorizations | categorization_type_categorization_id | 1 | category_id | 154 | | categorizations | categorization_type_categorization_id | 2 | categorization_type | 6336303 | | categorizations | categorization_type_categorization_id | 3 | categorization_id | 3168151 | +-----------------+---------------------------------------+--------------+---------------------+-------------+

2018/7/3 SRE Lounge 35 SQLのCOUNT文をなくす ● 旧TOPページの仕事カテゴリ一覧

2018/7/3 SRE Lounge 36 SQLのCOUNT文をなくす ● 旧TOPページの仕事カテゴリ一覧 ○ 数十個のCOUNT文

2018/7/3 SRE Lounge 37 SQLのCOUNT文をなくす ●日次バッチで更新しキャッシュするように修正 ○DB1台削減できた

2018/7/3 SRE Lounge 38 全文検索への移行 ●ランサー検索をCloudSearchに移行 ○DB負荷が半減 lancers 000 lancers 001 lancers 002 lancers 003 Cloud Search App EC2 ランサー検索

2018/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

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

2018/7/3 SRE Lounge 41 データ取得作業の委譲 ●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/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

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

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

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

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

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

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

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

2018/7/3 SRE Lounge 50 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） 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を作成

2018/7/3 SRE Lounge 51 Dockerへ移行した理由 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を作成

2018/7/3 SRE Lounge 52 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を作成

2018/7/3 SRE Lounge 53 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） ●VMを1つにまとめる

2018/7/3 SRE Lounge 54 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） メッセージ（チャット） Nginx（3443） node.js（3001） Redis（6379 ●VMを1つにまとめる

2018/7/3 SRE Lounge 55 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） 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/7/3 SRE Lounge 56 Vagrant + Ansible時代の問題点 ●構築に時間がかかる ○PHP、MySQLのビルド時間：1.5時間 ○MySQLのインポート時間：2.5時間以上 ●構成更新時の問題 ○Appサーバーに新しいミドルウェアを追加 ■Ansible PlaybookにPRを投げる ●誰が検証するの？ ○検証中は開発できない ○再構築も時間がかかる（元に戻らないリスクも） ●誰もPlaybookを更新しなくなる ○更新差分は手動でカバー ○原因不明のエラーがさらに増える ●Windows環境での構築が不安定 ○Virtualbox、Vagrant、Ansibleのバージョン相性がシビア ■成功率50%以下 ○Windowsユーザーが激減

2018/7/3 SRE Lounge 57 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/7/3 SRE Lounge 58 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/7/3 SRE Lounge 59 Docker移行の方針 EC2 MySQLデータ 開発用データ App Ansible WordPress MySQL WebSocket WordPress App WebSocket MySQL Playbook docker push docker pull docker build Amazon ECR ●構築に時間をかけない ○コンテナをpullするだけで完了 コンテナは SREチームが構築 アプリチームは コンテナをpullするだけ

2018/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

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

2018/7/3 SRE Lounge 62 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer ●Githubにpush

2018/7/3 SRE Lounge 63 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer ●Webデプロイシステムからリリース

2018/7/3 SRE Lounge 64 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer ●DeployサーバーがGithubからpull

2018/7/3 SRE Lounge 65 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance composer install Developer ●composer installの実行 ○開発用Appコンテナを起動

2018/7/3 SRE Lounge 66 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance rsync Developer ●カナリア環境にrsync ○最終確認

2018/7/3 SRE Lounge 67 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance rsync Developer ●本番環境にrsync

2018/7/3 SRE Lounge 68 リリースシステム 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/7/3 SRE Lounge ランサーズの提供サービス SREチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 今期のSREチーム

2018/7/3 SRE Lounge 2018年度のSREチーム体制 70 デザイナー エンジニア カスタマー サポート バージョンアップ チーム CREチーム システム エスカレーション サービス改善 SREチーム PHP、CakePHP バージョンアップ 新卒エンジニア

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

2018/7/3 SRE Lounge 御静聴ありがとうございました！