Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

#sapurimeetup

Slide 3

Slide 3 text

01 02 03 Agenda | 自己紹介 SRE チームの紹介 僕が SRE になった理由

Slide 4

Slide 4 text

01 自己紹介

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

@yuya-takeyama 2015 年 9 月 Quipper に転職 Web Developer として Rails, Backbone.js, React.js, React Native など 2018 年 4 月 SRE チームに異動 絶賛弱くてニューゲーム中

Slide 8

Slide 8 text

02 SRE チームの紹介

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

➔ Kubernetes による Microservices 基盤の構築 ◆ Kubernetes クラスタの構築・運用・デプロイ自動化 ◆ 旧環境からのアプリケーションの移行 SRE チームの最近の取り組み

Slide 11

Slide 11 text

03 僕が SRE になった理由

Slide 12

Slide 12 text

Kubernetes やりたかった

Slide 13

Slide 13 text

Kubernetes とは?

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

コンテナ オーケストレーション システム とは？

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

➔ アプリケーションのあるべき状態を YAML で宣言的に定義 ◆ 使用するイメージ、必要なリソース、コンテナ数... ➔ 障害が起きても、「あるべき状態」に自動的に復旧 ➔ 使用リソースに応じて、複数サーバに均等に配置 (スケジューリング) ➔ 更新時にはコンテナを少しずつサーバを入れ替えて行く いい感じとは?

Slide 19

Slide 19 text

Kubernetes は Microservices に最適

Slide 20

Slide 20 text

Kubernetes 楽しいよ！

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

最高の プロダクト開発 とは？

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

➔ 現状: 1 つのソースを数十人のエンジニアで開発している ◆ 境界が曖昧だと空気の読み合い・お見合いになりがち ● それでは Ownership を持つのは難しい ➔ 各 Service Unit が個別の Service を所有し、責任を持つようにしたい ➔ サービス間のインターフェイスだけ決めて、あとはよろしくやる ◆ 制約があるからこそ自由になれる ➔ それ、Microservices じゃん Ownership

Slide 27

Slide 27 text

➔ なんでもやりたい人はなんでもできるように ➔ 権限の制限をできる限り取り払う ◆ アプリケーションエンジニアだってインフラをいじりたい ◆ ネイティブエンジニアも API を作りたい ➔ Monorepo にすることで複数領域を一気にガッとやれる状態 ◆ 依存関係のある複数サービスを 1 Pull Request でまとめて変更 Borderless

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

➔ 仮説検証のサイクルを高速に回せる ◆ 個別アプリでなく、サービス群全体でのステージングデプロイ ◆ 本番へのデプロイも各 Service Unit の裁量で ➔ 本番環境で、柔軟に少しずつ検証するための仕組みが必要 ◆ Feature Flag, Canary Release ◆ ダメだったらすぐに戻せる ➔ ユーザーに高速に価値を届け続ける Agility

Slide 30

Slide 30 text

➔ 基本的にはアプリケーションの開発に集中してほしい ➔ サービスは安定稼働させなければならない ➔ そのためにはあらゆる自動化が必要 ◆ メトリクス、アラート、オートスケール... ➔ オンコール対応の移譲 ◆ 障害からの復旧時間の最小化 ◆ Dev も SRE も同じメトリクスを見て、同じテーブルで会話する Reliability

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Thank you For Listening!