Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper

Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper

StudySapuri Product Meetup #1 〜脱スタートアップフェーズにおける開発チームの現在と未来。少数精鋭の運用体制からデザイン・アーキテクチャまで~ における SRE チーム @yuya-takeyama の発表です。
https://techplay.jp/event/680406

33685a20ded68e6861bec3c1bd7f0870?s=128

Yuya Takeyama

July 19, 2018
Tweet

Transcript

  1. Product Meetup #1 Quipper における SRE チームの紹介 ~僕が SRE になった理由~

    @yuya-takeyama
  2. #sapurimeetup

  3. 01 02 03 Agenda | 自己紹介 SRE チームの紹介 僕が SRE

    になった理由
  4. 01 自己紹介

  5. @yuya-takeyama 2009 年新卒で音楽系事業を行う IT ベンチャーに入社 エンジニア 10 年目

  6. None
  7. @yuya-takeyama 2015 年 9 月 Quipper に転職 Web Developer として

    Rails, Backbone.js, React.js, React Native など 2018 年 4 月 SRE チームに異動 絶賛弱くてニューゲーム中
  8. 02 SRE チームの紹介

  9. ➔ サイトの信頼性に責任を持つ ◆ 可用性、パフォーマンス、キャパシティプランニング... ➔ インフラの構築、運用 ➔ そのためにソフトウェアによる自動化を行う ◆ Infrastructure

    as Code, GitOps Site Reliability Engineering
  10. ➔ Kubernetes による Microservices 基盤の構築 ◆ Kubernetes クラスタの構築・運用・デプロイ自動化 ◆ 旧環境からのアプリケーションの移行

    SRE チームの最近の取り組み
  11. 03 僕が SRE になった理由

  12. Kubernetes やりたかった

  13. Kubernetes とは?

  14. コンテナ オーケストレーション システム

  15. コンテナ オーケストレーション システム とは?

  16. たくさんのコンテナを いい感じに 動かし続ける

  17. たくさんのコンテナを いい感じに 動かし続ける

  18. ➔ アプリケーションのあるべき状態を YAML で宣言的に定義 ◆ 使用するイメージ、必要なリソース、コンテナ数... ➔ 障害が起きても、「あるべき状態」に自動的に復旧 ➔ 使用リソースに応じて、複数サーバに均等に配置

    (スケジューリング) ➔ 更新時にはコンテナを少しずつサーバを入れ替えて行く いい感じとは?
  19. Kubernetes は Microservices に最適

  20. Kubernetes 楽しいよ!

  21. でももっと 大事なのは...

  22. Quipperの プロダクト開発を 最高にしたい

  23. Quipperの プロダクト開発を 最高にしたい

  24. 最高の プロダクト開発 とは?

  25. ➔ Ownership ➔ Borderless ➔ Agility ➔ Reliability 僕が思う最高のプロダクト開発

  26. ➔ 現状: 1 つのソースを数十人のエンジニアで開発している ◆ 境界が曖昧だと空気の読み合い・お見合いになりがち • それでは Ownership を持つのは難しい

    ➔ 各 Service Unit が個別の Service を所有し、責任を持つようにしたい ➔ サービス間のインターフェイスだけ決めて、あとはよろしくやる ◆ 制約があるからこそ自由になれる ➔ それ、Microservices じゃん Ownership
  27. ➔ なんでもやりたい人はなんでもできるように ➔ 権限の制限をできる限り取り払う ◆ アプリケーションエンジニアだってインフラをいじりたい ◆ ネイティブエンジニアも API を作りたい

    ➔ Monorepo にすることで複数領域を一気にガッとやれる状態 ◆ 依存関係のある複数サービスを 1 Pull Request でまとめて変更 Borderless
  28. None
  29. ➔ 仮説検証のサイクルを高速に回せる ◆ 個別アプリでなく、サービス群全体でのステージングデプロイ ◆ 本番へのデプロイも各 Service Unit の裁量で ➔

    本番環境で、柔軟に少しずつ検証するための仕組みが必要 ◆ Feature Flag, Canary Release ◆ ダメだったらすぐに戻せる ➔ ユーザーに高速に価値を届け続ける Agility
  30. ➔ 基本的にはアプリケーションの開発に集中してほしい ➔ サービスは安定稼働させなければならない ➔ そのためにはあらゆる自動化が必要 ◆ メトリクス、アラート、オートスケール... ➔ オンコール対応の移譲

    ◆ 障害からの復旧時間の最小化 ◆ Dev も SRE も同じメトリクスを見て、同じテーブルで会話する Reliability
  31. Quipperの プロダクト開発を 最高にしたい

  32. Quipperの プロダクトを 最高にしたい

  33. ユーザーに 最高の教育を 届けたい

  34. 最高の技術で 最高の教育を

  35. Thank you For Listening!