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

2018/2/21 のtechplayで発表した資料です。
https://techplay.jp/event/654623?utm_source=event_654623&utm_medium=social&utm_campaign=feed&utm_content=tw731068152189059073

話したいことはたくさんありましたら時間の関係で結構削りました。

Transcript

1. 2018/2/20 TechPlay ランサーズ株式会社 インフラエンジニア ／ 金澤裕毅 ランサーズで積み重ねた SRE的取り組みとこれから
2. 2018/2/20 TechPlay 自己紹介
3. 2018/2/20 TechPlay 自己紹介 3 氏名：金澤 裕毅 出身：宮城県仙台市 入社時期：2013年11月 略歴： 大学時代はネットワークを専攻 Windowsパッケージ開発(C++) ASP開発(Java)&インフラ(オンプレ) SNS開発(PHP)&インフラ(オンプレ) ランサーズのインフラ(AWS)
4. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
5. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
6. 2018/2/20 TechPlay 6 ランサーズの提供サービス デジタルマーケティング クラウドソーシング シェアリングエコノミー 2016/4 サービス開始 2017/6末 サービス開始 2017夏 サービス開始 2016/4 サービス開始 2008/12 サービス開始
7. 2018/2/20 TechPlay 7 ランサーズの提供サービス APIシステム コーポレートサイト お知らせ Quantトップページ 認証システム 広告システム メールシステム 管理画面 電話確認システム 分析システム クラウドソーシング
8. 2018/2/20 TechPlay 8 ランサーズを支える技術
9. 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
10. 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
11. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
12. 2018/2/20 TechPlay インフラメンバーとサービス数 12 アプリエンジニアが兼任 インフラ専任1名 + アプリエンジニア 2008 / 12 2013 / 11 2016 / 3 2017 / 10 インフラ専任2名 + アプリエンジニア インフラ専任2名 + 新卒1名 + インターン1名 + アプリエンジニア 5 10 15 25 20
13. 2018/2/20 TechPlay インフラチームの方針 13 •最新のサービス、最新バージョンに追従する ◦変化を恐れず、競争力を確保する ◦旧バージョンをカスタマイズしない ▪最新バージョンを維持し、OSSに貢献する ◦新サービスのノウハウを社外にも共有する •インフラチームをボトルネックにしない ◦差し込みの依頼は即対応 •サーバー運用に留まらず、事業の加速を支援する ◦開発環境の支援 ◦リリースの支援 ◦分析環境の支援
14. 2018/2/20 TechPlay インフラチームの業務 14 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策 最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他
15. 2018/2/20 TechPlay インフラチームの業務 15 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策 最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他 •SREとして認知されている業務
16. 2018/2/20 TechPlay インフラチームの業務 16 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策 最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他 •ランサーズのインフラチームが重視している業務 インフラチームを介さずに 完結できる仕組みの構築
17. 2018/2/20 TechPlay インフラチームの業務 17 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策 最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他 •スタートアップで必要とされる業務 組織が拡大すれば 管理部に委譲できる クラウド化も選択肢
18. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
19. 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
20. 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
21. 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
22. 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
23. 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レベルの障害を想定
24. 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以下
25. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
26. 2018/2/20 TechPlay 26 負荷、レスポンス対策 •サーバー負荷、レスポンスは継続的に改善が必要 ◦放っておくと悪化する一方 •負荷、レスポンスの悪化要因 ◦アクセス数の増加 ◦データ数の増加 ◦サービスの機能追加 •レスポンスの種類 ◦サーバーレスポンス ▪極端に遅いページが1つでもあるとユーザーは不快に感じる •DBが原因であることがほとんど ◦ブラウザレスポンス ▪CDN等で対策 ▪フロントエンジニアやデザイナーと協力して改善
27. 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 プロセスをこまめに削除 してメモリを確保
28. 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/
29. 2018/2/20 TechPlay 29 サーバーのスケールアップ •M1系インスタンス時代（サーバーレスポンス1000ms超） •M1系→ C3系インスタンスへ移行
30. 2018/2/20 TechPlay 30 サーバーのスケールアップ •C3系→C4系インスタンスへの移行 ◦PV → HVM AMIへ移行 ▪Ansibleでコード化 •CentOS6 → Amazon Linuxで再構築 ◦ミドルウェアのバージョンが最新に ◦EBS最適化 ◦拡張ネットワーキング ◦Magnetic → SSD 負荷、レスポンス改善の取り組み アプリケーションサーバー
31. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
32. 2018/2/20 TechPlay 32 スロークエリの監視 •1分毎にスロークエリをチェック ◦以下のSQLで取得 •取得結果をChatWorkに通知 SELECT * FROM mysql.slow_log WHERE start_time >= '1分前の時刻'
33. 2018/2/20 TechPlay 33 インデックスチューニング •無計画に作成されたインデックスの見直し ◦MySQLは1テーブルにつき1インデックスしか使えない ◦MySQLは常に最適なインデックスを選択してくれるとは限らない ▪適切でない複合インデックスを選択する場合も •インデックスの掃除から開始 ◦適切でないインデックスの削除 ▪概ね改善するが、一部のクエリが悪化する場合も •事前に悪化するクエリを検出しておく必要がある
34. 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 … インデックス削除後に 悪化するクエリ
35. 2018/2/20 TechPlay 35 インデックスチューニングの具体例 •インデックス対象カラムの置き換え ◦作成日時（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 | +-----------------+---------------------------------------+--------------+---------------------+-------------+
36. 2018/2/20 TechPlay 36 SQLのCOUNT文をなくす • 旧TOPページの仕事カテゴリ一覧
37. 2018/2/20 TechPlay 37 SQLのCOUNT文をなくす • 旧TOPページの仕事カテゴリ一覧 ◦ 数十個のCOUNT文
38. 2018/2/20 TechPlay 38 SQLのCOUNT文をなくす •日次バッチで更新しキャッシュするように修正 ◦DB1台削減できた
39. 2018/2/20 TechPlay 39 全文検索への移行 •ランサー検索をCloudSearchに移行 ◦DB負荷が半減 lancers 000 lancers 001 lancers 002 lancers 003 Cloud Search App EC2 ランサー検索
40. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
41. 2018/2/20 TechPlay サーバーのコード化 41 •PV AMI→HVM AMI移行のタイミングで導入 ◦AMIでの移行が困難なため新規に構築する必要があった ◦現サーバー仕様を把握することから始まった。。。 ▪漏れなく再現しないと障害に •新規サービスを新VPCに作成するタイミングで導入 •インフラの構成変更も管理
42. 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
43. 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
44. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
45. 2018/2/20 TechPlay 開発環境構築の自動化と委譲 45 •Dockerで常に最新の開発環境を提供（後述） •GitHub Wikiに構築手順を集約 ◦リモートでも構築しやすい環境に
46. 2018/2/20 TechPlay 46 ランサーズ開発環境の歴史（2008 ~ 2010） •開発人数：2人 •PC環境 ◦Windowsデスクトップ •開発環境 ◦Linuxサーバーに直接ログイン ▪CentOS •開発ツール ◦ソース管理：SVN ◦直接ログインしてVimで開発
47. 2018/2/20 TechPlay 47 ランサーズ開発環境の歴史（2011 ~ 2013） •開発人数：4人～10人 •PC環境 ◦Windowsデスクトップ ◦デザイナーはMac •開発環境 ◦社内開発サーバー（VMWare ESXi） •開発ツール ◦ソース管理：SVN ◦直接ログインしてVimで開発 ◦ssh経由でIDEを使う人も
48. 2018/2/20 TechPlay 48 ランサーズ開発環境の歴史（2014 ~ 2015） •開発人数：10人～20人 •PC環境 ◦Windowsデスクトップ ◦エンジニアもMacに移行し始める •開発環境 ◦VirtualBox + Vagrant ◦Ansibleで個人PC内に開発環境を構築 ▪アプリチームで管理 •開発ツール ◦ソース管理：SVN→Githubに移行 ◦PC上のエディタで開発 ▪VirtualBox共有フォルダ ◦PHP Stormでデバッグする人も
49. 2018/2/20 TechPlay 49 ランサーズ開発環境の歴史（2016 ~ 2017） •開発人数：20人以上 •PC環境 ◦ほとんどMac ◦Windowsは数人 •開発環境 ◦VirtualBox + Docker Toolbox ◦Dockerfile + Ansibleでコンテナ構築 ▪インフラチームで管理 ▪開発者は構築済のコンテナをpullするだけ •開発ツール ◦ソース管理：Github ◦PC上のエディタで開発 ▪VirtualBox共有フォルダ Dockerマウント ◦PHP Stormのデバッグも可能
50. 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のデバッグも可能
51. 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を作成
52. 2018/2/20 TechPlay 52 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を作成
53. 2018/2/20 TechPlay 53 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を作成
54. 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を作成
55. 2018/2/20 TechPlay 55 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App（ランサーズ本体） Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached（11211） •VMを1つにまとめる
56. 2018/2/20 TechPlay 56 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つにまとめる
57. 2018/2/20 TechPlay 57 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つにまとめる ◦バージョン混在の問題 ◦言語別、バージョン別に環境が欲しい
58. 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ユーザーが激減
59. 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に 各種コンテナを配置
60. 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 リバースプロキシ データ入り
61. 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するだけ
62. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
63. 2018/2/20 TechPlay 63 リリースの自動化と委譲 •Webからリリース可能なシステムを構築 ◦アプリエンジニアやデザイナーでもリリース可能
64. 2018/2/20 TechPlay 64 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer •Githubにpush
65. 2018/2/20 TechPlay 65 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer •Webデプロイシステムからリリース
66. 2018/2/20 TechPlay 66 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer •DeployサーバーがGithubからpull
67. 2018/2/20 TechPlay 67 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance composer install Developer •composer installの実行 ◦開発用Appコンテナを起動
68. 2018/2/20 TechPlay 68 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance rsync Developer •カナリア環境にrsync ◦最終確認
69. 2018/2/20 TechPlay 69 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance rsync Developer •本番環境にrsync
70. 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のキャッシュクリア
71. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
72. 2018/2/20 TechPlay 72 不要なサービス、ソースコードの削除 •不要サービス、機能の削除 ◦更新されず、効果の薄いサービスや機能の削除 ▪残しておくとセキュリティ面のリスクを抱える ◦ほとんど交渉作業 ▪オーナー不在の場合が多い •何のために作ったのかもはや理由が曖昧なことも •ソースコードの削除 ◦一時的に残しておいてそのまま放置されたソースなど ◦使われないソースが検索でヒットすると初見の開発者が混乱 ▪生産性低下の原因に
73. 2018/2/20 TechPlay ランサーズの提供サービス インフラチーム サービス安定化の取り組み 負荷、レスポンス対策（アプリ） 負荷、レスポンス対策（DB） 定型作業の自動化と委譲 定型作業の自動化と委譲（開発環境） 定型作業の自動化と委譲（リリース） 削除 今後の計画
74. 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に更新 イマココ
75. 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
76. 2018/2/20 TechPlay 76 本番環境のDocker化、API化、マイクロサービス化、サーバーレス化 •本番環境のDocker化 ◦アプリエンジニアが開発、リリース、運用を全て行える仕組み ◦リリース時間の短縮が課題 •API化の促進 ◦言語に依存しないサービス運用環境 ◦開発スピードの改善 ◦アプリチームの責任範囲を明確にする •マイクロサービス化 ◦モノリシックのまま膨れ上がったプロダクトを分割 •サーバーレスで済む機能は積極的にサーバーレス化 ◦運用工数の削減 ◦サーバー費用の削減 Amazon ECR Amazon ECS Amazon API Gateway AWS Lambda
77. 2018/2/20 TechPlay 77 SREチームの設立 •チーム体制でSREを行う ◦事業横断チーム •初期サービスのPDCAサイクルのスピードアップ ◦アプリエンジニアで運用まで完結する仕組みの構築 •各サービスのSREの促進 ◦ランサーズで培ったノウハウを他サービスにも適用していく ◦軌道に乗ったサービス全てにSREを適用したい
78. 2018/2/20 TechPlay 78 SREエンジニア採用中！ https://www.wantedly.com/projects/178494
79. 2018/2/20 TechPlay 御静聴ありがとうございました！