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

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

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 年目
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
29. ➔ 仮説検証のサイクルを高速に回せる ◆ 個別アプリでなく、サービス群全体でのステージングデプロイ ◆ 本番へのデプロイも各 Service Unit の裁量で ➔ 本番環境で、柔軟に少しずつ検証するための仕組みが必要 ◆ Feature Flag, Canary Release ◆ ダメだったらすぐに戻せる ➔ ユーザーに高速に価値を届け続ける Agility
30. ➔ 基本的にはアプリケーションの開発に集中してほしい ➔ サービスは安定稼働させなければならない ➔ そのためにはあらゆる自動化が必要 ◆ メトリクス、アラート、オートスケール... ➔ オンコール対応の移譲 ◆ 障害からの復旧時間の最小化 ◆ Dev も SRE も同じメトリクスを見て、同じテーブルで会話する Reliability
31. Quipperの プロダクト開発を 最高にしたい
32. Quipperの プロダクトを 最高にしたい
33. ユーザーに 最高の教育を 届けたい
34. 最高の技術で 最高の教育を
35. Thank you For Listening!