Kazuto Kawamura Recruit Co., Ltd. 『ホットペッパービューティー』 美容クリニックでのSRE活動

Whoami Kazuto Kawamura Software Engineer at 株式会社リクルート ● 2018年7月中途入社 『ホットペッパービューティー』美容クリニックチーム所属 ● 2018年7月〜 サーバサイド担当 ● 2020年10月〜 開発チームリーダー＆SREチームリーダー ● 2021年4月〜 美容領域TechLead

今日の発表内容 本講演ではこれからSRE活動を始めていこうとしている方にとって役立つ事例紹介をさせていただきます。 今回は『ホットペッパービューティー』の美容クリニックのカウンセリング予約ができるサービス （以降、美容クリニック）のリリースから現在に至るまで、SREが取り組んできた活動のいくつかを、利用 しているクラウド技術を交えながら発表いたします。 もともとはサーバサイドエンジニアとして開発を行っていた私は、美容クリニックにて初めてSREを担当 し、現在に至るまでに試行錯誤しつつも様々なSRE活動に取り組んできました。 経験がない状態でSREチームを組閣し、SLI/SLOの策定からモニタリング環境整備まで、技術/非技術問わ ず、美容クリニックのSREがこれまで何をやってきたのかを具体的な事例を挙げて紹介いたします。

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

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

美容クリニックとは 2020年3月ローンチ 美容クリニックのカウンセリング予約サービス 掲載中の1,000件超のクリニックを24時間いつでも 予約できる https://clinic.beauty.hotpepper.jp/ 美容クリニック 東京院
 ビヨウクリニック トウキョウイン 


Java+SpringBoot Nginx Datadog fluentd, X-Ray 美容クリニックとは Front 予約API 入稿API Java+SpringBoot Nginx Datadog fluentd, X-Ray Java+SpringBoot Nginx Datadog fluentd, X-Ray

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から必要な情報を取得し、ブラウザへのレスポンスを返却 する

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。データリソースも分割されている

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

美容クリニックにおけるSREチームの組閣 PJ発足 ● SRETが発足 2020年3月 ● 美容クリニックC/O 2020年4月 ● 　がSRETリーダーに SRET 現在 アプリ開発T 人数

美容クリニックにおけるSREチームの組閣 PJ発足 ● SRETが発足 2020年3月 ● 美容クリニックC/O 2020年4月 ● 　がSRETリーダーに SRET 現在 アプリ開発T 人数 ①開発組織の中でSRETは約1割と少ない人数 課題

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

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

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

美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく 課題

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

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

美容クリニックにおけるSREチームの組閣 SREが何をすべきかわからない & 限られた人数でSRE活動をしていく SRETの責務を定義し直し 限られた人数で何をやる/やらないかを明確にしておくことで 本当に必要なタスクに集中する ● 他社のSREの募集要項からSREがやるべきことを把握 課題 Action 狙い そもそもSREって何するの？ SREの具体的な職務内容が 書かれているのでイメージ しやすい！

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

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

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

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

美容クリニックにおける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の業務内容をキャッチアップ ● 限られた人数で何をやる/やらないかを明確にしておくことで本当に必要な タスクに集中する 狙い

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

開発KPIの策定と各種モニタリングの整備 ● 美容クリニックC/O 現在 背景 2020年3月 内部向けSLA ● 開発内部向けの非機能要件に関する定義 ● 例: 各画面のレスポンスタイム → 3秒以内 企画

開発KPIの策定と各種モニタリングの整備 ● 美容クリニックC/O 現在 2020年3月 企画 内部向けSLA 新機能追加 背景

背景 開発KPIの策定と各種モニタリングの整備 ● 美容クリニックC/O 現在 2020年3月 企画 内部向けSLA 新機能追加 非機能要件が忘れ去られる → サービスの品質低下

背景 開発KPIの策定と各種モニタリングの整備 ● 美容クリニックC/O 現在 2020年3月 企画 内部向けSLA 新機能追加 内部向けSLA（非機能要件） の担保をどう評価する？

開発KPIの策定と各種モニタリングの整備 課題 ● 機能開発に意識が向きがちで非機能要件でサービスの品質が低下するリスク ● 内部向けのSLAに対して開発Tがどのようなアクションをとって担保してい るのか評価できない

開発KPIの策定と各種モニタリングの整備 課題 ● 機能開発に意識が向きがちで非機能要件でサービスの品質が低下するリスク ● 内部向けのSLAに対して開発Tがどのようなアクションをとって担保してい るのか評価できない Action 開発KPI（SLI/SLO）を策定＆モニタリング 狙い ● 非機能要件における開発Tの行動指針/評価基準を定める ● 非機能要件に対する改善意識を持つ

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

Java+SpringBoot Nginx Datadog fluentd Front 開発KPIの策定と各種モニタリングの整備（稼働率） 稼働率を月次でスプレッドシートにまとめ、トレンドやQoQ/MoMでの比較可能にする Datadogでのリアルタイムモニタリング

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

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の策定と各種モニタリングの整備（性能）

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

開発KPIの策定と各種モニタリングの整備（性能） Java+SpringBoot Nginx Datadog fluentd, X-Ray Front, API fluentdでnginxのアクセスログを BigQueryに転送 正規化されたURL毎の 性能レポートを生成 定期通知 性能モニタリングの集計担当をローテ → 性能がどう変化しているか見て考える機会を増やす

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

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

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

開発KPIの策定と各種モニタリングの整備 事業KPIに紐づく指標を開発KPIとし、事業（売上）に貢献する 例: 事業KPI = 予約数 → 予約を阻害していないことがわかる指標 = 予約導線のリクエスト成功率 課題 ● 機能開発に意識が向きがちで非機能要件でサービスの品質が低下するリスク ● 内部向けのSLAに対して開発Tがどのようなアクションをとって担保してい るのか評価できない Action 開発KPI（SLI/SLO）を策定＆モニタリング 狙い ● 非機能要件における開発Tの行動指針/評価基準を定める ● 非機能要件に対する改善意識を持つ 今後

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

DX ( Developer eXperience ) の改善活動 課題 SRETがアプリ開発Tが感じている不満や困っていることを認知できていない アプリ開発T 不満 困り SRET 認知の壁 As-Is ● CIが遅い ● テストデータを手動で作成するのが辛い ?

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

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

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

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

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

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つの指標のトレンドをモニタリングし、開発プロセスを評価

DX改善活動 - PRの解析による開発プロセスの評価 PR解析処理 Webhook APIを利用したPR詳細情報取得 データ抽出 スプレッドシートでトレンド観測 開発時間の 目安

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

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

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

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

まとめ これからSRE活動を始めていこうとしている方にとって（きっと）役立つ事例紹介をさせていただきました。 ※紹介できなかったSRE活動もたくさんあります。 We Are Now SRE 課題を分析し、それに対する打ち手を定め、実行する、というシンプルなループを回し続けることで SRE活動は実践できます。 人とシステムに向き合ってSRE活動を継続していきましょう！ ● 限られた人数のSRE活動 → SRETの責務を定義し直し ● 品質低下リスクやアクション評価 → SLI/SLO策定＆モニタリング ● アプリ開発Tの不満が認知できない → 定性・定量評価する

We are HIRING! 中途採用 → https://recruit-saiyo.jp/ 学生向け → https://www.recruit-jinji.jp/ 美容クリニックでは SRE としてサービスに関わり、サービスを成長させてい くことができる環境が整っています。 AWS をメインにクラウドサービスを用いたインフラ上で SRE 活動をしたい、 成長期にあるサービスに SRE として携わってみたい、など興味がある方がい らっしゃいましたら、ぜひ下記の採用ページからご応募ください。