概要
パレート最適
Argo（¥55,000）+ BigQuery（¥38,000）で全体の63%。この2つから着手するだけで目標達成が見えてくる。
アイドルコストの排除
Cloud Run の min-instances=2 が月500時間課金の原因。実処理時間はわずか15時間。
BigQuery パーティション化
2TB/日フルスキャン → 直近7日分 70GB/日。96%削減（$38,000 → $1,400相当）。
GKE Autopilot 移行
アイドルノード課金をゼロに。月300回×10分の実行時間分のみ課金で91%削減。
問題
販促メール配信パイプラインのインフラコストを月次40%以上削減（¥147,000 → ¥88,200以下）せよ。
現状アーキテクチャ
| サービス | 構成 | 月次コスト |
|---|---|---|
| Cloud Run（配信ジョブ） | 2 vCPU / 4GB RAM × 最大10インスタンス、月500時間稼働 | ¥42,000 |
| BigQuery（クエリ） | 毎日フルスキャン（約2TB/日） | ¥38,000 |
| Cloud Storage | 500GB、Standardストレージ | ¥12,000 |
| Argo Workflows（GKE Node） | n2-standard-4 ノードプール | ¥55,000 |
| 合計 | ¥147,000 |
前提条件
- BigQuery:
event_dateカラムを持つが、パーティションテーブルになっていない - Cloud Run: 1日2回（朝9時・夜21時）実行、実行時間は平均15分/回
- Argo Workflows: GKE Standard（n2-standard-4）上で動作
- Cloud Storage: 90日以上経過したデータは参照頻度が極めて低い
期待する回答形式: 数値計算 + 施策提案（表・フェーズ計画を含む文章形式）
ヒント（段階的開示）
ヒント1 — 方向性
コスト最大の項目から着手する「パレート最適」アプローチを取れ。Argo Workflows（¥55,000）と BigQuery（¥38,000）で全体の63%を占めている。まずこの2つの削減策を深掘りすること。
ヒント2 — 各サービスのアプローチ
- Cloud Run: 実処理時間 = 2回/日 × 15分 × 30日 = 900分 = 15時間/月。しかし月500時間稼働は異常値 →
min-instancesが設定されている可能性 - BigQuery: 典型的なECイベントログでは日次クエリで参照する期間は直近7〜30日が多い。パーティションフィルタで激減
- GKE Autopilot: ノードはIdle時間にもコストが発生する。Autopilot に移行すると Pod が実行中の時間のみ課金
- Cloud Storage: Object Lifecycle Management で90日後に Nearline/Coldline へ自動移行
ヒント3 — 計算の骨格
【Cloud Run アイドルコスト】
実処理時間 = 2回/日 × 15分 × 30日 = 15時間/月
請求されている時間 = 500時間/月
差分 = 485時間 ≈ 常時2インスタンス分のアイドル（min-instances=2）
【BigQuery 削減試算】
現在: 2TB/日 × 30日 = 60TB/月
パーティション適用後（直近7日）: 70GB/日 → 2.1TB/月
削減率: 96%
【GKE Autopilot 試算】
月次実行時間: 300回 × 10分 = 50時間
Autopilot 料金: CPU 4vCPU + MEM 16GB × 50時間 ≈ ¥4,900
削減額: ¥55,000 - ¥4,900 = ¥50,100模範解答 — 1. 各サービスの削減施策と試算
A. BigQuery: パーティションテーブル化（¥38,000 → ¥1,400）
施策:
試算:
event_date カラムをパーティションキーとして再作成、require_partition_filter = true を設定、セグメントクエリの WHERE 句に event_date BETWEEN を明示
試算:
現在: 2TB/日 × 30日 = 60TB/月 × ¥650 = ¥39,000
改善後: 直近7日のイベントを参照 → 2TB × (7/200) ≈ 70GB/日
70GB × 30日 = 2.1TB/月 × ¥650 ≈ ¥1,365
削減額: 約¥37,600（削減率96%）
B. Argo Workflows: GKE Autopilot移行（¥55,000 → ¥4,900）
施策: GKE Standard ノードプールを GKE Autopilot クラスタに移行。ノードはPod実行中のみ課金（アイドルコストゼロ）
試算:
試算:
月次実行時間: 300回 × 10分平均 = 50時間 Autopilot料金（4vCPU/16GB相当）: CPU: 4vCPU × ¥0.0048/vCPU秒 × 3,600秒 × 50時間 ≈ ¥3,456 MEM: 16GB × ¥0.0005/GB秒 × 3,600秒 × 50時間 ≈ ¥1,440 合計: ≈ ¥4,900 削減額: ¥50,100（削減率91%）
C. Cloud Run: 最小インスタンス数の見直し（¥42,000 → ¥5,000）
施策:
試算:
min-instances=0 に変更、Cloud Scheduler トリガー直前に warm-up リクエスト送信、メモリを実測値ベースで2GBへダウンサイジング
試算:
実処理時間 = 15時間/月（2回/日 × 15分 × 30日） min-instances=0、処理時間のみ課金: 2vCPU × ¥0.0048/vCPU秒 × 900秒/月 × 10インスタンス最大 ≈ ¥864 4GB × ¥0.0005/GB秒 × 900秒 × 10 ≈ ¥180 合計: ≈ ¥5,000 削減額: ¥37,000（削減率88%）
D. Cloud Storage: Lifecycle Management（¥12,000 → ¥4,800）
施策: 90日以降のオブジェクトを Nearline（¥1.0/GB）へ自動移行、365日以降は Coldline（¥0.4/GB）へ移行
試算（3ヶ月後）:
試算（3ヶ月後）:
直近90日（アクティブ）: 150GB × ¥2.3 = ¥345 91〜365日（Nearline）: 250GB × ¥1.0 = ¥250 365日超（Coldline）: 100GB × ¥0.4 = ¥40 合計: ¥635/月 → 実際は移行に数ヶ月かかるため3ヶ月後 ≈ ¥4,800 削減額（3ヶ月後）: ¥7,200（削減率60%）
フェーズ別コスト推移
2. コストトレードオフマトリクス
| 施策 | 実装コスト | 削減効果 | 削減額/月 | 優先度 |
|---|---|---|---|---|
| BigQueryパーティション化 | 中 | 高 | ¥37,600 | ★★★ |
| GKE Autopilot移行 | 高 | 高 | ¥50,100 | ★★★ |
| Cloud Run min-instances=0 | 低 | 高 | ¥37,000 | ★★★ |
| Storage Lifecycle設定 | 低 | 中 | ¥7,200 | ★★☆ |
3. 実装フェーズ計画
Phase 1（Week 1-2）: 即効性の高い設定変更
担当: エンジニア2名
期待コスト削減: ¥37,000（Cloud Run）+ ¥3,600（Storage一部）= 約¥40,600
期待コスト削減: ¥37,000（Cloud Run）+ ¥3,600（Storage一部）= 約¥40,600
- Cloud Run
min-instances=0に変更、Cloud Scheduler の warm-up リクエスト追加 - Cloud Storage Lifecycle Management ポリシー設定
- BigQuery クエリのパーティションフィルタ付与（既存クエリの WHERE 句修正）
Phase 2（Week 3-4）: BigQueryパーティション化
担当: エンジニア2名
期待コスト削減: ¥37,600（BigQuery） → この時点で目標 40% 削減達成
期待コスト削減: ¥37,600（BigQuery） → この時点で目標 40% 削減達成
- テーブルパーティション移行（
CREATE TABLE ... PARTITION BY DATE(event_date) AS SELECT ...） require_partition_filter = true設定- 全依存 dbt モデルの WHERE 句確認・修正
- 移行後の動作確認・コスト検証
Phase 3（Week 5-6）: GKE Autopilot移行
担当: エンジニア2名
期待コスト削減: ¥50,100（Argo Workflows） → Phase3後は89%削減（¥16,100/月）
期待コスト削減: ¥50,100（Argo Workflows） → Phase3後は89%削減（¥16,100/月）
- GKE Autopilot クラスタ作成
- Argo Workflows Helm チャートを新クラスタへデプロイ
- ワークフロー定義・RBAC 設定の移行
- 並行稼働・動作確認後に Standard クラスタ削除
4. 施策後の月次コスト予測
| サービス | 現状 | Phase1後 | Phase2後 | Phase3後 |
|---|---|---|---|---|
| Cloud Run | ¥42,000 | ¥5,000 | ¥5,000 | ¥5,000 |
| BigQuery | ¥38,000 | ¥38,000 | ¥1,400 | ¥1,400 |
| Cloud Storage | ¥12,000 | ¥10,000 | ¥8,000 | ¥4,800 |
| Argo (GKE) | ¥55,000 | ¥55,000 | ¥55,000 | ¥4,900 |
| 合計 | ¥147,000 | ¥108,000 | ¥69,400 | ¥16,100 |
| 削減率 | — | 27% | 53% ✓ | 89% |
Phase2 完了時点（4週間後）で目標 40% 削減（¥88,200以下）を達成。 Phase3 完了後は 89% 削減（¥16,100/月）となり、目標を大幅超過。
ポイント解説
1
パレート最適でコスト構造を分析する
上位2サービス（Argo + BQ）が全体の63%を占める。エンジニアはついコードレベルの最適化に目が向きがちだが、インフラ設定変更で最大のROIが得られることを常に意識する。
上位2サービス（Argo + BQ）が全体の63%を占める。エンジニアはついコードレベルの最適化に目が向きがちだが、インフラ設定変更で最大のROIが得られることを常に意識する。
2
アイドルコストは見えにくい最大の罠
Cloud Run の月500時間稼働は、実処理15時間に対して33倍の水増し。
Cloud Run の月500時間稼働は、実処理15時間に対して33倍の水増し。
min-instances の見落としは特に長時間稼働しているサービスで顕著。GKE の Standard もノードが起動しているだけで課金されるため、バッチ専用ワークロードには Autopilot が圧倒的に有利。
3
パーティションプルーニングは BigQuery コスト削減の王道
テーブルサイズが大きいほど、クエリでスキャンする範囲をパーティションフィルタで絞り込む効果が劇的。2TB → 70GB は96%削減。
テーブルサイズが大きいほど、クエリでスキャンする範囲をパーティションフィルタで絞り込む効果が劇的。2TB → 70GB は96%削減。
require_partition_filter で将来の事故防止も同時に実現する。
今日のまとめ
クラウドコスト削減はアイドルリソース（min-instances、GKEノード）とデータスキャン量（BigQueryフルスキャン）の2点を押さえるだけで80%以上の削減を実現できる。
提案には必ず「施策 × 削減額 × 実装コスト × 期間」の4軸を揃えた表を添えることで、技術提案をビジネス判断に接続できる。シニアエンジニアとしてコスト設計を語れることは、EMや経営層の信頼を得るための重要なスキルである。
提案には必ず「施策 × 削減額 × 実装コスト × 期間」の4軸を揃えた表を添えることで、技術提案をビジネス判断に接続できる。シニアエンジニアとしてコスト設計を語れることは、EMや経営層の信頼を得るための重要なスキルである。