Slide 1

Slide 1 text

未経験でSRE、はじめました! 組織を支える役割と軌跡 【SRE特集】3社が語るSREの役割 組織の変遷と直面した課題とは? 2025/2/27 Recustomer株式会社 CTO Shugo Manabe @curekoshimizu

Slide 2

Slide 2 text

Profile : 眞鍋 秀悟 ( X: @curekoshimizu ) 略歴 ● 京都大学 / 大学院 ○ 入試一位合格 ○ 数学系 (丸め誤差についてが専門) ● Fixstars ○ Executive Engineer ● Mujin ○ Architect ● Preferred Networks ○ Engineering Mananger ● Hacobu ○ 研究開発部部長・CTO室室長 ● [Now] Recustomer ○ CTO 2

Slide 3

Slide 3 text

Profile : 眞鍋 秀悟 ( X: @curekoshimizu ) 略歴 ● 京都大学 / 大学院 ○ 入試一位合格 ○ 数学系 (丸め誤差についてが専門) ● Fixstars ○ Executive Engineer ● Mujin ○ Architect ● Preferred Networks ○ Engineering Mananger ● Hacobu ○ 研究開発部部長・CTO室室長 ● [Now] Recustomer ○ CTO 3 組み込み・ファームウェア・CUDA・コンパイラー ロボティクス・画像処理・制御・レンダラー・ 機械学習・統計分析・アルゴリズム など 基本的に「クラウド技術・Web技術」と 縁遠く生き方をしてきた経歴 AWS環境・ Web SaaS 自分たちが用意したコンピュータに対して デプロイをするお仕事 ≒ デプロイが頻繁には行えない とても 相反する環境

Slide 4

Slide 4 text

Recustomer社 との出会いはちょうど昨年 (30社ほど選考していたちょうど昨年今頃) 4

Slide 5

Slide 5 text

今選考を受けている どの企業よりも ガッツがある会社だ! エンジニアの一体感・やり切り力が ずば抜けている・雰囲気めちゃいい 5

Slide 6

Slide 6 text

6 簡単にRecustomerとは? = ECをより良くするサービスを提供する会社 特に返品が できる機能が有名 (有名な企業に導入)

Slide 7

Slide 7 text

何か力になれれば と思い 入社を決意! 7

Slide 8

Slide 8 text

エンジニアたちと お話をして 現在の状況整理 8

Slide 9

Slide 9 text

初期の スタートアップは 当たり前だが エンジニアの数が そもそも少ない 9

Slide 10

Slide 10 text

インフラに関するエンジニアが 0人 の中で 皆がよくわからないながらも  もがいている状況  ガッツだけでなんとかなっている感じ 10

Slide 11

Slide 11 text

入社前の会社の 状況を整理してみると 11

Slide 12

Slide 12 text

[直面した課題] 今自分に問われているのは 苦手なクラウドインフラに 関する知識。 12

Slide 13

Slide 13 text

AWSについてほとんど 何も知らないエンジニアが インフラについて 勉強するぞと決心する! 13

Slide 14

Slide 14 text

AWSは機能数がとても多く できることを知らないと 戦えない... 網羅的に学ぶ必要がありそう 知識の高速道路が整備されているのありがたい 14

Slide 15

Slide 15 text

4日に1個のペースで AWS資格受験して 9個ほど資格取得できた 勉強する前から受験日を決める作戦! あとはTerraformを使って いろいろ触る練習をする 知らない知識を埋めてあとは困ったときに 何を学んだらいいのかが分かる状態をつくる。 そうすれば、何かあってもキーワードから 手がかりを得られるぞという考え。 15

Slide 16

Slide 16 text

ドキドキしながら 入社日を迎える (+業務委託のSRE経験者と一緒にやりきるぞ) 以下、内容深堀りをせず ざっくりいろいろと紹介 16

Slide 17

Slide 17 text

17 1ヶ月目:問題をみつける旅 ● 問題発見フェイズ ○ コストが高すぎる ○ セキュリティの問題 ■ ルートパスワードの2段階認証が紛失されている ■ ACCESS KEY管理がとても多い など ○ 不安定なデプロイ ○ 形式的な役に立っていないPRレビュー ○ AWS 1アカウントで dev, stg, prod環境が同居 ■ 互いが干渉して影響を及ぼし合っていた ○ 不足したアラーム ■ 何か問題が発生しているかよくわからない などなど

Slide 18

Slide 18 text

18 2ヶ月目 ・デプロイシステムの全書き直し ・GitHub Actionsでecspressoを利用したECS Fargateシステムへ ・アカウント分離 ・AWSマルチアカウント管理に移行 ・本番DBなどすべて新しい環境にお引越し ・元のIaCコードをTerraformで全書き直し 短期間でアーキテクチャの全容を 把握してすべて移管完了! アカウント分離

Slide 19

Slide 19 text

19 3ヶ月目 ・AWS ACCESS KEYの排除とAWS Identity Center化 ・セキュリティ設定有効化 (SecurityHub・GuardDutyなど) ・CloudWatchでアラームを設定 ・x86から全ARM化 ・エンジニアのPCも全てARM Macに統一

Slide 20

Slide 20 text

20 4・5ヶ月目 ・SQSを使った非同期アーキテクチャの採用 ・APIサーバーの負荷と非同期処理失敗時のリカバリーの手順の確立 ・ECSを自動スケーリングできるようにする ・コストアラートの設定 ・パスワード等のセキュリティ情報のローテーション

Slide 21

Slide 21 text

21 6・7ヶ月目 ・OOM (Out of Memory) の監視 ・ログシステムの整備 ・型システムとlinterの強化 ・Tailscaleの導入 ・IPアドレスの固定化とセキュリティ強化 ・スロークエリの検知・分析 ・ローカル環境整備 ・ローカル環境構築が1ヶ月から1時間に短縮 インフラ管理という低レイヤーのところから アプリケーションコードへの貢献に も力が入るようになってきたフェイズ

Slide 22

Slide 22 text

22 8・9ヶ月目 (今) ・mono repo化 ・PR速度向上へ ・データ基盤(再)構築 ・Datadog導入 ・監視強化 ・解析時間短縮 monorepo でスコア 改善

Slide 23

Slide 23 text

難しい知識を抽象化して 隠蔽してメンバーに アプリケーションロジックに集中できる 環境をつくることはできた! 23

Slide 24

Slide 24 text

結果どうなったのか? 24

Slide 25

Slide 25 text

無駄なインフラが少なくなり 顧客の増加と反比例に コストがどんどん下がっていった 25 350万/月 180万/月 来月には 100万/月 になりそう

Slide 26

Slide 26 text

エンジニアが機能開発に 集中できるようになった 新機能開発の割合が増えた 26 新規機能開発割合 20% 新規機能開発割合 80%

Slide 27

Slide 27 text

運で本番デプロイされることが なくなり デプロイが頻繁になった (祈る人もいなくなった) 27 1回/週 3回/日

Slide 28

Slide 28 text

インフラという 認知負荷が減って アプリケーションロジックの 開発速度がどんどん高くなり 開発生産性に関する Findy Team+ Award 2024 受賞 28

Slide 29

Slide 29 text

結局のところ学びは? 29

Slide 30

Slide 30 text

AWSは勉強方法について 知の高速道路整備が きちんとされていて キャッチアップができるようになっていた 30

Slide 31

Slide 31 text

Web開発は求められる知識が多いことを 改めて実感 31 インフラ BE FE React SSR npm N+1 AWS セキュリティ 認証 アーキテクチャ BFF ドメイン 設計 ログ デプロイ そもそもこれ全部できる人を求めている開発というよりは 皆で協力して足りないところを補っているのが Web開発。チームワーク。 Graph QL gRPC データ 基盤 Storybook

Slide 32

Slide 32 text

初期のスタートアップは とにかく人が少ない 32 インフラ BE FE 初期のスタートアップは 苦手な分野がインフラになりがち + 集合知でカバーしようにもそもそも人数が少ない 市場に全然いない 市場に結構いる

Slide 33

Slide 33 text

初期のスタートアップは インフラがウィークポイントになりがち 33 インフラ BE FE 一人の知識が埋めている領域と 集団知の状況図 不足しがち 1人の知識 カバー範囲

Slide 34

Slide 34 text

認知負荷を小さくして お金を稼ぐための機能開発に集中できる状 態を 34 プラットフォーム チーム ストリームアラインド チーム プラットフォームチームによる開発支援が 実は小さなスタートアップには効果が高いのではないかと思うようになる 価値提供を簡単にできるよう 生産性が高まる施策を 引き受けて組織全体の力をあげる お金を生み出す 仕事をして どんどん事業貢献

Slide 35

Slide 35 text

現在のRecustomerの状況 35 プラットフォームチームを 組織して 気合とガッツに満ち溢れた開発力満々の エンジニア組織 を 価値のあるプロダクト開発に より集中できるように全力サポートしたい

Slide 36

Slide 36 text

未経験SREをやっている CTOを助けてくれる、 Platformチームの 組織化を一緒くれる人 募集しています! 36 ご清聴ありがとうございました @curekoshimizu