Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Site Reliability を向上するためにやったことすべて
Search
Takuya TAKAHASHI
May 14, 2020
Programming
11
2.1k
Site Reliability を向上するためにやったことすべて
ペパボ・はてな技術大会で発表した内容になります
Takuya TAKAHASHI
May 14, 2020
Tweet
Share
More Decks by Takuya TAKAHASHI
See All by Takuya TAKAHASHI
実例から学ぶ Kubernetes Custom Controller の状態管理
takutakahashi
0
1.4k
しきい値監視からの卒業! Prometheus による機械学習を用いた異常検知アラートの実装
takutakahashi
0
1.8k
15年以上動くECシステムをクラウドネイティブにするためにやっていること
takutakahashi
1
1.9k
カラーミーショップの 可用性向上のための インフラ刷新
takutakahashi
1
410
ペパボが求める「守って攻める」インフラとは?
takutakahashi
4
610
Rook/Ceph on ZFS
takutakahashi
1
1.8k
Deep-dive KubeVirt
takutakahashi
2
1.7k
Other Decks in Programming
See All in Programming
ACES Meet におけるリリース作業改善の取り組み
fukucheee
0
140
実践Dash - 手を抜きながら本気で作るデータApplicationの基本と応用 / Dash for Python and Baseball
shinyorke
2
640
[PHPカンファレンス沖縄2024]「無理なくできるだけ安全に」テストもないレガシーコードをリファクタリングするテクニック
ikezoemakoto
3
130
tsconfig.jsonの最近の新機能 ファイルパス編
uhyo
7
1.8k
Pydantic x Database API:turu-pyの開発
yassun7010
1
750
GrafanaのHTTP API を眺めてみよう
rinchoku
0
350
WEBアプリケーションにおけるAWS Lambdaを用いた大規模な非同期処理の実践
delhi09
PRO
7
4.4k
クラウドサービスの 利用コストを削減する技術 - 円安の真南風を感じて -
pyama86
3
400
(Deep|Web) Link support with expo-router
mrtry
0
180
Integrating AI in Your Enterprise Java Applications
ivargrimstad
0
390
データサイエンスのフルサイクル開発を実現する機械学習パイプライン
xcnkx
2
510
Why I Choose NetBeans for Jakarta EE
ivargrimstad
0
370
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Making the Leap to Tech Lead
cromwellryan
131
8.9k
Unsuck your backbone
ammeep
668
57k
Building Better People: How to give real-time feedback that sticks.
wjessup
362
19k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.3k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Testing 201, or: Great Expectations
jmmastey
38
7k
We Have a Design System, Now What?
morganepeng
50
7.2k
Building an army of robots
kneath
302
42k
4 Signs Your Business is Dying
shpigford
180
21k
Transcript
Site Reliability 向上のために やったことすべて 高橋 拓也 @ GMOペパボ 2020/05/14
ペパボ・はてな技術大会〜@オンライン
本日おはなしすること SUZURI プロダクト開発チームで SRE を頑張って軌道に乗せた際に やったこと うまくいったこと うまくいかなかったことをお話します。
アジェンダ • 自己紹介 • SRE をやることになった経緯 • SRE を進めるためにやったこと ◦
「SRE できた」とは? ◦ 現状の確認 ◦ 必要なものの洗い出し ◦ がんばる • うまくいったこと • うまくいかなかったこと • まとめ
自己紹介
高橋 拓也 (takutaka) 自己紹介 • 所属: 技術部 技術基盤チーム (joined at
2019/10) ◦ 事業部のお手伝いをしたり、 ◦ 全社的なインフラ基盤を開発したりするチーム • 好きなもの: k8s, OpenStack, kvm, zfs, drbd, etc… • 好きなこと: 開発すること、アーキテクチャを考えること、冗長化すること • https://github.com/takutakahashi • https://www.takutakahashi.dev • https://twitter.com/takutaka1220 写真
経緯
2019年の年末ごろ
上長
takutaka くん 上長
来年から SUZURI の SRE 手伝ってくれない? 上長 本当はもうちょっと詳しく
ぼく
いいすよ! 本当はもっとていねい ぼく
どんな感じで 進めましょう? ぼく
上長
いい感じに バーンとお願い! 上長 これはだいたいこんな感じ
ヨッシャ ぼく
SUZURI って なんだろう? ぼく
None
SUZURI について 補足 • https://suzuri.jp • 自分だけのオリジナルグッズを簡単に作成・販売できるサービス ◦ T シャツやトートバッグから、スマホケースやステッカーまで
◦ 画像を用意してアップロードするだけ
SUZURI について 補足 • 2020年度第一四半期の決算によると... ◦ 売上高約 2.5億円 ◦
前年比 220% 成長 ◦ 2019年はTシャツ累計10万枚売ったらしい
すごいサービス
やっていくぞ
SRE を進めるために やったこと
目指す終着点 SRE やってよかったね と誰もが思う状態にする
目指す終着点 SRE やってよかったね と誰もが思う状態にする 1. SRE に関わるエンジニア 2. 開発エンジニア
3. CS、マーケター、ステークホルダー 4. サービスを利用いただくユーザー
「SRE ができた」とは?
「 ができた」とは? • なんのために SRE をやるのか? • なにができたら SRE できたと言えるのか?
「 ができた」とは? • なんのために SRE をやるのか? • なにができたら SRE できたと言えるのか?
なんのために をやるのか? 「 ができた」とは? サービスが持続的に成長できるようにするため
サービスが成長できる 「 ができた」とは? • サービス規模が10倍、100倍になったときに健全に運営できるのか? ◦ 100倍のヒト、モノ、カネのコストが発生しないか? ◦
線形で増えるようではまずい • 成長限界が(暗黙的に)定まってないか? ◦ アーキテクチャの制限によりボトルネックが解消できない ◦ あるいは解消に膨大な工数が必要となる
サービスが成長できる 「 ができた」とは? • サービス規模が10倍、100倍になったときに健全に運営できるのか? ◦ 100倍の手作業が発生しないか? ◦ 100倍のヒト、モノ、カネのコストが発生しないか?
◦ 100倍で済めばまだいい ▪ 1000倍、10000倍コストがかからないか? • 成長限界が(暗黙的に)定まってないか? ◦ アーキテクチャの制限によりボトルネックが解消できない ◦ あるいは解消に膨大な工数が必要となる だいたい 手遅れになってから知る
サービスが成長できる 「 ができた」とは? • サービス規模が10倍、100倍になったときに健全に運営できるのか? ◦ 100倍の手作業が発生しないか? ◦ 100倍のヒト、モノ、カネのコストが発生しないか?
◦ 100倍で済めばまだいい ▪ 1000倍、10000倍コストがかからないか? • 成長限界が(暗黙的に)定まってないか? ◦ アーキテクチャの制限によりボトルネックが解消できない ◦ あるいは解消に膨大な工数が必要となる 手遅れになる前に 検知できる状態になっている
サービスが成長できる 「 ができた」とは? • サービス規模が10倍、100倍になったときに健全に運営できるのか? ◦ 100倍の手作業が発生しないか? ◦ 100倍のヒト、モノ、カネのコストが発生しないか?
◦ 100倍で済めばまだいい ▪ 1000倍、10000倍コストがかからないか? • 成長限界が(暗黙的に)定まってないか? ◦ アーキテクチャの制限によりボトルネックが解消できない ◦ あるいは解消に膨大な工数が必要となる 手遅れになるまでの リードタイムを最大化する
「 ができた」とは? • なんのために SRE をやるのか? • なにができたら SRE できたと言えるのか?
なにができたら できたと言えるのか? 「 ができた」とは? サービスが成長できる!と言えたら
サービスが成長できる!と言えるには? 「 ができた」とは? • サービス規模が100倍になっても安心 ◦ 性能を日々計測、改善できている ◦ 運用作業を日々計測、改善できている
何を良くすればいいの? • 「全部すぐ最高にする」というのは無理 • 効果てきめんな部分から最高にしていく • サービスの特徴から優先順位をつける
の特徴は? 「 ができた」とは? • EC サービスである • プラットフォームである
サービスである 「 ができた」とは? • ユーザー × 単価 = 売上 ◦
単価を上げるためにシステムでできることは? ◦ → 回遊しやすいシステム ◦ → ページ表示速度を速く保つ必要がある
プラットフォームである 「 ができた」とは? • サービス利用を通じてお金を稼ぐ人がいる • サービスダウン = ユーザーの収益ダウン ◦
可用性をとにかく高く保つべき
やることがわかってきたぞ!
ここまでのまとめ
ここまでのまとめ • SRE をやる目的を明確にする ◦ サービスの成長を支えるためにできることをやる • 大事なものから最高にする ◦ SUZURI
では、レイテンシと可用性が大事
ゴールを目指す
SUZURI のシステム構成 先の理解を深めるためにざっくりと
heroku プライベートクラウド web worker 画像合成 CloudFront いろいろ
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
レイテンシの最適な状態 • 最適とは、最高に適している状態のこと ◦ 最高に速い状態ではない! • コストとパフォーマンスのバランス ◦ ✖ とにかく最高速度を求める
◦ ◦ ユーザーが満足する最低ラインを死守する
レイテンシの最適な状態 ユーザーが満足する最低ラインって??? • わからん • わからんので、とりあえず決めちゃう
では? レイテンシの最適な状態 • レイテンシの最適解を 95percentile 1.0s と定めた ◦ SRE でいう、SLO
(Service Level Objective) • わからんので、調整する前提で決める
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
現在地の確認 • SLO 95p 1.0s と定めたが、今はどのくらい? • 計測できなければ、計測する
では? • heroku addon の newrelic insights を使った • exporter
→ prometheus → grafana • 計測開始当初はだいたい平均 1.2s くらい
では? • 「SLO 達成率」を定義 ◦ 1時間 のうち、SLO を何分達成できたか? ◦ 計測開始当初は
50% を切っていた
None
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
SUZURI のシステム構成 再掲
heroku プライベートクラウド web worker 画像合成 CloudFront いろいろ
こんな便利な項目が
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
https://git.pepabo.com/suzuri/suzuri/issues/7002 から画像を作る
https://git.pepabo.com/suzuri/suzuri/issues/7002 から画像を作る
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
None
達成!!
エンジニアリングで 解決してないぞ!!
ユーザーは 嬉しい結果になった!
これでいいのか? • 関係者全員を喜ばせてない ◦ ユーザーは速くなって嬉しい ◦ ステークホルダーはコストが高まって嬉しくない ◦ 継続的に改善していくことで対応する
可用性も同様に 画像合成サーバを例に
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する
ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ) 1. A の最適な状態を定義する 2.
A が今どの状態にあるのか確認する 3. A が最適な状態に移行するための要素を出す 4. がんばる 5. A が最適に近づいたか計測する 単一障害点がない状態 必要なキャパシティが 計測できている状態 社内クラウドに依存 キャパシティ計測できていない スケールアウトが大変 社内 k8s + GKE で マルチクラウド化 キャパシティ計測 リソース量をメトリクス化
このサイクルを回すぞ!
うまくいったこと
うまくいったこと • システムの健康状態がわかるようになった ◦ SLO 達成率低下、レイテンシの低下 ◦ → アラートで気づけ、対応できる ◦
日々の健康管理もできる ◦ 突発的なアクセス増でも冷静に対応できる
大規模セール時に冷静に対応できた うまくいったこと • App は heroku のオートスケールに任せる ◦ 以前なら dyno
の増加が適切かわからなかった ◦ p95 レイテンシを維持する数に調整できた
うまくいかなかったこと
うまくいかなかったこと 改善タスクにとりかかれない
うまくいかなかったこと あるある
うまくいかなかったこと • 新機能や新アイテムリリースが主作業 ◦ 主作業でみんなだいたい手一杯になる ◦ みんな直したいことはたくさんあるのに。。。 • 一時リソース投下はカンフル剤 ◦
僕がやってもいいけど、あくまでヘルパー ◦ チーム内で完結する仕組みが必要
その中でも幸運だったこと • エンジニアたちに理解があった ◦ 直していくの大事だよね、と皆が思っている ◦ 時間さえあれば、という状態 • ステークホルダーに理解があった ◦
エンジニアの工数を一部使うことができた
時間を作るぞ!
時間を作るぞ! • バックログをプロダクト開発タスクから分離 ◦ SRE 専用バックログを作った ◦ 「できてない」という負の意識をなくす
時間を作るぞ! • SRE のバックログ消化会を週次開催 ◦ モブプログラミング形式で開催 ◦ 関連作業は全てこの時間に行う ▪ タスク積み、優先順位づけ、コーディング
効果 • 少しずつだけど進捗するようになった ◦ 1回開催につき 1 PR 出すことが目標 ◦ 元がゼロだったので大きな進歩
見渡してみると • システムにとって大事な要素を定義できた ◦ レイテンシ、可用性 • 大事な要素を日々確認できるようになった ◦ ダッシュボード化、メトリクス収集 •
課題を積み、消化できるようになった ◦ モブプロ会 • ユーザーに改善効果を提供できた ◦ レイテンシ向上、負荷時のスケール、障害回避
SREができたね
まとめ
まとめ • SUZURI で SRE を始める段階から軌道に乗るまでをお話し ました。 • 現状把握、課題発見、取り組み、価値を提供するまでのサイ クルについてお話しました。
• SRE を始めたいがどうして良いかわからない、SRE が定着 せずに困っている人の参考になれば幸いです。
ありがとうございました! おまけがあるので公開資料も見てね!
アジェンダ • 自己紹介 • SRE をやることになった経緯 • SRE を進めるためにやったこと ◦
「SRE できた」とは? ◦ 現状の確認 ◦ 必要なものの洗い出し ◦ がんばる • うまくいったこと • うまくいかなかったこと • まとめ
おまけ
画像構成サーバ構成図
GCP プライベートクラウド CloudFront GKE k8s App App App App App
App L7LB nginx OpenStack LB Route53
GCP プライベートクラウド CloudFront GKE k8s App App App App App
App L7LB nginx OpenStack LB Route53 k8s を使い、 キャパプラと スケールアウトを容易に
GCP プライベートクラウド CloudFront GKE k8s App App App App App
App L7LB nginx OpenStack LB Route53 同じものを GKE で動かし リクエスト増に オートスケールで対応
GCP プライベートクラウド CloudFront GKE k8s App App App App App
App L7LB nginx OpenStack LB Route53 リクエストの多くは プライベートクラウドで動かし コスト最適化
GCP プライベートクラウド CloudFront GKE k8s App App App App App
App L7LB nginx OpenStack LB Route53 Route 53 の GSLB 機能を使い 重み付けリクエスト割り振りと フェイルオーバーを実現