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

『ホットペッパービューティー』 美容クリニックでのSRE活動

Recruit
November 09, 2021

『ホットペッパービューティー』 美容クリニックでのSRE活動

CloudNative Days Tokyo 2021で発表したスライドです
https://event.cloudnativedays.jp/cndt2021/talks/1255

Recruit

November 09, 2021
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. Whoami Kazuto Kawamura Software Engineer at 株式会社リクルート • 2018年7月中途入社 『ホットペッパービューティー』美容クリニックチーム所属

    • 2018年7月〜 サーバサイド担当 • 2020年10月〜 開発チームリーダー&SREチームリーダー • 2021年4月〜 美容領域TechLead
  2. アジェンダ 1. 美容クリニックとは a. サービス概要 b. アーキテクチャ概要 2. SREチームの組閣 3.

    SRE活動事例 a. 開発KPIの策定と各種モニタリングの整備 b. DX ( Developer eXperience ) の改善活動 4. まとめ
  3. アジェンダ 1. 美容クリニックとは a. サービス概要 b. アーキテクチャ概要 2. SREチームの組閣 3.

    SRE活動事例 a. 開発KPIの策定と各種モニタリングの整備 b. DX ( Developer eXperience ) の改善活動 4. まとめ
  4. Java+SpringBoot Nginx Datadog fluentd, X-Ray 美容クリニックとは Front 予約API 入稿API Java+SpringBoot

    Nginx Datadog fluentd, X-Ray Java+SpringBoot Nginx Datadog fluentd, X-Ray
  5. Java+SpringBoot Nginx Datadog fluentd, X-Ray Java+SpringBoot Nginx Datadog fluentd, X-Ray

    美容クリニックとは 予約API 入稿API Java+SpringBoot Nginx Datadog fluentd, X-Ray Front Front APIから必要な情報を取得し、ブラウザへのレスポンスを返却 する
  6. Java+SpringBoot Nginx Datadog fluentd, X-Ray 美容クリニックとは Front 予約API 入稿API Java+SpringBoot

    Nginx Datadog fluentd, X-Ray Java+SpringBoot Nginx Datadog fluentd, X-Ray API ドメイン毎に分割されたAPI。データリソースも分割されている
  7. アジェンダ 1. 美容クリニックとは a. サービス概要 b. アーキテクチャ概要 2. SREチームの組閣 3.

    SRE活動事例 a. 開発KPIの策定と各種モニタリングの整備 b. DX ( Developer eXperience ) の改善活動 4. まとめ
  8. 美容クリニックにおけるSREチームの組閣 PJ発足 • SRETが発足 2020年3月 • 美容クリニックC/O 2020年4月 •  がSRETリーダーに

    SRET 現在 アプリ開発T 人数 ①開発組織の中でSRETは約1割と少ない人数 ②C/O前後でSRETのメインの責務が変化 課題 “インフラの初期構築” “インフラの保守運用”
  9. 美容クリニックにおけるSREチームの組閣 PJ発足 • SRETが発足 2020年3月 • 美容クリニックC/O 2020年4月 •  がSRETリーダーに

    SRET 現在 アプリ開発T 人数 ①開発組織の中でSRETは約1割と少ない人数 ②C/O前後でSRETのメインの責務が変化 課題 “インフラの初期構築” “インフラの保守運用” 限られた人数でSRE活動をしていく
  10. 美容クリニックにおけるSREチームの組閣 PJ発足 • SRETが発足 2020年3月 • 美容クリニックC/O 2020年4月 •  がSRETリーダーに

    SRET 現在 アプリ開発T 人数 ①開発組織の中でSRETは約1割と少ない人数 ②C/O前後でSRETのメインの責務が変化 課題 “インフラの初期構築” “インフラの保守運用” 限られた人数でSRE活動をしていく そもそもSREってインフラ 保守運用以外何するの?
  11. 美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SREの募集要項からキャッチアップ → SRETの責務を定義し直し • 他社のSREの募集要項からSREがやるべきことを把握 課題

    Action • 手早く、具体的にSREの業務内容をキャッチアップ • 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い
  12. 美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SREの募集要項からキャッチアップ → SRETの責務を定義し直し • 他社のSREの募集要項からSREがやるべきことを把握 •

    美容クリニックの環境/体制/状況に照らし合わせて調整 課題 Action • 手早く、具体的にSREの業務内容をキャッチアップ • 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い
  13. 美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SREの募集要項からキャッチアップ → SRETの責務を定義し直し Summary • SRE

    チームはDevelopers(アプリ開発者)とSystems(システム) の2つに向き合ってタスクを遂行するチーム • 大事なのはSREチームはインフラのみを担当するのではないという点 • 軸足はインフラに置きつつも、アプリ開発者やアプリケーションに も向き合って改善をしていくと定義 課題 Action • 手早く、具体的にSREの業務内容をキャッチアップ • 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い
  14. 美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SREの募集要項からキャッチアップ → SRETの責務を定義し直し Summary • (問題点)本来アプリ開発Tでやるべきことのいくつかをリリース前

    はSRETが気を利かせてやっていた → その名残からリリース後にもSRETへの問い合わせが頻発 • (対策)左図のように責務を明確にする → 自然とSRETへの問い合わせも減少 課題 Action • 手早く、具体的にSREの業務内容をキャッチアップ • 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い
  15. 美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SREの募集要項からキャッチアップ → SRETの責務を定義し直し 課題 Action •

    手早く、具体的にSREの業務内容をキャッチアップ • 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い
  16. 美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SREの募集要項からキャッチアップ → SRETの責務を定義し直し We Are Now

    SRE 2020年3月 • 美容クリニックC/O 2020年4月 •  がSRETリーダーに 現在 • The Google Model? • SRE Center of Practice? etc. 目指すべき姿 cf. https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517 課題 Action 今後 • 手早く、具体的にSREの業務内容をキャッチアップ • 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い
  17. アジェンダ 1. 美容クリニックとは a. サービス概要 b. アーキテクチャ概要 2. SREチームの組閣 3.

    SRE活動事例 a. 開発KPIの策定と各種モニタリングの整備 b. DX ( Developer eXperience ) の改善活動 4. まとめ
  18. 内部向けSLA SLI/SLOへマッピング 開発KPI 計測方法 コミットライン 稼働率 Datadog Synthetics 毎月のモニタリングで稼働率が99.7%以上であること 性能

    アクセスログ 毎月のモニタリングで正規化された各エンドポイントの 95percentileが全て3秒以内であること 特に「サービス稼働率」と「レイテンシ」に着目 → 手軽に定量的な計測がしやすい 例: 開発KPIの策定と各種モニタリングの整備 企画 月次でレポーティング
  19. 内部向けSLA SLI/SLOへマッピング 開発KPI 計測方法 コミットライン 稼働率 Datadog Synthetics 毎月のモニタリングで稼働率が99.7%以上であること 性能

    アクセスログ 毎月のモニタリングで正規化された各エンドポイントの 95percentileが全て3秒以内であること 特に「サービス稼働率」と「レイテンシ」に着目 → 手軽に定量的な計測がしやすい 例: 開発KPIの策定と各種モニタリングの整備 企画 月次でレポーティング
  20. Java+SpringBoot Nginx Datadog fluentd, X-Ray Front 予約API 入稿API Java+SpringBoot Nginx

    Datadog fluentd, X-Ray Java+SpringBoot Nginx Datadog fluentd, X-Ray ログ集約 開発KPIの策定と各種モニタリングの整備(性能)
  21. 開発KPIの策定と各種モニタリングの整備(性能) Java+SpringBoot Nginx Datadog fluentd, X-Ray Front, API 正規化されたURL毎の 性能レポートを生成

    性能レポートをスプレッドシートで集計し、 トレンドで変化を見れるようにする fluentdでnginxのアクセスログを BigQueryに転送
  22. 開発KPIの策定と各種モニタリングの整備(性能) Java+SpringBoot Nginx Datadog fluentd, X-Ray Front, API fluentdでnginxのアクセスログを BigQueryに転送

    正規化されたURL毎の 性能レポートを生成 定期通知 性能モニタリングの集計担当をローテ → 性能がどう変化しているか見て考える機会を増やす
  23. 内部向けSLA SLI/SLOへマッピング 開発KPI 計測方法 コミットライン 稼働率 Datadog Synthetics 毎月のモニタリングで稼働率が99.7%以上であること 性能

    アクセスログ 毎月のモニタリングで正規化された各エンドポイントの 95percentileが全て3秒以内であること 特に「サービス稼働率」と「レイテンシ」に着目 → 手軽に定量的な計測がしやすい 例: 開発KPIの策定と各種モニタリングの整備 企画 月次でレポーティング
  24. 内部向けSLA SLI/SLOへマッピング 開発KPI 計測方法 コミットライン 稼働率 Datadog Synthetics 毎月のモニタリングで稼働率が99.7%以上であること 性能

    アクセスログ 毎月のモニタリングで正規化された各エンドポイントの 95percentileが全て3秒以内であること 特に「サービス稼働率」と「レイテンシ」に着目 → 手軽に定量的な計測がしやすい 例: 開発KPIの策定と各種モニタリングの整備 企画 月次でレポーティング 内部向けSLAの担保を定量的 に評価できる!
  25. 内部向けSLA SLI/SLOへマッピング 開発KPI 計測方法 コミットライン 稼働率 Datadog Synthetics 毎月のモニタリングで稼働率が99.7%以上であること 性能

    アクセスログ 毎月のモニタリングで正規化された各エンドポイントの 95percentileが全て3秒以内であること 特に「サービス稼働率」と「レイテンシ」に着目 → 手軽に定量的な計測がしやすい 例: 開発KPIの策定と各種モニタリングの整備 企画 月次でレポーティング 内部向けSLAのトレンドを追 うことで忘れ去られない!
  26. 開発KPIの策定と各種モニタリングの整備 事業KPIに紐づく指標を開発KPIとし、事業(売上)に貢献する 例: 事業KPI = 予約数 → 予約を阻害していないことがわかる指標 = 予約導線のリクエスト成功率

    課題 • 機能開発に意識が向きがちで非機能要件でサービスの品質が低下するリスク • 内部向けのSLAに対して開発Tがどのようなアクションをとって担保してい るのか評価できない Action 開発KPI(SLI/SLO)を策定&モニタリング 狙い • 非機能要件における開発Tの行動指針/評価基準を定める • 非機能要件に対する改善意識を持つ 今後
  27. アジェンダ 1. 美容クリニックとは a. サービス概要 b. アーキテクチャ概要 2. SREチームの組閣 3.

    SRE活動事例 a. 開発KPIの策定と各種モニタリングの整備 b. DX ( Developer eXperience ) の改善活動 4. まとめ
  28. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない アプリ開発T 不満

    困り SRET 認知の壁 As-Is • CIが遅い • テストデータを手動で作成するのが辛い ? • アプリ開発Tが感じている不を認知して解消したい • 特に開発プロセスや開発環境における不を見つけ出 し、改善していきたい
  29. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない アプリ開発T 不満

    困り SRET 認知の壁 As-Is • CIが遅い • テストデータを手動で作成するのが辛い ? • アプリ開発Tが感じている不を認知して解消したい • 特に開発プロセスや開発環境における不を見つけ出 し、改善していきたい 問題を検知するために ① アプリ開発Tへのヒアリング → 定性評価 ② PR解析による開発プロセス評価 → 定量評価
  30. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない アプリ開発T 不満

    困り SRET 認知の壁 As-Is • CIが遅い • テストデータを手動で作成するのが辛い ? • アプリ開発Tが感じている不を認知して解消したい • 特に開発プロセスや開発環境における不を見つけ出 し、改善していきたい DX (=気持ちよく開発・保守できるかどうか)を改善! 問題を検知するために ① アプリ開発Tへのヒアリング → 定性評価 ② PR解析による開発プロセス評価 → 定量評価
  31. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない Action DX改善活動

    狙い 開発プロセスや開発環境における問題を認知し改善する アプリ開発T 不満 困り SRET 認知の壁 DX改善活動 アプリ開発T SRET ヒアリング PR解析 As-Is To-Be • 定性評価 - DX 改善ヒアリング • 定量評価 - PR の解析による開発プロセスの評価
  32. DX改善活動 - PRの解析による開発プロセスの評価 cf. https://blog.shibayu36.org/entry/2020/08/24/173000 https://sourcelevel.io/blog/50-shades-of-lead-time-measuring-each-part-of-the-development-process Commit Pull Request First

    Review Last Review Close or Merge Pull Request Deploy to QA, Stage or Production Opens waits for discuss until Code is ready waits for 各種lead timeから開発フローのボトルネックを探る(評価する) ex. Time to First Reviewが長い → レビュアーに偏りがあるのでは? “Commit to Deploy” “Time to First Review” “First Commit to Pull Request Time” “Time to Review” “Last Review to Merge Time” PR の解析による開発プロセスの評価 開発フローと各Lead Time
  33. DX改善活動 - PRの解析による開発プロセスの評価 cf. https://blog.shibayu36.org/entry/2020/08/24/173000 https://sourcelevel.io/blog/50-shades-of-lead-time-measuring-each-part-of-the-development-process Commit Pull Request First

    Review Review Close or Merge Pull Request Deploy to QA, Stage or Production Opens waits for discuss until Code is ready waits for “Commit to Deploy” “Time to First Review” “First Commit to Pull Request Time” “Time to Review” “Last Review to Merge Time” 美容クリニックの開発フローと各Lead Time Ready for Review が付与される → “開発時間” → “開発+レビュー時間” → “リリース回数” PR の解析による開発プロセスの評価 3つの指標のトレンドをモニタリングし、開発プロセスを評価
  34. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない Action DX改善活動

    狙い アプリ開発T 不満 困り SRET 認知の壁 アプリ開発T SRET ヒアリング PR解析 As-Is To-Be • 定性評価 - DX 改善ヒアリング • 定量評価 - PR の解析による開発プロセスの評価 DX改善活動 開発プロセスや開発環境における問題を認知し改善する
  35. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない Action DX改善活動

    狙い アプリ開発T 不満 困り SRET 認知の壁 アプリ開発T SRET ヒアリング PR解析 As-Is Now • 定性評価 - DX 改善ヒアリング • 定量評価 - PR の解析による開発プロセスの評価 ヒアリングからの改善 → Good PR解析からの改善 → ???(明確なボトルネックは見つけられていない) DX改善活動 開発プロセスや開発環境における問題を認知し改善する
  36. DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない Action DX改善活動

    狙い アプリ開発T 不満 困り SRET 認知の壁 アプリ開発T SRET ヒアリング PR解析 As-Is Now • 定性評価 - DX 改善ヒアリング • 定量評価 - PR の解析による開発プロセスの評価 ヒアリングからの改善 → Good PR解析からの改善 → ???(明確なボトルネックは見つけられていない) DX改善活動 開発プロセスや開発環境における問題を認知し改善する もともとアプリ開発をして いたからこそ持てた視点! → これまでの経験がSREに 活かすことができる!
  37. アジェンダ 1. 美容クリニックとは a. サービス概要 b. アーキテクチャ概要 2. SREチームの組閣 3.

    SRE活動事例 a. 開発KPIの策定と各種モニタリングの整備 b. DX ( Developer eXperience ) の改善活動 4. まとめ
  38. We are HIRING! 中途採用 → https://recruit-saiyo.jp/ 学生向け → https://www.recruit-jinji.jp/ 美容クリニックでは

    SRE としてサービスに関わり、サービスを成長させてい くことができる環境が整っています。 AWS をメインにクラウドサービスを用いたインフラ上で SRE 活動をしたい、 成長期にあるサービスに SRE として携わってみたい、など興味がある方がい らっしゃいましたら、ぜひ下記の採用ページからご応募ください。