メインコンテンツへスキップ

v1.9.0 — イベント事前スケーリング + Aurora データ層基盤 (ADR-030)

· 約7分で読めます
AWSops Team

運用負荷が予測されるイベント（セール、ライブストリーミング、四半期末など）に備えてリソースを事前にウォームアップするイベント事前スケーリングを v1.9.0 に追加しました。同時に、単一 EC2 ホストにビルド・運用・ローカル JSON 状態がすべて集約されていた構造を解消するための ADR-030 Aurora データ層基盤（CDK スタック・スキーマ・db.ts）も導入しました。本リリースの Aurora はデフォルト off / opt-in で入っており、既存の単一ホストデプロイには影響しません。

主な変更点

イベント事前スケーリング (ADR-010 Phase 1+2) · Aurora Serverless v2 基盤 (ADR-030 Phase 1) · ADR-029 変更作業ゲート · AI コードレビューワークフロー · ゾンビ接続クリーンアップの強化

イベント事前スケーリング (ADR-010 Phase 1+2)​

大規模トラフィックイベントの開始前にリソースをウォームアップできるよう、/event-scaling 管理者ページが追加されました。登録からスクリプトのダウンロードまで 4 ステップで動作します:

  1. イベント登録 — イベント名、開始/終了時刻、影響を受けるリソースタグ
  2. 過去メトリクスの収集 — 同じイベントが過去にあった場合、その区間の CloudWatch メトリクス（ASG・RDS・MSK・EBS・ALB）を GetMetricData バッチで収集
  3. AI ウォームアッププラン生成 — Bedrock Sonnet 4.6 がリソースごとに多段階の事前スケールプランを生成し、PLAN_JSON マーカーで構造化された結果を返却
  4. bash スクリプトのダウンロード — リソースタイプごとに安全なスクリプトを生成（KEDA・HPA、Aurora リーダー追加、MSK パーティション拡張、ASG warm pool、EBS IOPS ブースト）

レビュー後実行 (mutation-by-review)​

ダッシュボードは**変更作業を直接実行しません。**スクリプトはダウンロード専用であり、オペレーターがレビューした後、適切な環境（kubectl、aws cli）で自ら適用します。これは ADR-029（Proposed）の変更作業ゲートモデル — 「AI が生成した mutating action は明示的な人間の承認後にのみ実行される」— と一致しています。

関連ファイル​

ファイル役割
src/app/event-scaling/page.tsxイベント登録・メトリクスチャート・プラン表示・スクリプトダウンロード UI（admin 専用）
src/app/api/event-scaling/route.tsCRUD + メトリクス + Bedrock プラン + スクリプト（GET/POST/PUT/DELETE）
src/lib/event-scaling.tsデータモデル + JSON 永続化（data/event-scaling/）
src/lib/event-scaling-prompts.tsBedrock Sonnet 4.6 プロンプト + PLAN_JSON パース
src/lib/event-scaling-scripts.tsリソースタイプ別 bash スクリプト生成器
src/lib/queries/event-scaling.tsCloudWatch GetMetricData + ASG/RDS/MSK/EBS/ALB リソース状態クエリ

Aurora データ層基盤 (ADR-030 Phase 1)​

ビルドサーバーと運用サーバーが同じ EC2 に集約されており、AgentCore の Docker ビルド時に Next.js の遅延が跳ね上がり、Steampipe FDW クエリがタイムアウトする問題を解決するため、ADR-030 で **ECS Fargate ワークロード + Aurora アプリ状態 + デュアル ECR（Dev=Private、Prod=Public）**への移行を決定しました。v1.9.0 にはそのうち Phase 1 の基盤のみが入ります。

導入されたもの​

コンポーネント説明
infra-cdk/lib/awsops-data-stack.tsAurora Serverless v2 PostgreSQL 15.5（0.5–4 ACU、Writer + Reader、KMS 暗号化、IAM 認証、Private Subnet、rds.logical_replication=1）
infra-cdk/data/schema.sqlidempotent な 7 テーブルスキーマ（inventory_snapshots、cost_snapshots、agentcore_memory、agentcore_stats、alert_diagnosis、event_scaling_plans、report_schedules）+ schema_migrations バージョントラッキング + touch_updated_at トリガー
src/lib/db.tsアプリ側 pg Pool（Steampipe のプールとは分離）。AURORA_DATABASE_URL DSN または AURORA_HOST/USER/PASSWORD/DB の個別環境変数、isAuroraEnabled() / checkDbHealth() ヘルパー
scripts/13-deploy-aurora.shCDK デプロイ + Secrets Manager から認証情報を取得して psql でスキーマ適用。deploy / schema / status / dsn サブコマンド

opt-in デプロイ​

デフォルトは off です。有効化するにはコンテキストフラグを明示します:

cd infra-cdk
npx cdk deploy AwsopsDataStack -c enableAurora=true
# または、スクリプトを使用
../scripts/13-deploy-aurora.sh deploy

このようにゲートした理由は、(1) Aurora Serverless v2 の最低 0.5 ACU 課金（~$43/月）がすべての環境に適しているわけではないこと、(2) Phase 1 の dual-write がまだ入っておらず、実際のデータは依然として data/*.json に蓄積されるためです。

Steampipe はそのまま​

ADR-030 の微妙なポイント: Steampipe は stateless です。FDW が AWS API をリアルタイムに照会し、結果を一時的にインメモリに置く構造のため、コンテナが再起動しても失われる「データ」はありません。Aurora が置き換えるのは Steampipe ではなく、ダッシュボード自体が EC2 のディスクに蓄積していた data/*.json（インベントリ・Cost・メモリ・alert 記録・event-scaling プランなど）です。

次のリリース予定 (Phase 1 dual-write)​

7 つのソースファイルにデュアル書き込み経路が入ります。書き込みは JSON と Aurora の両方に行われ、読み取りは 7 日間のパリティゲートが通過するまで JSON 側から行います:

  • resource-inventory.ts、cost-snapshot.ts、agentcore-memory.ts、agentcore-stats.ts、alert-knowledge.ts、event-scaling.ts、report-scheduler.ts

ADR-029: 変更作業フレームワーク (Proposed)​

イベント事前スケーリングがレビュー後実行として導入された理由は、ADR-010 Phase 3（自動実行）のゲートモデルがまだ決まっていないためです。ADR-029 はそのゲート — 「どのような条件で、AI が生成した変更作業を、どのような権限モデルで実行可能にするか」— を Proposed 状態で登録し、今後の Phase 3 作業の前提条件を明示します。

AI コードレビューワークフロー​

PR がオープンまたは更新された際に Claude が自動でコードレビューを行う GitHub Actions ワークフローが追加されました（.github/workflows/claude-review.yml）。AWSops のコンベンション（Steampipe pg Pool、basePath、SCP ブロックカラムなど）に合わせたレビュープロンプトを使用します。

ゾンビ接続クリーンアップの強化​

src/lib/steampipe.ts のゾンビクリーンアップ処理が、プールから connection を借りるのではなく、専用の短命 Client を使用するように変更されました。Cost Explorer/IAM サマリーの FDW が hung 状態でプール全体が枯渇しても、クリーンアップは継続して動作します。しきい値も 90 秒に短縮されました。

統計比較​

項目v1.8.1v1.9.0変更
ページ4143+2（/event-scaling、/login の訂正反映）
API ルート1819+1（/api/event-scaling）
SQL クエリファイル2526+1（event-scaling.ts）
ADR28 (001-028)30 (001-030)+2（029 Proposed、030 Accepted）
CDK スタック3（Awsops·Cognito·AgentCore）4+1（AwsopsDataStack、opt-in）
デプロイスクリプト12 段階13 段階+1（13-deploy-aurora.sh）
lib ファイル2731+4（event-scaling* 3 個、db.ts）

参考​