Zenn
🌟

スタートアップの一人目エンジニアとしてやったこと(インフラ編)

に公開
AWS
インフラ
スタートアップ
SRE
tech

はじめに

こんにちは。
BtoB向けSaaSを開発しているスタートアップで、一人目のエンジニアをしています。

入社から半年が経ち、アプリケーション開発から情シス系業務まで気付けば色々やっていました。
本記事ではインフラ周りでやったことを中心に記録したものです。

同じような立場の方にとって、何かしらの参考になればうれしいです。

1. インフラの技術選定と実装

以下前提のもと、インフラの技術選定をしました

  • BtoB SaaSや生成AI系サービスを提供する予定でインフラを構築
  • 筆者はインフラの実務経験がない

IaC選択の結論

  1. 選択肢の洗い出し

    • AWS CloudFormation
    • AWS CDK
    • Terraform

  2. 最終選択: CloudFormation + CDKのハイブリッド

    • CloudFormation:
      • スタックの定義はほぼ100%CFnのYAMLを利用
    • CDK:
      • 環境ごとの変数定義や、デプロイ周りでCDKの仕組みを利用

※Terraformについては実際にトライしておらず、深い比較はできていません。

IaC選択の過程

  1. 試した構成①: CloudFormation 単体

    • 構成: GitHubと連携してGitSync機能で自動デプロイ
    • メリット:
      • CI/CDのセットアップが爆速で楽
      • AWSネイティブで安定性が高い
      • ドキュメントが充実しており、AIに高品質なアウトプットを生成させやすい(気がする)
    • デメリット:
      • GitSyncがPRにコメントを大量投下してきて耳障り

  2. 試した構成②: CDK単体(TypeScript)

    • 構成: すべてのCFn定義をTypeScriptで実装、極力抽象度の高い表現を利用
    • メリット:
      • 抽象度が高くて、ぱっと見で構成を理解しやすい
      • cdk diff や cdk deploy など、ツールのUXが優秀
      • 環境差分の吸収や再利用性が高い
    • デメリット:
      • 頻繁なデプロイでデッドロック多発
        • これは構成の詰めが甘かった自分のミス。抽象レイヤーに甘えていた…
      • デッドロックの例:
        • 抽象的に書きすぎたことでデプロイ時の依存関係の解決がうまくいかない現象が多発
        • 例えばECSに破壊的な変更を加えようとすると、CDKが「subnetもう要らんでしょ？」と判断して先に削除をかけようとする、実際にはECSでまだ利用しているためデプロイ失敗、といったイメージの状況が頻発

  3. 試した構成③: CDKベース + 定義はCloudFormation

    • メリット:
      • 前述の「GitSyncのうるささ」や「デプロイデッドロック」問題を解決
      • CDKの快適な開発体験と、CFnの安定感をどちらも取り込めた
    • 概要:
      • TypeScriptベースでCDKを使いながら、スタック定義自体はYAMLのCFnファイル
      • 環境ごとの定義(context)や、diff確認の体験、デプロイ周りはCDKに乗っかる

得られた効果

  • 環境構築の再現性
  • 構成変更のバージョン管理とレビュー体制の確立
  • AWSリソースの可視化
    • CloudFormationベースなので、抽象度が低くすべてのリソースがコード上で確認できる

2. 障害試験

障害対応の課題

カオスエンジニアリング的なアプローチとしてAWSのFault Injection Simulator（FIS）を導入。
いつでも障害試験を発動できる仕組みを整え、もしもに強いインフラ文化を構築しようという意図です。

AWS Fault Injection Simulator（FIS）の導入

AWSが提供する管理されたサービスであるFISを活用して、様々な障害シナリオをシミュレーションしました。
障害シナリオも、CDKでIaC管理しています。

  1. 試験シナリオの設計

    • AZ障害の再現
      • 例えばSecurityGroupを変更して特定AZのDB繋がらない風を再現したり、いろんなシナリオを組み合わせて発動
      • 例：Security Group を変更して特定AZのDBに“繋がらない風”を再現
      • 複数の障害アクションを組み合わせて発動
    • 特定リソースの障害
      • RDS / ECS / OpenSearch などを対象としたスケールインや強制停止
    • 突発的な負荷増大

  2. 事前・事後の確認項目の設定

    • オートスケーリングや自動復旧機能の検証
    • フェイルオーバーの確認
    • Route53やALBなど、ネットワーク周りのルーティングが切り替わることの確認
    • アラート通知の検証
    • 実際の復旧時間の計測

  3. 安全装置の設置

    • CloudWatchアラームによる自動停止条件
    • 復旧しない場合の手動対応フロー
    • ロールバック手順の準備

得られた効果

  • 「壊して試す」ことで時限爆弾の扱いを学ぶ
  • 監視と通知の連携テストにもなる(設定不備の炙り出し)
  • フェイルセーフ設計の挙動チェックと強化

3. CI/CDパイプラインの最適化

用途ごとに最適なツールを選びつつ、GitHub Actionsをハブにした構成にしています。

  • インフラ: CDK + CFn(GitHub Actionsでデプロイ)
  • Webフロント: Vercel(GitHub連携で自動デプロイ)
  • バックエンドAPI: CodeDeploy(BlueGreen) + ALB(GitHub Actionsでデプロイ)
  • DBマイグレーション: ECSタスク(GitHub Actionsで1回実行)
  • Androidアプリ: Firebase App Distribution(GitHub Actions)
  • iOSアプリ: Codemagic(TestFlight連携・証明書管理込み)

4. セキュアなリソースアクセス基盤

AWS上の特定リソースに直接アクセスしたいとき、ありますよね。

AWS Systems Manager Session Manager（SSM）

基本的なアクセスは SSM経由での踏み台アクセス に統一しています。
EC2インスタンスを踏み台として配置し、SSM経由で内部リソースに繋げる設計。

  • ポート開放不要でセキュア
  • IAM権限ベースでアクセス管理ができ、操作ログもCloudTrailに記録される
  • SSH鍵の管理が不要

OpenVPN：アクセス頻度が若干高いサービスアクセスのための補助線

追加で、VPN(OpenVPN)も用意しています。
OpenSearchのダッシュボードなど、アクセス頻度が若干高いものに限りVPN経由でアクセスできるように調整しています。

最後に

インフラについては、完璧な構成や正解があるわけではなく、
本記事で紹介した構成も今後チームやサービスが成長するにつれて形を変えていくはずです。

これからインフラを整えようとしている方にとって、一つの参考事例になればうれしいです。
そして、そんな環境を一緒に育ててくれる仲間も募集しています。

  • スタートアップフェーズで裁量を持って働きたい人
  • 得意な技術領域を持ち、そのスキルを活かしたい人
  • スピード感や変化を楽しめる人
  • 対話のゴールを意識し、建設的な議論ができる人

どれか一つでもピンと来たら、ぜひカジュアル面談しましょう！
詳細は以下のリンクからご覧いただけます👇
株式会社FAcraft - 採用（開発部門）

Discussion