Contents
スポンサードリンク
1️⃣ FinOps の基本概念と導入フレームワーク
| 項目 | 内容 |
|---|---|
| FinOps とは | 「Finance（財務）＋Operations（運用）」の合成語で、クラウド費用を 可視化・測定・最適化 のサイクルで管理する組織横断的プロセスです。 |
| 目的 | 予算超過やリソース浪費を防ぎつつ、ビジネス価値に合わせた投資判断を迅速に行うこと。 |
| 主要なサイクル | Plan → Measure → Optimize → Report の4段階で継続的改善を実施します（※1）。 |
1.1 FinOps が必要になる背景
- 従量課金モデル：クラウドは使った分だけ支払うため、利用状況と費用が乖離しやすい。
- 部門横断のコスト所有権：開発チームは機能実装に集中したい一方で、財務側は予算管理を求める。このギャップを埋めるのが FinOps の役割です。
1.2 導入ステップ（初心者向け）
- ステークホルダーの合意
- CFO・CTO・DevLead が参加する「FinOps 委員会」を設置。
- 費用データの取得基盤構築
- 各クラウドベンダーが提供する Cost Management API（Azure、AWS、GCP）を統合し、毎日自動でデータを取得します。
- 可視化と KPI 設定
- 「コスト可視化率」「予算遵守率」などの指標をダッシュボードに表示（例：Grafana + Prometheus）。
- 最適化アクションの実行
- 予約インスタンス・スポット活用、リソースサイジング、不要リソース削除を定期的に行う。
ポイント：FinOps は「一度やって終わり」ではなく、上記サイクルを 四半期ごと に回すことで継続的なコスト改善が実現します。
2️⃣ Azure AKS（Azure Kubernetes Service）でのコスト最適化ベストプラクティス
2.1 包括的監視と費用分析基盤の構築
| 項目 | 実装例 | 効果 |
|---|---|---|
| メトリクス収集 | az aks enable-addons -a monitoring --resource-group RG –-name myAKS で Container insights を有効化。 |
CPU・Memory のリアルタイム可視化、過剰使用の早期検知 |
| コストタグ付け | リソース作成時に --tags Environment=prod Team=backend App=order-service を指定。 |
部門・プロジェクト単位で費用配分が可能 |
| アラート設定 | Azure Monitor で「CPU 使用率 > 80% が 5 分連続」→メール/Teams 通知を作成。 | スケールアウトの自動トリガー化と過剰リソース防止 |
ポイント：監視データが可視化できれば、無駄なノードや Pod を即座に検出し、対策に移せます。
2.2 ノードプール設計とインスタンスタイプの選択
2.2.1 標準的なマネージドクラスター定義（正しい API）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
apiVersion: containerservice.azure.com/v2022-09-01 kind: ManagedCluster metadata: name: myAKS spec: location: japaneast agentPoolProfiles: - name: prod count: 3 vmSize: Standard_D4s_v3 # 安定したミッション・クリティカル向け osDiskSizeGB: 128 mode: System - name: batch-spot vmSize: Standard_D2s_v3 spotMaxPrice: 0.02 # スポット価格上限（USD/時間） enableAutoScaling: true minCount: 1 maxCount: 10 mode: User |
注意：
AzureManagedClusterは実在しないリソースです。上記は Azure の正式 API (Microsoft.ContainerService/managedClusters) に合わせた例です。
2.2.2 コスト削減効果の根拠
- Microsoft のベストプラクティスレポートでは、スポットノードをワークロードに組み込むことで平均 30‑40% の費用削減が確認されています（※2）。
- ただし 「最大 40% 削減」 といった具体的数値は、対象環境・利用率によって変動するため、必ず自社データで検証してください。
2.3 動的サイジングと自動スケーリングの組み合わせ
| コンポーネント | 主な役割 |
|---|---|
| Cluster Autoscaler | ノード数を需要に応じて増減。--scale-down-delay-after-add=5m でスパイク後の過剰ノードを速やかに削除。 |
| Horizontal Pod Autoscaler (HPA) | 同一デプロイメント内の Pod レプリカ数を CPU/Memory 利用率で調整（例：目標利用率 60%）。 |
| Vertical Pod Autoscaler (VPA)（オプション） | Pod の リクエスト を実測使用量に合わせて自動更新し、ノードのリソース効率を向上。 |
実装例：HPA
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-deployment minReplicas: 2 maxReplicas: 15 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 # CPU が 60% を超えたらスケールアウト |
ポイント：Cluster Autoscaler と HPA の連携により、ノードレベルと Pod レベルの両方で過剰供給を防げます。実運用では「スパイク後5分以内にノードが削除される」ことが目安です（※3）。
3️⃣ AWS EKS におけるコスト削減ベストプラクティス
3.1 Savings Plans と Reserved Instance の活用戦略
| プラン | 特徴 | 推奨シナリオ |
|---|---|---|
| Compute Savings Plans | インスタンスタイプ・リージョン横断で最大 30% 割引（※4）。 | 変動が大きい汎用ワークロード全般。 |
| EC2 Reserved Instances (1 年/3 年) | 同一インスタンスファミリに対して最大 40% 割引（※5）。 | 常時稼働が 95% 以上のデータベースや認証サーバーなど。 |
手順例
- Cost Explorer で過去 3 ヶ月の EC2 使用率を確認。
On-Demandが 70%以上 のt3.medium系は Compute Savings Plans に集約。- 稼働時間が 95% 超えるノードは 1 年 RI（All‑Upfront） を購入し、残りは Savings Plans に割り当てる。
根拠：AWS の公式ドキュメントに基づく割引率です（※4, ※5）。実際の削減効果は利用パターン次第で変動します。
3.2 Auto Scaling と安全なダウンスケーリング
CloudWatch アラーム例（Target Tracking）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "AlarmName": "EKS-CPU-Low", "MetricName": "CPUUtilization", "Namespace": "AWS/EKS", "Statistic": "Average", "Period": 300, "EvaluationPeriods": 2, "Threshold": 20, "ComparisonOperator": "LessThanThreshold", "AlarmActions": [ "arn:aws:sns:us-east-1:123456789012:EKS-ScaleIn" ] } |
- アラームが発火すると、Lambda が
eks:update-nodegroup-configを呼び出し 最小ノード数を 1 に縮小。 - 同時に Target Tracking Scaling Policy（CPU < 20%）で自動的にインスタンスを削減します。
ポイント：過度な速さでダウンスケールすると Pod の再スケジューリングが遅延するため、評価期間（2 回）と閾値（20%）は保守的に設定してください。
3.3 費用可視化ツールの統合
| ツール | 主な機能 |
|---|---|
| kubecost | Pod/Namespace 単位のコストメトリクス (cpuCost, memoryCost) を取得。 |
| AWS Cost Explorer | サービス別・タグ別に費用を集計。 |
| CloudWatch | カスタムメトリクスでスケールイン/アウト条件を可視化。 |
kubecostの UI で「Top 5 Costly Pods」を抽出し、リソースリミットを削減すると 約 10% の月次コスト低減 が報告されています（※6）。
4️⃣ Google GKE における最新コスト最適化ガイド（2024/09版）
4.1 Node Autoscaler と Preemptible VM（Spot）の組み合わせ
| 特徴 | Autopilot | Standard (Node Pool) |
|---|---|---|
| 管理対象範囲 | Pod レベルの自動リソース最適化 | ノードレベルの手動設定が必要 |
| コストモデル | 使用した CPU/Memory に対して従量課金 | VM SKU + ディスク課金 |
| Spot 対応 | 非対応 | 対応（Node Pool の spot: true） |
NodePool 定義例（標準モード）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerNodePool metadata: name: batch-spot-pool spec: autoscaling: enabled: true minNodeCount: 0 maxNodeCount: 20 config: machineType: e2-medium spot: true # Preemptible (Spot) ノードを有効化 |
根拠：Google の公式ベストプラクティスでは、Preemptible VM による割引は 最大 80%（※7）。ただし短時間で停止するリスクがあるため、バッチ処理や開発環境に限定します。
4.2 VPA と HPA の併用によるリクエスト最適化
VPA 定義例
|
1 2 3 4 5 6 7 8 9 10 11 12 |
apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: api-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: api-deployment updatePolicy: updateMode: Auto # 自動でリクエストを更新 |
- 効果：VPA が
cpuリクエストを500m → 350mに削減した結果、同一ノードに配置できる Pod 数が約 1.3 倍増加。実運用で月次コスト 12% 削減 が確認されています（※8）。
HPA と併せた例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-deployment minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 65 |
ポイント：VPA がリクエストを最適化し、HPA がレプリカ数で負荷変動に対応することで「リソース過剰供給」→「コスト増大」のサイクルを断ち切ります。
4.3 スポットノード向けスケジューラ設定
|
1 2 3 4 5 6 7 8 |
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: low-priority-spot value: 1000 # 標準より低い優先度 globalDefault: false description: "Spot 用ワークロードの低優先度クラス" |
Pod 定義に priorityClassName: low-priority-spot と tolerations: を付与し、スポットノードプールの taint (spot:true:NoSchedule) にマッチさせます。これにより、Spot ノードが停止した際に重要な Pod が自動的に標準ノードへ再スケジュールされます。
期待効果：Google のアーキテクチャベストプラクティス（2024/09）では、上記構成で 約 30% のコスト削減が報告されています（※9）。
5️⃣ セルフホステッド Kubernetes と共通のコスト最適化戦略
5.1 代表的な 9 つの施策
| # | 施策 | 簡単な実装例 |
|---|---|---|
| 1 | 未使用リソースの削除 | kubectl top pods --no-headers | awk '$3==0{print $1}' | xargs -r kubectl delete pod |
| 2 | クラスタ統合 | 複数ステージ環境を 1 クラスタに集約し、ノード総数を削減。 |
| 3 | Cluster Autoscaler の均等配置 | --balance-similar-node-groups=true オプションで同種ノードのバランス調整。 |
| 4 | Namespace と ResourceQuota | kubectl apply -f quota.yaml（例：CPU 2000m、Memory 8Gi） |
| 5 | ハードウェア省電力設定 | BIOS の C‑state 有効化、Turbo Boost 無効化でサーバー消費電力を約 5% 減。 |
| 6 | Pod リクエスト/リミットの最適化 | VPA を導入し自動調整。 |
| 7 | イメージサイズ削減 | マルチステージ Dockerfile → 最終イメージが 150 MB 以下に収まる例が多い。 |
| 8 | ログ・メトリクス保持期間の短縮 | Prometheus 起動オプション --storage.tsdb.retention.time=30d |
| 9 | 定期的なレビューサイクル | 月次で費用レポートを作成し、改善案をチケット化。 |
5.2 推奨ツールと主要メトリクス
| ツール | 用途 | 主なメトリクス |
|---|---|---|
| kubecost | Pod/Namespace 単位の費用可視化 | cpuCost, memoryCost, pvCost |
| Prometheus + Grafana | リアルタイムリソース監視 | node_cpu_seconds_total, container_memory_working_set_bytes |
| Grafana Dashboard (Cost Overview) | コスト可視化率・予算遵守率を一目で把握 | cost_by_namespace, budget_compliance_ratio |
実装例：Grafana の「Top 5 Costly Pods」パネルに
kubecost_pod_total_costを表示し、閾値（例：$200/日）超過時に Slack 通知を設定するだけで即座に対策が可能です。
5.3 月次／四半期レビューと改善フロー
- データ収集（月初）
- 各ツールから
cost_by_namespace.csvとresource_utilization.jsonをエクスポート。 | - 分析（第1週）
- 可視化率 < 90% → タグ付け漏れ洗い出し。
CPU/Memory 使用率 < 70% のノードはスケールダウン候補。 | - 改善提案（第2週）
- 「未使用 Pod 削除」「Spot ノード比率 30%」など具体的アクションをテンプレート化。 |
- 実装・テスト（第3週）
- Terraform / Helm による設定変更をステージングでデプロイし、ベンチマーク結果を比較。 |
- レビュー & 次サイクル計画（第4週）
- 予算実績例：
予算 10,000 USD → 実績 8,500 USD、差異 15%を経営層に報告し、次四半期の目標を設定。 |
ポイント：このサイクルを繰り返すことで「一時的な削減」ではなく、組織全体に根付いた 継続的コスト最適化文化 が醸成されます。
6️⃣ まとめ
| 項目 | 重要ポイント |
|---|---|
| FinOps | 財務とエンジニアが協働し、Plan‑Measure‑Optimize のサイクルで費用を見える化・最適化。 |
| AKS | スポットノード＋自動スケーリングで 30 % 前後の削減効果（※2）。正しい API 定義とタグ付けが鍵。 |
| EKS | Savings Plans と RI のハイブリッド活用、CloudWatch アラートで安全なダウンスケールを実現。 |
| GKE | Preemptible VM + VPA/HPA 併用で最大 30 % 削減（※9）。PriorityClass でスポットノードのリスク管理。 |
| セルフホステッド | 未使用リソース削除、Cluster Autoscaler の均等配置、kubecost 等で可視化し、定期レビューを徹底。 |
次にすべきこと：自社環境の「費用データ取得」→「KPI 設定」→「改善サイクル開始」の3ステップから始めましょう。
参考文献・出典
- FinOps Foundation, “The FinOps Framework”, 2023.
- Microsoft Docs, “Optimize AKS costs with Spot nodes”, 2024年6月, https://learn.microsoft.com/azure/aks/cost-optimization (閲覧日: 2024‑11‑02).
- Azure Architecture Center, “Autoscaling best practices for AKS”, 2023年9月.
- AWS Documentation, “Savings Plans Overview”, 2024年5月, https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plan.html.
- AWS Documentation, “Reserved Instances”, 2024年3月, https://aws.amazon.com/ec2/pricing/reserved-instances/.
- kubecost Blog, “How to reduce Kubernetes costs by 10% with pod-level insights”, 2023年11月.
- Google Cloud Docs, “Preemptible VM pricing”, 2024年1月, https://cloud.google.com/compute/docs/instances/preemptible.
- Google Cloud Blog, “Vertical Pod Autoscaler reduces GKE costs by up to 12%”, 2023年8月.
- Google Cloud Architecture Center, “Cost optimization best practices for GKE” (2024/09版), https://cloud.google.com/architecture/gke-cost-optimization.
スポンサードリンク