はじめまして、Recustomerという会社のCTOを務めている眞鍋（@curekoshimizu）と申します。
今回は、私が未経験でSREを始めたのですが、その役割と軌跡をお伝えさせていただきます。
私たちRecustomerはまだ小さなスタートアップで、従業員でいうと20名ほど、エンジニアは7、8名ほどの規模になります。そんな状況のなか、私がRecustomerに入社する前後からどのようにSREを始めて、立ち上げていったのかをお伝えできればと思います。
インフラ専任が不在
SREを始めるきっかけは入社前にまで遡ります。
当時、会社にはインフラを専任とするエンジニアがおらず、皆が兼務しながらインフラ関連の課題に対処している状況でした。障害発生時の対応や、特定の実装をする際のインフラ構成など、多くの場面で苦労しながら乗り切っていました。
このような課題があったため、入社後に私に求められるのは「クラウドインフラの知識」だと感じ、正直なところ入社前の私はAWSについてほとんど知識がありませんでしたが、インフラについて本格的に勉強することを決意しました。
入社前のAWS学習
インフラを勉強するにあたり、私が最初に直面した課題は「AWSの膨大な機能数と日々更新される新機能」についてでした。これらを知らないままでは、問題解決の方法や適切な調査方法さえわからない状況に陥ります。そこで、「どのサービスがあり、特定の問題にはどう対処すべきか」を網羅的に学ぶ必要があると考えました。
私が選んだアプローチは、AWS資格を集中的に取得することでした。知識を短期間で詰め込むため、4日に1つのペースで試験申し込みをし、集中して勉強しました。その後、仕組みが理解できてきたらTerraformを活用していきました。
この方法によって、断片的だったキーワードの理解が深まり、質問があった時も「これを調べればよい」とわかるようになりました。こうして入社前にインフラの知識を身につけることができました。
入社してからの取り組み
1ヶ月目：問題発見のフェーズ
入社前にAWSの理解は深めていきましたが、入社してすぐに具体的な取り組みは開始せず、まずは「問題を発見するフェーズ」として取り組みました。
そうすると、様々な課題が見えてきまして、コストの高さ、セキュリティの問題、不安定なデプロイなど、多岐にわたる問題が存在していました。例えば、データベースが単一のアカウントで運用されており、開発環境が本番環境に影響を与えているという状況などもありました。
2ヶ月目：インフラ刷新の取り組み
1ヶ月目で様々な問題が発見されてきたこともあり、2ヶ月目には、インフラストラクチャの全面的な刷新に取り組みました。
まず、GitHub Actionsとecspressoを活用し、すべてのシステムをECS Fargateへ移行することで、Dockerイメージを効率的にデプロイできる環境を構築し、デプロイシステムを完全に書き直しました。
次に、セキュリティリスクを軽減するため、単一アカウントで運用されていた環境を開発/ステージング環境と本番環境に明確に分離し、すべてのデータベースやインフラの移行作業を実施しました。
さらに、インフラコード全体をIaCおよびTerraformで完全に書き直す作業にも着手し、これを1ヶ月以内に完了させることができました。
この期間において最も困難だったのは、複雑なアーキテクチャ全体を短期間で理解することと、データベースの安全な移行作業でした。非常に神経を使う作業でしたが、1ヶ月という制約の中でこれらの改善を実現できたことは、大きな成果だったと感じています。
3ヶ月目：セキュリティと運用効率の向上
3ヶ月目には、セキュリティと運用効率の向上に取り組みました。
まず、AWSアクセスキーに関する様々なセキュリティ問題を解消し、AWS Identity Centerを導入することで、マルチアカウント環境でのアクセス管理を効率化しました。
セキュリティ面では、SecurityHubやGuardDutyなどの機能を有効化し、監視体制を強化するとともに、CloudWatchでアラームを設定し、異常検知の仕組みを整えました。
インフラ面では、x86からARMアーキテクチャへの完全移行を実現し、コスト削減に成功しました。この移行により、Dockerイメージ作成時にアーキテクチャの違いを考慮する必要もなくなり、開発効率も向上しました。
4,5ヶ月目：アプリケーション処理基盤の強化
4,5ヶ月目では、インフラからアプリケーション側へと焦点を移していきました。
ECサイトという特性上、膨大な数のイベント処理が発生するシステムであり、その堅牢性が求められる環境だったので、まずSQSを活用した非同期アーキテクチャを採用し、イベント処理の信頼性を向上させました。また、APIサーバーの負荷対策と、非同期処理が失敗した際のリカバリー手順を確立しました。
システムの柔軟性向上のため、ECSの自動スケーリング設定を導入し、トラフィック変動に適応できる環境を構築しました。同時に、コスト管理のためのアラート設定を実装し、予算管理の可視化も進めました。
セキュリティ面では、パスワードなどの機密情報の定期的なローテーション体制を整えました。
これらの施策により、大量のイベント処理を安定して行うための基盤を強化することができました。
6,7ヶ月目：パフォーマンスと開発環境の改善
6～7ヶ月目は、システムの安定性とパフォーマンス向上に注力しました。
まず、メモリアラームの発生とOOM（Out of Memory）エラーによるシステム停止の問題に対して、監視体制を強化しました。
コスト効率と機能性のバランスを重視し、ログシステムの費用を抑えながらも検索性を高める仕組みを導入しました。また、主要開発言語であるPythonの型システム強化により、障害発生率を低減させることに成功しました。
セキュリティ面では、Tailscaleを導入してIPアドレスを固定化し、開発環境やステージング環境へのアクセス制限を実装することで、許可された人員のみが環境にアクセスできる仕組みを確立しました。
さらに、スロークエリの分析やローカル開発環境の整備支援も実施し、インフラだけでなくアプリケーションの上位レイヤーまで踏み込んだ改善が可能になりました。
8~10ヶ月目：開発効率と監視体制の強化
この3ヶ月では、開発プロセスとデータ分析基盤の改善に注力しました。
リポジトリをモノレポ化したことで、プルリクエストの処理速度が大幅に向上し、開発効率が改善されました。また、データ基盤を再構築することで、より効率的なデータ活用が可能になりました。
監視体制の強化としては、Datadogを導入しました。これにより、システム全体の可視性が向上し、問題発生時の解析時間を大幅に短縮することができました。
これらの施策により、開発サイクルの高速化とシステム品質の向上を同時に実現することができました。
10ヶ月間の成果
これら10ヶ月の取り組みを通して、複雑なインフラ知識を適切に抽象化し、開発メンバーがアプリケーション開発に集中する環境が構築できたと感じています。
特にエンジニアの生産性に関して、以前はインフラの問題やデプロイの失敗に対して、エンジニアが総動員で対応せざるを得ない状況でした。この問題解決・分析に費やしていた時間が大幅に削減され、新規機能開発に注力できるようになりました。これはスタートアップにとって売上向上に直結する重要な変化でした。
また、デプロイプロセスも著しく改善されました。私が入社する以前のシステムでは、本番デプロイに強い不安があり、半分は「祈り」に頼っていたようですが、現在ではデプロイが日常的な作業となりました。週1回だったデプロイ頻度が1日2〜3回に向上し、お客様に新機能をより早く提供できるようになりました。
これらの改善により、インフラ関連の認知負荷が軽減され、アプリケーションロジックの開発生産性が大幅に向上した結果、Findy Team+のアワードを獲得するに至りました。
それ以外にも、インフラの最適化によって大幅なコスト削減を実現しました。顧客数が大きく増加したにもかかわらず、クラウドインフラ費用は約3分の1に削減することができました。
スタートアップにおけるSREの重要性
この経験から得た学び
この取り組みから得られた主な学びを整理すると、まずはAWSの勉強法については、非常に体系化された「知の高速道路」のような仕組みが整備されており、効率的に知識をキャッチアップできる環境が整っていることを実感しました。
また、Web開発の世界では幅広い知識が求められることを改めて認識しました。しかし重要なのは、すべてを理解している「スーパーエンジニア」を求めることではなく、様々な専門性を持つメンバーがチームとして協力し合うことでプロジェクトが成り立っているという点です。Web開発の本質は、多様な知識と経験を持つ人々のチームワークにあるのではないかと感じています。
機能開発チームとプラットフォームチームの両輪を機能させる
初期段階のスタートアップでは、人的リソースが限られています。フロントエンド・バックエンド開発者は市場に比較的多く存在し採用しやすい一方、インフラエンジニアは希少で、この分野の知識不足が組織のウィークポイントになりやすいことを実感しました。
小規模スタートアップにとって、インフラ関連の認知負荷を軽減し、収益に直結する機能開発に集中できる環境を整えることは極めて重要です。事業貢献に直結する機能開発チームと、その生産性を向上させるプラットフォームチームの両輪がバランスよく機能することが成功の鍵となります。また、この1年間で組織における風通しの良さと効率性の重要性も強く認識しました。
we are hiring
現在のRecustomerには、情熱あふれるエンジニアたちが在籍しており、彼らを全力でサポートしていきたいと考えています。
現在、未経験からSREに挑戦しているCTOを支援し、プラットフォームチームを組織化できる人材を募集しています。ぜひRecustomerにご応募いただければ幸いです。[1]
-
本記事は、2025年2月27日に開催されたイベントの内容を元に編集した記事になります ↩
