Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
未経験でSRE、はじめました! 組織を支える役割と軌跡
Search
curekoshimizu
February 27, 2025
Programming
0
110
未経験でSRE、はじめました! 組織を支える役割と軌跡
【SRE特集】3社が語るSREの役割 組織の変遷と直面した課題とは?
で発表した際のスライドになります。
https://findy.connpass.com/event/344949/
curekoshimizu
February 27, 2025
Tweet
Share
More Decks by curekoshimizu
See All by curekoshimizu
級数を大改造劇的ビフォーアフター
curekoshimizu
0
11
Pythonの数学機能を学ぼう! その仕組も学ぼう!
curekoshimizu
7
1.9k
Other Decks in Programming
See All in Programming
PRレビューのお供にDanger
stoticdev
1
220
プログラミング言語学習のススメ / why-do-i-learn-programming-language
yashi8484
0
150
CloudNativePGを布教したい
nnaka2992
0
100
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
14
4.5k
Introduction to kotlinx.rpc
arawn
0
750
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
200
もう僕は OpenAPI を書きたくない
sgash708
5
1.8k
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
53
18k
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
8
2.8k
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
210
Datadog Workflow Automation で圧倒的価値提供
showwin
1
100
Djangoアプリケーション 運用のリアル 〜問題発生から可視化、最適化への道〜 #pyconshizu
kashewnuts
1
260
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building Adaptive Systems
keathley
40
2.4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The World Runs on Bad Software
bkeepers
PRO
67
11k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
It's Worth the Effort
3n
184
28k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Faster Mobile Websites
deanohume
306
31k
Transcript
未経験でSRE、はじめました! 組織を支える役割と軌跡 【SRE特集】3社が語るSREの役割 組織の変遷と直面した課題とは? 2025/2/27 Recustomer株式会社 CTO Shugo Manabe @curekoshimizu
Profile : 眞鍋 秀悟 ( X: @curekoshimizu ) 略歴 •
京都大学 / 大学院 ◦ 入試一位合格 ◦ 数学系 (丸め誤差についてが専門) • Fixstars ◦ Executive Engineer • Mujin ◦ Architect • Preferred Networks ◦ Engineering Mananger • Hacobu ◦ 研究開発部部長・CTO室室長 • [Now] Recustomer ◦ CTO 2
Profile : 眞鍋 秀悟 ( X: @curekoshimizu ) 略歴 •
京都大学 / 大学院 ◦ 入試一位合格 ◦ 数学系 (丸め誤差についてが専門) • Fixstars ◦ Executive Engineer • Mujin ◦ Architect • Preferred Networks ◦ Engineering Mananger • Hacobu ◦ 研究開発部部長・CTO室室長 • [Now] Recustomer ◦ CTO 3 組み込み・ファームウェア・CUDA・コンパイラー ロボティクス・画像処理・制御・レンダラー・ 機械学習・統計分析・アルゴリズム など 基本的に「クラウド技術・Web技術」と 縁遠く生き方をしてきた経歴 AWS環境・ Web SaaS 自分たちが用意したコンピュータに対して デプロイをするお仕事 ≒ デプロイが頻繁には行えない とても 相反する環境
Recustomer社 との出会いはちょうど昨年 (30社ほど選考していたちょうど昨年今頃) 4
今選考を受けている どの企業よりも ガッツがある会社だ! エンジニアの一体感・やり切り力が ずば抜けている・雰囲気めちゃいい 5
6 簡単にRecustomerとは? = ECをより良くするサービスを提供する会社 特に返品が できる機能が有名 (有名な企業に導入)
何か力になれれば と思い 入社を決意! 7
エンジニアたちと お話をして 現在の状況整理 8
初期の スタートアップは 当たり前だが エンジニアの数が そもそも少ない 9
インフラに関するエンジニアが 0人 の中で 皆がよくわからないながらも もがいている状況 ガッツだけでなんとかなっている感じ 10
入社前の会社の 状況を整理してみると 11
[直面した課題] 今自分に問われているのは 苦手なクラウドインフラに 関する知識。 12
AWSについてほとんど 何も知らないエンジニアが インフラについて 勉強するぞと決心する! 13
AWSは機能数がとても多く できることを知らないと 戦えない... 網羅的に学ぶ必要がありそう 知識の高速道路が整備されているのありがたい 14
4日に1個のペースで AWS資格受験して 9個ほど資格取得できた 勉強する前から受験日を決める作戦! あとはTerraformを使って いろいろ触る練習をする 知らない知識を埋めてあとは困ったときに 何を学んだらいいのかが分かる状態をつくる。 そうすれば、何かあってもキーワードから 手がかりを得られるぞという考え。
15
ドキドキしながら 入社日を迎える (+業務委託のSRE経験者と一緒にやりきるぞ) 以下、内容深堀りをせず ざっくりいろいろと紹介 16
17 1ヶ月目:問題をみつける旅 • 問題発見フェイズ ◦ コストが高すぎる ◦ セキュリティの問題 ▪ ルートパスワードの2段階認証が紛失されている
▪ ACCESS KEY管理がとても多い など ◦ 不安定なデプロイ ◦ 形式的な役に立っていないPRレビュー ◦ AWS 1アカウントで dev, stg, prod環境が同居 ▪ 互いが干渉して影響を及ぼし合っていた ◦ 不足したアラーム ▪ 何か問題が発生しているかよくわからない などなど
18 2ヶ月目 ・デプロイシステムの全書き直し ・GitHub Actionsでecspressoを利用したECS Fargateシステムへ ・アカウント分離 ・AWSマルチアカウント管理に移行 ・本番DBなどすべて新しい環境にお引越し ・元のIaCコードをTerraformで全書き直し
短期間でアーキテクチャの全容を 把握してすべて移管完了! アカウント分離
19 3ヶ月目 ・AWS ACCESS KEYの排除とAWS Identity Center化 ・セキュリティ設定有効化 (SecurityHub・GuardDutyなど) ・CloudWatchでアラームを設定
・x86から全ARM化 ・エンジニアのPCも全てARM Macに統一
20 4・5ヶ月目 ・SQSを使った非同期アーキテクチャの採用 ・APIサーバーの負荷と非同期処理失敗時のリカバリーの手順の確立 ・ECSを自動スケーリングできるようにする ・コストアラートの設定 ・パスワード等のセキュリティ情報のローテーション
21 6・7ヶ月目 ・OOM (Out of Memory) の監視 ・ログシステムの整備 ・型システムとlinterの強化 ・Tailscaleの導入
・IPアドレスの固定化とセキュリティ強化 ・スロークエリの検知・分析 ・ローカル環境整備 ・ローカル環境構築が1ヶ月から1時間に短縮 インフラ管理という低レイヤーのところから アプリケーションコードへの貢献に も力が入るようになってきたフェイズ
22 8・9ヶ月目 (今) ・mono repo化 ・PR速度向上へ ・データ基盤(再)構築 ・Datadog導入 ・監視強化 ・解析時間短縮
monorepo でスコア 改善
難しい知識を抽象化して 隠蔽してメンバーに アプリケーションロジックに集中できる 環境をつくることはできた! 23
結果どうなったのか? 24
無駄なインフラが少なくなり 顧客の増加と反比例に コストがどんどん下がっていった 25 350万/月 180万/月 来月には 100万/月 になりそう
エンジニアが機能開発に 集中できるようになった 新機能開発の割合が増えた 26 新規機能開発割合 20% 新規機能開発割合 80%
運で本番デプロイされることが なくなり デプロイが頻繁になった (祈る人もいなくなった) 27 1回/週 3回/日
インフラという 認知負荷が減って アプリケーションロジックの 開発速度がどんどん高くなり 開発生産性に関する Findy Team+ Award 2024 受賞
28
結局のところ学びは? 29
AWSは勉強方法について 知の高速道路整備が きちんとされていて キャッチアップができるようになっていた 30
Web開発は求められる知識が多いことを 改めて実感 31 インフラ BE FE React SSR npm N+1
AWS セキュリティ 認証 アーキテクチャ BFF ドメイン 設計 ログ デプロイ そもそもこれ全部できる人を求めている開発というよりは 皆で協力して足りないところを補っているのが Web開発。チームワーク。 Graph QL gRPC データ 基盤 Storybook
初期のスタートアップは とにかく人が少ない 32 インフラ BE FE 初期のスタートアップは 苦手な分野がインフラになりがち + 集合知でカバーしようにもそもそも人数が少ない
市場に全然いない 市場に結構いる
初期のスタートアップは インフラがウィークポイントになりがち 33 インフラ BE FE 一人の知識が埋めている領域と 集団知の状況図 不足しがち 1人の知識
カバー範囲
認知負荷を小さくして お金を稼ぐための機能開発に集中できる状 態を 34 プラットフォーム チーム ストリームアラインド チーム プラットフォームチームによる開発支援が 実は小さなスタートアップには効果が高いのではないかと思うようになる
価値提供を簡単にできるよう 生産性が高まる施策を 引き受けて組織全体の力をあげる お金を生み出す 仕事をして どんどん事業貢献
現在のRecustomerの状況 35 プラットフォームチームを 組織して 気合とガッツに満ち溢れた開発力満々の エンジニア組織 を 価値のあるプロダクト開発に より集中できるように全力サポートしたい
未経験SREをやっている CTOを助けてくれる、 Platformチームの 組織化を一緒くれる人 募集しています! 36 ご清聴ありがとうございました @curekoshimizu