Site Reliability を向上するためにやったことすべて

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 って  なんだろう？  ぼく 

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 できたと言えるのか？ 

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

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

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

  ◦ 100倍で済めばまだいい  ▪ 1000倍、10000倍コストがかからないか？   • 成長限界が(暗黙的に)定まってないか？  ◦ アーキテクチャの制限によりボトルネックが解消できない  ◦ あるいは解消に膨大な工数が必要となる  手遅れになる前に検知できる状態になっている

  ◦ 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 が最適に近づいたか計測する 

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

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

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

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

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

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

SUZURI のシステム構成  再掲 

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

こんな便利な項目が

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

達成！！ 

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

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

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

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

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

App L7LB nginx OpenStack LB Route53 k8s を使い、キャパプラとスケールアウトを容易に

App L7LB nginx OpenStack LB Route53 同じものを GKE で動かしリクエスト増にオートスケールで対応

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

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

Site Reliability を向上するためにやったことすべて

Site Reliability を向上するためにやったことすべて

More Decks by Takuya TAKAHASHI

Other Decks in Programming

Featured

Transcript