EnablingとEmbeddedのはざまで
28.5K Views
July 11, 24
スライド概要
2024/7/11開催のEmbedded SRE 現場に寄り添うアプローチで話したスライドです。
https://findy.connpass.com/event/323099/
関連スライド
SPAセキュリティ超入門
徳丸 浩
736.2K
各ページのテキスト
EnablingとEmbedded のはざまで 2024/7/11 Embedded SRE 現場に寄り添うアプローチ 横山達男/tatsuo48
横山 達男 (@tatsuo48) Money Forward Enabling SRE/テックリード
お話すること ● ● ● ● マネーフォワードのサービス基盤のご紹介 Enabling活動 Enabling から Embedded へ 今後の展望
マネーフォワードの サービス基盤のご紹介
マネーフォワードのサービス基盤 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ サービス単位で namespaceを分離 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● サービス単位で namespaceを分離 複数のAWSアカウント ○ サービス単位で AWSアカウントを分離 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● 複数のAWSアカウント ○ ● サービス単位で namespaceを分離 サービス単位で AWSアカウントを分離 何を狙っているのか？ 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● 複数のAWSアカウント ○ ● サービス単位で namespaceを分離 サービス単位で AWSアカウントを分離 何を狙っているのか？ ○ 開発者への適切な権限委譲を図る 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● マルチテナントEKSクラスター ○ ● 複数のAWSアカウント ○ ● サービス単位で namespaceを分離 サービス単位で AWSアカウントを分離 何を狙っているのか？ ○ 開発者への適切な権限委譲を図る ■ 100以上のマイクロサービス ■ 開発チームによるセルフサービス化 ■ インフラチームがボトルネックになる ことを解消 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは？ 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは？ ○ ただ権限を渡すだけでは 🙅 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは？ ○ ○ ただ権限を渡すだけでは 🙅 責任とともに渡す 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは？ ○ ○ ただ権限を渡すだけでは 🙅 責任とともに渡す ■ システムの信頼性を担保 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● 「適切な権限委譲」とは？ ○ ○ ● ただ権限を渡すだけでは 🙅 責任とともに渡す ■ システムの信頼性を担保 でもどうやって？ 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● Enabling SREの出番 💪 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● Enabling SREの出番 💪 ○ ○ サービス基盤の利用開始のサポート 高い信頼性をもつシステム構築のノウハ ウを伝達 ■ 「開発者自身」でできるようにする 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
マネーフォワードのサービス基盤 ● Enabling SREの出番 💪 ○ ○ ● サービス基盤の利用開始のサポート 高い信頼性をもつシステム構築のノウハ ウを伝達 ■ 「開発者自身」でできるようにする Enabling SREの使命(ミッション) 出典: 組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ
Enabling活動
なぜEnabling活動？ ● ● ● マネーフォワードには100近いマイクロサービスが存在 各サービスに専任のSREを置くことは難しい 開発者にサービスの信頼性を担保する責任とともに権限委譲をしていきたい
なぜEnabling活動？ ● ● ● マネーフォワードには100近いマイクロサービスが存在 各サービスに専任のSREを置くことは難しい 開発者にサービスの信頼性を担保する責任とともに権限委譲をしていきたい ->SREスキルをEmbeddedではなくEnablingすることを重視
Enabling活動の具体例 ● ● ● SRE成熟度評価 Production Readiness Checklist 開発チームとのコラボレーション
Enabling活動の具体例 ● ● ● SRE成熟度評価 Production Readiness Checklist 開発チームとのコラボレーション 詳細はブログがあるのでそちらをご確認ください Enabling SREの現在地点
一定の成果はあがったが。。
一定の成果はあがったが。。 ● ものたりない感
一定の成果はあがったが。。 ● ● ものたりない感 開発チームをうまく巻き込めていない感
一定の成果はあがったが。。 ● ● ものたりない感 開発チームをうまく巻き込めていない感 ○ ex: SRE成熟度評価はつけたものの、多くのチームでは有効活用はできていない
あらためてEnabling活動の目的に立ち返る ● 開発者自身で信頼性について担保できる状態をつくる
あらためてEnabling活動の目的に立ち返る ● ● 開発者自身で信頼性について担保できる状態をつくる Enablingだけではこれが進んでいないように感じた。
なぜか？？
なぜか？？ ● 開発チームは忙しい！
なぜか？？ ● 開発チームは忙しい！ ○ 機能開発
なぜか？？ ● 開発チームは忙しい！ ○ ○ ○ ○ 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上
なぜか？？ ● 開発チームは忙しい！ ○ ○ ○ ○ ● 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上 ここに「信頼性の向上」が追加！
なぜか？？ ● 開発チームは忙しい！ ○ ○ ○ ○ ● ● 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上 ここに「信頼性の向上」が追加！ Enablingというアプローチであるため「開発者の工数」を奪いがち
なぜか？？ ● 開発チームは忙しい！ ○ ○ ○ ○ ● ● ● 機能開発 プロダクトの品質向上 開発速度の向上 セキュリティの向上 ここに「信頼性の向上」が追加！ Enablingというアプローチであるため「開発者の工数」を奪いがち これはなかなか厳しい状況 😇
アプローチを変えていこう！
アプローチを変えていこう！ ● EnablingからEmbeddedへ重視する方向を転換🚦
アプローチを変えていこう！ ● ● EnablingからEmbeddedへ重視する方向を転換🚦 工数をかけることを気にせずに、最大限の力で開発チームをサポート
アプローチを変えていこう！ ● ● EnablingからEmbeddedへ重視する方向を転換🚦 工数をかけることを気にせずに、最大限の力で開発チームをサポート 「スケールを考えすぎず、最高のSRE体験を開発者に」
Enabling から Embedded へ
Enabling から Embedded へ ● ● 具体的な取り組み 気をつけたこと
チームA ● アラートの割れ窓改善 ○ ● チャンネル分割 ○ ● 即対応、注視の 2つにSlackのアラートチャンネルを分割 ポストモーテム改善 ○ ● 鳴っても誰も対応していないアラートを精査、不要なものは STOP 書いて終わりではなく、ふりかえりの場を設ける コスト最適化 ○ コンテナのリソース使用量のデータを元に、コンテナへの割当リソースの削減を実施
チームB ● Pod停止時の5xxエラー増加の解消 ○ ● preStopへのsleep導入 ダッシュボードの整備 ○ ○ ○ チームB以外でも利用されている AWSサービス(例:DynamoDB)に関して横断的なダッシュボードを作 成した 他のチームでも活用可能 Embeddedすることで、全体にレバレッジが効くような改善ポイントを発見
チームC ● コストの最適化 ○ ● Cost Explorerの内容をサマライズ ダッシュボード，監視内容のレビュー ○ DBのクラウド移行 (オンプレミス to RDS)に伴って作成したダッシュボード，監視内容をレビュー
気をつけたこと
気をつけたこと ● 「相手の立場になって考える」 ○ ○ 想定通りにすすまなくても気にしない 相手のレベル感や時間的余裕によって Embeddedのレベルを意図的に変える
気をつけたこと ● 「相手の立場になって考える」 ○ ○ ● 想定通りにすすまなくても気にしない 相手のレベル感や時間的余裕によって Embeddedのレベルを意図的に変える EnablingするのではなくEmbedded ○ ○ 改善施策を思いついたら自分から動いていく サービスを良くするためには？を常に考えて動こう
気をつけたこと ● 「相手の立場になって考える」 ○ ○ ● EnablingするのではなくEmbedded ○ ○ ● 想定通りにすすまなくても気にしない 相手のレベル感や時間的余裕によって Embeddedのレベルを意図的に変える 改善施策を思いついたら自分から動いていく サービスを良くするためには？を常に考えて動こう コミュニケーション重要 ○ ○ ○ 朝会への参加 定期的な会議体の作成 Slackに気を張っておく
今後の展望
今後の展望 ● 各チームに対してのEmbeddedを強化 ○ ○ SREが各チームに常駐し、より具体的・長期的な改善を実施 全体最適な改善の実現
その実現のためには、
その実現のためには、SREがもっと必要！
その実現のためには、SREがもっと必要！ ● 各拠点で積極採用中！ ○ ○ ○ ● 東京 大阪 福岡 HRMOS URL
まとめ
まとめ ● ● ● ● Enabling 🤝 Embedded どちらかに固執せず柔軟にやってきましょう！ 目指すべきは「ユーザに信頼されるサービス」であり、進め方はどちらでもよい みなさんもそれぞれの道で歩んでいきましょ〜
宣伝
🎉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
おわり ~Fin~