元RX-7乗りの適当な日々

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

IT

楽しみにしていた 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数を調整する職人技的対応のシステム化を実現

Permalink | コメント(0) | トラックバック(0)