ランサーズで積み重ねたSRE的取り組みとこれから（2018/7/3）

2018/7/3 のSRE Loungeで発表した資料です。
https://sre-lounge.connpass.com/event/91566/

2018/2/21 のtechplayで発表した内容のアップデート版になります。

Transcript

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

   View Slide

2. 2018/7/3 SRE Lounge
   自己紹介
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. 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
    

    View Slide

19. 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
    

    View Slide

20. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

26. 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
    プロセスをこまめに削除
    してメモリを確保
    

    View Slide

27. 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/
    

    View Slide

28. 2018/7/3 SRE Lounge
    28
    サーバーのスケールアップ
    ●M1系インスタンス時代（サーバーレスポンス1000ms超）
    ●M1系→ C3系インスタンスへ移行
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. 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 |
    +-----------------+---------------------------------------+--------------+---------------------+-------------+
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

47. 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のデバッグも可能
    

    View Slide

48. 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のデバッグも可能
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

53. 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つにまとめる
    

    View Slide

54. 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つにまとめる
    

    View Slide

55. 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つにまとめる
    ○バージョン混在の問題
    ○言語別、バージョン別に環境が欲しい
    

    View Slide

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

    View Slide

57. 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に
    各種コンテナを配置
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide