皆がSRE的な観点を持ったエンジニアになっていく仕組みとは

皆がSRE的な観点を持った エンジニアになっていく仕組みとは @icchy_san 1

イントロダクション 自己紹介 伊藤 友一 @icchy_san ● ● ● 株式会社ハイヤールー共同創業者の一人 前職では某エンジニアQ&Aサイトや看護・介護職の方向けのサービス のインフラを触っていました 最近はPlatform周りの業務に携わる事が多いです 2

Agenda 1 スタートアップフェーズのSRE 2 ハイヤールーのSRE活動紹介 3 まとめ

01 スタートアップフェーズのSRE

スタートアップフェーズのSRE スタートアップでSRE活動が軽視されそうな理由 機能が少ない ユーザーも少ない 問題が顕在化する 可能性も低い 安定性 << 機能開発 5

スタートアップフェーズのSRE SRE的活動をしたほうがよいと考えられる理由 スケールしていく企業の場合、 信頼性の担保は必要不可欠 ● ● サービスのパフォーマンスが低い ダウンタイムが長い サービスに対するマイナスの印象がつく。 マイナスの印象はなかなか払拭できない 自社サービスが他社サービスと比較された結果選ばれない 6

スタートアップフェーズのSRE 一般的にSREがやること SREがやることって… ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ 7

スタートアップフェーズのSRE 一般的にSREがやること SREがやることって… ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ とにかく多い！ 8

スタートアップフェーズのSRE New! スタートアップでSRE活動が軽視されそうな理由 全システムの管理を1人で行うと... ● ● ● ? 1人で全サービスを把握 ⇒ 負荷がかかる 各サービスの理解が浅い ⇒ 難しい業務も いずれ限界が来る ⇒ スケールしない スタートアップでは1人運用は厳しい。 フェーズ的に合わない活動内容も存在する。 9

02 ハイヤールーのSRE活動紹介

スタートアップフェーズのSRE 結論 （再掲） SREがやることって… ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ 11

スタートアップフェーズのSRE 結論 ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ 12

スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 – SREの区分 大まかなSRE区分 Pure SRE いわゆるGoogle SREで サービス横断するSRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、パフォーマンス チューニングなどを行う Embedded SRE 各開発チームに派遣されるSRE Platform SRE Center of Practiceを実装するSREで 各チームにツールや環境の提供を行う ※他にもあると思うが、説明しやすいように一部抜粋 13

スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 – SREの区分 ハイヤールーでのSRE区分 Pure SRE いわゆるGoogle SREで サービス横断するSRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、パフォーマンス チューニングなどを行う Embedded SRE 各開発チームに派遣されるSRE Platform SRE Center of Practiceを実装するSREで 各チームにツールや環境の提供を行う ※他にもあると思うが、説明しやすいように一部抜粋 14

スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 – 実際に行うこと SRE活動や開発をしやすくなるように 基盤やツールの提供 Role SRE ● ● ● （メイン）開発 所属チーム内のインシデント対応・管理 パフォーマンスチューニング Platform SRE ● ● トイル削減 ポストモーテム会の実施 サービスのコンテキストを理解しているメンバーが インシデント対応や管理を行ったり、 パフォーマンスチューニングをしたりするので、 SRE専任1名で対応するよりも低コストでSRE活動ができる。 15

スタートアップフェーズのSRE ハイヤールーで行っていること ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング 16

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(1) – 何故やるのか サービスをリリースするまでにやること サービスの新規作成 手作業が必要な処理 モニタリングの設定 本番・開発環境の両方に構築 高頻度・多量 新しいバージョンの リリース作業 ︙ 初期構築者の レビュー 生産性の低下 & オペミスによる インシデント率 増加 リリースまでの リードタイム 増加 要望対応速度 が遅くなり 信頼が薄れる 17

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めるか 優先度（例） サービスの新規作成 モニタリングの設定 本番・開発環境の両方に構築 新しいバージョンの リリース作業 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 優先度ぎめ 新しいバージョンの リリース作業 ︙ 18

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 CI/CDによるワークフローの自動化 CI周りの話は「モノレポでマイクロサービスを開発するための戦略と運用」で書いています。 19

• https://hireroo.io/journal/tech/mono-repo-for-microservices

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 IaCによる宣言的なリソース管理 20

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 テンプレーティングやモジュール化 21

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 22

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(3) – 最終的にできたもの テンプレートから サービス初期化 IaCでリソース定義 CI ・単体テストの実行 ・成果物を生成（Docker Imageなど） CD ・IaCで管理されたリソース の適用 ・成果物を各環境へデプロイ 23

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(3) – 最終的にできたもの テンプレートから サービス初期化 IaCでリソース定義 CI ・単体テストの実行 ・成果物を生成（Docker Imageなど） CD ・IaCで管理されたリソース の適用 ・成果物を各環境へデプロイ Platform SREから提供されたワークフローに則るだけで Role SREは開発を始める段階でSRE活動に必要なツール郡が揃う 24

● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(3) – 最終的にできたもの テンプレートから サービス初期化 IaCでリソース定義 CI ・単体テストの実行 ・成果物を生成（Docker Imageなど） CD ・IaCで管理されたリソース の適用 ・成果物を各環境へデプロイ Platform SREから提供されたワークフローに則るだけで Role SREは開発を始める段階でSRE活動に必要なツール郡が揃う トイル削減にコストはかかるが、全員でSRE活動を行うマインドを 構築する上で必要な投資 25

スタートアップフェーズのSRE ハイヤールーで行っていること ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング 26

● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (1) ポストモーテムを導入する上で重要なこと ロギング 共有 見返したり、インシデント対応者同士のコミュニケーションに利用 ポストモーテム共有会を利用して社内全員でインシデントの共有・知識の蓄積 ポストモーテム: インシデント内容と学びの共有を目的とした報告書のこと ポストモーテム インシデント の内容・影響範囲 インシデント からの学び 27

● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (2) – ロギング インシデントタイムライン（ロギング）を活用し、 チーム内の作業のコンフリクトや不適切な対応を防ぐ NG OK A B A B Slack Slack Ale Ale rt rt 対応 互いに知らぬ 場所で対応 Ale rt Ale rt 方針 の共 有 vi a Sla ck 共通認識を持って対応 インシデントの範囲が 増加の可能性 UP 対応完了 28

● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (3) – 共有 ポストモーテム会までの流れ インシデント 対応 ・アラート確認 ・Slackで対応報告 ・恒久対応 or 一次対応 ポストモーテム 作成 ・Notionに ポストモーテムを作成 ポストモーテム会 実施 ・ポストモーテムの レビュー ・チームを横断した知見の 共有 オペレーション化 （Optional） ・再発する可能性があると判断 されたものはオペレーション として残す ・属人化を防ぐ 29

● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (3) – 共有 ポストモーテム会までの流れ インシデント 対応 ・アラート確認 ・Slackで対応報告 ・恒久対応 or 一次対応 ポストモーテム 作成 ・Notionに ポストモーテムを作成 ポストモーテム会 実施 ・ポストモーテムの レビュー ・チームを横断した知見の 共有 オペレーション化 （Optional） ・再発する可能性があると判断 されたものはオペレーション として残す ・属人化を防ぐ 上記サイクルを回しながら知識を蓄積 サービスが無くなってもポストモーテムで得た知識は消えない ⇒ 早めに始めると知識が多く貯まるのでオススメ 30

スタートアップフェーズのSRE ● ● ● パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (4) – ハイヤールーで利用しているテンプレート ● ● ● ● インシデントの詳細 ○ 根本原因 ○ 影響範囲 ○ 一次対応方法 ○ 恒久対応方法 インシデント対応のために行った（行う）アクション インシデントからの学び ○ うまく行ったこと ○ うまく行かなかったこと インシデントタイムライン 31

スタートアップフェーズのSRE ハイヤールーで行っていること ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング 32

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 トイル削減 パフォーマンスチューニング パフォーマンスチューニング サービスの規模 ∝ 負荷増減 なるべく楽をして全員で パフォーマンスチューニングに取り組む環境を作りたい 外部サービスの利用 & moduleで自動構築 Datadog ● ● APM、Tracingを利用してリクエストごとのパフォーマンス計測 Infrastructureを利用してシステムメトリクスの計測 Query Insights ● スロークエリや頻繁に実行されるクエリの計測 33

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 トイル削減 パフォーマンスチューニング パフォーマンスチューニング – システムメトリクスの可視化 リクエスト数をモニタリング コンテナに割り当てられるCPUの使用率 メトリクスを取っておくだけで因果関係が明確 34

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 トイル削減 パフォーマンスチューニング パフォーマンスチューニング – 実際に利用例 1 インシデント発生 & ログやAPMのチェック 2 調査結果の共有 & ソリューションの提案 3 ソリューションの実装とリリース 収集前のデータとの比較はできないので、 初期からメトリクスは収集したほうがよい データがない データが存在 メトリクス収集開始 35

03 まとめ

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 Platform/Role SREが改めて何をしているのか Platform SRE Role SRE トイル削減 インシデント 管理 ポストモーテム パフォーマンチューニング トイル削減 ポストモーテム インシデント 管理 パフォーマンス チューニング 37

スタートアップフェーズのSRE 以上を踏まえてハイヤールーでのSRE活動全体 サービス開発 基盤やツールの提供 メイン業務 基盤を活用して開発を行う インシデント管理 自分が管理しているサービスでインシデントが 発生した際にライブインシデントレポート、ポス トモーテムの作成を行う パフォーマンス チューニング サービス初期化時に構築されるオブザーバビ リティを元にボトルネックになる部分を見つけ、 チューニングを行う developers (Role SRE) platform SRE ポストモーテム会 38

Take Away 全体のまとめ ● PoC後のサービス拡大フェーズでは開発速度だけでなく、 信頼性も重要 ● SRE活動しようと動いている一人に負荷が集中しないよう、開発者全員が SRE的な動きを行いやすい環 境を構築することが重要 ○ Platform SREとRole SREとして分離することで、全員が部分的に SREとしてサービスの信頼性の 担保に寄与できる環境を作っている ● SRE活動をする上で最低限行ったほうが良いと考えていること ○ トイル削減 ○ ポストモーテム ○ パフォーマンスチューニング 39

ご清聴ありがとうございました 40

スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 ハイヤールーでの SRE 区分 Pure SRE いわゆるGoogle SREで サービス横断する SRE Embedded SRE 各開発チームに派遣される SRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、 パフォーマンスチューニングなどを行う 41

スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 ハイヤールーでの SRE 区分 Pure SRE Embedded SRE いわゆるGoogle SREで サービス横断する SRE 各開発チームに派遣される SRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、 パフォーマンスチューニングなどを行う ハイヤールーでの 組織体制 Platform チーム ≒ Embedded SRE 開発 チーム ≒ Role SRE 開発 チーム ≒ Role SRE 開発 チーム ≒ Role SRE 42

スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 Platform チーム + Role SREという構成になっており、各サービスの メンバーは開発と Role SREとしての活動を行っている。 そのため、各サービスのチームでは ● 各サービスにおけるインシデント管理 ● パフォーマンスチューニング を行っている。 SRE活動をメインとしたメンバーではないため、 CI/CDの構築や各 サービスでオブザーバビリティを構築するための基盤となる部分の 開発に関しては Platformチームで行っている。 その結果、 各サービスのコンテキストを理解しているメンバーがパ フォーマンスチューニングだったり、インシデントの管理を行うことが できるため、負荷を分散することができる 。 また、開発者側も、パフォーマンスチューニングを行うために必要な 基盤が自動で Platformチームから提供されるため、その時間を開発 に充てることができるため Win-Winな状態になっている。 大まかにな僕のSRE区分 Pure SRE いわゆるGoogle SREで サービス横断する SRE Embedded SRE 各開発チームに派遣される SRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、パフォーマンスチュー ニングなどを行う 43

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 ポストモーテムの実施 (2) – ロギング インシデントタイムラインはインシデント発生から一次対応、あるいは恒久対応ま でのリアルタイムなログを関係者同士で共有する場であり、対応者それぞれが共通 認識を持ってインシデント対応作業を実行する際に利用される。 NG OK A A B B Slack Slack Ale rt Ale rt Ale Ale rt 対応 互いに知らぬ 場所で対応 インシデントの範囲が 増加の可能性 UP rt 方針 の共 有 vi a Sla ck 共通認識を持って対応 対応完了 44

スタートアップフェーズのSRE ● ● ● ポストモーテムの実施 パフォーマンスチューニング トイル削減 [WIP] ポストモーテムの実施 (1) ポストモーテムを導入する上で重要なこと 1. 2. 3. インシデントタイムライン（ログ）を取ること 全員に対して共有する場を設けること 人を非難しないこと メモ：スライド全体コピーして別のスライドを作成して作業 する（編集がぶつからないように） 45

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 ポストモーテムの実施 (2) – インシデントタイムライン（ログ）を取ること 各チーム（サービス）ごとに アラートが流れてくる Slack のチャンネルが存在 し、その中でやり取りされる（ライブ インシデントレポートとして活用）ため、 どのようなインシ デントがどのように解決されたか を知る機会が他のチー ムに無くなってしまう。 ポストモーテム会を行うことで ● ● ● ● インシデントの解決と恒久対応のアクションが全 員に共有できる 根本原因の解決の放置を防ぐ機会になる 対応方法によってはオペレーションに落とし込 み、ドキュメントを作ることでアラート対応の属人 化を防ぐことができる サービスの作成・削除をしても知見として残る といったメリットが挙げられる。 ※人ではなく仕組みに問題があるはずなので、ポストモーテムではそこを議論する事が重要 46

● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 ポストモーテムの実施 (3) – 全員に対して共有する場を設けること 各チーム（サービス）ごとに アラートが流れてくる Slack のチャンネルが存在 し、その中でやり取りされる（ライブ インシデントレポートとして活用）ため、 どのようなインシ デントがどのように解決されたか を知る機会が他のチー ムに無くなってしまう。 ポストモーテム会までの流れ 1 Slack上で対応についての コミュニケーションを取る 2 恒久対応可能なら行う、時間がかかる場 合は一次対応後にタスクを切る 3 対応後にインシデントレポートを Notion上 に作成する 4 ポストモーテムの会で発生したインシデ ントの発表と恒久対応の進捗確認 5 継続して発生する可能性があるものに関 してはオペレーションとしてドキュメント化 し、属人化しないように対応 ポストモーテム会を行うことで ● ● ● ● インシデントの解決と恒久対応のアクションが全 員に共有できる 根本原因の解決の放置を防ぐ機会になる 対応方法によってはオペレーションに落とし込 み、ドキュメントを作ることでアラート対応の属人 化を防ぐことができる サービスの作成・削除をしても知見として残る といったメリットが挙げられる。 ※人ではなく仕組みに問題があるはずなので、ポストモーテムではそこを議論する事が重要 47

スタートアップフェーズのSRE ● ● ● ポストモーテムの実施 パフォーマンスチューニング トイル削減 トイル削減 日々の開発の中にある代表的なトイル ● ● ● ● ● デプロイ ビルド サービス初期化時の共通コード Terraformの適用 Kubernetesへの変更適用 これらはリリースに必要で、毎回ほぼ同じことを繰り返 す作業でありつまらない仕事であり、ヒューマンエラー による事故が発生する部分でもある。 かつて、手動でサービスの初期化を行った際に、サービ ス名をconfigに設定するコードに不備があり、サービス 名が unnamed-go-serviceとなってしまい、正しくア ラートできない危険性のあるコードが開発環境に出てい たことがある。 48

スタートアップフェーズのSRE 現状のハイヤールーで採用していない項目について ● ● SLI/SLO ○ 指標（Latencyや成功したレスポンスの割合）と指標の数値目標 エラーバジェット ○ 100%エラーのないサービスは無いという前提のもと、一定期間 において事前に許容するエラー率 ○ エラーバジェットがない状態では新しいリリースは許容されない ○ 開発陣とSREとで対立しないために設定されることが多い ○ ハイヤールーではエラーバジェットによるリリースストップをして いない ■ 機能を拡充しないといけないフェーズでリリースができな いとサービスの成長が止まってしまう ■ エラーが発生していることに素早く気づき、ユーザーが 気づくよりも早く修正を行うことで、実質 SLO100％を保 つことができる ■ エラーバジェットの設定はできる状態になっている 機能Aがほしい HireRoo Error Budget 超えてるので NG SRE developers 49