会社情報
採用情報
お問い合わせ
Article

電気代を考慮したサーバー室の運用改善

高田晃太郎
電気代を考慮したサーバー室の運用改善

企業の電気代は直近数年で上昇が続き、データセンター関連の電力消費は世界全体の約1〜2%を占めると報告されています¹。さらに、業界調査では施設電力の30〜40%を冷却が占めるケースが多く²、Uptime Instituteの年次調査でも平均PUEは1.8と報告されています³。多くの組織で、電気代がIT予算に食い込む速度はハード更新周期より速く、サーバー室の運用改善は「運用を変えるだけで翌月の請求書が変わる」数少ない領域です。設備投資より先に運用を磨くことは、リードタイムが短く、ROIが高い意思決定になり得ます。この記事では、サーバー室の電気代削減を目的に、可視化から施策、検証、ガバナンスまでを一気通貫で整理し、参考となる数式や実装例を提示します。

PUEを起点にした「見える化」と指標設計

電気代を抑えるサーバー室運用改善では、計測と基準線づくりが出発点です。PUEは「施設全体の消費電力 ÷ IT機器の消費電力」で定義され⁴、同一のIT負荷でPUEが1.8から1.6に改善すると、総消費電力は定義上おおむね**約11%**低下します⁴。現場で最初に行うべきは、IT負荷と施設負荷を分けて連続計測し、PUEとデマンド（最大需要電力。契約電力や基本料金に影響）を時系列化することです。UPSやラックPDUのSNMP（機器監視の標準プロトコル）、サーバーのIPMI（管理用標準インターフェース）、空調のBAS/BACnet/Modbus（ビル設備向け制御プロトコル）を束ね、15秒〜1分間隔で収集すると、冷却制御やワークロード変更に対する応答が読み解きやすくなります。

計測基盤は、既存の監視に寄り添って拡張するのが現実的です。PrometheusやInfluxDB、Grafanaを用いれば、最小限の構成でPUEやEUI（床面積あたりの電力使用量。kWh/㎡・月）を可視化できます。以下はUPSとPDUをSNMPで収集するPrometheusのジョブ定義の一例です。ポイントはメトリクスの命名をPUE計算に合わせておくこと、そして時刻同期をNTPで厳密化することです。

scrape_configs:
  - job_name: 'ups'
    scrape_interval: 30s
    static_configs:
      - targets: ['10.0.10.5']
    metrics_path: /snmp
    params:
      module: ["apcups"]
  - job_name: 'pdu'
    scrape_interval: 30s
    static_configs:
      - targets: ['10.0.20.11','10.0.20.12']
    metrics_path: /snmp
    params:
      module: ["rfc1628"]

可視化の肝は、IT電力と施設電力を同一時間窓で割ってPUEを出すことです。PromQLなら関数化してダッシュボードの再利用性を高められます。外気温や時間帯別料金（時間帯で単価が変わる電気料金）と重ねると、対策の優先度が見えてきます。

pue:avg5m =
  sum_over_time(facility_power_kw[5m]) / sum_over_time(it_power_kw[5m])

サーバー室ならではの制約として、オフィス空調と共用のケースがあり、施設電力の分離が難しいことがあります。この場合、短期間だけクランプメータで専用回路を直接測るか、電気工事のタイミングで分岐ごとのスマートメータを追加し、以後は推定モデルで補間するのが現実解です。いずれにしても、最初の2週間で「平日/休日」「日中/深夜」「外気温の高低」を含むデータを集めれば、十分に信頼できる基準線が作れます。

IPMIでIT電力を収集し、タイムシリーズに送る

多くの筐体はBMC経由のIPMI（管理インターフェース）で瞬時電力が取得できます。Pythonで収集しInfluxDBに書き込む最小サンプルを示します。失敗時は指数バックオフし、BMCの過負荷を避けるのが運用のコツです。

import subprocess, time, json
from datetime import datetime
from influxdb import InfluxDBClient

HOSTS = ["srv01","srv02","srv03"]
client = InfluxDBClient(host='127.0.0.1', port=8086, database='power')

def ipmi_watts(host):
    out = subprocess.check_output([
        "ipmitool","-I","lanplus","-H",host,"-U","monitor","-P","secret",
        "dcmi","power","reading"
    ], timeout=3).decode()
    for line in out.splitlines():
        if "Instantaneous power reading" in line:
            return float(line.split(':')[-1].split()[0])
    return None

while True:
    points = []
    ts = datetime.utcnow().isoformat()
    for h in HOSTS:
        try:
            w = ipmi_watts(h)
            if w:
                points.append({
                    "measurement":"it_power",
                    "tags":{"host":h},
                    "time":ts,
                    "fields":{"watts":w}
                })
        except Exception as e:
            continue
    if points:
        client.write_points(points, time_precision='s')
    time.sleep(15)

冷却・気流とIT側制御を同時に動かす運用施策

計測が整ったら、冷却とITの両輪でサーバー室の運用改善を進めます。複数の業界レポートでは、サーバー吸気温を1℃引き上げると冷却エネルギーが2〜4%低下する傾向が報告されており²、ASHRAE TC 9.9（データセンター環境の国際ガイドライン）の推奨範囲内（推奨は概ね18〜27℃）での設定変更は即効性の高い打ち手です⁵。例えば、吸気温を22℃から25℃へ段階的に引き上げ、ホット/コールドアイルの簡易封じ込めを併用すると、PUEのスパイクが縮小し、日中ピークの電力単価が高い時間帯の施設電力を削減できるケースが見られます。温度の変更は1週間単位で観察し、サーバーのCorrectable ECCやファン回転数の増加が異常検知のトリガーにならないかを並行監視すると、品質と省エネの両立が図れます。

IT側のレバーはさらに多彩です。CPUの周波数スケーリングとC-stateの有効化、夜間へのバッチ移行、クラスタの電力キャップ、アイドルノードの計画停止、ストレージのスピンダウンなど、システム管理に直結します。以下は、クラスタ全体に緩い電力キャップをかけるコマンドの例です。急に絞るのではなく、アプリケーションのSLAに応じて時間帯と上限値を分けるのが現実的です。

#!/usr/bin/env bash
for h in srv01 srv02 srv03; do
  ipmitool -I lanplus -H "$h" -U monitor -P secret \
    dcmi power set_limit 180 300 || echo "cap failed on $h"
done

ワークロードの時間帯移行は、料金メニューの違いを直撃します。時間帯別料金のオプションで深夜が安い場合、夜間にCPU使用率が上がるようジョブをずらすだけで、同じkWhでも請求額が変わります。Kubernetesを使うなら、CronJobとPodPriorityで日中の低優先度ジョブを抑制し、夜間に解放します。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-batch
spec:
  schedule: "0 1 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          priorityClassName: batch-low
          containers:
          - name: etl
            image: registry/etl:stable
            resources:
              limits:
                cpu: "8"
                memory: 16Gi
          restartPolicy: OnFailure

冷却側では、送風機の無駄な全開運転を避け、差圧や吸気温に対するPI制御（比例・積分制御）に切り替えるのが王道です。BASと連携できるなら、Modbus/TCPで設定温度を昼は24.5℃、夜は26℃のように微調整します。以下はModbusで設定温度を更新するPythonの断片です。実機のレジスタ構成は設備ベンダー仕様に従ってください。

from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('10.0.30.5', port=502)
if client.connect():
    # holding register 40001 に 24.5℃を10倍精度で書き込む例
    client.write_register(address=0, value=int(24.5*10))
    client.close()

ガワを変えずに効く「気流整流」

ラックブランクパネルの徹底、床下のケーブル開口ふさぎ、吸気側の空気ショートカット抑止は、どれも安価で効きます。可視化後に熱画像と温度センサの分布を重ねると、特定ラックの吸気が外れ値になっていることがよくあります。そこに集中投資せず、まずは「空気のバイパスを塞ぐ」「吸気に向けて風を押す」を繰り返すだけで、送風機に無理をさせずに温度を引き上げられる余白が生まれます。

成果数値の出し方とROIの算定

システム管理の説得力は、成果数値で決まります。例えばIT電力が平均60kW、PUEが1.8のサーバー室があるとします。施設電力は108kWで、1カ月（720時間）に77,760kWhを消費します。吸気温の引き上げと気流改善でPUEを1.6に下げられれば、施設電力は96kWとなり、月間で8,640kWhの削減です。単価が25円/kWhなら、電気代は216,000円/月下がります。排出係数は各社の実態により異なりますが、例として0.45kg-CO2/kWhと仮定すれば、月3.9t-CO2の削減に相当します。これに加え、夜間シフトと電力キャップでIT電力を5%抑えられれば、さらに3,600kWhの上積みが見込めます。重要なのは、これらが設備の更新を伴わない運用改善だけで狙える打ち手である点です。

財務的な評価では、初期費用の小さい順に着手し、翌月からキャッシュフローが改善するものを選ぶのが鉄則です。ブランクパネルや温度センサの追加、監視基盤の整備、設定温度の見直し、優先度制御の導入は、いずれも数十万円規模で始められ、年換算で数百万円の電気代を圧縮できるポテンシャルがあります。クラウド移行と比較した場合も、オンプレのサーバー室でPUEを1.8から1.5に近づけられるなら、ハード更新の延命効果と合わせて総保有コストの低下が現実的です。意思決定の裏付けとして、以下の簡易スクリプトで削減電力量、コスト、排出量を一括計算しておくと、社内の合意形成が速くなります。

def savings(it_kw=60, pue_before=1.8, pue_after=1.6, hours=720, unit=25, ef=0.45):
    facility_before = it_kw * pue_before
    facility_after  = it_kw * pue_after
    kwh = (facility_before - facility_after) * hours
    jpy = kwh * unit
    tco2 = kwh * ef / 1000
    return {"kwh":kwh, "jpy":jpy, "tco2":tco2}
print(savings())

成果数値は、ダッシュボードに「前月比・前年同月比・外気温補正後」の三つの視点で並べると、季節要因を排除した議論ができます。さらに、時間帯別料金を適用している場合は、kWh削減と請求額削減を分けて示すと、運用変更の価値が明瞭になります。時間帯単価の高い時間帯を狙って削ると、請求額の下がり幅がkWh削減率を上回る（例えば1.3倍程度になる）事例もあります。社内資料としては、詳説を電力監視の実践ガイドに、SRE観点の運用をGreen SRE入門に、財務インパクトの整理をITコスト最適化フレームに紐づけると、関係者が横断的に理解できます。

失敗を防ぐガバナンス、SLA、フェイルセーフ

サーバー室の運用改善は、電気代だけでなく可用性と背中合わせです。変更は小さく、観察は長く、ロールバックは即座に、を基本に据えます。特に温度の引き上げは、機器ごとのマージンが異なるため、同じ25℃設定でも局所的にホットスポットが出ます。吸気温センサを各ラックの上中下に置き、最大値で判断する文化を育てると、トラブルの未然防止に寄与します。IT側では、SLAを満たす範囲で電力キャップやスロットリングを適用し、突発トラフィックや月末バッチに備えた例外ウィンドウを設けると、性能劣化のクレームを防げます。計測のメタデータとして、どの変更がいつ適用されたかをタイムラインに刻むことも重要です。変更イベントを監視へ送るだけで、因果の推定が一気に容易になります。

最後に、しきい値を越えたら自動的に保守的な設定へ戻す仕掛けを用意します。AlertmanagerやOpsgenieなどと連携し、PUEの急上昇や吸気温の逸脱、CRCエラーの増加をトリガーに、キャップ解除や設定温度の一時引き下げを行います。以下はPrometheusのアラート例です。現場の閾値は、実測から丁寧に合わせ込んでください。

groups:
- name: power.room
  rules:
  - alert: HighInletTemp
    expr: max_over_time(inlet_temp_c[5m]) > 27
    for: 10m
    labels:
      severity: critical
    annotations:
      runbook: "set cooling setpoint -1C and lift power cap"

ロールバックの実装は各社で異なりますが、Ansibleで吸気温の一時引き下げとクラスタの電力キャップ解除を束ねておくと、一次対応が整然と進みます。現場に任せきりにせず、誰が見ても同じ動作をする自動化を「最後の保険」に据えることが、システム管理の成熟度そのものです。

BCP視点での電力最適化

電気代の削減と、計画停電や非常時の耐性は両立します。UPSの負荷率を下げることはバックアップ時間の延伸に直結し、分散ジョブの夜間集中は、非常時に優先停止すべき非本質ワークロードの棚卸しにもなります。運用改善は、コストのためだけではなく、レジリエンスのための投資でもあるのです。

まとめ：次の請求書から変える

電気代を考慮したサーバー室の運用改善は、計測、冷却と気流、IT制御、検証、ガバナンスが一体となってこそ成果数値に変わります。PUEの連続監視や吸気温の段階的引き上げ、ワークロードの夜間移行と電力キャップ、そしてアラート駆動のフェイルセーフを組み合わせれば、月8,640kWh規模の削減も十分に視野に入ります。次のアクションとして、まず2週間の基準線計測を始め、ダッシュボードにPUEと時間帯別料金、吸気温を並べてください。その上で、吸気温を**+1℃**だけ引き上げ、夜間に移せるジョブを一つ選び、軽い電力キャップを適用してみましょう。サーバー室の運用改善は、思っているよりずっと速く、賢く進められます。

参考文献

  1. 日立総合計画研究所. IEAの取りまとめによる2024年のデータセンター電力需要（世界全体の約1.5%）. https://www.hitachi-hri.com/research/contribution/vol20_01_0616_4.html
  2. Indvstrvs. Raise Data Center Temperature and Reduce Emissions（冷却エネルギー比率、温度引き上げ効果）. https://indvstrvs.org/raise-data-center-temperature-and-reduce-emissions/
  3. DataCenterKnowledge. Uptime Institute: The Average PUE is 1.8. https://www.datacenterknowledge.com/uptime/uptime-institute-the-average-pue-is-1-8
  4. Vertiv. What Is PUE (Power Usage Effectiveness) and What Does It Measure?（PUEの定義）. https://www.vertiv.com/en-asia/about/news-and-insights/articles/educational-articles/what-is-pue-power-usage-effectiveness-and-what-does-it-measure/
  5. MC Digital Realty. データセンターの適正温度（ASHRAE TC 9.9推奨範囲）. https://www.mc-digitalrealty.com/blog/21