EnablingとEmbeddedのはざまで

33.1K Views

July 11, 24

スライド概要

2024/7/11開催のEmbedded SRE 現場に寄り添うアプローチで話したスライドです。
https://findy.connpass.com/event/323099/

profile-image

SRE/テックリード 過去のスライドはこちら https://speakerdeck.com/tatsuo48

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

EnablingとEmbedded のはざまで 2024/7/11 Embedded SRE 現場に寄り添うアプローチ 横山達男/tatsuo48

2.

横山 達男 (@tatsuo48) Money Forward Enabling SRE/テックリード

3.

お話すること ● ● ● ● マネーフォワードのサービス基盤のご紹介 Enabling活動 Enabling から Embedded へ 今後の展望

4.

マネーフォワードの サービス基盤のご紹介

5.

マネーフォワードのサービス基盤 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

6.

マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ サービス単位で namespaceを分離 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

7.

マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● サービス単位で namespaceを分離 複数のAWSアカウント ○ サービス単位で AWSアカウントを分離 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

8.

マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● 複数のAWSアカウント ○ ● サービス単位で namespaceを分離 サービス単位で AWSアカウントを分離 何を狙っているのか? 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

9.

マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● 複数のAWSアカウント ○ ● サービス単位で namespaceを分離 サービス単位で AWSアカウントを分離 何を狙っているのか? ○ 開発者への適切な権限委譲を図る 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

10.

マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● 複数のAWSアカウント ○ ● サービス単位で namespaceを分離 サービス単位で AWSアカウントを分離 何を狙っているのか? ○ 開発者への適切な権限委譲を図る ■ 100以上のマイクロサービス ■ 開発チームによるセルフサービス化 ■ インフラチームがボトルネックになる ことを解消 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

11.

マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは? 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

12.

マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは? ○ ただ権限を渡すだけでは 🙅 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

13.

マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは? ○ ○ ただ権限を渡すだけでは 🙅 責任とともに渡す 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

14.

マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは? ○ ○ ただ権限を渡すだけでは 🙅 責任とともに渡す ■ システムの信頼性を担保 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

15.

マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは? ○ ○ ● ただ権限を渡すだけでは 🙅 責任とともに渡す ■ システムの信頼性を担保 でもどうやって? 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

16.

マネーフォワードのサービス基盤 ● Enabling SREの出番 💪 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

17.

マネーフォワードのサービス基盤 ● Enabling SREの出番 💪 ○ ○ サービス基盤の利用開始のサポート 高い信頼性をもつシステム構築のノウハ ウを伝達 ■ 「開発者自身」でできるようにする 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

18.

マネーフォワードのサービス基盤 ● Enabling SREの出番 💪 ○ ○ ● サービス基盤の利用開始のサポート 高い信頼性をもつシステム構築のノウハ ウを伝達 ■ 「開発者自身」でできるようにする Enabling SREの使命(ミッション) 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

19.

Enabling活動

20.

なぜEnabling活動? ● ● ● マネーフォワードには100近いマイクロサービスが存在 各サービスに専任のSREを置くことは難しい 開発者にサービスの信頼性を担保する責任とともに権限委譲をしていきたい

21.

なぜEnabling活動? ● ● ● マネーフォワードには100近いマイクロサービスが存在 各サービスに専任のSREを置くことは難しい 開発者にサービスの信頼性を担保する責任とともに権限委譲をしていきたい ->SREスキルをEmbeddedではなくEnablingすることを重視

22.

Enabling活動の具体例 ● ● ● SRE成熟度評価 Production Readiness Checklist 開発チームとのコラボレーション

23.

Enabling活動の具体例 ● ● ● SRE成熟度評価 Production Readiness Checklist 開発チームとのコラボレーション 詳細はブログがあるのでそちらをご確認ください Enabling SREの現在地点

24.

一定の成果はあがったが。。

25.

一定の成果はあがったが。。 ● ものたりない感

26.

一定の成果はあがったが。。 ● ● ものたりない感 開発チームをうまく巻き込めていない感

27.

一定の成果はあがったが。。 ● ● ものたりない感 開発チームをうまく巻き込めていない感 ○ ex: SRE成熟度評価はつけたものの、多くのチームでは有効活用はできていない

28.

あらためてEnabling活動の目的に立ち返る ● 開発者自身で信頼性について担保できる状態をつくる

29.

あらためてEnabling活動の目的に立ち返る ● ● 開発者自身で信頼性について担保できる状態をつくる Enablingだけではこれが進んでいないように感じた。

30.

なぜか??

31.

なぜか?? ● 開発チームは忙しい!

32.

なぜか?? ● 開発チームは忙しい! ○ 機能開発

33.

なぜか?? ● 開発チームは忙しい! ○ ○ ○ ○ 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上

34.

なぜか?? ● 開発チームは忙しい! ○ ○ ○ ○ ● 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上 ここに「信頼性の向上」が追加!

35.

なぜか?? ● 開発チームは忙しい! ○ ○ ○ ○ ● ● 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上 ここに「信頼性の向上」が追加! Enablingというアプローチであるため「開発者の工数」を奪いがち

36.

なぜか?? ● 開発チームは忙しい! ○ ○ ○ ○ ● ● ● 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上 ここに「信頼性の向上」が追加! Enablingというアプローチであるため「開発者の工数」を奪いがち これはなかなか厳しい状況 😇

37.

アプローチを変えていこう!

38.

アプローチを変えていこう! ● EnablingからEmbeddedへ重視する方向を転換🚦

39.

アプローチを変えていこう! ● ● EnablingからEmbeddedへ重視する方向を転換🚦 工数をかけることを気にせずに、最大限の力で開発チームをサポート

40.

アプローチを変えていこう! ● ● EnablingからEmbeddedへ重視する方向を転換🚦 工数をかけることを気にせずに、最大限の力で開発チームをサポート 「スケールを考えすぎず、最高のSRE体験を開発者に」

41.

Enabling から Embedded へ

42.

Enabling から Embedded へ ● ● 具体的な取り組み 気をつけたこと

43.

チームA ● アラートの割れ窓改善 ○ ● チャンネル分割 ○ ● 即対応、注視の 2つにSlackのアラートチャンネルを分割 ポストモーテム改善 ○ ● 鳴っても誰も対応していないアラートを精査、不要なものは STOP 書いて終わりではなく、ふりかえりの場を設ける コスト最適化 ○ コンテナのリソース使用量のデータを元に、コンテナへの割当リソースの削減を実施

44.

チームB ● Pod停止時の5xxエラー増加の解消 ○ ● preStopへのsleep導入 ダッシュボードの整備 ○ ○ ○ チームB以外でも利用されている AWSサービス(例:DynamoDB)に関して横断的なダッシュボードを作 成した 他のチームでも活用可能 Embeddedすることで、全体にレバレッジが効くような改善ポイントを発見

45.

チームC ● コストの最適化 ○ ● Cost Explorerの内容をサマライズ ダッシュボード,監視内容のレビュー ○ DBのクラウド移行 (オンプレミス to RDS)に伴って作成したダッシュボード,監視内容をレビュー

46.

気をつけたこと

47.

気をつけたこと ● 「相手の立場になって考える」 ○ ○ 想定通りにすすまなくても気にしない 相手のレベル感や時間的余裕によって Embeddedのレベルを意図的に変える

48.

気をつけたこと ● 「相手の立場になって考える」 ○ ○ ● 想定通りにすすまなくても気にしない 相手のレベル感や時間的余裕によって Embeddedのレベルを意図的に変える EnablingするのではなくEmbedded ○ ○ 改善施策を思いついたら自分から動いていく サービスを良くするためには?を常に考えて動こう

49.

気をつけたこと ● 「相手の立場になって考える」 ○ ○ ● EnablingするのではなくEmbedded ○ ○ ● 想定通りにすすまなくても気にしない 相手のレベル感や時間的余裕によって Embeddedのレベルを意図的に変える 改善施策を思いついたら自分から動いていく サービスを良くするためには?を常に考えて動こう コミュニケーション重要 ○ ○ ○ 朝会への参加 定期的な会議体の作成 Slackに気を張っておく

50.

今後の展望

51.

今後の展望 ● 各チームに対してのEmbeddedを強化 ○ ○ SREが各チームに常駐し、より具体的・長期的な改善を実施 全体最適な改善の実現

52.

その実現のためには、

53.

その実現のためには、SREがもっと必要!

54.

その実現のためには、SREがもっと必要! ● 各拠点で積極採用中! ○ ○ ○ ● 東京 大阪 福岡 HRMOS URL

55.

まとめ

56.

まとめ ● ● ● ● Enabling 🤝 Embedded どちらかに固執せず柔軟にやってきましょう! 目指すべきは「ユーザに信頼されるサービス」であり、進め方はどちらでもよい みなさんもそれぞれの道で歩んでいきましょ〜

57.

宣伝

58.

🎉SRE NEXT 2024🎉 ● https://sre-next.dev/2024/ ○ ● 今年のテーマ ○ ● 8/3~4(Sat~Sun)@Abema Towers 「Beyond NEXT」 Road to SRE NEXTも開催中! ○ ○ ○ ○ 5月24日 at GMOペパボ福岡オフィス 6月29日 at 楽天仙台支社 7月5日 at マネーフォワード京都オフィス 7月20日 at サイボウズ株式会社 広島オフィス ■ connpass

59.

おわり ~Fin~