デブサミ2018「インフラチームからSREへ〜メルカリを支える新しいインフラのあり方」講演メモ #devsumi

楽しみにしていた kazeburo 先生のセッション。
電車が遅れていたおかげで間に合わないかと思ったけど、自己紹介が始まったところで、なんとか滑り込み。
メモを書いたので貼り付けておきます。

自己紹介

  • 〜2006 京都のスタートアップ
  • 2006〜 mixi
  • 2010〜 Livedoor(NHN, Line)
  • 2015〜 Mercari

SREとの出会い

  • インフラエンジニア?
    • mixi時代は「アプリ運用チーム」
      • インフラチームは別で存在
      • DCチームが用意したサーバの能力を目一杯引き出す
      • アプリチームが開発したコードを最大限能力を引き出す
  • オペレーションエンジニア?
    • オペレーション(ルーチンワーク)と捉える人も多い
  • SREとの出会い
    • 2012/7にIRCで友人から教えてもらう
    • Googleの巨大なインフラとサービスの稼働・安定性を担保するチームがSRE
    • 2015/11 メルカリにてチーム名として提案

メルカリについて

  • 国内最大級のフリマアプリ
  • 3分で簡単に出品
  • 安心安全な決済・取引
    • エスクロー、匿名配送
  • 米国・英国でも展開
  • KPI
    • ダウンロード数:1億
    • 出品数:1日100万品以上
    • GMV(流通総額):月間100億以上

インフラストラクチャについて

  • マルチクラウド構成
    • JPはさくらインターネット、USはAWS、UKはGCP
    • さらにJP・USではGCPを組み合わせてマイクロサービスの基盤に
  • DNSはRoute53
  • CDNはAkamai、Fastly、ImageFluxなど
  • マイクロサービス基盤
    • 既存API(モノリスAPI)をラップするAPI Gatewayを開発し、GCP(GKE)で構築

改めてSREとは

  • SREとは
    • システム管理とサービス運用の方法論としてGoogleの運用チームを率いていたBen Treynorが提唱

GoogleのSRE

  • GoogleのSREには、ソフトウェアエンジニアリングに加え、システム・運用の能力が求められる
    • ソフトウェアエンジニアリングは「自動化」に特に注力
    • SREの人数はサービスの規模に比例させない(Googleの規模においても実現できない)
    • 「トイル」の撲滅
  • 業務時間の50%はソフトウェアエンジニアリングを行う
    • 自動化(自律化)、信頼性向上にあてる
  • SLA、エラーバジェットによる開発者の利害調整
    • 開発者チームと可用性の目標をサービスごとに設定
    • エラーバジェット内にあるときは開発者は積極的にリリース
    • 予算を超える場合は、信頼性回復のための開発が求められる

日本国内でのSRE

  • 2015/11 メルカリ技術blogでSREを紹介
  • Retty、サイボウズ、Cookpad、Mixi、はてななどWeb企業中心にSREの採用が進む
  • SRE Tech Talk開催
  • 書籍
    • オライリー「SREサイトリライアビリティエンジニアリング」

メルカリSRE

  • 2015/11 インフラチームからSREに改称
    • お客様に長く使ってもらえるには「いつでも快適に安全に使える」が重要
    • サービスパフォーマンスや可用性の担保、デプロイの自動化などが主な業務
  • 2018/2時点でメンバーは10名
    • マイクロサービス基盤構築や機械学習プラットフォームに携わるエンジニアも
    • 大規模Webサービス運用経験のある中途が多いが、新卒メンバーも在籍
    • ここのメンバーが能動的に問題を発見し解決していく

自動化例

  • SlackでJIRAのチケットを作成
    • 寝ながらでも思いついた時に作れる

業務範囲

  • ソフトウェアエンジニアリング
    • スケーラビリティ、可用性改善、自動化、DBA、ミドルウェア構築、アプリ設計のレビュー
  • オペレーション
    • Oncall
  • 基盤構築
    • ログ収集・分析基盤、デプロイ、マイクロサービス基盤、セキュリティなど

最近の事例

  • Worker/Queueシステムの問題点
  • Jobの処理速度は様々な要因で変化する
    • バッチからのenqueue速度
    • Workerのプロセス数
    • 処理内容
  • 処理が速すぎることでシステムに負荷

内製CRMツールの事例

  • 配信の速度は配信メディアによって決まる
    • Push配信は速い、メール配信は遅いなど
  • 処理速度が一定ではない、配信ごとに変化
    • 配信にかかる時間をい自覚するためにWorkerの数を手動で調整
    • 調整漏れによって想定外の負荷・障害(DBに高負荷がかかって障害)

CruiseControl

  • 「速度を制御するサービス」を構築
  • Workerが処理を開始する前にCruiseControlに問い合わせる
    • 処理速度が速い場合はwaitが入る
  • CruiseControl = NGINX
    • nginx_http_limit_rew_modukeを利用
    • pathとheaderによって速度を制御
  • システム負荷とqueue数を見ながらWorker数を調整する職人技的対応のシステム化を実現