管理プロセス

管理プロセスとは

管理プロセスは、Twelve-Factor App の第 12 原則で、DB マイグレーション、データ修正、レポート生成などの管理タスクをワンオフプロセスとして実行する考え方である。Adam Wiggins が 2011 年に Heroku での運用経験をもとに Twelve-Factor App を発表し、管理プロセスはその最後の原則として位置づけられた。

核心は「管理タスクもアプリケーションと同じコードベース・同じ環境・同じ設定で実行する」という点にある。本番環境のデータを修正するスクリプトが、開発者のローカルマシンから異なる設定で実行されると、環境差異による事故が起きる。管理タスクをアプリと同じデプロイパイプラインに載せることで、この問題を根本的に排除する。

管理タスクの種類

タスク	説明	AWS での実行例
DB マイグレーション	スキーマ変更、カラム追加	Lambda (手動実行)
データ修正	不整合データの修正、一括更新	Lambda + DynamoDB
レポート生成	月次集計、分析レポート	Step Functions
キャッシュクリア	古いデータの削除、キャッシュ無効化	Lambda
ユーザー管理	管理者の追加、権限変更	Cognito CLI
シード投入	初期データの投入、マスタデータ更新	Lambda + S3

管理タスクの 4 原則

1. 同一コードベース

管理スクリプトはアプリケーションと同じリポジトリに含める。別リポジトリに分離すると、アプリのモデル変更に管理スクリプトが追従できず、実行時エラーの原因になる。

2. 同一環境

本番の管理タスクは本番環境で実行する。ローカルから本番 DB に接続するのではなく、本番と同じ Lambda 関数として実行する。

# 本番環境の Lambda を手動実行
aws lambda invoke --function-name MigrationFunction \
  --payload '{"version": "003"}' /dev/stdout

3. 冪等性の確保

同じタスクを 2 回実行しても安全な設計にする。ネットワーク障害やタイムアウトで再実行が必要になるケースは頻繁に起きる。

// 冪等なマイグレーション: 適用済みならスキップ
async function migrate(version: string): Promise<void> {
  const applied = await getAppliedMigrations();
  if (applied.includes(version)) {
    console.log(`Migration ${version} already applied, skipping`);
    return;
  }
  await runMigration(version);
  await recordMigration(version);
}

4. 監査証跡

実行結果を CloudWatch Logs に記録し、誰が・いつ・何を実行したかを追跡可能にする。手動の SQL 実行は監査証跡が残らないため禁止する。

Step Functions による複雑な管理タスク

複数ステップにまたがる管理タスクは、Step Functions でワークフローとして定義する。途中で失敗した場合の再開やロールバックが容易になる。

開始 → データ検証 → バックアップ作成 → マイグレーション実行 → 検証 → 完了
                                          ↓ (失敗)
                                    バックアップから復元

アンチパターン

アンチパターン	問題	正しいアプローチ
本番 DB に直接 SQL を実行	監査証跡がない、ロールバック不能	Lambda 経由で実行
ローカルから本番 DB に接続	セキュリティリスク、環境差異	本番環境の Lambda で実行
管理スクリプトを手動で実行	再現性がない、手順ミス	CI/CD パイプラインに組み込む
管理タスクを別リポジトリで管理	モデル変更に追従できない	アプリと同一リポジトリ
冪等性のない一括更新	再実行で二重処理	処理済みフラグで冪等性を確保

詳しくは関連書籍を参照。