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

SLOを活用した技術的改善

@ジュジュ
September 30, 2021

 SLOを活用した技術的改善

株式会社タイミーではスキマバイトプラットフォームを開発・運用しています。サービスもリリースして3年を超え、"負債"と呼ばれるものが増えてきました。一方でビジネス的に開発したいものは後を絶ちません。そこで開発チームでSLOを制定し、サービスの健全な状態を測定・監視することで「システムが健全にサービス提供できているか」を調べ、必要なときに必要な改修を行えるようにしました。本セッションでは弊社のSLOの解釈や利用方法を伝えるとともに、実際に感じたメリットや行われた技術的改善を紹介します。

セッション動画
https://www.youtube.com/watch?v=VburNEFcg64

@ジュジュ

September 30, 2021
Tweet

More Decks by @ジュジュ

Other Decks in Technology

Transcript

  1. 株式会社タイミー 岡野兼也
    SLOを活用した技術的改善
    @Juju_62q

    View Slide

  2. まずは伝えたいこと

    View Slide

  3. 継続的な技術的改善、
    どうやったらいいの?

    View Slide

  4. すぐに気づいてすぐに実行

    View Slide

  5. いや...そんなこといわれても...

    View Slide

  6. 今日は技術的改善を
    「すぐに気づいてすぐに実行」
    する方法を紹介します

    View Slide

  7. 目次
    ● 技術的改善の流れ
    ● 技術的改善の問題点
    ● 指標を使おう
    ● 事例紹介
    ● 一歩先の未来とまとめ

    View Slide

  8. 岡野兼也 / @Juju_62q
    株式会社タイミー
    プロダクト本部 ワーカーチーム
    Backend Engineer

    View Slide

  9. View Slide

  10. View Slide

  11. 目次
    ● 技術的改善の流れ
    ● 技術的改善の問題点
    ● 指標を使おう
    ● 事例紹介
    ● 一歩先の未来とまとめ

    View Slide

  12. よくある?技術的改善

    View Slide

  13. 技術的改善のながれ
    パフォーマンスちょっとやばい...?
    よく気づくエンジニア

    View Slide

  14. 技術的改善のながれ
    なんかパフォーマンス遅そうで、直し
    たほうが良さそうです
    おっ、ちょっと考えたいから
    起きる問題と時期、予想工数ほしいです
    よく気づくエンジニア
    PM

    View Slide

  15. View Slide

  16. 技術的改善のながれ
    これならhoge機能開発よりも
    先にやったほうが良さそうですね。
    資料作りました!よろしくおねがいします!

    View Slide

  17. 技術的改善のながれ

    View Slide

  18. 技術的改善のながれ
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定

    View Slide

  19. 目次
    ● 技術的改善の流れ
    ● 技術的改善の問題点
    ● 指標を使おう
    ● 事例紹介
    ● 一歩先の未来とまとめ

    View Slide

  20. 歯車が狂うと...?
    パフォーマンスちょっとやばい...?

    View Slide

  21. 歯車が狂うと...?
    でも伝えるとなんかやりたくない仕事めっ
    ちゃ増えちゃうしな〜

    View Slide

  22. 歯車が狂うと...?
    今週はhoge機能とfuga機能を作ろう
    来週はfoo機能とbar機能を作ろう

    View Slide

  23. 歯車が狂うと...?
    なんかアプリ全然開かないんだけど...?

    View Slide

  24. 歯車が狂うと...?
    やばいやばい!早くなんとかしないと!!
    開発全部止めてなんとかするぞ!!

    View Slide

  25. 歯車が狂うと...?
    問題が絡まってて解決できない

    View Slide

  26. どうしてこうなった?

    View Slide

  27. よくある技術的改善のつらいところ
    - 問題に気づくと作業が増える
    - やりたいことに対してやらなきゃいけないことが多い
    - 技術的改善が気づく人に属人化している
    - 問題が起きてから解消が遅い
    - 時間がたつと往々にして問題は大きくなる
    - 大きな問題は解決が難しい

    View Slide

  28. 炎上と鎮火を繰り返す

    View Slide

  29. 遅く気づいて遅く実行

    View Slide

  30. 技術的改善のながれ(再掲)
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定

    View Slide

  31. エンジニアの立場で見てみる

    View Slide

  32. エンジニアのやりたいこと
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定

    View Slide

  33. エンジニアの立場
    - システムに近いので気づきやすい
    - 実行権限はない
    - 技術的改善をしたい
    - プログラミング(エンジニアリング)をしたい
    - 技術的改善をやるために頑張りたく
    ない
    - 局所最適に陥りやすい

    View Slide

  34. PMの立場で見てみる

    View Slide

  35. PMのやりたいこと
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定

    View Slide

  36. PMの立場
    - はじめの気付きは遅い
    - 意見通したい人に説明責任を担って
    ほしい
    - 実行権限がある
    - 全体最適を考えるのが仕事

    View Slide

  37. 二人に問題はあった?

    View Slide

  38. 問題...?
    - エンジニアの仕事は資料作りではない
    ので面倒臭がるのも自然
    - PMがエンジニアリング起因の問題に
    気づかないのも不自然でない
    - 問題を評価してから実行するのは当然

    View Slide

  39. あれ?

    View Slide

  40. 人は最善の行動をしてる...?

    View Slide

  41. 改めて問題を探す

    View Slide

  42. 誰もやりたくない
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定

    View Slide

  43. 仕組みの問題
    - 気づく人に負荷が偏ってしまう
    - やりたくないけどやらないといけない仕事がある
    - やりたくない仕事は頑張れない
    - やれる人・気づく人がやって疲弊する
    - 判断ポイントが介在している
    - 作業者から見た不確実性
    - 実行が遅れる可能性

    View Slide

  44. 解決策1: よく気づく社員しか採用しない
    - メリット
    - 気づいて実行する人が分散される
    - デメリット
    - 採用が大変そう
    - 気づく人ってなんやねん

    View Slide

  45. 解決策1: よく気づく社員しか採用しない
    - メリット
    - 気づいて実行する人が分散される
    - デメリット
    - 採用が大変そう
    - そもそもよくわからない

    View Slide

  46. 解決策2: 現場の意見はすべて即実行する
    - メリット
    - よく気づく社員が疲弊しない
    - 問題が深化する前に解決できる
    - デメリット
    - 適切な優先度判断がなされない
    - 全エンジニアがPM的な視点を持たなければならない
    - 妥当な説明が社内に残りにくい

    View Slide

  47. 解決策2: 現場の意見はすべて即実行する
    - メリット
    - よく気づく社員が疲弊しない
    - 問題が深化する前に解決できる
    - デメリット
    - 適切な優先度判断がなされない
    - 全エンジニアがPdM/PjM的な視点を持たなければなら
    ない
    - 妥当な説明が社内に残りにくい

    View Slide

  48. じゃあどうするか...?

    View Slide

  49. 目次
    ● 技術的改善の流れ
    ● 技術的改善の問題点
    ● 指標を使おう
    ● 事例紹介
    ● 一歩先の未来とまとめ

    View Slide

  50. 技術的改善のながれ(改良版)
    1. SLOをチームで見る
    2. エラーバジェットの減少を認知
    3. 技術的改善の実行
    4. SLOの改善をチェック

    View Slide

  51. SLO/Error Budget
    SLO (Service Level Objective)
    サービスを運用する上で守るべき基準値
    ex. /hoge APIは99.95%で正常なレスポンスを返却する
    Error Budget
    事実とSLOの間にある余裕
    ex. SLOが99.95%に対して事実99.97%であれば40%(0.02%分)の
    エラーバジェットがある

    View Slide

  52. どうしてSLOを使うか?

    View Slide

  53. 技術的改善のながれ(再掲)
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定

    View Slide

  54. 技術的改善のながれ(再掲)
    1. 誰かが唐突に気づく
    2. PMが判断可能な材料を作る
    3. 優先度判断
    4. 技術的改善の実行
    5. 効果測定
    属人的
    面倒くさい

    View Slide

  55. Why SLO…?
    属人性排除
    SLOはシステム/チームに所属するので個人の所作に非依存
    面倒臭さの解消
    SLOを作成した段階で観測可能で合意形成が完了している
    エンジニアは原因究明や改善に注力することができる

    View Slide

  56. 技術的改善のながれ(改良版・再掲)
    1. SLOをチームで見る
    2. エラーバジェットの減少を認知
    3. 技術的改善の実行
    4. SLOの改善をチェック

    View Slide

  57. すぐに気づいてすぐに実行

    View Slide

  58. 従来との違い(属人性)
    よく気づくエンジニアが、たまたま観測できた
    結果として技術的改善につながっていた
    問題の発生にチームで速やかに気づくことができる
    もっと言えば、問題の予兆に対応ができるようになる

    View Slide

  59. 従来との違い(面倒くささ)
    PMが問題を適切に評価するために資料を作る必要があった
    また、これはあまりやりたい仕事ではなかった
    SLOを眺めて閾値を超えているかをチェックすれば良くなった
    運用フェーズで疲弊せず、最速で実行に移すことができる

    View Slide

  60. なぜそうなっているのか
    SLOを策定する場合以下について事前に考える
    - 対象に問題が起きたときのビジネスインパクト
    - 問題が顕在化するしきい値
    コストを事前に支払うことで、運用の再現性を高め、
    技術的改善の実行を容易にできる

    View Slide

  61. 目次
    ● 技術的改善の流れ
    ● 技術的改善の問題点
    ● 指標を使おう
    ● 事例紹介
    ● 一歩先の未来とまとめ

    View Slide

  62. ここからタイミーの話

    View Slide

  63. 岡野兼也 / @Juju_62q
    株式会社タイミー
    プロダクト本部 ワーカーチーム
    Backend Engineer
    今日の話はtoC側の話です

    View Slide

  64. SLO導入前の技術的改善
    - 良くも悪くも熱意ベース
    - やりたい人がやるべきという材料を揃えられるかが実行に対す
    る強い変数となる
    - ファーストビューの高速化とかは実施されなかった
    - やったほうが良さそう
    - やると確実に良いと説明しにくい
    - 限界がどこにあるのか誰も知らない
    - 何なら問題に気づかない

    View Slide

  65. SLOを作ってどう変わったか

    View Slide

  66. タイミーで運用中のSLO
    CS, PdMなどにヒアリングを重ね、重要な機能がなにかを
    調査し以下のSLOを作成した(一部抜粋)
    1. API全体のx%が正常なレスポンスを返却する
    2. ファーストビューがy%以上の期間でz秒以内に開く

    View Slide

  67. 技術的改善のながれ(改良版・再掲)
    1. SLOをチームで見る
    2. エラーバジェットの減少を認知
    3. 技術的改善の実行
    4. SLOの改善をチェック

    View Slide

  68. SLOをチームで見る
    - 毎日SlackでSLOを画像として投稿
    - 開発スプリントごとにSLOの傾向をチェック

    View Slide

  69. エラーバジェットの減少を認知
    開発スプリント末に傾向をチェックする
    - 問題が発生しそうな時期の推定
    - いつ作業を入れるかを話す

    View Slide

  70. エラーバジェットの減少を認知
    違反した場合Slack内やデイリーMTGで話す

    View Slide

  71. 技術的改善の実行(SLO違反)
    デイリーMTGで以下を周知する
    - 違反している事実
    - チームの対応
    - 基本的に他の作業に作業に割り込む※
    ただし、現状はエラーバジェットの減少を検知できているのであまり
    発生していない
    ※事実として発生し、計測期間内の改善困難となった場合再発防止策をたてる

    View Slide

  72. 技術的改善の実行(例)
    過去にTV露出でアクセスがスパイクし、コンテナが
    落ちてしまい、DBも処理できない状態となった
    結果としてALB -> ECSのアクセスが通らなくなり5xxエラーが大
    量に発生し、エラーレートのSLO違反となった
    これを受けてRDSのRead Replicaを増やし、重要なAPIに関してECS
    Serviceを分けることでインフラの独立性を高めた

    View Slide

  73. 技術的改善の実行(例)
    サービス成長や繁忙期により、x月あたりに現状のロジックでは
    ファーストビューのSLOを満たせないことがわかった
    ファーストビューにページングを入れることで処理対象を
    制限することにした

    View Slide

  74. SLOの改善をチェック
    実行した改善がSLOにきちんと響いているかを翌日等にチェック

    View Slide

  75. すぐに気づいてすぐに実行

    View Slide

  76. できるようになった 

    View Slide

  77. 5 一歩先の未来とまとめ

    View Slide

  78. できるようになったこととできてないこと
    - できるようになったこと
    - システムの振る舞いが伴う技術的な改善
    - 長期的なシステム品質低下の抑止
    - できていないこと
    - システムの振る舞いが伴わない技術的な改善
    - リファクタリング
    - インフラの刷新

    View Slide

  79. 今後やっていきたいこと
    エンジニアの生産性の測定
    エンジニアの生産性を測定することで、コードの可読性などシステ
    ムの振る舞い以外の負債の大きさを明らかにする
    挑戦に対する環境圧の形成
    エンジニアが挑戦しやすい、したほうがうまくいきやすい
    環境を作り負債になる前の改善をサポートする

    View Slide

  80. まだわからないこと
    - 測定や効果測定は大切であることに対して測定/観測可能に
    する行為ROIをどう示すのが良いか
    - 現状は定性的に判断している
    - 本当にコスパが良かったのかは不明
    - 根拠のない満足感が高い
    - SLO違反時の行動
    - 原因が常に異なるため都度都度判断している
    - 現状エラーバジェット消費の逆の行動をしている

    View Slide

  81. まとめ
    - 技術的改善の問題はエンジニアリングじゃないところにありが

    - 合意形成
    - 放置するとよく気づく人が疲弊する
    - 技術的改善にはSLOを使うと便利
    - 意思決定コストを前払いしているので、エンジニアにとって
    は気が楽
    - 責任をチームに持たせるので属人性も撤廃

    View Slide

  82. もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください!

    View Slide

  83. Thank you


    View Slide