個人開発SaaSで必要な監視・バックアップ設計

「個人開発だから監視は後回し」は危険

SaaSとして料金を受け取る以上、障害への対応は義務です。 ユーザーが使えない時間が長引くほど、信頼を失います。

SOFTBASEで採用している最小限の監視・バックアップ設計を公開します。

構成の全体像

[ECS Fargate]  ← Laravel API + Next.js
[RDS MySQL]    ← ユーザーデータ
[S3]           ← アップロードファイル・処理結果
[ElastiCache]  ← Redisキュー・セッション

↓ 監視・通知
[CloudWatch]   ← メトリクス・ログ収集
[SNS]          ← アラートのメール/Slack通知

監視すべき指標

アプリケーション層

指標	閾値の例	対応
HTTPエラー率（5xx）	1%超	即時調査
レスポンスタイム	p95 > 3秒	ボトルネック調査
キュー積み残し	50件超	Workerスケールアウト

インフラ層

指標	閾値の例
CPU使用率（ECS）	80%超
メモリ使用率	85%超
RDS接続数	max_connections の70%超
S3エラー率	0.1%超

CloudWatch Alarmの設定（Terraform例）

# 5xxエラー率のアラーム
resource "aws_cloudwatch_metric_alarm" "high_5xx_rate" {
  alarm_name          = "softbase-high-5xx-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "HTTPCode_Target_5XX_Count"
  namespace           = "AWS/ApplicationELB"
  period              = "60"
  statistic           = "Sum"
  threshold           = "10"
  alarm_actions       = [aws_sns_topic.alerts.arn]
}

バックアップ設計

RDS自動バックアップ

resource "aws_db_instance" "main" {
  # ...
  backup_retention_period = 7        # 7日間保持
  backup_window           = "02:00-03:00"  # 深夜2時〜3時
  deletion_protection     = true     # 誤削除防止
  
  # ポイントインタイムリカバリを有効化
  # → 任意の時点に復元可能
}

S3ライフサイクル

{
  "Rules": [{
    "Id": "archive-old-uploads",
    "Status": "Enabled",
    "Transitions": [
      {
        "Days": 30,
        "StorageClass": "STANDARD_IA"
      },
      {
        "Days": 90,
        "StorageClass": "GLACIER"
      }
    ],
    "Expiration": {
      "Days": 365
    }
  }]
}

障害時の対応フロー

1. CloudWatch アラーム発火
   ↓
2. SNS → メール・Slack通知（深夜でも起きる）
   ↓
3. CloudWatch Logs でエラーログ確認
   ↓
4. 原因特定
   ├── コードバグ → ECS新バージョンデプロイ（<5分）
   ├── DB問題 → RDSフェイルオーバー or 復元
   └── インフラ問題 → Terraformで再構築
   ↓
5. ユーザー向けステータスページ更新
   （status.softbase.jp）

まとめ：最低限やること

個人開発でも以下は必須です：

1. ✅ CloudWatch でエラー率・CPU・メモリを監視
2. ✅ RDS自動バックアップ（7日保持）
3. ✅ S3バージョニング有効化
4. ✅ アラートをメールまたはSlackに通知
5. ✅ ステータスページの公開

「障害が起きた時に気づける仕組み」があるだけで、SaaSとしての信頼性は大きく変わります。