省エネ設定でランニングコストを削減

複数の調査では、企業のクラウド支出のうち約30%前後が未使用・過剰プロビジョニングに起因する無駄と報告されています¹²。加えて、電力価格の上昇がP/Lへの圧力を強めています⁵。サーバーのアイドル電力はケースによりピーク時の50%以上に達し得るという報告もあり³⁴、負荷に見合わないリソース配分はコストとエネルギーの両方に跳ね返ります。基本的な省エネ設定とワークロード整流だけでも、SLO（Service Level Objective：サービスの目標品質）を守りながらランニングコストの圧縮が期待できます。鍵は、パフォーマンスと電力の両面を測り、設定を“適切に”効かせることです。

省エネ設定がP/Lに効く理由とKPIの設計

省エネを“節約術”としてではなく、技術的合理性に基づく性能/ワットの最適化と捉えると判断が明快になります。サーバーとランタイムは一定のアイドル電力を消費するため、アイドル領域を削る「自動化」と、ピークの形を整える「スムージング」が直接のコスト削減レバーになります。SLOを保つ前提で、目的変数をコスト/1,000リクエストやWh/リクエスト（1回の処理あたりの電力量）に置き換えると、意思決定は感覚からデータ駆動に切り替わります。実務では、ベースラインとしてCPU/メモリ使用率の分布、p95/99レイテンシ（95/99パーセンタイル）、エラー率、インスタンス時間、ストレージIO、そして月次コストを同一ダッシュボードで見える化し、設定変更前後で分散の変化を見ることが重要です。平均値だけではアイドルの削減やスパイク耐性の効果が判別できないため、分位点とヒストグラムでの比較が効きます。

成果数値は短期と中長期に分けて設計します。短期はコンピュート時間とネットワーク転送料の削減率、ストレージ階層化によるGB単価の低減、キャッシュヒット率の改善といった直接効果を追います。中長期はデプロイ頻度や障害復旧時間の改善など、設定の自動化がもたらす運用コストの逓減です。例えば、HPA（Horizontal Pod Autoscaler：Kubernetesの自動水平スケール）によるスケール最適化と、オブジェクトストレージのライフサイクル設定の組み合わせは、計算資源とストレージの両面で効く典型例です。具体的な削減幅はワークロードとトラフィック特性に依存するため、前述のKPIで前後比較を行い、SLO内での最適点を探ります。

即効性の高いインフラ層の省エネ設定

まずは台数とサイズ、そして稼働時間を動的に合わせるだけで効果が出ます。クラウドでの自動スケールとスケジールドダウン、そしてコンテナのリクエスト/リミットの適正化が柱です。TerraformなどのIaC（Infrastructure as Code：インフラ設定のコード化）で定義し、設定の再現性を確保することが継続改善の前提になります。

# 例1: TerraformでASGをターゲット追従スケールに設定（AWS）
terraform {
  required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } }
}

provider "aws" { region = var.region }

resource "aws_launch_template" "app" {
  name_prefix   = "app-lt-"
  image_id      = var.ami
  instance_type = var.instance_type
  monitoring { enabled = true }
}

resource "aws_autoscaling_group" "app" {
  name                      = "app-asg"
  desired_capacity          = 2
  max_size                  = 20
  min_size                  = 2
  vpc_zone_identifier       = var.subnets
  health_check_type         = "EC2"
  launch_template { id = aws_launch_template.app.id version = "$Latest" }
  target_group_arns         = [var.tg_arn]
}

resource "aws_autoscaling_policy" "cpu_tgt" {
  name                   = "cpu-50"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" }
    target_value = 50
  }
}

resource "aws_autoscaling_schedule" "night_down" {
  scheduled_action_name  = "night-down"
  autoscaling_group_name = aws_autoscaling_group.app.name
  recurrence             = "0 22 * * MON-FRI"  # 平日22時に縮退
  min_size               = 1
  max_size               = 5
  desired_capacity       = 1
}

コンテナ基盤では過大なリクエスト設定がアイドル電力を助長します。HPAでトラフィックに追従させつつ、リクエスト/リミットを守ると、ノードの密度が上がりクラスタオートスケーラの縮退が働きます⁴。

# 例2: KubernetesのHPAと適正なリソース指定
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels: { app: web }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
      - name: web
        image: ghcr.io/example/web:v1
        resources:
          requests: { cpu: "200m", memory: "256Mi" }
          limits:   { cpu: "800m", memory: "512Mi" }
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

オンプレやエッジではCPUガバナ（CPU周波数制御）を状況で切り替えるとワット単位で効きます。安全側に倒すため、負荷しきい値と温度、エラーを監視して復帰できるようにしておきます³。

#!/usr/bin/env bash
# 例3: 低負荷時にpowersave、負荷上昇でperformanceへ自動復帰
set -euo pipefail
log() { echo "[$(date --iso-8601=seconds)] $*"; }
get_load() { awk '{print $1}' /proc/loadavg; }
get_temp() { sensors 2>/dev/null | awk '/Package id 0:/ {print int($4)}' | tr -d '+' | head -1; }

target="powersave"
load=$(get_load); temp=$(get_temp || echo 50)
if (( $(echo "$load < 0.5" | bc -l) )) && (( temp < 75 )); then
  target="powersave"
else
  target="performance"
fi

for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
  if [[ -w "$c" ]]; then echo "$target" | sudo tee "$c" >/dev/null; else log "skip $c"; fi
done
log "set governor=$target (load=$load, temp=${temp:-na})"

ストレージはアクセス頻度の分布に合わせて階層化します。オブジェクトストレージでのライフサイクルルールは“設定して終わり”の代表格で、リテンション方針と監査要件に適合させれば、冷温データの比率次第で大幅な削減につながることが多いです⁶。

アプリケーション層で効かせるスロットリングとジョブ設計

アプリケーション側の無駄は、瞬間的なバーストと低優先度ジョブの競合が生みます。処理をスロットリングしてバックグラウンドへ逃がし、オフピークへ平準化するだけで、ピーク瞬間のプロビジョニングを抑えられます。Node.jsでのワーカー並列数の制御とキュー、Pythonでのスケジューリングを組み合わせるのが実装しやすいです。

// 例4: Node.jsでバックグラウンド処理をスロットリング
import PQueue from 'p-queue';
import fetch from 'node-fetch';

const queue = new PQueue({ concurrency: Number(process.env.WORKER_CONCURRENCY || 8) });

async function processTask(task) {
  const started = Date.now();
  const res = await fetch(task.url, { timeout: 5000 });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const ms = Date.now() - started;
  if (ms > 1000) console.warn('slow-task', { ms });
}

export async function enqueue(tasks) {
  for (const t of tasks) queue.add(() => processTask(t));
  await queue.onIdle();
}

夜間に移せるジョブはスケジューラで強制的にオフピークへ回します。SLO影響のない再計算やレポート生成、キャッシュのプリウォームなどが対象です。スケジュールは祝日やリージョン差も加味して、設定をコードで管理します。

# 例5: Python APSchedulerでオフピーク実行に寄せる
from apscheduler.schedulers.background import BackgroundScheduler
from datetime import datetime
import os

sched = BackgroundScheduler(timezone=os.getenv('TZ', 'UTC'))

def rebuild_reports():
    start = datetime.now()
    # 重いI/Oや再集計処理
    # ...
    print('rebuild done', (datetime.now() - start).total_seconds())

sched.add_job(rebuild_reports, 'cron', hour='2-5', day_of_week='mon-fri')
sched.start()

言語ランタイムのスレッドとガーベジコレクションも省エネに直結します。GoではGOMAXPROCSを制御してスレッド過剰生成を避け、待機が多いIO型ならプロセス数を抑えたほうが電力効率が上がることが多いです。

// 例6: GoでCPU利用の上限を制御して過剰スレッドを回避
package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "runtime"
    "time"
    "strconv"
    "os/signal"
)

func max(a, b int) int {
    if a > b { return a }
    return b
}

func main() {
    if p := os.Getenv("GOMAXPROCS"); p != "" {
        if n, err := strconv.Atoi(p); err == nil { runtime.GOMAXPROCS(n) }
    } else {
        runtime.GOMAXPROCS(max(1, runtime.NumCPU()-1)) // 1コア余らせてスパイク吸収
    }
    srv := &http.Server{ Addr: ":8080", Handler: http.DefaultServeMux }
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("ok")) })

    go func() {
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) }
    }()

    c := make(chan os.Signal, 1)
    signal.Notify(c, os.Interrupt)
    <-c
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    _ = srv.Shutdown(ctx)
}

キャッシュは最も安いリソースです。アプリ側のETagやCache-Controlを整備し、エッジ/CDNのTTL（Time To Live：キャッシュ有効期間）と一致させると送信バイトとオリジンCPUが同時に下がります。設計のポイントは、命中すべきものが必ず命中し、無効化が確実に届くことです。

計測・検証・継続改善で成果数値を定着させる

省エネ設定は設定して終わりではなく、実データで回し続ける運用が価値を生みます。メトリクスはコスト、パフォーマンス、環境影響の三位一体で眺めます。Prometheusを使うなら、CPUスロットリングとレイテンシ、リクエスト数、そして外部のコスト指標を同じパネルに置くと相関が見やすくなります。

# 例7: スロットリングとレイテンシ、リクエスト単価を同時可視化
sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
quantile_over_time(0.95, histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)))
sum(rate(http_requests_total[5m]))
# 外部指標: cloud_cost_usd_total はExporterで取り込み
sum(rate(cloud_cost_usd_total[1h])) / sum(increase(http_requests_total[1h]))

ベンチマークは本番に近い形で、設定変更の前後比較を行います。HPAの閾値やワーカー並列、キャッシュTTLなどを1項目ずつ変更し、同一期間・同一負荷・同一指標で差分を取るのが基本です。結果はコンピュート時間、送信バイト、総コスト、CO2e/リクエスト（推計）に集約すると意思決定が早くなります。削減幅が月間で大きいほど、設定・検証・計測の実装コストは短期間で回収しやすくなります。

ROIは削減額と実装コスト、リスクの三点で評価します。例えば、月額100万円のワークロードで10%削減できたと仮定すると月10万円の改善です。初期工数60時間、時給1.5万円だと投資は90万円、回収は約9カ月となります。これを短縮するには、IaCとパイプラインに省エネ設定の型を組み込み、各プロダクトに横展開できるよう共通モジュール化するのが効果的です。TerraformモジュールとKubernetesのベースマニフェスト、CIでの自動検証をテンプレート化すれば、以降の追加コストは小さくなります。

最後に、失敗しがちなポイントを挙げます。リクエスト/リミットのゼロ設定や、HPAの無制限スケールで逆にノード増殖が起きるケース、キャッシュの無効化経路が整っておらず整合性のために微妙なバーストが常に発生するケース、データ階層化で誤ってホットデータを冷温に落としてレイテンシを悪化させるケースなどです。これらはいずれも計測とリカバリ設計で回避できます。フェイルセーフに倒す、ローリングで小さく試す、メトリクスとログで確実に見える化する。この三点が実務の勘所です。

まとめ：SLOを守りつつ、数字で省エネを積み上げる

省エネ設定の目的は、単に節約することではなく、事業に資源を振り向ける余力を生むことです。今日からできる第一歩として、ベースラインのダッシュボードを整え、HPAとジョブのスケジューリングを見直し、IaCで設定をコード化してください。次に、削減率、p95レイテンシ、コスト/1,000リクエスト、CO2e/リクエストの四つを“成果数値”として四半期で追い、会話を数字中心に変えましょう。もし最初の改善が思うように出なくても、計測と設定の粒度を一段細かくするだけで道は開きます。どこから着手するのが自社にとって最短か、今のダッシュボードで十分に判断できますか。迷いがあるなら、まずは最もアイドルの長いワークロードから、設定の型を小さく試してみましょう。

参考文献

ZDNet Japan. クラウド支出の無駄は約35%—RightScale調査. https://japan.zdnet.com/article/35092503/#:~:text=%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E7%AE%A1%E7%90%86%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AERightScale%E3%81%AB%E3%82%88%E3%82%8B%E3%81%A8%E3%80%81%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%AE%E9%81%8E%E5%89%B0%E3%81%AA%E3%83%97%E3%83%AD%E3%83%93%E3%82%B8%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%82%84%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%8C%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%81%93%20%E3%81%A8%E3%81%8B%E3%82%89%E3%80%81%E3%81%8A%E3%81%8A%E3%82%88%E3%81%9D35%EF%BC%85%E3%81%AE%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E6%94%AF%E5%87%BA%E3%81%8C%E7%84%A1%E9%A7%84%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E3%81%A8%E3%81%84%E3%81%86%E3%80%82
TechMonitor. A significant proportion of cloud spending is being wasted. https://www.techmonitor.ai/hardware/cloud/cloud-spending-wasted-oracle-computing-aws-azure#:~:text=But%20a%20significant%20proportion%20of,over%20budget
InfoQ（日本語）. サーバーの電力消費を理解する（PmaxとPidleの関係など）. https://www.infoq.com/jp/articles/power-consumption-servers/#:~:text=%E6%9C%80%E5%A4%A7%E6%80%A7%E8%83%BD%E6%99%82%E3%81%AE%E9%9B%BB%E5%8A%9B%E6%B6%88%E8%B2%BB%E9%87%8F%28Pmax%29%E3%81%8A%E3%82%88%E3%81%B3%E3%82%A2%E3%82%A4%E3%83%89%E3%83%AB%E7%8A%B6%E6%85%8B%E3%81%A7%E3%81%AE%E9%9B%BB%E5%8A%9B%E6%B6%88%E8%B2%BB%E9%87%8F%28Pidle%29%E3%81%8C%E3%82%8F%E3%81%8B%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8C%E3%81%B0%E3%80%81%E3%81%82%E3%82%8B%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B5%E5%88%A9%E7%94%A8%E7%8E%87%28n
ComputerWeekly. A waste of energy: Dealing with idle servers in the datacentre. https://www.computerweekly.com/feature/A-waste-of-energy-Dealing-with-idle-servers-in-the-datacentre#:~:text=The%20Uptime%20Institute%20estimated%20as,such%20as%20virtualisation%20largely%20plateaued
日経XTech. 電力高騰がデータセンター運営コストを押し上げる状況. https://xtech.nikkei.com/atcl/nxt/column/18/02096/063000007/#:~:text=2022%E5%B9%B4%E5%A4%8F%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%AEIT%E3%83%99%E3%83%B3%E3%83%80%E3%83%BC%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%99%E3%82%8B%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC%EF%BC%88DC%EF%BC%89%E9%96%A2%E9%80%A3%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%A7%E6%A8%99%E6%BA%96%E6%96%99%E9%87%91%E3%81%AE%E5%80%A4%E4%B8%8A%E3%81%92%E3%82%84%E3%80%81%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E4%BC%81%E6%A5%AD%E3%81%A8%E3%81%AE%E4%BE%A1%E6%A0%BC%E4%BA%A4%E6%B8%89%E3%81%8C%E5%A7%8B%E3%81%BE%E3%82%8B%E5%85%AC%E7%AE%97%E3%81%8C%E5%A4%A7%E3%81%8D%E3%81%84%E3%80%82%E8%A8%98%E9%8C%B2%E7%9A%84%E3%81%AA%E9%9B%BB%E5%8A%9B%E3%81%AE%20%E9%AB%98%E9%A8%B0%E3%81%8C%E9%81%8B%E5%96%B6%E3%82%B3%E3%82%B9%E3%83%88%E3%82%92%E6%8A%BC%E3%81%97%E4%B8%8A%E3%81%92%E3%80%81%E3%83%99%E3%83%B3%E3%83%80%E3%83%BC%E3%81%8C%E5%90%B8%E5%8F%8E%E3%81%A7%E3%81%8D%E3%82%8B%E9%99%90%E7%95%8C%E3%82%92%E8%B6%85%E3%81%88%E3%81%A4%E3%81%A4%E3%81%82%E3%82%8B%E3%81%8B%E3%82%89%E3%81%A0%E3%80%82
AWS. Optimize Amazon S3 storage costs（ストレージ階層化とライフサイクル管理）. https://aws.amazon.com/s3/cost-optimization/#:~:text=to%20optimize%20storage%20costs