タグから見つける

タグから見つける

職種を選択

事業領域を選択

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

ホットペッパービューティーの美容クリニックのカウンセリング予約ができるサービス（以降 美容クリニック）にて SRE を担当している川村です。

この記事タイトルに興味をもって読み始めていただいている方の多くは実際に SRE として活動されていたり、もしくは SRE に興味を持っている方なのではないかと思います。

私は美容クリニックにて SRE を担当して約 1 年が経ちますが、元々はサーバサイドエンジニアとして開発を行っておりました。 当時は SRE という言葉を聞いたことがある程度の状態だったのですが、試行錯誤しつつも様々な SRE 活動に取り組むことにより SRE が果たすべき使命がわかるようになってきています。

そこで、本記事では美容クリニックをリリースした 2020 年 3 月から約 1 年間で SRE チームが取り組んできた活動のいくつかを紹介させていただこうと思います。

目次

前提知識

SRE の取り組みを理解してもらうために、美容クリニックの開発体制を少し紹介させてください。

美容クリニックでは以下のような開発体制と役割になっています。

hpbc-development-teams

役割 ミッション
開発統括 ・開発計画の作成
・コスト管理
開発チームリーダー ・開発内課題解決
・障害管理
・チーム運営
開発チームテックリード ・技術相談窓口
・本番作業最終レビュー
アプリ開発チーム ・各案件の実行計画立案、実行
SRE チーム ・（以降で説明する内容のため割愛）
QA チーム ・各案件でのテストの計画/設計/実行

美容クリニックは新規体制用の少人数体制で開発を行っており、その内の約 7 割がアプリ開発をしているエンジニアとなっています。 一方で、SRE は全体の約 1 割の人数しかいないという状況にあります。

この SRE の人数が少ないかどうかは扱っているシステムの規模や課題によって評価が変わるかと思いますが、美容クリニックが現在抱えている課題の量に対しては少ない人数だと感じています。

では、このように限られた人数の中でどのようにして SRE 活動を行ってきたのかを紹介していきます。

SRE チームの組閣

美容クリニックのリリース以前から SRE チームは存在していたのですが、リリース前後でその責務は変わってきます。 例えばリリース前はインフラの初期構築がメインの責務となってきますが、リリース後（エンハンス開発）にはインフラの保守運用がメインの責務となります。

さらに、メンバーの変動などにより当初の SRE チームメンバーが 1 名のみしか残らないという状況だったため、改めて SRE チームの組閣を行いました。

アクションと狙い

具体的には SRE チームの「責務」を定義し直しました。

先述したように限られた人数で SRE 活動をするため、本当に必要なタスクのみに集中する必要がありました。 そのため、SRE チームとしてやること/やらないことを明確にしておくことでタスクの取捨選択を可能にしました。

責務の定義をするために SRE チームのミッション、つまり、一言で SRE チームは何をするチームなのかを決めました。 初めに他社の SRE の採用要件に記載されている内容を参考にさせてもらいながら他社の SRE がどんなことをしているのかイメージを掴み、美容クリニックの環境・体制・状況に照らして調整しつつ、美容クリニックにおける SRE は何をすべきなのかを考えていきました。

結果として、美容クリニックの SRE チームのミッションと責務を以下のように定めることができました。

mission

概要を説明すると、 SRE チームは Developers（アプリ開発者） と Systems（システム） の 2 つに向き合ってタスクを遂行するチームになります。 それぞれに対する具体的なタスクは上図に記載のとおりです。 上図に記載されたタスクはあくまでも一例であり、記載されていないタスクはその都度 SRE チームが責務を負って遂行すべきものかを判断しています。

大事なのは SRE チームはインフラのみを担当するのではないという点です。軸足はインフラに置きつつも、アプリ開発者やアプリケーションにも向き合って改善をしていくと定義しています。

さらに、アプリ開発チームとの責務分担も以下のように明確に定義しました。

appt-and-sret

本来アプリ開発チームでやるべきことのいくつかをリリース前は SRE が気を利かせてやっており、その名残からリリース後にも SRE チームへの問い合わせが頻発していたのですが、上記のように責務を明確にしておくことで自然と SRE チームへの問い合わせも減っていきました。

もちろん、協業が必要な部分や上図に記載されていない事項などがあった場合には都度アプリ開発チームと SRE チームがコミュニケーションを取りつつどうするかを考えるようにしています。 このようなコミュニケーションが取れるような関係になっているのも SRE チームの責務がアプリ開発チームと密接に関係し、開発組織としての一体感が生まれているからなのかもしれません。

これらの結果として、当初の目的であった SRE チームが本当に必要なタスクのみに集中することができていると感じています。

課題

責務を定義してから約 1 年が経ち、取り巻く状況も変わってきているため、責務のアップデートが課題となっています。 これについては期毎など定期的に見直すタイミングを設け、適切な責務へアップデートしていこうと考えています。

SRE 活動事例

DX ( Developer eXperience ) の改善活動

エンハンス開発において、アプリ開発チームから SRE チームに開発プロセスや開発環境に関する問い合わせや不満の声が度々寄せられていました。 そんな中、SRE チームではアプリ開発チームが感じている不満や困っていることを認知できておらず、さらに多々寄せられる声に対して SRE チームが認知して対応を検討しているということを示せていないことが課題と感じていました。

この課題を解消するため、Developer Experience （以降、DX ) の改善活動を実施しました。 DX とはシステムを「気持ちよく開発・保守できるかどうか」を示すもので、開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DX は UX の一種であると定義されています。

DX 改善活動では、

  • プロダクトやアプリ開発チームが拡大していくにつれて将来問題になりうる開発プロセスを見直したい
  • 開発プロセスに対する問題検知から改善までのフローを考えたい
  • 「慣れ」によって見落とされてしまう開発における不を探し出したい

という観点を踏まえて、後述する 2 つのアクションを実施しました。

アクションと狙い

開発プロセスや開発環境における問題の認知のために、定性評価と定量評価を導入しました。

DX 改善ヒアリング

定性評価としては、DX 改善ヒアリングと題し、月次でアプリ開発チームに開発プロセスに対するアンケートを実施しました。 自由記述での回答なのですが、例えば「 CI が遅い」「テストデータを手動で作成するのが辛い」などアプリ開発チームが普段開発する上で感じている不満や辛さが辛辣に寄せられていました。

この DX 改善ヒアリングの回答結果を元に、SRE チーム内でアプリ開発チームが感じている問題を認知しタスク化します。 問題に対する根本原因を調査し優先順位をつけて対応していくことで、アプリ開発チームが気持ちよく開発できる環境を整備していきました。 また、タスクとして管理することで SRE チームが計画的に改善を進めていることがアプリ開発チームにも理解され、普段開発する上で感じている不満や辛さを吐き出しやすい雰囲気になっていきました。

DX 改善ヒアリングはアプリ開発チームが感じている・直面している問題点、言い換えると SRE チームが見えていないエンハンス開発における問題点を認知することとそれに対する改善を目的としていたのですが、狙い通りの結果を得ることができたと感じています。

PR の解析による開発プロセスの評価

一方で、定量評価としては PullRequest（以降、PR） の解析による開発プロセスの評価を実施しました。 DX 改善ヒアリング（定性評価）とは異なり、PR の解析による開発プロセスの評価（定量評価）では SRE チームがアプリ開発チームの外部から観測し評価できるものを利用して課題を見つけることを目的としました。

こちらで紹介されている各種 lead time を美容クリニックの開発プロセスに当てはめ、開発プロセスにおけるボトルネックを定量評価していきました。

実際に評価対象とした lead time は以下の 2 つになります。

development-process

それぞれの lead time を計測することで得られる評価事項については以下のとおりと定義しました。

lead time 評価事項
First Commit to PR ・開発時間
・1 PR あたりの開発粒度
PR lead time ・レビューに出した PR の品質
・レビュアーの忙しさ

評価結果の一例として、美容クリニックのあるリポジトリにおける First Commit to PR を集計した結果を以下に掲載します。

sample-result

この結果から想定していた評価事項が得られるということがわかりましたが、実際に開発プロセスにおける明確なボトルネックを見つけることはできませんでした。

しかしながら、SRE チームがアプリ開発チームを外部から観測し評価する、ある意味アプリ開発チームの外形監視ができるということがわかりました。 これを継続していくことで異常を検知できたり、トレンドを分析できたりと一定価値があるものになるのではないかと思っています。

課題

PR 解析による開発プロセスの評価において、具体的なボトルネックを見つけて改善につなげるという一連のフローを回すことができていない点が課題として挙げられます。 また、今回採用している lead time 以外の定量評価の導入についても検討の余地があると感じています。

中長期計画の策定

美容クリニックがリリースしてから約半年間、 SRE チームではリリース時に存在していたインフラ面での負債返却を優先的に取り組んでいました。 この負債返却がある程度落ち着き、案件以外のタスクを考えるフェーズに差し掛かったとき、新たな問題が発生しました。 SRE チームとして「やりたいこと」はたくさんあったのですが、「やるべきかどうか」を判断できない状態になってしまったのです。 つまり、タスクの優先度をつけるための「物差し」が存在していなかったのです。

アクションと狙い

SRE チームのタスクの優先度をつけるために中長期計画を策定することにしました。 中長期計画を策定するために、まずはリスクマインドマップを作成しました。

リスクマインドマップとは美容クリニックというサービスの「成長」を「アクセス数の増加」と仮定し、それによって起こり得る事象を想定し、その事象のリスクを評価したものになります。 アクセス数については、ディレクターが作成している三ヶ年の予測数値を参考にしています。 言葉だけではわかりにくいと思いますので、具体例を以下に掲載します。

risk-mindmap-infra

上記をリスクマインドマップと呼びます。 リスクマインドマップはアクセス数の増加を起点として、そこから想定し得る事象を記載してきます。 例えばアクセス数が増加するということは、美容クリニックのアーキテクチャに照らし合わせるとフロントアプリへのアクセス数が増加するということに繋がります。 さらに、フロントアプリのアクセス数が増加するとフロントアプリのサイドカーにいる nginx のコネクションが枯渇するリスクがあります。 他にも、フロントアプリが利用している API へのアクセス数が増加し、最終的に DB の負荷高騰に繋がる可能性もあります。

いずれの事象も最悪の場合はサービスダウンに繋がる可能性を秘めており、これを表現したのがリスクマインドマップになります。

上記ではインフラ視点のリスクマインドマップになっていましたが、もちろんアプリ視点のリスクマインドマップも下記の例のように作成することができます。（下記リスクマインドマップの説明については割愛）

risk-mindmap-app

このように「美容クリニックの成長」に対応したリスクマインドマップを作成し起こり得るリスクを評価することで、リスクに対する対策（タスク）を考え、タスクに優先度をつけて対応できる状態となります。 その結果として、中長期的なタスク計画とそれに合わせた要員計画を策定することができました。

また、SRE チームとして「やるべきかどうか」を腹落ちした状態でタスクをこなすことができる状態になっているのも良かったと感じています。

課題

先述したようにリスクマインドマップを作成する際にはディレクターが作成している三ヶ年の予測数値を参考にタスクの優先度をつけていたのですが、API の呼び出し数などアプリ開発チーム起因で増加していく数値が優先度をつける際に考慮されていないことがわかりました。 完全に考慮漏れではあったのですが予測するのも難しいと思われるので、API の呼び出し数を定期的にモニタリングしつつ適宜優先度のアップデートを行うようにしていく必要があると考えています。

開発 KPI, 各種モニタリングの整備

エンハンス開発をしているとどうしても機能追加や修正にばかり意識が向いてしまい、非機能要件でサービスの質を落としてしまうことがあります。 それに対し、本章に記載する SRE 活動を通じて、開発チーム全体に非機能要件に対して改善する意識を持つように啓蒙していきました。

アクションと狙い

美容クリニックではリリース当初から非機能要件として概要レベルのサービス目標が定義されていたので、SRE チームではそれを計測可能なレベルで分解し、開発 KPI と称して SLI ( Service Level Indicator ) / SLO ( Service Level Objective ) を再定義しました。（ SLI, SLO の説明についてはこちらを参照ください）

実際に定義した 開発 KPI について一部を抜粋して以下の表で紹介します。

SLI 概要 SLI 詳細 計測方法 集計スパン SLO
障害数 重要機能の障害数 障害チケット数を計測 月次 0 件であること
稼働率 各フロントアプリの稼働率 Datadog Synthetics 月次 99.7 %以上であること
レイテンシ 各フロントアプリにおける正規化されたエンドポイントのサーバサイドレスポンスタイムの 95 percentile フロントアプリのサイドカーの nginx ログ 月次 3 秒以内であること

SLI としては一般的な項目になっているかと思います。 障害数の SLO はかなり厳しいように見えますが、美容クリニックでは障害レベルが定められており、高いレベル（重要機能）の障害に対するものであるため実際はそこまで厳しいものではありません。

次に、定義した開発 KPI のモニタリングの例として、上記表のレイテンシのモニタリング方法を紹介します。

レイテンシのモニタリング

美容クリニックではインフラのメトリクスのほとんどを Datadog に集約しています。 そのため、レイテンシの計測方法にも記載がある nginx のメトリクスは Datadog から参照できるようになっています。

そこでまずは Datadog のダッシュボードを見る機会を増やすため、Slack の Workflow を利用してダッシュボードのキャプチャを定期的に投稿する仕組みを導入しました。（下図参照）

datadog-dashboard

これにより気軽に Datadog のダッシュボードにアクセスできるようになり、レイテンシを確認する機会が増えるようになりました。

また、月次での集計担当をローテーション制にしました。 集計作業は Google Data Studio とスプレッドシートを用いて行い、集計結果を Slack の専用チャンネルにてレポートする運用をしています。 集計作業によって下図のようにレイテンシのトレンドがグラフ化されるようになっているため、集計担当をローテーションすることでレイテンシがどのような変化をしているのかを目で見て考える機会を増やそうという狙いがありました。

latency-monitoring

このようにレイテンシをモニタリングすることによって、実際にアプリケーションとインフラにおける問題を見つけ、改善へ繋げた事例も生まれました（今後テックブログに寄稿されると思いますのでご期待ください）。

開発 KPI を定義し、SRE チームだけではなくアプリ開発チームも巻き込んでモニタリングを継続することで、非機能要件に対する意識を持った開発組織が出来上がっていると実感しています。

課題

事業 KPI に紐づく指標を開発 KPI として定義・モニタリングしていき、より事業の売上にも貢献していきたいと考えています。 現在の開発 KPI だけだと、例えば、稼働率を担保することで副次的には売上 UP に繋がるかもしれませんが、直接的に影響を及ぼすにはいたらないと思っています。 事業会社で働くエンジニアとしては、やはり事業や売上にも貢献したいという思いがあり、その観点でももっと開発組織として力を入れていきたいと考えています。

本番障害一次受け体制の構築

SRE 本や SRE ワークブックにも登場しているオンコールについて、美容クリニックでの取り組みを紹介いたします。

当初、美容クリニックではサービス影響のある障害が発生した際に PagerDuty を利用して開発体制で紹介した開発統括、開発チームリーダー、SRE チームリーダーの 3 名への架電を実施していました。

これらのメンバーの特性上、夜間休日に発生した障害であっても当事者意識を持って対応することができていたのですが、負荷が集中していたのは否めません。

アクションと狙い

そこで本番障害一次受け体制を構築し、上述した問題を解消しようと試みました。

また、サービスを運用する経験が少なかったメンバーに経験を積んでもらい、障害が起きにくいシステムや保守運用しやすいシステムを経験から具体的にイメージして設計できるようになってほしいという狙いもありました。

本番障害一次受け体制を構築するために以下の 3 つを行いました。

  • 責務の定義
  • オンコールローテーション
  • インフラ障害時のサービス影響有無一覧

責務の定義

1 つ目は責務の定義です。 本番障害一次受けがやるべきことを明確、かつシンプルに定め、いざ障害が発生した際にすぐ適切な行動を取れるようにしました。 具体的には、以下の 2 つを責務として定義しています。

  • PagerDutyを受け取り、サービス影響と障害状況を確認する
  • 適切な連絡先へ連絡する

オンコールローテーション

2 つ目は PagerDuty のローテーション設定です。 週次で 1 番最初に架電されるメンバーをローテーションするように PagerDuty のスケジュールとエスカレーションポリシーを用いて実現しています。

例えば、

スケジュール名 スケジュール ローテーション頻度
schedule 1 A さん, B さん, Cさん 週次
schedule 2 B さん, C さん, Aさん 週次
schedule 3 C さん, A さん, Bさん 週次

のようなスケジュールを作成し、

架電順序 架電先
1 schedule 1
2 schedule 2
3 schedule 3

とすることで、週次で最初に架電されるメンバーをローテーションすることができるようになります。

インフラ障害時のサービス影響有無一覧

最後にインフラ障害時のサービス影響有無一覧を作成しました。 これは主に AWS や利用している SaaS で障害が発生した場合に美容クリニックにどのような影響があるのかをまとめたものになります（下図参照）。

架電されるメンバーにはアプリ開発チームも含まれていたため、インフラ関連の障害発生時にどんなサービス影響があるのか、リカバリとして何をすればいいのかをすぐに判断できるようにする狙いがありました。 アプリ開発チーム向けの資料になっているのですがインフラとして使っている技術スタックが一覧でわかるようになっており、SRE チームのオンボーディング資料としても使えるのかもしれません。

infra-failure-check

infra-failure-check2

課題

本番障害一次受け体制は 2021 年 4 月から本格導入しているのですが、幸いなことにまだ障害による架電が発生していません。 そのため、本番障害一次受け体制がうまくいっているのかどうか判断できず、もう少し運用してから振り返りをしてみようと思います。

まとめ

美容クリニックをリリースした 2020 年 3 月からの約 1 年間で実践してきた SRE チームの取り組みとその結果を以下の表にまとめます。

取り組み 具体的なアクション 狙い 結果
SRE チームの組閣 他社の SRE 募集要項を参考に SRE チームのミッションを定義 限られた人数でやる/やらないを明確にしておくことでタスクの取捨選択をできるようにする ◯
狙い通りとなった
DX ( Developer eXperience ) の改善活動 定性評価 : アプリチームへのヒアリング
定量評価 : アプリチームの PullRequest を解析		 定性評価 : アプリチーム（内部）から見たエンハンス開発におけるボトルネックを検知する
定量評価 : SRE チーム（外部）から見たエンハンス開発フローにおけるボトルネックを検知する		 △
定量評価から問題検知と改善に繋げることが課題
中長期計画の策定 リスクマインドマップから中長期計画を策定 潜在リスクを洗い出し、タスクの優先度をつける ◯
各タスクを腹落ちした状態で遂行できている
開発 KPIの策定と各種モニタリングの整備 開発 KPI を策定し、開発チーム全体でモニタリングを実施 非機能要件に対する意識付け △
事業 KPI に繋げることが課題
本番障害一次受け体制の構築 ・責務定義
・オンコールローテーション
・インフラ障害時のサービス影響有無一覧の作成		 ・サービス運用の経験を積む
・障害が起きにくく、保守運用しやすいシステムを設計できるようになる		 ?
評価できるほど事例がないため

今回紹介しきれなかった SRE チームの取り組みも多々あるのですが、約 1 年間でよくチャレンジできたなと感慨深いものがあります。 課題を分析し、それに対する打ち手を定め、実行する、というシンプルなループを回し続けることでこのような SRE 活動を実践でき、とても良い経験になったと思います。 また、これらの SRE 活動をアプリ開発チームが理解して協力してくれたからこその成果だとも感じています。

さいごに

拙い文章でしたが、最後まで読んでいただきありがとうございました。

美容クリニックでは SRE としてサービスに関わり、サービスを成長させていくことができる環境が整っています。

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

引用