heyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~

SRE NEXT2022の登壇資料です。
https://sre-next.dev/2022/schedule#sp15

Transcript

1. 　　 ©hey, Inc heyにおけるSREの大切さ ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~ ヘイ株式会社 プロダクト基盤本部 SRE 藤原 涼馬
2. 自己紹介 藤原 涼馬 ヘイ株式会社 プロダクト基盤本部 SRE (他にもいろいろ) 経歴 　SIer R&D →　　　　　　→ 趣味 　自動車の運転 　模型製作 　各種寄稿・登壇 好きなAWSサービス 　ECS Fargate / AWS SSO + 他 今ここ
3. 会社概要 会社名 ヘイ株式会社 設立 2012年3月23日 代表取締役社長 佐藤裕介 資本金 1億円 所在地 〒150-0011 東京都渋谷区東3丁目16番3号　エフ・ ニッセイ恵比寿ビル4階 事業内容 インターネットビジネスの企画・開発・ 運営
4. 従業員数・職種比率 従業員数 350名 （2021/04 時点) エンジニア 31% セールス・ マーケ・事業開発 30% サポート・ サクセス 23% デザイナー 5.5% PM 2.8% コーポレート 8% エンジニア職の比率 31%
5. heyの事業・STORESプラットフォーム お店のデジタルを まるっとサポート。 個人や中小事業の方々に向けて、 お店のデジタル化をまるっと 実現できる価値を提供しています。
6. 目次 • SREとはなにか • heyにおけるSREの楽しさ • heyにおけるSREの難しさ • 難しさへのSREとしての対峙
7. SREとはなにか？
8. SRE(Site Reliability Engineering)とは？ 1. SREとは、ソフトウェアと自動化を通じてスケーラブルで 信頼性の高いシステム構築と運用を実現する 2. SREチームはリリースエンジニアリングや、プロダクション環境におけるサー ビスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当する IT Operation Software Engineering 参考)https://www.redhat.com/ja/topics/devops/what-is-sre ※ もちろんですがこれが全てではありません
9. 狩野モデル 充足 不充足 充足状況 満足感 一 元 的 品 質 満足 不満 魅力的品質 当たり前品質 品質特性 • 魅力的品質 ◦ 操作していて楽しくなるユーザー体験 • 一元的品質 ◦ 業務を遂行するのに必要な機能が揃っている • 当たり前品質 ◦ システムや機能が意図した通りに動く
10. SRE(Site Reliability Engineering)とは？ 1. SREとは、ソフトウェアと自動化を通じてスケーラブルで 信頼性の高いシステム構築と運用を実現する 2. SREチームはリリースエンジニアリングや、プロダクション環境におけるサー ビスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当する IT Operation Software Engineering 参考)https://www.redhat.com/ja/topics/devops/what-is-sre ※ もちろんですがこれが全てではありません
11. 狩野モデルとSREの役割の関係 品質特性 • 魅力的品質 ◦ 操作していて楽しくなるユーザー体験 • 一元的品質 ◦ 業務を遂行するのに必要な機能が揃っている • 当たり前品質 ◦ システムや機能が意図した通りに動く リリースエンジニアリング プロダクション環境におけ るサービスの可用性、遅延 対応、変更管理、緊急対 応、容量管理
12. もう一段読み替える 品質特性 • 魅力的品質 ◦ 操作していて楽しくなるユーザー体験 • 一元的品質 ◦ 業務を遂行するのに必要な機能が揃っている • 当たり前品質 ◦ システムや機能が意図した通りに動く リリースエンジニアリング プロダクション環境におけ るサービスの可用性、遅延 対応、変更管理、緊急対 応、容量管理 価値提供の支援 “魅力品質、一元的品質”実現のために リリースエンジニアリングを介して 実装された機能を滞りなくユーザーに届けられるようにする
13. もう一段読み替える 品質特性 • 魅力的品質 ◦ 操作していて楽しくなるユーザー体験 • 一元的品質 ◦ 業務を遂行するのに必要な機能が揃っている • 当たり前品質 ◦ システムや機能が意図した通りに動く リリースエンジニアリング プロダクション環境におけ るサービスの可用性、遅延 対応、変更管理、緊急対 応、容量管理 価値提供の支援 “魅力品質、一元的品質”実現のために リリースエンジニアリングを介して 実装された機能を滞りなくユーザーに届けられるようにする 提供価値の維持 “当たり前品質”実現のために、アーキテクチャ設計や運用設計に 非機能的観点から関与し、安定運用の責務を担う。 提供している価値の維持を通じて機会損失の発生を防ぐ
14. SREとは 価値提供の支援 “魅力品質、一元的品質 ”実現のために リリースエンジニアリングを介して 実装された機能を滞りなくユーザーに届けられるようにする 提供価値の維持 “当たり前品質”実現のために、アーキテクチャ設計や運用設計に 非機能的観点から関与し、安定運用の責務を担う 提供している価値の維持を通じて機会損失の発生を防ぐ 上記をソフトウェアエンジニアリングの知識を活用して実現する
15. heyにおけるSREの楽しさ
16. heyにおけるSREの楽しさ(SREに限らない部分ではある)の例 “ネットショップ”でお買い物 このサイトのサービス提供者は... 実店舗で”買い物” このお店のPOSレジは、キャッシュレス決済端末は... 何かしらのサービスを”予約” 通ってるスポーツジムのパーソナルトレーニングの予約システムは...
17. heyにおけるSREの楽しさ(SREに限らない部分ではある)の例 “ネットショップ”でお買い物 このサイトのサービス提供者は... 実店舗で”買い物” このお店のPOSレジは、キャッシュレス決済端末は... 何かしらのサービスを”予約” 通ってるスポーツジムのパーソナルトレーニングの予約システムは... 身近なところで使われているだけに貢献している感は強い (ただしその分責任も感じやすい) 楽しさポイント

18. heyにおけるSREの楽しさ 単一プロダクトの中で価値提供を支援する、提供されている価値を維持する
19. SREの活動事例(価値提供の支援事例) STORES 決済における Elastic BeanstalkからECS Fargateへのリアーキテクチャリング https://speakerdeck.com/fufuhu/storesjue-ji-niokeruec2karaecs-fargatehefalseyi-xing-wu-ting-zhi-yao-jian-motian-ete
20. SREの活動事例(価値提供の支援事例) STORES 決済における Elastic BeanstalkからECS Fargateへのリアーキテクチャリング https://speakerdeck.com/fufuhu/storesjue-ji-niokeruec2karaecs-fargatehefalseyi-xing-wu-ting-zhi-yao-jian-motian-ete プロダクト開発者ほかとの協力が”非常に”重要です
21. SREの活動事例(リアーキテクチャリングにおける関わり方) エンジニアリング マネジメント 時間軸 全体アーキテクチャ 把握 プロダクト固有の 制約条件確認 移行方式の 提案と設計 移行方式の 実装とテスト 切替実施 全体スケジューリング 進捗管理
22. SREの活動事例(リアーキテクチャリングにおける関わり方) エンジニアリング マネジメント 時間軸 全体アーキテクチャ 把握 プロダクト固有の 制約条件確認 移行方式の 提案と設計 移行方式の 実装とテスト 切替実施 全体スケジューリング 進捗管理 SREが本来は把握しているべき(※)だが、 プロダクト開発者に教えてもらいつつ推進
23. SREの活動事例(リアーキテクチャリングにおける関わり方) エンジニアリング マネジメント 時間軸 全体アーキテクチャ 把握 プロダクト固有の 制約条件確認 移行方式の 提案と設計 移行方式の 実装とテスト 切替実施 全体スケジューリング 進捗管理 プロダクト開発者の実現したいことを 確認しつつSREとして主導して推進 QAに協力してもらう範囲なども確定
24. SREの活動事例(リアーキテクチャリングにおける関わり方) エンジニアリング マネジメント 時間軸 全体アーキテクチャ 把握 プロダクト固有の 制約条件確認 移行方式の 提案と設計 移行方式の 実装とテスト 切替実施 全体スケジューリング 進捗管理 SRE主導で推進しつつ手が足りない部分をプロ ダクト開発者に支援してもらう
25. SREの活動事例(リアーキテクチャリングにおける関わり方) エンジニアリング マネジメント 時間軸 全体アーキテクチャ 把握 プロダクト固有の 制約条件確認 移行方式の 提案と設計 移行方式の 実装とテスト 切替実施 全体スケジューリング 進捗管理 プロダクト開発者とSREだけでなく PdMやQAにも助力いただきながら進める
26. SREの活動事例(リアーキテクチャリングにおける関わり方) エンジニアリング マネジメント 時間軸 全体アーキテクチャ 把握 プロダクト固有の 制約条件確認 移行方式の 提案と設計 移行方式の 実装とテスト 切替実施 全体スケジューリング 進捗管理 PdMやEMを中心に推進 SREからはスケジュール的な制約や、 システム面での顧客影響の情報を提供
27. 事例を結果から眺めてみる 結果として、プロダクト開発者、EM、PdM、QA、SREと関係者全員を巻き込みつ つ進めることができた。
28. 事例を結果的に眺めてみる 結果として、プロダクト開発者、EM、PdM、QA、SREと関係者全員を巻き込みつ つ進めることができた。 ユーザーの顔が想像できる分、意思統一を図りやすい かつ、取り組みがうまくいった際に成功を共有しやすい 楽しさポイント

29. 個別プロダクトにおけるSREの活動事例 個別プロダクト内での取組は他にも多々存在します。 heyのプロダクトブログを参照してみてください。 https://tech.hey.jp/
30. heyにおけるSREの難しさ
31. 事業・組織規模の拡大 従業員数 350名 （2021/04 時点)
32. 事業・組織規模の拡大 従業員数 350名 （2021/04 時点) https://note.com/naokos/n/n3e64a68bdaf3
33. 事業・組織規模の拡大 従業員数 350名 （2021/04 時点) https://note.com/naokos/n/n3e64a68bdaf3 基本的には組織が成長することに伴う成長痛
34. 事業・組織が拡大すると何が起きる? 1. 個別プロダクトの拡大と個別最適化 2. コミュニケーションパスの複雑化と知識の散在
35. 事業・組織が拡大すると何が起きる? 1. 個別プロダクトの拡大と個別最適化 2. コミュニケーションパスの複雑化と知識の散在
36. 個別プロダクトの拡大と個別最適化 メリット プロダクトの拡大(≒提供機能の増加)による一元的品質の向上 ドメインに合わせた個別最適化による競争優位性、魅力的品質の創出 デメリット プロダクトの拡大による機能やアーキテクチャの複雑化 過度な最適化 = たこつぼ化
37. 個別プロダクトの拡大と個別最適化 メリット プロダクトの拡大(≒提供機能の増加)による一元的品質の向上 ドメインに合わせた個別最適化による競争優位性、魅力的品質の創出 デメリット プロダクトの拡大による機能やアーキテクチャの複雑化 過度な最適化 = たこつぼ化 向き合わなければいけない課題
38. プロダクトの拡大による機能やアーキテクチャの複雑化による問題点 大原則 複雑なもの = 壊れやすい
39. プロダクトの拡大による機能やアーキテクチャの複雑化による問題点 必要な複雑性の導入は避けられない 不要な複雑性を避ける 大原則 複雑なもの = 壊れやすい
40. プロダクトA たこつぼ化の問題点 • プロダクト間で構成や前提事項が異なりすぎる結果、学習コストが高騰 • 組織として重点投資すると決めた際に機動的な人員の割り当てが困難になる 個々のエンジニアの悩み 言われて来てみたのは良いものの 何がどうなってるのかさっぱりわからない...... 少しずつ学びながら進めよう プロダクトB マネジメント層の悩み プロダクトBに重点投資するので 人員を移動させたけれども 立ち上げにxxヶ月かかるらしい困ったな
41. 事業・組織が拡大すると何が起きる? 1. 個別プロダクトの拡大と個別最適化 2. コミュニケーションパスの複雑化と知識の散在
42. コミュニケーションパスの複雑化 プロダクト間のシステム的な連携の複雑化 人と人の間のコミュニケーションパスの複雑化(もちろん積極的なやりとりは推奨) プロダクトや人が増えるほどコミュニケーションパスが複雑化し、どこに情報があ るのかがわからなくなる(＝知識の散在)
43. 諸問題を放置した場合に予期される未来 組織規模 現実的に目指したい状況 理想的な状況 エンジニアリング的な 創出価値
44. 諸問題を放置した場合に予期される未来 組織規模 現実的に目指したい状況 理想的な状況 エンジニアリング的な 創出価値 放置した場合に想定される状況 （収穫逓減）
45. 諸問題を放置した場合に予期される未来 組織規模 現実的に目指したい状況 理想的な状況 エンジニアリング的な 創出価値 放置した場合に想定される状況 （収穫逓減） 投入できる人員が増えた（＝組織規模が が拡大した）にもかかわらず 創出価値が増えない
46. 諸問題を放置した場合に予期される未来 組織規模 現実的に目指したい状況 理想的な状況 エンジニアリング的な 創出価値 放置した場合に想定される状況 （収穫逓減） この状況を避けるにはどうしたら良いか？
47. 難しさへのSREとしての対峙
48. 課題をまとめてみる 1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず) 2. たこつぼ化による学習コストの高騰 3. 知識の散在による知識習得、活用の効率低下
49. 課題をまとめてみる 1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず) 2. たこつぼ化による学習コストの高騰 3. 知識の散在による知識習得、活用の効率低下 プロダクトに閉じない横断的な考え方、取組の必要性
50. 課題をまとめてみる 1. 個別プロダクト、プロダクト間連携の複雑化 2. たこつぼ化による学習コストの高騰 3. 知識の散在による知識習得、活用の効率低下
51. 個別プロダクト、プロダクト間連携の複雑化への対応 複雑性に対応できるハイスキルエンジニアの育成 各種学習機会の提供 （自助努力のみに頼らない） 安全に試行錯誤 できる場の提供 e.g. ある程度自由に利用できる 　　パブリッククラウドアカウント e.g. 各種学習の補助
52. 課題をまとめてみる 1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず) 2. たこつぼ化による学習コストの高騰 3. 知識の散在による知識習得、活用の効率低下
53. たこつぼ化による学習コストの高騰 知識の散在による知識習得、活用の効率低下 への対応 さまざまな知識を容易に収集、活用できるようにして 歪んだアーキテクチャの導入を避ける 知識の集約と活用容易化 (次スライド以降で補足) 外部視点の導入 組織外の知見者の視点 e.g. AWS TAMによる構成レビュー
54. 知識の集約と活用の容易化 横断的に活用可能な知識集約と活用の容易化 • 知識の集約場所の確保 • 知識活用の容易化
55. 知識の集約と活用の容易化 横断的に活用可能な知識集約と活用の容易化 • 知識の集約場所の確保 • 知識活用の容易化 • 個別プロダクトの知識を集約するための(仮想)組織の準備 • プロダクト個別の取組 ー 固有事情 ＝ 横断的に利用可能な知識 (レアケースだが重要なもののなどの知識が蓄積できる e.g. DBのメジャーバージョンアップに伴う停止時間の最小化など )
56. 知識の集約と活用の容易化 横断的に活用可能な知識集約と活用の容易化 • 知識の集約場所の確保 • 知識活用の容易化 • 個別プロダクトの知識を集約するための(仮想)組織の準備 • プロダクト個別の取組 ー 固有事情 ＝ 横断的に利用可能な知識 (レアケースだが重要なもののなどの知識が蓄積できる e.g. DBのメジャーバージョンアップに伴う停止時間の最小化など ) • 横断的に利用可能なコードの提供 • いわゆるソフトウェアの再利用性といった大きな課題にしっかり取り組む （まずはドメイン依存の少ない部分かつ必ず必要な部分から e.g. インフラのネットワーク、ストレージ、ログ集約など）
57. 取り組みの結果、何を期待する？ ドメイン非依存かつ魅力的品質につながりづらい部分の標準化 と 標準化に伴う品質改善の効率化 プロダクト固有度合 高 低 Application Middleware (Guest)OS VM Network & Strage 魅力的品質につながりやすい 当たり前品質として必要
58. 取り組みの結果、何を期待する？ 当たり前品質の部分から徐々に標準化などを進めていく プロダクト1 プロダクト2 プロダクト3 プロダクトN ・・・ SREはスタック的に下のレイヤで 当たり前品質の実現を主導
59. 取り組みの結果、何を期待する？ 当たり前品質の部分から徐々に標準化などを進めていく プロダクト1 プロダクト2 プロダクト3 プロダクトN ・・・ SREはスタック的に下のレイヤで 当たり前品質の実現を主導 SREはCI/CDなどの構築支援を通じ てプロダクト開発者の一元的、魅力 的品質実現支援も担う
60. 取り組みの結果、何を期待する？ 当たり前品質の部分から徐々に標準化などを進めていく プロダクト1 プロダクト2 プロダクト3 プロダクトN ・・・ SREはスタック的に下のレイヤで 当たり前品質の実現を主導 プロダクト開発者は スタック的に上のレイヤに注力 プロダクト開発者は当たり前品質の実現は SREに任せ、 一元的品質と魅力的品質の実現 に注力
61. まとめ 自分の身近なお商売のオーナーをチームとして支えることによる責任感と達成感が heyのSREに限らない楽しさです。 提供価値の拡大と維持を目的として組織規模の成長にともなう収穫逓減の影響を回 避、緩和するための様々な活動を進めていきたいと考えています。 SREとしては、価値提供の支援、提供価値の維持をより広く、より深く行うための ナレッジマネジメントやナレッジ活用の容易化、人員の機動的運用のための標準化 などにも取り組みたいです。
62. heyの事業・STORESプラットフォーム お店のデジタルを まるっとサポート。 個人や中小事業の方々に向けて、 お店のデジタル化をまるっと 実現できる価値を提供しています。
63. 価値提供の支援、提供価値の維持に興味のあるエンジニア大募集です！ https://hello.hey.jp/engineer
64. MORE INFO heyのオープンな社内報 hey note https://days.hey.jp/ Tech イベント hey connpass https://hey.connpass.com/ プロダクト開発の裏側を発信中 hey Product Blog https://tech.hey.jp/ heyのメディア hey MAGAZINE https://mag.hey.jp プロダクトのこと、技術のこと色々お話しましょう カジュアル面談 (Meety) https://meety.net/ heyのひとびとを伝える動画 hey People https://vimeo.com/heyinc
65. ご清聴ありがとうございました!