kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

Retty Tech Cafe #5 (テーマ: SRE) に行ってきた


勉強会

3.12(土) に五反田のRettyオフィスで開催されたRetty Tech Cafe #5 に行ってきました。

http://connpass.com/event/26679/

タイムテーブルはこんな感じ。今回のテーマは "SRE" ということで、自分が一休.comで担当している業務に近しいものがあったので興味を持って参加されていただきました。

# Speaker Title
1 Retty CTO 樽石さん(@taru0216) Retty SRE のご紹介〜 元 SRE エンジニアによる SRE の概要と Retty での適用事例について 〜
2 All About 鈴木さん (@jp_taku2) オールアバウトをオンプレミスで支える技術
3 mercari 長野さん (@kazeburo) メルカリにおける、継続的なアプリケーションの改善を支える技術
4 Retty teemuさん Ensuring highly available services. Infrastructure and service monitoring

あんまりメモれてなかったのでスライドが公開されたらアップデートしたいです。

Retty SRE のご紹介〜 元 SRE エンジニアによる SRE の概要と Retty での適用事例について 〜

CTO 樽石さんによるSREの紹介。樽石さんはRedhat -> Google -> 楽天 -> Rettyという経歴でGoogle時代にSREを担当されていたそうです。

Retty

食を通じて世界中の人々をHappyに。 というコンセプトの元、実名のクチコミを特徴としたグルメ系キュレーションサービスを展開していて、食という領域はまだまだ伸びると思っている。とのこと。

https://retty.me/

懇親会で中の人とお話する機会があったのですが、全社では60名くらいでエンジニアは20名くらいだとおっしゃっていました。一休.comとくらべて比率的にはエンジニアが多い印象ですね。

SRE

直訳するとサイト信頼性エンジニアリング。

ユーザがサービスを快適に利用できるようにシステムを設計・構築・運用するエンジニアリング活動　

を指す。

指標は主に3つ

  1. QPS(Traffic)
  2. 稼働率(Availability)

  3. 遅延(Latency)

  4. インフラエンジニアとの比較

    • 似ているスキルセットやマインドを持っていることが多い
    • ITサービスの基盤に関わるエンジニアがインフラエンジニア
    • 基盤の信頼性が低いとサービスに関わるのでSRE的考えが自然発生していく

  5. アプリSREの例(単純例)

    • アプリからサーバAPIにリクエストを送ったらエラーが返ってきたのでリトライした

SREというワードはあまり耳慣れませんが、アプリケーションエンジニアにしても、インフラエンジニアにしても、サービスに長く関わっているとこういった改善活動は必要になってきて、普段意識せずにやっていることがSREの一環だった、ということが多いのではないかと思いました。

  • 3つの指標を達成するために重要な2つの要素
    • 障害発生時の応急処置・調査
      • サービス規模が拡大すると障害発生から対応までのスピードが重要性を増す
    • 障害に強い開発
      • 指標を定量化するための開発なども行うようになる

SRE in Retty

ふりかえってみると、4つくらいのフェーズがあったように思う。

  1. シンプルな構成だった時代
  2. キャッシュとスケールアウトを進めた時代
  3. 監視力を強化していった時代
  4. ビッグデータ解析ができるようになった時代 <- イマココ

フェーズのはじめの方はインフラ的な要素が多く

などを推進してSRE活動を行ってきた。

後半のフェーズではインフラだけでなく、アプリのクラッシュ率改善のようなアプリ側でのSRE活動が成果を生んだりした。

future of SRE in Retty

これからRettyは海外展開をしようとしている。で、まずは海外展開可能なインフラの整備から進めていて、Cloud on Cloudでサービスを提供できるようにしたい。

  • Cloud on Cloud
    • バックエンドがAWS/GCP/AzureなどのどのIaaSでもConfigファイル一発で切り替えて使えるようなサービスラッパー

これをCTOの樽石さんが1人でやっているらしく、「誰か一緒にやりませんか」的な採用募集でのクロージングでした。

オールアバウトをオンプレミスで支える技術

オールアバウトインフラエンジニア @jp_taku2 さんによるセッション。障害からの改善、自動化といった事例を紹介されていました。

オールアバウトとインフラ構成

メディアサービス。

  • 月間 1億5020万PV
  • 記事 170,000本

くらいの規模感で運用している。

構成

LBの下にVarnishがプロキシ兼キャッシュサーバとして存在していて、その下にPHPアプリケーションがApacheで動いているという構成でした。DBはMySQL。

Varnish

  • cacheサーバ兼プロキシサーバとして活用している

障害事例と改善の話

  • SPOFとなっていたルータが落ちた
    • SPOFをなくして冗長構成にして改善
  • NFSが落ちた
    • NFSをS3へ移行して改善
  • 高負荷障害
    • Varnish、CDNをフル活用して改善

監視改善の話

  • zabbixによるログ監視(初期)はアラートが飛びすぎてメールが埋もれていた
    • Criticalなエラーのみをメールで通知
    • Elasticsearch+Kibanaを使ってアラートを可視化
    • Fluentd -> PHPスクリプト -> メールでサマリを通知

といった形で徐々に監視を改善していった。

自動化事例

Chef導入前

  • 構築用のShellScriptがメンテされていない
  • 属人化してブラックボックス化したサーバ(つらい)

Chef導入後

  • サーバ構築手順をChefのレシピでコード化
  • BitBucketでコードを管理してプルリクベースでレビュー
  • レビューを通った変更のみが本番／Stagingへデプロイ

属人性が排除され、サーバに直接ログインして設定変更等する必要がなくなった。

Jenkins

特に説明はなし。JenkinsジョブでChefのレシピ適用をしているとのこと。

メルカリにおける、継続的なアプリケーションの改善を支える技術

ご存知 @kazeburo さんによるメルカリのSREについてのお話。個人的にはこのセッションがとても勉強になりました。

http://tech.mercari.com/entry/2015/11/18/153421

主にはこの話をベースにした発表でした。

Mercai & Infrastructure

  • 3200万DLのアプリ
  • GMV(総取扱額)月間100億以上
  • 1日数十万出品以上

1,200,000 reqs/min (API/HTTPS)

をさばいている（スゴイ！）。

Infrastructure

mercariさんはJpはAWSではなく、さくらインターネットの物理サーバを使っているそうです。

Jp, Usで同じ構成をとっている。

Software

  • nginx
  • Apache
  • Solr
  • ...
  • widebullet
  • Gaurun

などなど、多くのSoftwareを使っていて、OSSを積極的に活用している。mercari内で作られたOSSも多数あり、 github.com/mercari で公開している。

10+ Deploys/day

Cookpadでも同じような話がありましたが、mercariでも1日に1x回デプロイしているそうです。

PHPのデプロイ

動的言語なので、変更ファイルを配置したらデプロイできるのだが、事はそんなに単純でもない。

  • 依存関係を解決しないといけない

    • 参照するモジュールを増やした場合、参照される新規モジュールが既にデプロイされている必要があったり...etc

  • 解決方法案

    • Blue-Green Deployment
    • Symlink Swapping Deployment
      • ref. Capistrano
      • キャッシュのコントロールが結構シビア
    • Request Pausing Deployment
      • デプロイ中のサーバにリクエストが来ないようにする方式

mercariでは Request Pausing Deployment の方式を採用している。

  • ngx_dynamic_upstream

    • @cubicdaiya さん作のNginxモジュール
    • up/downコマンド1発で対象サーバへのリクエストをOn/Offできる
      • AWSのELBのように反映に時間がかかることなく、一瞬での切り替えが可能なスグレモノ

  • ansibleのデプロイジョブ

    • Inside ChatOps
      • SlackでBotとやり取りすると、対象のプルリクをチェックして問題なければBotがmergeしてansbleのデプロイジョブをスタートする

Monitoring

  • Log monitoring

    • Fluentd で一旦ログ中継サーバへ
    • 中継ログサーバからBigQuery, Norikraへ転送し、活用している
    • NorikraからX分間隔でSlack, Mackerel, DBへ

  • Agent based monitoring

    • Mackerel, NewRelic, Kurado(自作)のデータをpagerduty, slackへ通知
  • Mackerel
    • 25を超えるpluginやutility commandを書いてる
  • Kurado
    • グラフを画像で表示できるOSS(kazeburoさん作)

まとめ

  • SRE@mercari
    • 自分達で問題発見・解決して、サービスの信頼性を向上
    • スケールさせるミドルウェアの開発と運用

Ensuring highly available services. Infrastructure and service monitoring

ほぼメモれていないので割愛。スミマセン。。

所感

SREについて

SREについて少しだけ理解できました。

自分たちが日頃行っているサービス改善や監視強化、ログの見える化といった作業もSREの活動であることもわかりましたし、SREによって

  • アプリの評価(レビュー)が改善できた
  • 特定のAPIが遅いことがわかって改善できた

という成果を生み出すことができるということも再認識できました。

オールアバウト

オールアバウトさんはオンプレでサービスを運用していて、現在クラウドに移行する計画を進めているとのことでした。一休の状況も少し似ている部分があるので、別途情報交換の機会を作ってお互いのサービスにフィードバックできるようにアクションしたいです。

mercari

@kazeburo さんのセッションはさすがでした。

  • mackerel, NewRelic, Kurado(自作のグラフダッシュボード)などでサービス・システム的なメトリクスを見える化して改善を促進する
  • 10+ deploy/day なデリバリーについての足回りを整える

といった自分が担当している部分に直結する話が多く、めちゃ参考になりました。良い部分は少しでも取り込んで改善につなげたいですね。

Retty

良い勉強会を企画してくださり、ありがとうございました。

Rettyさんのオフィスはステキでした。懇親会でもピザとビールに加えてオシャンな料理が振る舞われたり、ウェルカムスイーツが出てきたり、普段の勉強会と比べて女子力高めでビックリしました。

懇親会でRettyのエンジニアの方々と少しお話をさせていただいたのですが、みなさん楽しそうにサービスの話をしていて、とても好感が持てました。

一休でもレストラン予約の事業をやっているので、「レストランのエンジニアと合同で情報交換とかできたら良いですね〜」なんて話をしていたので、うまいこといけば実現するかもしれません。

おまけ

  • ウェルカムスイーツ

f:id:kentana20:20160312202742j:plain

  • オープンなスペースでの勉強会でした

f:id:kentana20:20160312202821j:plain

  • 懇親会時にふるまわれた料理(美味しかったです)

f:id:kentana20:20160312202905j:plain