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

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

Transcript

1. 　　
   ©hey, Inc
   heyにおけるSREの大切さ
   ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~
   ヘイ株式会社 プロダクト基盤本部 SRE 藤原 涼馬
   

   View Slide

2. 自己紹介
   藤原 涼馬
   ヘイ株式会社 プロダクト基盤本部 SRE
   (他にもいろいろ)
   経歴
   　SIer R&D →　　　　　　→
   趣味
   　自動車の運転
   　模型製作
   　各種寄稿・登壇
   好きなAWSサービス
   　ECS Fargate / AWS SSO
   + 他
   今ここ
   

   View Slide

3. 会社概要
   会社名 ヘイ株式会社
   設立 2012年3月23日
   代表取締役社長 佐藤裕介
   資本金 1億円
   所在地
   〒150-0011
   東京都渋谷区東3丁目16番3号　エフ・
   ニッセイ恵比寿ビル4階
   事業内容
   インターネットビジネスの企画・開発・
   運営
   

   View Slide

4. 従業員数・職種比率
   従業員数
   350名
   （2021/04 時点)
   エンジニア
   31%
   セールス・
   マーケ・事業開発
   30%
   サポート・
   サクセス
   23%
   デザイナー
   5.5%
   PM
   2.8%
   コーポレート
   8%
   エンジニア職の比率
   31%
   

   View Slide

5. heyの事業・STORESプラットフォーム
   お店のデジタルを
   まるっとサポート。
   個人や中小事業の方々に向けて、
   お店のデジタル化をまるっと
   実現できる価値を提供しています。
   

   View Slide

6. 目次
   ● SREとはなにか
   ● heyにおけるSREの楽しさ
   ● heyにおけるSREの難しさ
   ● 難しさへのSREとしての対峙
   

   View Slide

7. SREとはなにか？
   

   View Slide

8. SRE(Site Reliability Engineering)とは？
   1. SREとは、ソフトウェアと自動化を通じてスケーラブルで
   信頼性の高いシステム構築と運用を実現する
   2. SREチームはリリースエンジニアリングや、プロダクション環境におけるサー
   ビスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当する
   IT Operation
   Software
   Engineering
   参考)https://www.redhat.com/ja/topics/devops/what-is-sre
   ※ もちろんですがこれが全てではありません
   

   View Slide

9. 狩野モデル
   充足
   不充足
   充足状況
   満足感
   一
   元
   的
   品
   質
   満足
   不満
   魅力的品質
   当たり前品質
   品質特性
   ● 魅力的品質
   ○ 操作していて楽しくなるユーザー体験
   ● 一元的品質
   ○ 業務を遂行するのに必要な機能が揃っている
   ● 当たり前品質
   ○ システムや機能が意図した通りに動く
   

   View Slide

10. SRE(Site Reliability Engineering)とは？
    1. SREとは、ソフトウェアと自動化を通じてスケーラブルで
    信頼性の高いシステム構築と運用を実現する
    2. SREチームはリリースエンジニアリングや、プロダクション環境におけるサー
    ビスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当する
    IT Operation
    Software
    Engineering
    参考)https://www.redhat.com/ja/topics/devops/what-is-sre
    ※ もちろんですがこれが全てではありません
    

    View Slide

11. 狩野モデルとSREの役割の関係
    品質特性
    ● 魅力的品質
    ○ 操作していて楽しくなるユーザー体験
    ● 一元的品質
    ○ 業務を遂行するのに必要な機能が揃っている
    ● 当たり前品質
    ○ システムや機能が意図した通りに動く
    リリースエンジニアリング
    プロダクション環境におけ
    るサービスの可用性、遅延
    対応、変更管理、緊急対
    応、容量管理
    

    View Slide

12. もう一段読み替える
    品質特性
    ● 魅力的品質
    ○ 操作していて楽しくなるユーザー体験
    ● 一元的品質
    ○ 業務を遂行するのに必要な機能が揃っている
    ● 当たり前品質
    ○ システムや機能が意図した通りに動く
    リリースエンジニアリング
    プロダクション環境におけ
    るサービスの可用性、遅延
    対応、変更管理、緊急対
    応、容量管理
    価値提供の支援
    “魅力品質、一元的品質”実現のために
    リリースエンジニアリングを介して
    実装された機能を滞りなくユーザーに届けられるようにする
    

    View Slide

13. もう一段読み替える
    品質特性
    ● 魅力的品質
    ○ 操作していて楽しくなるユーザー体験
    ● 一元的品質
    ○ 業務を遂行するのに必要な機能が揃っている
    ● 当たり前品質
    ○ システムや機能が意図した通りに動く
    リリースエンジニアリング
    プロダクション環境におけ
    るサービスの可用性、遅延
    対応、変更管理、緊急対
    応、容量管理
    価値提供の支援
    “魅力品質、一元的品質”実現のために
    リリースエンジニアリングを介して
    実装された機能を滞りなくユーザーに届けられるようにする
    提供価値の維持
    “当たり前品質”実現のために、アーキテクチャ設計や運用設計に
    非機能的観点から関与し、安定運用の責務を担う。
    提供している価値の維持を通じて機会損失の発生を防ぐ
    

    View Slide

14. SREとは
    価値提供の支援
    “魅力品質、一元的品質 ”実現のために
    リリースエンジニアリングを介して
    実装された機能を滞りなくユーザーに届けられるようにする
    提供価値の維持
    “当たり前品質”実現のために、アーキテクチャ設計や運用設計に
    非機能的観点から関与し、安定運用の責務を担う
    提供している価値の維持を通じて機会損失の発生を防ぐ
    上記をソフトウェアエンジニアリングの知識を活用して実現する
    

    View Slide

15. heyにおけるSREの楽しさ
    

    View Slide

16. heyにおけるSREの楽しさ(SREに限らない部分ではある)の例
    “ネットショップ”でお買い物
    このサイトのサービス提供者は...
    実店舗で”買い物”
    このお店のPOSレジは、キャッシュレス決済端末は...
    何かしらのサービスを”予約”
    通ってるスポーツジムのパーソナルトレーニングの予約システムは...
    

    View Slide

17. heyにおけるSREの楽しさ(SREに限らない部分ではある)の例
    “ネットショップ”でお買い物
    このサイトのサービス提供者は...
    実店舗で”買い物”
    このお店のPOSレジは、キャッシュレス決済端末は...
    何かしらのサービスを”予約”
    通ってるスポーツジムのパーソナルトレーニングの予約システムは...
    身近なところで使われているだけに貢献している感は強い
    (ただしその分責任も感じやすい)
    楽しさポイント

    

    View Slide

18. heyにおけるSREの楽しさ
    単一プロダクトの中で価値提供を支援する、提供されている価値を維持する
    

    View Slide

19. SREの活動事例(価値提供の支援事例)
    STORES 決済における
    Elastic BeanstalkからECS Fargateへのリアーキテクチャリング
    https://speakerdeck.com/fufuhu/storesjue-ji-niokeruec2karaecs-fargatehefalseyi-xing-wu-ting-zhi-yao-jian-motian-ete
    

    View Slide

20. SREの活動事例(価値提供の支援事例)
    STORES 決済における
    Elastic BeanstalkからECS Fargateへのリアーキテクチャリング
    https://speakerdeck.com/fufuhu/storesjue-ji-niokeruec2karaecs-fargatehefalseyi-xing-wu-ting-zhi-yao-jian-motian-ete
    プロダクト開発者ほかとの協力が”非常に”重要です
    

    View Slide

21. SREの活動事例(リアーキテクチャリングにおける関わり方)
    エンジニアリング
    マネジメント
    時間軸
    全体アーキテクチャ
    把握
    プロダクト固有の
    制約条件確認
    移行方式の
    提案と設計
    移行方式の
    実装とテスト
    切替実施
    全体スケジューリング 進捗管理
    

    View Slide

22. SREの活動事例(リアーキテクチャリングにおける関わり方)
    エンジニアリング
    マネジメント
    時間軸
    全体アーキテクチャ
    把握
    プロダクト固有の
    制約条件確認
    移行方式の
    提案と設計
    移行方式の
    実装とテスト
    切替実施
    全体スケジューリング 進捗管理
    SREが本来は把握しているべき(※)だが、
    プロダクト開発者に教えてもらいつつ推進
    

    View Slide

23. SREの活動事例(リアーキテクチャリングにおける関わり方)
    エンジニアリング
    マネジメント
    時間軸
    全体アーキテクチャ
    把握
    プロダクト固有の
    制約条件確認
    移行方式の
    提案と設計
    移行方式の
    実装とテスト
    切替実施
    全体スケジューリング 進捗管理
    プロダクト開発者の実現したいことを
    確認しつつSREとして主導して推進
    QAに協力してもらう範囲なども確定
    

    View Slide

24. SREの活動事例(リアーキテクチャリングにおける関わり方)
    エンジニアリング
    マネジメント
    時間軸
    全体アーキテクチャ
    把握
    プロダクト固有の
    制約条件確認
    移行方式の
    提案と設計
    移行方式の
    実装とテスト
    切替実施
    全体スケジューリング 進捗管理
    SRE主導で推進しつつ手が足りない部分をプロ
    ダクト開発者に支援してもらう
    

    View Slide

25. SREの活動事例(リアーキテクチャリングにおける関わり方)
    エンジニアリング
    マネジメント
    時間軸
    全体アーキテクチャ
    把握
    プロダクト固有の
    制約条件確認
    移行方式の
    提案と設計
    移行方式の
    実装とテスト
    切替実施
    全体スケジューリング 進捗管理
    プロダクト開発者とSREだけでなく
    PdMやQAにも助力いただきながら進める
    

    View Slide

26. SREの活動事例(リアーキテクチャリングにおける関わり方)
    エンジニアリング
    マネジメント
    時間軸
    全体アーキテクチャ
    把握
    プロダクト固有の
    制約条件確認
    移行方式の
    提案と設計
    移行方式の
    実装とテスト
    切替実施
    全体スケジューリング 進捗管理
    PdMやEMを中心に推進
    SREからはスケジュール的な制約や、
    システム面での顧客影響の情報を提供
    

    View Slide

27. 事例を結果から眺めてみる
    結果として、プロダクト開発者、EM、PdM、QA、SREと関係者全員を巻き込みつ
    つ進めることができた。
    

    View Slide

28. 事例を結果的に眺めてみる
    結果として、プロダクト開発者、EM、PdM、QA、SREと関係者全員を巻き込みつ
    つ進めることができた。
    ユーザーの顔が想像できる分、意思統一を図りやすい
    かつ、取り組みがうまくいった際に成功を共有しやすい
    楽しさポイント

    

    View Slide

29. 個別プロダクトにおけるSREの活動事例
    個別プロダクト内での取組は他にも多々存在します。
    heyのプロダクトブログを参照してみてください。
    https://tech.hey.jp/
    

    View Slide

30. heyにおけるSREの難しさ
    

    View Slide

31. 事業・組織規模の拡大
    従業員数
    350名
    （2021/04 時点)
    

    View Slide

32. 事業・組織規模の拡大
    従業員数
    350名
    （2021/04 時点)
    https://note.com/naokos/n/n3e64a68bdaf3
    

    View Slide

33. 事業・組織規模の拡大
    従業員数
    350名
    （2021/04 時点)
    https://note.com/naokos/n/n3e64a68bdaf3
    基本的には組織が成長することに伴う成長痛
    

    View Slide

34. 事業・組織が拡大すると何が起きる?
    1. 個別プロダクトの拡大と個別最適化
    2. コミュニケーションパスの複雑化と知識の散在
    

    View Slide

35. 事業・組織が拡大すると何が起きる?
    1. 個別プロダクトの拡大と個別最適化
    2. コミュニケーションパスの複雑化と知識の散在
    

    View Slide

36. 個別プロダクトの拡大と個別最適化
    メリット
    プロダクトの拡大(≒提供機能の増加)による一元的品質の向上
    ドメインに合わせた個別最適化による競争優位性、魅力的品質の創出
    デメリット
    プロダクトの拡大による機能やアーキテクチャの複雑化
    過度な最適化 = たこつぼ化
    

    View Slide

37. 個別プロダクトの拡大と個別最適化
    メリット
    プロダクトの拡大(≒提供機能の増加)による一元的品質の向上
    ドメインに合わせた個別最適化による競争優位性、魅力的品質の創出
    デメリット
    プロダクトの拡大による機能やアーキテクチャの複雑化
    過度な最適化 = たこつぼ化
    向き合わなければいけない課題
    

    View Slide

38. プロダクトの拡大による機能やアーキテクチャの複雑化による問題点
    大原則
    複雑なもの = 壊れやすい
    

    View Slide

39. プロダクトの拡大による機能やアーキテクチャの複雑化による問題点
    必要な複雑性の導入は避けられない
    不要な複雑性を避ける
    大原則
    複雑なもの = 壊れやすい
    

    View Slide

40. プロダクトA
    たこつぼ化の問題点
    ● プロダクト間で構成や前提事項が異なりすぎる結果、学習コストが高騰
    ● 組織として重点投資すると決めた際に機動的な人員の割り当てが困難になる
    個々のエンジニアの悩み
    言われて来てみたのは良いものの
    何がどうなってるのかさっぱりわからない......
    少しずつ学びながら進めよう
    プロダクトB
    マネジメント層の悩み
    プロダクトBに重点投資するので
    人員を移動させたけれども
    立ち上げにxxヶ月かかるらしい困ったな
    

    View Slide

41. 事業・組織が拡大すると何が起きる?
    1. 個別プロダクトの拡大と個別最適化
    2. コミュニケーションパスの複雑化と知識の散在
    

    View Slide

42. コミュニケーションパスの複雑化
    プロダクト間のシステム的な連携の複雑化
    人と人の間のコミュニケーションパスの複雑化(もちろん積極的なやりとりは推奨)
    プロダクトや人が増えるほどコミュニケーションパスが複雑化し、どこに情報があ
    るのかがわからなくなる(＝知識の散在)
    

    View Slide

43. 諸問題を放置した場合に予期される未来
    組織規模
    現実的に目指したい状況
    理想的な状況
    エンジニアリング的な
    創出価値
    

    View Slide

44. 諸問題を放置した場合に予期される未来
    組織規模
    現実的に目指したい状況
    理想的な状況
    エンジニアリング的な
    創出価値
    放置した場合に想定される状況
    （収穫逓減）
    

    View Slide

45. 諸問題を放置した場合に予期される未来
    組織規模
    現実的に目指したい状況
    理想的な状況
    エンジニアリング的な
    創出価値
    放置した場合に想定される状況
    （収穫逓減）
    投入できる人員が増えた（＝組織規模が
    が拡大した）にもかかわらず
    創出価値が増えない
    

    View Slide

46. 諸問題を放置した場合に予期される未来
    組織規模
    現実的に目指したい状況
    理想的な状況
    エンジニアリング的な
    創出価値
    放置した場合に想定される状況
    （収穫逓減）
    この状況を避けるにはどうしたら良いか？
    

    View Slide

47. 難しさへのSREとしての対峙
    

    View Slide

48. 課題をまとめてみる
    1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず)
    2. たこつぼ化による学習コストの高騰
    3. 知識の散在による知識習得、活用の効率低下
    

    View Slide

49. 課題をまとめてみる
    1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず)
    2. たこつぼ化による学習コストの高騰
    3. 知識の散在による知識習得、活用の効率低下
    プロダクトに閉じない横断的な考え方、取組の必要性
    

    View Slide

50. 課題をまとめてみる
    1. 個別プロダクト、プロダクト間連携の複雑化
    2. たこつぼ化による学習コストの高騰
    3. 知識の散在による知識習得、活用の効率低下
    

    View Slide

51. 個別プロダクト、プロダクト間連携の複雑化への対応
    複雑性に対応できるハイスキルエンジニアの育成
    各種学習機会の提供
    （自助努力のみに頼らない）
    安全に試行錯誤
    できる場の提供
    e.g. ある程度自由に利用できる
    　　パブリッククラウドアカウント
    e.g. 各種学習の補助
    

    View Slide

52. 課題をまとめてみる
    1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず)
    2. たこつぼ化による学習コストの高騰
    3. 知識の散在による知識習得、活用の効率低下
    

    View Slide

53. たこつぼ化による学習コストの高騰
    知識の散在による知識習得、活用の効率低下 への対応
    さまざまな知識を容易に収集、活用できるようにして
    歪んだアーキテクチャの導入を避ける
    知識の集約と活用容易化
    (次スライド以降で補足)
    外部視点の導入
    組織外の知見者の視点
    e.g. AWS TAMによる構成レビュー
    

    View Slide

54. 知識の集約と活用の容易化
    横断的に活用可能な知識集約と活用の容易化
    ● 知識の集約場所の確保
    ● 知識活用の容易化
    

    View Slide

55. 知識の集約と活用の容易化
    横断的に活用可能な知識集約と活用の容易化
    ● 知識の集約場所の確保
    ● 知識活用の容易化
    ● 個別プロダクトの知識を集約するための(仮想)組織の準備
    ● プロダクト個別の取組 ー 固有事情 ＝ 横断的に利用可能な知識
    (レアケースだが重要なもののなどの知識が蓄積できる
    e.g. DBのメジャーバージョンアップに伴う停止時間の最小化など
    )
    

    View Slide

56. 知識の集約と活用の容易化
    横断的に活用可能な知識集約と活用の容易化
    ● 知識の集約場所の確保
    ● 知識活用の容易化
    ● 個別プロダクトの知識を集約するための(仮想)組織の準備
    ● プロダクト個別の取組 ー 固有事情 ＝ 横断的に利用可能な知識
    (レアケースだが重要なもののなどの知識が蓄積できる
    e.g. DBのメジャーバージョンアップに伴う停止時間の最小化など
    )
    ● 横断的に利用可能なコードの提供
    ● いわゆるソフトウェアの再利用性といった大きな課題にしっかり取り組む
    （まずはドメイン依存の少ない部分かつ必ず必要な部分から
    e.g. インフラのネットワーク、ストレージ、ログ集約など）
    

    View Slide

57. 取り組みの結果、何を期待する？
    ドメイン非依存かつ魅力的品質につながりづらい部分の標準化
    と
    標準化に伴う品質改善の効率化
    プロダクト固有度合
    高
    低
    Application
    Middleware
    (Guest)OS
    VM
    Network &
    Strage
    魅力的品質につながりやすい
    当たり前品質として必要
    

    View Slide

58. 取り組みの結果、何を期待する？
    当たり前品質の部分から徐々に標準化などを進めていく
    プロダクト1 プロダクト2 プロダクト3 プロダクトN
    ・・・
    SREはスタック的に下のレイヤで
    当たり前品質の実現を主導
    

    View Slide

59. 取り組みの結果、何を期待する？
    当たり前品質の部分から徐々に標準化などを進めていく
    プロダクト1 プロダクト2 プロダクト3 プロダクトN
    ・・・
    SREはスタック的に下のレイヤで
    当たり前品質の実現を主導
    SREはCI/CDなどの構築支援を通じ
    てプロダクト開発者の一元的、魅力
    的品質実現支援も担う
    

    View Slide

60. 取り組みの結果、何を期待する？
    当たり前品質の部分から徐々に標準化などを進めていく
    プロダクト1 プロダクト2 プロダクト3 プロダクトN
    ・・・
    SREはスタック的に下のレイヤで
    当たり前品質の実現を主導
    プロダクト開発者は
    スタック的に上のレイヤに注力
    プロダクト開発者は当たり前品質の実現は SREに任せ、
    一元的品質と魅力的品質の実現 に注力
    

    View Slide

61. まとめ
    自分の身近なお商売のオーナーをチームとして支えることによる責任感と達成感が
    heyのSREに限らない楽しさです。
    提供価値の拡大と維持を目的として組織規模の成長にともなう収穫逓減の影響を回
    避、緩和するための様々な活動を進めていきたいと考えています。
    SREとしては、価値提供の支援、提供価値の維持をより広く、より深く行うための
    ナレッジマネジメントやナレッジ活用の容易化、人員の機動的運用のための標準化
    などにも取り組みたいです。
    

    View Slide

62. heyの事業・STORESプラットフォーム
    お店のデジタルを
    まるっとサポート。
    個人や中小事業の方々に向けて、
    お店のデジタル化をまるっと
    実現できる価値を提供しています。
    

    View Slide

63. 価値提供の支援、提供価値の維持に興味のあるエンジニア大募集です！
    https://hello.hey.jp/engineer
    

    View Slide

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
    

    View Slide

65. ご清聴ありがとうございました!
    

    View Slide