PART 06 — 外部バッチからのDB処理
バッチとAPの競合をアーキテクチャで解決する

バッチサーバー（常時稼働・専用機）
  ├── JP1 / A-AUTO / cron でスケジュール管理
  ├── シェルスクリプト + Java 実行
  └── JDBC で直接 Oracle / PostgreSQL に接続

問題：
  夜間バッチ実行中にAPが同じテーブルを更新
  → ロック待ち → タイムアウト → バッチ失敗 or APエラー

対策（オンプレでの工夫）：
  ・バッチ実行中はAP側のメンテナンスウィンドウを設ける
  ・バッチ専用スキーマを作る
  ・SELECT FOR NOWAIT / SKIP LOCKED を使う
  いずれも根本的な解決ではなく、運用でカバーしている状態

【パターン1：Reader Endpoint分離（参照系バッチ）】

バッチ（参照のみ）→ Aurora Reader Endpoint
APサーバー         → Aurora Writer Endpoint（更新）

→ バッチがReaderを使う限りWriterへの影響ゼロ
→ Replicaのレプリケーション遅延（数ms〜数十ms）を許容できる場合に有効

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【パターン2：時間帯スケジューリング（更新バッチ）】

夜間2:00〜5:00  → バッチ実行ウィンドウ
               → AP側のECSタスク数を最小（0〜1台）にスケールイン
               → バッチがWriterに集中してロック競合なし

→ EventBridge + ECS Auto Scaling で自動化可能

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【パターン3：Aurora Clone（本番無影響）】

① バッチ開始時に Aurora Clone を作成（ほぼ瞬時・コピーオンライト）
② バッチは Clone DB で処理（本番Aurora は無影響）
③ バッチ完了後 Clone を削除

→ 大量データの集計・帳票生成・分析バッチに最適
→ Cloneは本番の時点スナップショット（整合性が保たれる）

EventBridge Scheduler（毎日 AM 2:00）
    ↓
Step Functions ステートマシン起動
    │
    ├─ State 1: Aurora Clone 作成
    │     aws rds restore-db-cluster-to-point-in-time
    │     --restore-type copy-on-write
    │     --source-db-cluster-identifier prod-cluster
    │     → Clone エンドポイントを取得
    │
    ├─ State 2: バッチ ECS Task 起動
    │     環境変数 DB_URL=Clone Endpoint を注入
    │     → Clone DB で集計・帳票生成 → S3 に出力
    │
    ├─ State 3: SNS 完了通知（メール）
    │
    └─ State 4: Clone 削除
          → ストレージコスト精算終了

オンプレ JP1/A-AUTO 機能      Step Functions での対応
─────────────────────────────────────────────────────
ジョブネット定義               ステートマシン定義（JSON/YAML）
先行ジョブ待ち                 次状態への遷移条件
リトライ設定                   Retry設定（回数・間隔・バックオフ）
エラー時の後続スキップ         Catch設定（エラー種別ごとに分岐）
実行履歴の管理                 Step Functions 実行履歴（90日保持）
ジョブ実行状況の可視化         AWS コンソール上でフローをグラフ表示
異常終了通知                   EventBridge + SNS でメール / Slack通知