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

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

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

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

Takuya TAKAHASHI

May 14, 2020
Tweet

More Decks by Takuya TAKAHASHI

Other Decks in Programming

Transcript

  1. Site Reliability

    向上のために

    やったことすべて

    高橋 拓也 @ GMOペパボ


    2020/05/14

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


    View full-size slide

  2. 本日おはなしすること
    SUZURI プロダクト開発チームで

    SRE を頑張って軌道に乗せた際に

    やったこと

    うまくいったこと

    うまくいかなかったことをお話します。


    View full-size slide

  3. アジェンダ

    ● 自己紹介

    ● SRE をやることになった経緯

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

    ○ 「SRE できた」とは?

    ○ 現状の確認

    ○ 必要なものの洗い出し

    ○ がんばる

    ● うまくいったこと

    ● うまくいかなかったこと

    ● まとめ


    View full-size slide

  4. 自己紹介


    View full-size slide

  5. 高橋 拓也 (takutaka)

    自己紹介

    ● 所属: 技術部 技術基盤チーム (joined at 2019/10)

    ○ 事業部のお手伝いをしたり、

    ○ 全社的なインフラ基盤を開発したりするチーム

    ● 好きなもの: k8s, OpenStack, kvm, zfs, drbd, etc…

    ● 好きなこと: 開発すること、アーキテクチャを考えること、冗長化すること

    ● https://github.com/takutakahashi

    ● https://www.takutakahashi.dev

    ● https://twitter.com/takutaka1220

    写真

    View full-size slide

  6. 2019年の年末ごろ


    View full-size slide


  7. takutaka くん

    上長 


    View full-size slide

  8. 来年から

    SUZURI の SRE

    手伝ってくれない?

    上長 

    本当はもうちょっと詳しく 


    View full-size slide


  9. いいすよ!

    本当はもっとていねい 

    ぼく


    View full-size slide

  10. どんな感じで

    進めましょう?

    ぼく


    View full-size slide

  11. いい感じに

    バーンとお願い!

    上長 

    これはだいたいこんな感じ 


    View full-size slide


  12. ヨッシャ

    ぼく


    View full-size slide

  13. SUZURI って

    なんだろう?

    ぼく


    View full-size slide

  14. SUZURI について

    補足

    ● https://suzuri.jp

    ● 自分だけのオリジナルグッズを簡単に作成・販売できるサービス

    ○ T シャツやトートバッグから、スマホケースやステッカーまで

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


    View full-size slide

  15. SUZURI について

    補足

    ● 2020年度第一四半期の決算によると...

    ○ 売上高約 2.5億円 

    ○ 前年比 220% 成長

    ○ 2019年はTシャツ累計10万枚売ったらしい


    View full-size slide

  16. すごいサービス


    View full-size slide

  17. やっていくぞ 


    View full-size slide

  18. SRE を進めるために

    やったこと


    View full-size slide

  19. 目指す終着点
    SRE やってよかったね

    と誰もが思う状態にする


    View full-size slide

  20. 目指す終着点
    SRE やってよかったね

    と誰もが思う状態にする


    1. SRE に関わるエンジニア
    2. 開発エンジニア
    3. CS、マーケター、ステークホルダー
    4. サービスを利用いただくユーザー

    View full-size slide

  21. 「SRE ができた」とは?


    View full-size slide

  22. 「 ができた」とは?
    ● なんのために SRE をやるのか?

    ● なにができたら SRE できたと言えるのか?


    View full-size slide

  23. 「 ができた」とは?
    ● なんのために SRE をやるのか?

    ● なにができたら SRE できたと言えるのか?


    View full-size slide

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


    View full-size slide

  25. サービスが成長できる

    「 ができた」とは?

    ● サービス規模が10倍、100倍になったときに健全に運営できるのか?

    ○ 100倍のヒト、モノ、カネのコストが発生しないか? 

    ○ 線形で増えるようではまずい

    ● 成長限界が(暗黙的に)定まってないか?

    ○ アーキテクチャの制限によりボトルネックが解消できない

    ○ あるいは解消に膨大な工数が必要となる


    View full-size slide

  26. サービスが成長できる

    「 ができた」とは?

    ● サービス規模が10倍、100倍になったときに健全に運営できるのか?

    ○ 100倍の手作業が発生しないか?

    ○ 100倍のヒト、モノ、カネのコストが発生しないか? 

    ○ 100倍で済めばまだいい

    ■ 1000倍、10000倍コストがかからないか?

    ● 成長限界が(暗黙的に)定まってないか?

    ○ アーキテクチャの制限によりボトルネックが解消できない

    ○ あるいは解消に膨大な工数が必要となる

    だいたい
    手遅れになってから知る

    View full-size slide

  27. サービスが成長できる

    「 ができた」とは?

    ● サービス規模が10倍、100倍になったときに健全に運営できるのか?

    ○ 100倍の手作業が発生しないか?

    ○ 100倍のヒト、モノ、カネのコストが発生しないか? 

    ○ 100倍で済めばまだいい

    ■ 1000倍、10000倍コストがかからないか?

    ● 成長限界が(暗黙的に)定まってないか?

    ○ アーキテクチャの制限によりボトルネックが解消できない

    ○ あるいは解消に膨大な工数が必要となる

    手遅れになる前に
    検知できる状態になっている

    View full-size slide

  28. サービスが成長できる

    「 ができた」とは?

    ● サービス規模が10倍、100倍になったときに健全に運営できるのか?

    ○ 100倍の手作業が発生しないか?

    ○ 100倍のヒト、モノ、カネのコストが発生しないか? 

    ○ 100倍で済めばまだいい

    ■ 1000倍、10000倍コストがかからないか?

    ● 成長限界が(暗黙的に)定まってないか?

    ○ アーキテクチャの制限によりボトルネックが解消できない

    ○ あるいは解消に膨大な工数が必要となる

    手遅れになるまでの
    リードタイムを最大化する

    View full-size slide

  29. 「 ができた」とは?
    ● なんのために SRE をやるのか?

    ● なにができたら SRE できたと言えるのか?


    View full-size slide

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


    View full-size slide

  31. サービスが成長できる!と言えるには?
    「 ができた」とは?
    ● サービス規模が100倍になっても安心

    ○ 性能を日々計測、改善できている

    ○ 運用作業を日々計測、改善できている


    View full-size slide

  32. 何を良くすればいいの?
    ● 「全部すぐ最高にする」というのは無理

    ● 効果てきめんな部分から最高にしていく

    ● サービスの特徴から優先順位をつける


    View full-size slide

  33. の特徴は?
    「 ができた」とは?
    ● EC サービスである

    ● プラットフォームである


    View full-size slide

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

    ○ 単価を上げるためにシステムでできることは?

    ○ → 回遊しやすいシステム

    ○ → ページ表示速度を速く保つ必要がある


    View full-size slide

  35. プラットフォームである
    「 ができた」とは?
    ● サービス利用を通じてお金を稼ぐ人がいる

    ● サービスダウン = ユーザーの収益ダウン

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


    View full-size slide

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


    View full-size slide

  37. ここまでのまとめ


    View full-size slide

  38. ここまでのまとめ
    ● SRE をやる目的を明確にする

    ○ サービスの成長を支えるためにできることをやる

    ● 大事なものから最高にする

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


    View full-size slide

  39. ゴールを目指す


    View full-size slide

  40. SUZURI のシステム構成

    先の理解を深めるためにざっくりと

    View full-size slide

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

    View full-size slide

  42. ゴールとの距離を測る
    とある対象 A を最適にする (ex: レイテンシ)

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  43. ゴールとの距離を測る
    とある対象 A を最適にする (ex: レイテンシ)

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  44. レイテンシの最適な状態
    ● 最適とは、最高に適している状態のこと

    ○ 最高に速い状態ではない!

    ● コストとパフォーマンスのバランス

    ○ ✖ とにかく最高速度を求める

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


    View full-size slide

  45. レイテンシの最適な状態
    ユーザーが満足する最低ラインって???

    ● わからん

    ● わからんので、とりあえず決めちゃう


    View full-size slide

  46. では?
    レイテンシの最適な状態
    ● レイテンシの最適解を 95percentile 1.0s と定めた

    ○ SRE でいう、SLO (Service Level Objective)

    ● わからんので、調整する前提で決める


    View full-size slide

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

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  48. 現在地の確認
    ● SLO 95p 1.0s と定めたが、今はどのくらい?

    ● 計測できなければ、計測する


    View full-size slide

  49. では?
    ● heroku addon の newrelic insights を使った

    ● exporter → prometheus → grafana

    ● 計測開始当初はだいたい平均 1.2s くらい



    View full-size slide

  50. では?
    ● 「SLO 達成率」を定義

    ○ 1時間 のうち、SLO を何分達成できたか?

    ○ 計測開始当初は 50% を切っていた



    View full-size slide

  51. ゴールとの距離を測る
    とある対象 A を最適にする (ex: レイテンシ)

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  52. SUZURI のシステム構成

    再掲


    View full-size slide

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

    View full-size slide

  54. こんな便利な項目が

    View full-size slide

  55. ゴールとの距離を測る
    とある対象 A を最適にする (ex: レイテンシ)

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  56. https://git.pepabo.com/suzuri/suzuri/issues/7002 

    から画像を作る


    View full-size slide

  57. https://git.pepabo.com/suzuri/suzuri/issues/7002 

    から画像を作る


    View full-size slide

  58. ゴールとの距離を測る
    とある対象 A を最適にする (ex: レイテンシ)

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  59. 達成!!


    View full-size slide

  60. エンジニアリングで

    解決してないぞ!!


    View full-size slide

  61. ユーザーは

    嬉しい結果になった!


    View full-size slide

  62. これでいいのか?
    ● 関係者全員を喜ばせてない

    ○ ユーザーは速くなって嬉しい

    ○ ステークホルダーはコストが高まって嬉しくない

    ○ 継続的に改善していくことで対応する


    View full-size slide

  63. 可用性も同様に

    画像合成サーバを例に


    View full-size slide

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

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する


    View full-size slide

  65. ゴールとの距離を測る
    とある対象 A を最適にする (ex: レイテンシ)

    1. A の最適な状態を定義する

    2. A が今どの状態にあるのか確認する

    3. A が最適な状態に移行するための要素を出す

    4. がんばる

    5. A が最適に近づいたか計測する

    単一障害点がない状態
    必要なキャパシティが
    計測できている状態
    社内クラウドに依存
    キャパシティ計測できていない
    スケールアウトが大変
    社内 k8s + GKE で
    マルチクラウド化
    キャパシティ計測
    リソース量をメトリクス化

    View full-size slide

  66. このサイクルを回すぞ!


    View full-size slide

  67. うまくいったこと


    View full-size slide

  68. うまくいったこと
    ● システムの健康状態がわかるようになった

    ○ SLO 達成率低下、レイテンシの低下

    ○ → アラートで気づけ、対応できる

    ○ 日々の健康管理もできる

    ○ 突発的なアクセス増でも冷静に対応できる


    View full-size slide

  69. 大規模セール時に冷静に対応できた
    うまくいったこと
    ● App は heroku のオートスケールに任せる

    ○ 以前なら dyno の増加が適切かわからなかった

    ○ p95 レイテンシを維持する数に調整できた


    View full-size slide

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


    View full-size slide

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


    View full-size slide

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


    View full-size slide

  73. うまくいかなかったこと
    ● 新機能や新アイテムリリースが主作業

    ○ 主作業でみんなだいたい手一杯になる

    ○ みんな直したいことはたくさんあるのに。。。

    ● 一時リソース投下はカンフル剤

    ○ 僕がやってもいいけど、あくまでヘルパー

    ○ チーム内で完結する仕組みが必要


    View full-size slide

  74. その中でも幸運だったこと
    ● エンジニアたちに理解があった

    ○ 直していくの大事だよね、と皆が思っている

    ○ 時間さえあれば、という状態

    ● ステークホルダーに理解があった

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


    View full-size slide

  75. 時間を作るぞ!


    View full-size slide

  76. 時間を作るぞ!
    ● バックログをプロダクト開発タスクから分離

    ○ SRE 専用バックログを作った

    ○ 「できてない」という負の意識をなくす


    View full-size slide

  77. 時間を作るぞ!
    ● SRE のバックログ消化会を週次開催

    ○ モブプログラミング形式で開催

    ○ 関連作業は全てこの時間に行う

    ■ タスク積み、優先順位づけ、コーディング


    View full-size slide

  78. 効果
    ● 少しずつだけど進捗するようになった

    ○ 1回開催につき 1 PR 出すことが目標

    ○ 元がゼロだったので大きな進歩


    View full-size slide

  79. 見渡してみると
    ● システムにとって大事な要素を定義できた

    ○ レイテンシ、可用性

    ● 大事な要素を日々確認できるようになった

    ○ ダッシュボード化、メトリクス収集

    ● 課題を積み、消化できるようになった

    ○ モブプロ会

    ● ユーザーに改善効果を提供できた

    ○ レイテンシ向上、負荷時のスケール、障害回避


    View full-size slide

  80. SREができたね 


    View full-size slide

  81. まとめ


    View full-size slide

  82. まとめ
    ● SUZURI で SRE を始める段階から軌道に乗るまでをお話し
    ました。

    ● 現状把握、課題発見、取り組み、価値を提供するまでのサイ
    クルについてお話しました。

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


    View full-size slide

  83. ありがとうございました!

    おまけがあるので公開資料も見てね!

    View full-size slide

  84. アジェンダ

    ● 自己紹介

    ● SRE をやることになった経緯

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

    ○ 「SRE できた」とは?

    ○ 現状の確認

    ○ 必要なものの洗い出し

    ○ がんばる

    ● うまくいったこと

    ● うまくいかなかったこと

    ● まとめ


    View full-size slide

  85. おまけ


    View full-size slide

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


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide