プロダクト開発エンジニアからSREへの挑戦
下重 博資
GMOペパボ株式会社
shimoju.icon
下重 博資（しもじゅう ひろし）
プロダクト開発エンジニアとしてのキャリア
年表
2016/4：新卒入社、EC事業部 SUZURIチーム（現SUZURI事業部）に配属 2020/1：SUZURI事業部内にSREチームが発足、そのメンバーとしてSRE活動を開始 これまでの経験
Ruby on Railsを用いたサーバサイド開発が中心
SUZURIの新アイテムの実装をはじめ、新機能の追加や、モバイルアプリの開発
インフラの管理、CI/CDや開発環境の整備、セキュリティ対策など
開発の引き継ぎを担当し、自社で運用できるようにした
AWSで運用されていたサービスをHerokuに移設し、運用コストを削減
当時からインフラを触ることも多かった
配属当初のSUZURIは小さいチームだったため、Webをはじめ、インフラからモバイルアプリまで全部やっていた
SUZURIではHerokuを活用しており、アプリケーションエンジニアでもインフラを管理しやすかった その後チームが拡大し、2018年にSUZURI事業部として独立
Embedded SREとしてのキャリア
SREに挑戦した経緯
もともとインフラの構成管理を行ったり、開発環境やCIの高速化などに取り組んでいた
みんなに気持ちよく開発してもらい、組織としての生産性を上げることに興味があった
インフラやセキュリティ対策に強みをもつ事業部メンバーが少ない
こちらに手を伸ばした方が自分の強みが発揮でき、組織的にもカバー範囲が広がりそう
キャリアの幅を広げる
個人的にはキャリアチェンジではなく「キャリアの幅を広げる」イメージ
状況に応じてプロダクト開発も行っている
アプリケーションコードを直接修正してパフォーマンスを改善したりもする
SUZURIのSRE実践パターン
メンバー
SUZURI事業部 SRE座
技術部（技術基盤チーム、プラットフォームグループ）
メンバーやその状況に応じて、「2.外の人として、SREに関わるタスクや機能開発を引き受ける」「3.外の人として、SREに関わる助言を行う」「7.プラットフォームを提供する」など様々
Embedded SREとPlatform SREの協業
SRE座と技術部が週1回ミーティングし、直近のSLIを確認、今後の施策などを検討する
Datadogでダッシュボードを作成し、SLI/SLOを一目で確認できるようにしている 大規模セールの際は負荷試験を行い、キャパシティプランニングやパフォーマンス改善について相談する
各々の専門性に応じて担当を割り振って実行する
アプリケーションコードの調査が必要であればSRE座
Kubernetesクラスタやインフラの込み入った部分の調査が必要であれば技術部
実践例：CM放映&セール対策
SUZURI初のテレビCMを伴ったセールの実施が決まった
より確証を持った負荷対策が実施できるように、負荷試験に基づいたキャパシティプランニングやパフォーマンス改善を行うことにした
負荷試験は技術部@takutakaが担当
パフォーマンス改善は技術部@pyamaを中心に、SRE座とプロダクト開発エンジニアで担当
SRE座としてやったこと
ステージング環境で負荷試験を実施するためのアプリ側の修正
Rate Limitを無効化できるようにするなど
負荷試験のシナリオの作成
N+1を効率的に検知できるようにするための自動テストの修正
データベースのスケールアップ
Platform SREが変更したコードのレビュー
その結果
負荷試験の目標値を達成できた！
あるセールのN倍のトラフィックで、ログイン比率をM%としたとき、p95でO秒を切る
パフォーマンス関連の障害はなくセールを終えられた！
まとめ
プロダクト開発エンジニアがSREに挑戦してみて
事業ドメインの理解とバックエンドの専門性があることで、ボトルネックの特定やパフォーマンスの改善に直接踏み込める
高い専門性を持つSRE組織が既にあっても、Embedded SREとして働くことで価値を作れる
Platform SREと連携することでより素早く、より高度なことに取り組める
「プロダクトチームの中でSREをやる」選択肢も考えるとキャリアの幅が広がるはず！