Tweet
Tweet

Slide 1

Slide 1 text

Site Reliability
 向上のために
 やったことすべて
 高橋 拓也 @ GMOペパボ
 
 2020/05/14
 ペパボ・はてな技術大会〜@オンライン


Slide 2

Slide 2 text

本日おはなしすること SUZURI プロダクト開発チームで
 SRE を頑張って軌道に乗せた際に
 やったこと
 うまくいったこと
 うまくいかなかったことをお話します。
 


Slide 3

Slide 3 text

アジェンダ
 ● 自己紹介
 ● SRE をやることになった経緯
 ● SRE を進めるためにやったこと
 ○ 「SRE できた」とは？
 ○ 現状の確認
 ○ 必要なものの洗い出し
 ○ がんばる
 ● うまくいったこと
 ● うまくいかなかったこと
 ● まとめ


Slide 4

Slide 4 text

自己紹介


Slide 5

Slide 5 text

高橋 拓也 (takutaka)
 自己紹介
 ● 所属: 技術部 技術基盤チーム (joined at 2019/10)
 ○ 事業部のお手伝いをしたり、
 ○ 全社的なインフラ基盤を開発したりするチーム
 ● 好きなもの: k8s, OpenStack, kvm, zfs, drbd, etc…
 ● 好きなこと: 開発すること、アーキテクチャを考えること、冗長化すること
 ● https://github.com/takutakahashi
 ● https://www.takutakahashi.dev
 ● https://twitter.com/takutaka1220
 写真

Slide 6

Slide 6 text

経緯


Slide 7

Slide 7 text

2019年の年末ごろ


Slide 8

Slide 8 text

上長 


Slide 9

Slide 9 text


 takutaka くん
 上長 


Slide 10

Slide 10 text

来年から
 SUZURI の SRE
 手伝ってくれない？
 上長 
 本当はもうちょっと詳しく 


Slide 11

Slide 11 text

ぼく


Slide 12

Slide 12 text


 いいすよ！
 本当はもっとていねい 
 ぼく


Slide 13

Slide 13 text

どんな感じで
 進めましょう？
 ぼく


Slide 14

Slide 14 text

上長 


Slide 15

Slide 15 text

いい感じに
 バーンとお願い！
 上長 
 これはだいたいこんな感じ 


Slide 16

Slide 16 text


 ヨッシャ
 ぼく


Slide 17

Slide 17 text

SUZURI って
 なんだろう？
 ぼく


Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

SUZURI について
 補足
 ● https://suzuri.jp
 ● 自分だけのオリジナルグッズを簡単に作成・販売できるサービス
 ○ T シャツやトートバッグから、スマホケースやステッカーまで
 ○ 画像を用意してアップロードするだけ
 


Slide 20

Slide 20 text

SUZURI について
 補足
 ● 2020年度第一四半期の決算によると...
 ○ 売上高約 2.5億円 
 ○ 前年比 220% 成長
 ○ 2019年はTシャツ累計10万枚売ったらしい


Slide 21

Slide 21 text

すごいサービス


Slide 22

Slide 22 text

やっていくぞ 


Slide 23

Slide 23 text

SRE を進めるために
 やったこと


Slide 24

Slide 24 text

目指す終着点 SRE やってよかったね
 と誰もが思う状態にする
 


Slide 25

Slide 25 text

目指す終着点 SRE やってよかったね
 と誰もが思う状態にする
 
 1. SRE に関わるエンジニア 2. 開発エンジニア 3. CS、マーケター、ステークホルダー 4. サービスを利用いただくユーザー

Slide 26

Slide 26 text

「SRE ができた」とは？


Slide 27

Slide 27 text

「 ができた」とは？ ● なんのために SRE をやるのか？
 ● なにができたら SRE できたと言えるのか？


Slide 28

Slide 28 text

「 ができた」とは？ ● なんのために SRE をやるのか？
 ● なにができたら SRE できたと言えるのか？


Slide 29

Slide 29 text

なんのために をやるのか？ 「 ができた」とは？ サービスが持続的に成長できるようにするため


Slide 30

Slide 30 text

サービスが成長できる
 「 ができた」とは？ 
 ● サービス規模が10倍、100倍になったときに健全に運営できるのか？
 ○ 100倍のヒト、モノ、カネのコストが発生しないか？ 
 ○ 線形で増えるようではまずい
 ● 成長限界が(暗黙的に)定まってないか？
 ○ アーキテクチャの制限によりボトルネックが解消できない
 ○ あるいは解消に膨大な工数が必要となる


Slide 31

Slide 31 text

サービスが成長できる
 「 ができた」とは？ 
 ● サービス規模が10倍、100倍になったときに健全に運営できるのか？
 ○ 100倍の手作業が発生しないか？
 ○ 100倍のヒト、モノ、カネのコストが発生しないか？ 
 ○ 100倍で済めばまだいい
 ■ 1000倍、10000倍コストがかからないか？ 
 ● 成長限界が(暗黙的に)定まってないか？
 ○ アーキテクチャの制限によりボトルネックが解消できない
 ○ あるいは解消に膨大な工数が必要となる
 だいたい 手遅れになってから知る

Slide 32

Slide 32 text

サービスが成長できる
 「 ができた」とは？ 
 ● サービス規模が10倍、100倍になったときに健全に運営できるのか？
 ○ 100倍の手作業が発生しないか？
 ○ 100倍のヒト、モノ、カネのコストが発生しないか？ 
 ○ 100倍で済めばまだいい
 ■ 1000倍、10000倍コストがかからないか？ 
 ● 成長限界が(暗黙的に)定まってないか？
 ○ アーキテクチャの制限によりボトルネックが解消できない
 ○ あるいは解消に膨大な工数が必要となる
 手遅れになる前に 検知できる状態になっている

Slide 33

Slide 33 text

サービスが成長できる
 「 ができた」とは？ 
 ● サービス規模が10倍、100倍になったときに健全に運営できるのか？
 ○ 100倍の手作業が発生しないか？
 ○ 100倍のヒト、モノ、カネのコストが発生しないか？ 
 ○ 100倍で済めばまだいい
 ■ 1000倍、10000倍コストがかからないか？ 
 ● 成長限界が(暗黙的に)定まってないか？
 ○ アーキテクチャの制限によりボトルネックが解消できない
 ○ あるいは解消に膨大な工数が必要となる
 手遅れになるまでの リードタイムを最大化する

Slide 34

Slide 34 text

「 ができた」とは？ ● なんのために SRE をやるのか？
 ● なにができたら SRE できたと言えるのか？


Slide 35

Slide 35 text

なにができたら できたと言えるのか？ 「 ができた」とは？ サービスが成長できる！と言えたら


Slide 36

Slide 36 text

サービスが成長できる！と言えるには？ 「 ができた」とは？ ● サービス規模が100倍になっても安心
 ○ 性能を日々計測、改善できている
 ○ 運用作業を日々計測、改善できている


Slide 37

Slide 37 text

何を良くすればいいの？ ● 「全部すぐ最高にする」というのは無理
 ● 効果てきめんな部分から最高にしていく
 ● サービスの特徴から優先順位をつける


Slide 38

Slide 38 text

の特徴は？ 「 ができた」とは？ ● EC サービスである
 ● プラットフォームである


Slide 39

Slide 39 text

サービスである 「 ができた」とは？ ● ユーザー × 単価 ＝ 売上
 ○ 単価を上げるためにシステムでできることは？
 ○ → 回遊しやすいシステム
 ○ → ページ表示速度を速く保つ必要がある


Slide 40

Slide 40 text

プラットフォームである 「 ができた」とは？ ● サービス利用を通じてお金を稼ぐ人がいる
 ● サービスダウン = ユーザーの収益ダウン
 ○ 可用性をとにかく高く保つべき


Slide 41

Slide 41 text

やることがわかってきたぞ！


Slide 42

Slide 42 text

ここまでのまとめ


Slide 43

Slide 43 text

ここまでのまとめ ● SRE をやる目的を明確にする
 ○ サービスの成長を支えるためにできることをやる
 ● 大事なものから最高にする
 ○ SUZURI では、レイテンシと可用性が大事


Slide 44

Slide 44 text

ゴールを目指す


Slide 45

Slide 45 text

SUZURI のシステム構成
 先の理解を深めるためにざっくりと 


Slide 46

Slide 46 text

heroku プライベートクラウド web worker 画像合成 CloudFront いろいろ

Slide 47

Slide 47 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 48

Slide 48 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 49

Slide 49 text

レイテンシの最適な状態 ● 最適とは、最高に適している状態のこと
 ○ 最高に速い状態ではない！
 ● コストとパフォーマンスのバランス
 ○ ✖ とにかく最高速度を求める
 ○ ○ ユーザーが満足する最低ラインを死守する


Slide 50

Slide 50 text

レイテンシの最適な状態 ユーザーが満足する最低ラインって？？？
 ● わからん
 ● わからんので、とりあえず決めちゃう
 


Slide 51

Slide 51 text

では？ レイテンシの最適な状態 ● レイテンシの最適解を 95percentile 1.0s と定めた
 ○ SRE でいう、SLO (Service Level Objective)
 ● わからんので、調整する前提で決める


Slide 52

Slide 52 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 53

Slide 53 text

現在地の確認 ● SLO 95p 1.0s と定めたが、今はどのくらい？
 ● 計測できなければ、計測する


Slide 54

Slide 54 text

では？ ● heroku addon の newrelic insights を使った
 ● exporter → prometheus → grafana
 ● 計測開始当初はだいたい平均 1.2s くらい
 
 


Slide 55

Slide 55 text

では？ ● 「SLO 達成率」を定義
 ○ 1時間 のうち、SLO を何分達成できたか？
 ○ 計測開始当初は 50% を切っていた
 
 


Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 58

Slide 58 text

SUZURI のシステム構成
 再掲


Slide 59

Slide 59 text

heroku プライベートクラウド web worker 画像合成 CloudFront いろいろ

Slide 60

Slide 60 text

こんな便利な項目が

Slide 61

Slide 61 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 62

Slide 62 text

https://git.pepabo.com/suzuri/suzuri/issues/7002 
 から画像を作る


Slide 63

Slide 63 text

https://git.pepabo.com/suzuri/suzuri/issues/7002 
 から画像を作る


Slide 64

Slide 64 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

達成！！


Slide 67

Slide 67 text

エンジニアリングで
 解決してないぞ！！


Slide 68

Slide 68 text

ユーザーは
 嬉しい結果になった！


Slide 69

Slide 69 text

これでいいのか？ ● 関係者全員を喜ばせてない
 ○ ユーザーは速くなって嬉しい
 ○ ステークホルダーはコストが高まって嬉しくない
 ○ 継続的に改善していくことで対応する


Slide 70

Slide 70 text

可用性も同様に
 画像合成サーバを例に


Slide 71

Slide 71 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する


Slide 72

Slide 72 text

ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2. A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する
 単一障害点がない状態 必要なキャパシティが 計測できている状態 社内クラウドに依存 キャパシティ計測できていない スケールアウトが大変 社内 k8s + GKE で マルチクラウド化 キャパシティ計測 リソース量をメトリクス化

Slide 73

Slide 73 text

このサイクルを回すぞ！


Slide 74

Slide 74 text

うまくいったこと


Slide 75

Slide 75 text

うまくいったこと ● システムの健康状態がわかるようになった
 ○ SLO 達成率低下、レイテンシの低下
 ○ → アラートで気づけ、対応できる
 ○ 日々の健康管理もできる
 ○ 突発的なアクセス増でも冷静に対応できる


Slide 76

Slide 76 text

大規模セール時に冷静に対応できた うまくいったこと ● App は heroku のオートスケールに任せる
 ○ 以前なら dyno の増加が適切かわからなかった
 ○ p95 レイテンシを維持する数に調整できた


Slide 77

Slide 77 text

うまくいかなかったこと


Slide 78

Slide 78 text

うまくいかなかったこと 改善タスクにとりかかれない


Slide 79

Slide 79 text

うまくいかなかったこと あるある


Slide 80

Slide 80 text

うまくいかなかったこと ● 新機能や新アイテムリリースが主作業
 ○ 主作業でみんなだいたい手一杯になる
 ○ みんな直したいことはたくさんあるのに。。。
 ● 一時リソース投下はカンフル剤
 ○ 僕がやってもいいけど、あくまでヘルパー
 ○ チーム内で完結する仕組みが必要


Slide 81

Slide 81 text

その中でも幸運だったこと ● エンジニアたちに理解があった
 ○ 直していくの大事だよね、と皆が思っている
 ○ 時間さえあれば、という状態
 ● ステークホルダーに理解があった
 ○ エンジニアの工数を一部使うことができた


Slide 82

Slide 82 text

時間を作るぞ！


Slide 83

Slide 83 text

時間を作るぞ！ ● バックログをプロダクト開発タスクから分離
 ○ SRE 専用バックログを作った
 ○ 「できてない」という負の意識をなくす


Slide 84

Slide 84 text

時間を作るぞ！ ● SRE のバックログ消化会を週次開催
 ○ モブプログラミング形式で開催
 ○ 関連作業は全てこの時間に行う
 ■ タスク積み、優先順位づけ、コーディング


Slide 85

Slide 85 text

効果 ● 少しずつだけど進捗するようになった
 ○ 1回開催につき 1 PR 出すことが目標
 ○ 元がゼロだったので大きな進歩


Slide 86

Slide 86 text

見渡してみると ● システムにとって大事な要素を定義できた
 ○ レイテンシ、可用性
 ● 大事な要素を日々確認できるようになった
 ○ ダッシュボード化、メトリクス収集
 ● 課題を積み、消化できるようになった
 ○ モブプロ会
 ● ユーザーに改善効果を提供できた
 ○ レイテンシ向上、負荷時のスケール、障害回避


Slide 87

Slide 87 text

SREができたね 


Slide 88

Slide 88 text

まとめ


Slide 89

Slide 89 text

まとめ ● SUZURI で SRE を始める段階から軌道に乗るまでをお話し ました。
 ● 現状把握、課題発見、取り組み、価値を提供するまでのサイ クルについてお話しました。
 ● SRE を始めたいがどうして良いかわからない、SRE が定着 せずに困っている人の参考になれば幸いです。


Slide 90

Slide 90 text

ありがとうございました！
 おまけがあるので公開資料も見てね！ 


Slide 91

Slide 91 text

アジェンダ
 ● 自己紹介
 ● SRE をやることになった経緯
 ● SRE を進めるためにやったこと
 ○ 「SRE できた」とは？
 ○ 現状の確認
 ○ 必要なものの洗い出し
 ○ がんばる
 ● うまくいったこと
 ● うまくいかなかったこと
 ● まとめ


Slide 92

Slide 92 text

おまけ


Slide 93

Slide 93 text

画像構成サーバ構成図


Slide 94

Slide 94 text

GCP プライベートクラウド CloudFront GKE k8s App App App App App App L7LB nginx OpenStack LB Route53

Slide 95

Slide 95 text

GCP プライベートクラウド CloudFront GKE k8s App App App App App App L7LB nginx OpenStack LB Route53 k8s を使い、 キャパプラと スケールアウトを容易に

Slide 96

Slide 96 text

GCP プライベートクラウド CloudFront GKE k8s App App App App App App L7LB nginx OpenStack LB Route53 同じものを GKE で動かし リクエスト増に オートスケールで対応

Slide 97

Slide 97 text

GCP プライベートクラウド CloudFront GKE k8s App App App App App App L7LB nginx OpenStack LB Route53 リクエストの多くは プライベートクラウドで動かし コスト最適化

Slide 98

Slide 98 text

GCP プライベートクラウド CloudFront GKE k8s App App App App App App L7LB nginx OpenStack LB Route53 Route 53 の GSLB 機能を使い 重み付けリクエスト割り振りと フェイルオーバーを実現