Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ペパボ・はてな技術大会で発表した内容になります

Defdf943f6e9bfc3d3cd856d9d9e0f9b?s=128

Takuya TAKAHASHI

May 14, 2020
Tweet

Transcript

  1. Site Reliability
 向上のために
 やったことすべて
 高橋 拓也 @ GMOペパボ
 
 2020/05/14


    ペパボ・はてな技術大会〜@オンライン

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


  3. アジェンダ
 • 自己紹介
 • SRE をやることになった経緯
 • SRE を進めるためにやったこと
 ◦

    「SRE できた」とは?
 ◦ 現状の確認
 ◦ 必要なものの洗い出し
 ◦ がんばる
 • うまくいったこと
 • うまくいかなかったこと
 • まとめ

  4. 自己紹介


  5. 高橋 拓也 (takutaka)
 自己紹介
 • 所属: 技術部 技術基盤チーム (joined at

    2019/10)
 ◦ 事業部のお手伝いをしたり、
 ◦ 全社的なインフラ基盤を開発したりするチーム
 • 好きなもの: k8s, OpenStack, kvm, zfs, drbd, etc…
 • 好きなこと: 開発すること、アーキテクチャを考えること、冗長化すること
 • https://github.com/takutakahashi
 • https://www.takutakahashi.dev
 • https://twitter.com/takutaka1220
 写真
  6. 経緯


  7. 2019年の年末ごろ


  8. 上長 


  9. 
 takutaka くん
 上長 


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


  11. ぼく


  12. 
 いいすよ!
 本当はもっとていねい 
 ぼく


  13. どんな感じで
 進めましょう?
 ぼく


  14. 上長 


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


  16. 
 ヨッシャ
 ぼく


  17. SUZURI って
 なんだろう?
 ぼく


  18. None
  19. SUZURI について
 補足
 • https://suzuri.jp
 • 自分だけのオリジナルグッズを簡単に作成・販売できるサービス
 ◦ T シャツやトートバッグから、スマホケースやステッカーまで


    ◦ 画像を用意してアップロードするだけ
 

  20. SUZURI について
 補足
 • 2020年度第一四半期の決算によると...
 ◦ 売上高約 2.5億円 
 ◦

    前年比 220% 成長
 ◦ 2019年はTシャツ累計10万枚売ったらしい

  21. すごいサービス


  22. やっていくぞ 


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


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


  25. 目指す終着点 SRE やってよかったね
 と誰もが思う状態にする
 
 1. SRE に関わるエンジニア 2. 開発エンジニア

    3. CS、マーケター、ステークホルダー 4. サービスを利用いただくユーザー
  26. 「SRE ができた」とは?


  27. 「 ができた」とは? • なんのために SRE をやるのか?
 • なにができたら SRE できたと言えるのか?


  28. 「 ができた」とは? • なんのために SRE をやるのか?
 • なにができたら SRE できたと言えるのか?


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


  30. サービスが成長できる
 「 ができた」とは? 
 • サービス規模が10倍、100倍になったときに健全に運営できるのか?
 ◦ 100倍のヒト、モノ、カネのコストが発生しないか? 
 ◦

    線形で増えるようではまずい
 • 成長限界が(暗黙的に)定まってないか?
 ◦ アーキテクチャの制限によりボトルネックが解消できない
 ◦ あるいは解消に膨大な工数が必要となる

  31. サービスが成長できる
 「 ができた」とは? 
 • サービス規模が10倍、100倍になったときに健全に運営できるのか?
 ◦ 100倍の手作業が発生しないか?
 ◦ 100倍のヒト、モノ、カネのコストが発生しないか?

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

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

    
 ◦ 100倍で済めばまだいい
 ▪ 1000倍、10000倍コストがかからないか? 
 • 成長限界が(暗黙的に)定まってないか?
 ◦ アーキテクチャの制限によりボトルネックが解消できない
 ◦ あるいは解消に膨大な工数が必要となる
 手遅れになるまでの リードタイムを最大化する
  34. 「 ができた」とは? • なんのために SRE をやるのか?
 • なにができたら SRE できたと言えるのか?


  35. なにができたら できたと言えるのか? 「 ができた」とは? サービスが成長できる!と言えたら


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


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


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


  39. サービスである 「 ができた」とは? • ユーザー × 単価 = 売上
 ◦

    単価を上げるためにシステムでできることは?
 ◦ → 回遊しやすいシステム
 ◦ → ページ表示速度を速く保つ必要がある

  40. プラットフォームである 「 ができた」とは? • サービス利用を通じてお金を稼ぐ人がいる
 • サービスダウン = ユーザーの収益ダウン
 ◦

    可用性をとにかく高く保つべき

  41. やることがわかってきたぞ!


  42. ここまでのまとめ


  43. ここまでのまとめ • SRE をやる目的を明確にする
 ◦ サービスの成長を支えるためにできることをやる
 • 大事なものから最高にする
 ◦ SUZURI

    では、レイテンシと可用性が大事

  44. ゴールを目指す


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


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

  47. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

  48. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

  49. レイテンシの最適な状態 • 最適とは、最高に適している状態のこと
 ◦ 最高に速い状態ではない!
 • コストとパフォーマンスのバランス
 ◦ ✖ とにかく最高速度を求める


    ◦ ◦ ユーザーが満足する最低ラインを死守する

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


  51. では? レイテンシの最適な状態 • レイテンシの最適解を 95percentile 1.0s と定めた
 ◦ SRE でいう、SLO

    (Service Level Objective)
 • わからんので、調整する前提で決める

  52. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

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


  54. では? • heroku addon の newrelic insights を使った
 • exporter

    → prometheus → grafana
 • 計測開始当初はだいたい平均 1.2s くらい
 
 

  55. では? • 「SLO 達成率」を定義
 ◦ 1時間 のうち、SLO を何分達成できたか?
 ◦ 計測開始当初は

    50% を切っていた
 
 

  56. None
  57. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

  58. SUZURI のシステム構成
 再掲


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

  60. こんな便利な項目が

  61. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

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


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


  64. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

  65. None
  66. 達成!!


  67. エンジニアリングで
 解決してないぞ!!


  68. ユーザーは
 嬉しい結果になった!


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


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


  71. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する

  72. ゴールとの距離を測る とある対象 A を最適にする (ex: レイテンシ)
 1. A の最適な状態を定義する
 2.

    A が今どの状態にあるのか確認する
 3. A が最適な状態に移行するための要素を出す
 4. がんばる
 5. A が最適に近づいたか計測する
 単一障害点がない状態 必要なキャパシティが 計測できている状態 社内クラウドに依存 キャパシティ計測できていない スケールアウトが大変 社内 k8s + GKE で マルチクラウド化 キャパシティ計測 リソース量をメトリクス化
  73. このサイクルを回すぞ!


  74. うまくいったこと


  75. うまくいったこと • システムの健康状態がわかるようになった
 ◦ SLO 達成率低下、レイテンシの低下
 ◦ → アラートで気づけ、対応できる
 ◦

    日々の健康管理もできる
 ◦ 突発的なアクセス増でも冷静に対応できる

  76. 大規模セール時に冷静に対応できた うまくいったこと • App は heroku のオートスケールに任せる
 ◦ 以前なら dyno

    の増加が適切かわからなかった
 ◦ p95 レイテンシを維持する数に調整できた

  77. うまくいかなかったこと


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


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


  80. うまくいかなかったこと • 新機能や新アイテムリリースが主作業
 ◦ 主作業でみんなだいたい手一杯になる
 ◦ みんな直したいことはたくさんあるのに。。。
 • 一時リソース投下はカンフル剤
 ◦

    僕がやってもいいけど、あくまでヘルパー
 ◦ チーム内で完結する仕組みが必要

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

    エンジニアの工数を一部使うことができた

  82. 時間を作るぞ!


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


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


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


  86. 見渡してみると • システムにとって大事な要素を定義できた
 ◦ レイテンシ、可用性
 • 大事な要素を日々確認できるようになった
 ◦ ダッシュボード化、メトリクス収集
 •

    課題を積み、消化できるようになった
 ◦ モブプロ会
 • ユーザーに改善効果を提供できた
 ◦ レイテンシ向上、負荷時のスケール、障害回避

  87. SREができたね 


  88. まとめ


  89. まとめ • SUZURI で SRE を始める段階から軌道に乗るまでをお話し ました。
 • 現状把握、課題発見、取り組み、価値を提供するまでのサイ クルについてお話しました。


    • SRE を始めたいがどうして良いかわからない、SRE が定着 せずに困っている人の参考になれば幸いです。

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


  91. アジェンダ
 • 自己紹介
 • SRE をやることになった経緯
 • SRE を進めるためにやったこと
 ◦

    「SRE できた」とは?
 ◦ 現状の確認
 ◦ 必要なものの洗い出し
 ◦ がんばる
 • うまくいったこと
 • うまくいかなかったこと
 • まとめ

  92. おまけ


  93. 画像構成サーバ構成図


  94. GCP プライベートクラウド CloudFront GKE k8s App App App App App

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

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

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

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

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