E 会計/ファイナンス・コスト効率 — Unit Economics × Cloud Run min-instances=0 × Pub/Sub ackDeadline × BigQuery パーティション剪定（メール配信基盤 Bad→Good）

📋 コピー# terraform/cloud_run_delivery.tf

# Bad: min-instances=4 で CPU always-on（91.7%がアイドル）
resource "google_cloud_run_v2_service" "delivery_api_bad" {
  template {
    scaling {
      min_instance_count = 4   # ← 常時4インスタンス稼働・アイドルでも課金
      max_instance_count = 20
    }
    containers {
      resources {
        cpu_idle = false        # ← CPU always-on（リクエストなしでも課金）
      }
    }
  }
}

# Good: min-instances=0 + cpu_idle=true でアイドルコストを撲滅
resource "google_cloud_run_v2_service" "delivery_api_good" {
  name     = "mops-delivery-api"
  location = "asia-northeast1"

  template {
    scaling {
      min_instance_count = 0   # アイドル時はインスタンスゼロ（コスト $0）
      max_instance_count = 50  # バースト時に自動スケール
    }

    containers {
      image = "asia-northeast1-docker.pkg.dev/${var.project_id}/mops-images/delivery-api:latest"

      resources {
        limits = {
          cpu    = "2"
          memory = "1Gi"
        }
        cpu_idle          = true   # リクエスト処理時のみ CPU 課金（← 重要）
        startup_cpu_boost = true   # コールドスタート高速化（初回レイテンシ短縮）
      }
    }
  }
}

コールドスタート対策: コネクションプール再利用

📋 コピー# application/main.py
# コールドスタート対策: グローバル変数で接続プールを使い回す
# Cloud Run では同一インスタンスが複数リクエストを処理するため、
# リクエストごとに接続を張り直すのは最も多いアンチパターン

from google.cloud import bigquery
from google.cloud import pubsub_v1

# モジュールレベルで初期化（コールドスタート時のみ実行）
_bq_client: bigquery.Client | None = None
_publisher: pubsub_v1.PublisherClient | None = None


def get_bq_client() -> bigquery.Client:
    """シングルトンパターン: コールドスタート後は既存接続を再利用"""
    global _bq_client
    if _bq_client is None:
        _bq_client = bigquery.Client()  # 接続初期化は1回のみ
    return _bq_client


def get_publisher() -> pubsub_v1.PublisherClient:
    global _publisher
    if _publisher is None:
        _publisher = pubsub_v1.PublisherClient()
    return _publisher

削減試算

📋 コピー現状: $3,840/月（min-instances=4 × CPU always-on）
  - アイドル時間: 91.7%（660h/月）= $3,520 が無駄
  - 実行時間: 8.3%（60h/月）= $320 が実質稼働分

改善後（リクエスト課金のみ）:
  - アイドルコスト: $0（min-instances=0）
  - 実行コスト:
    2,400万リクエスト × 0.1vCPU-s/リクエスト = 240万 vCPU-s
    240万 vCPU-s × $0.0000240/vCPU-s ≈ $192/月

削減額: $3,840 - $192 = $3,648/月（95%削減）
工数: 2人日
削減額/工数: $1,824/人日

📋 コピー-- Bad: パーティション未設定でフルスキャン（800GB/クエリ）
SELECT
  campaign_id,
  DATE(created_at)          AS event_date,
  COUNT(*)                  AS send_count,
  COUNTIF(opened)           AS open_count
FROM `project.mops_dataset.email_events`  -- フルスキャン確定！
WHERE created_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY 1, 2


-- Good: パーティション + クラスタリング設定済みモデル（24GB/クエリ）
-- models/mart/mart_email_delivery_kpi.sql
{{
  config(
    materialized='incremental',
    incremental_strategy='insert_overwrite',
    partition_by={
      'field': 'event_date',
      'data_type': 'date',
      'granularity': 'day'
    },
    cluster_by=['campaign_id', 'segment_id'],  -- よく使うフィルタカラム
    on_schema_change='fail'
  )
}}

WITH events AS (
  SELECT
    DATE(created_at)                        AS event_date,  -- パーティションキー
    campaign_id,
    COALESCE(segment_id, 'unknown')         AS segment_id,  -- NULL 保護
    email_id,
    opened,
    clicked,
    converted,
    revenue_amount
  FROM {{ ref('stg_email_events') }}

  {% if is_incremental() %}
  -- パーティション剪定: 直近7日のみスキャン（800GB → 24GB）
  WHERE DATE(created_at) >= DATE_SUB(
    (SELECT MAX(event_date) FROM {{ this }}),
    INTERVAL 7 DAY
  )
  {% endif %}
)

SELECT
  event_date,
  campaign_id,
  segment_id,
  COUNT(DISTINCT email_id)                              AS send_count,
  COUNTIF(opened)                                       AS open_count,
  COUNTIF(clicked)                                      AS click_count,
  COUNTIF(converted)                                    AS conversion_count,
  COALESCE(SUM(revenue_amount), 0)                      AS total_revenue,

  -- KPI 指標（SAFE_DIVIDE でゼロ除算防止）
  SAFE_DIVIDE(COUNTIF(opened),    COUNT(DISTINCT email_id)) AS open_rate,
  SAFE_DIVIDE(COUNTIF(clicked),   COUNTIF(opened))          AS ctr,
  SAFE_DIVIDE(COUNTIF(converted), COUNTIF(clicked))         AS cvr,

  CURRENT_TIMESTAMP() AS _loaded_at
FROM events
GROUP BY event_date, campaign_id, segment_id

削減試算

📋 コピー現状: $5/TB × 800GB/クエリ × 720回/月 = $2,880/月

改善後（パーティション剪定: 7日分のみスキャン）:
  7日分スキャン: 800GB × (7/180) ≈ 31GB → 実績値 24GB/クエリ（97%削減）
  改善後コスト: $5/TB × 24GB/クエリ × 720回/月 = $86.4/月

削減額: $2,880 - $86.4 = $2,793.6/月（97%削減）
工数: 3人日
削減額/工数: $931/人日

📋 コピー"""Pub/Sub ackDeadline 延長 + modifyAckDeadline リース管理パターン"""
import threading
from google.cloud import pubsub_v1

# Terraform で subscription を管理する場合:
# resource "google_pubsub_subscription" "delivery_sub" {
#   ack_deadline_seconds       = 60   # 20秒処理 → 60秒（3倍の余裕）
#   message_retention_duration = "86400s"
#   retry_policy {
#     minimum_backoff = "10s"
#     maximum_backoff = "600s"
#   }
# }

ACK_DEADLINE_SECONDS: int = 60   # 名前付き定数（マジックナンバー禁止）
EXTEND_INTERVAL_SECONDS: int = 30  # 期限の半分で延長


def process_message_with_lease_management(
    message: pubsub_v1.types.ReceivedMessage,
    subscriber: pubsub_v1.SubscriberClient,
    subscription_path: str,
) -> None:
    """
    長時間処理でも確実に ack するリース管理パターン。

    処理時間が ackDeadline を超える可能性がある場合は
    modifyAckDeadline で延長する。
    """
    stop_event = threading.Event()

    def extend_ack_deadline() -> None:
        """バックグラウンドスレッドで定期的に ackDeadline を延長する"""
        while not stop_event.wait(timeout=EXTEND_INTERVAL_SECONDS):
            subscriber.modify_ack_deadline(
                request={
                    "subscription": subscription_path,
                    "ack_ids": [message.ack_id],
                    "ack_deadline_seconds": ACK_DEADLINE_SECONDS,
                }
            )

    extender = threading.Thread(target=extend_ack_deadline, daemon=True)
    extender.start()

    try:
        # メイン処理（平均20秒かかる配信処理）
        _deliver_emails(message.data)  # type: ignore[name-defined]
        subscriber.acknowledge(
            request={
                "subscription": subscription_path,
                "ack_ids": [message.ack_id],
            }
        )
    finally:
        stop_event.set()  # 延長スレッドを停止

削減試算

📋 コピー現状: 3.2倍再配信ループ
  実メッセージ: 2,400万通
  課金対象: 2,400万 × 3.2 = 7,680万メッセージ
  月額: $960/月

改善後（ackDeadline=60秒で再配信なし）:
  課金対象: 2,400万メッセージ（1.0倍）
  月額: $960 / 3.2 = $300/月

削減額: $660/月（68.75%削減）
工数: 0.5人日
削減額/工数: $1,320/人日 ← ROI 最高（Phase 1 に先着手）

施策別 ROI サマリー（優先順位順）

ROI 試算（全ステークホルダー向け）

📋 コピー【実施コスト】
6.5人日 × 8時間 × 6,000円/時間 = 312,000円（≈ $2,080）

【月次削減額】
$7,462/月 × 150円/$  = 1,119,300円/月

【ペイバック期間】
312,000円 ÷ 1,119,300円/月 = 0.279ヶ月 ≈ 8.5日

【年間 ROI】
年間削減額: $7,462 × 12 = $89,544（≈ 1,343万円）
年間 ROI:   ($89,544 - $2,080) / $2,080 = 4,207%

【ステークホルダー別の伝え方】
  CFO 向け:  「実施コスト $2,080 で年間 $89,544 の削減。ROI 4,207%。
              リスクフリーレートの 400倍以上の投資効果。」

  CTO 向け:  「6.5人日（約1.5スプリント）で月額 77.7%削減。
              ペイバック 8.5日。エンジニア2名で完遂可能。」

  エンジニア向け: 「ackDeadline を 10秒→60秒に変えるだけ（0.5人日）で
                  月 $660 削減。Terraform 1行変更で完了。」

【目標達成確認】
目標: Unit Cost 40%削減
実績: Unit Cost 77.7%削減 → 目標を 37.7pt 超過達成

リスクと対策