今回はインフラ／サーバエンジニア向けに、数字に関する最初の一歩、コストに関する考え方について述べたいと思います。

数字関係とかコストなどと言うと、経営関係に近い感じや、難しそうな簿記とか、決算など収支に関する書類を思い浮かべるかもしれません。これらを理解すること自体はそれほど難易度の高いことではない（かもしれない）ので、ぜひお時間を見つけて挑戦していただきたいと思いますが、普段の仕事の中でも考え方次第で数字に絡める事ができる事もあります。まずはそういう考え方をする事に慣れておければ、応用次第では昨今の情勢などへの展開が柔軟に対応でき、エンジニアとしての幅を広げる事ができるかもしれません。

今回は、インフラ、サーバエンジニアの親しみやすそうな所として、データセンターに関連しそうな事柄を例に取り、積極的に数字に親しみが持てたらと思います。

コストの発生する場所を考えてみる。

サービスの妥当性を考えるときは、自社が契約する部分の外側にどれくらいのコストがかかっているのか正確でなくても理解するクセをつけておく事が望ましいでしょう。さて、データセンター関連でコストが発生しそうな場所は、次の表のようになります。

エンドユーザ
サービスに対してお金を支払う。

	センター	フロア	ラック	ファシリティ （回線、電源など）	サーバ （ミドルウェア、サービスアプリなど）	サービス 内容
人件費	センター維持に関する要員		管理、監視等の付加サービスに対応した要員	維持、管理、場合に寄っては工事要員	パッケージ開発、保守要員等	サービスシステム開発に関する要員
発生するコスト	資産関連（固定資産管理、維持に関するコスト⁠）⁠、サービス維持に関するコスト（センター内従業員（監視要員など⁠）⁠）		保守料金などがあれば	回線利用料、電源工事、供給契約、利用料金など	イニシャル、ランイング 保守、監視など	開発費用、商材等の仕入れや在庫など
主に負担する者	データセンター事業者		サービス提供事業者	サービス提供事業者またはデータセンター事業者	サービス提供事業者	ユーザ

データセンター事業者はこれらを包括してメニュー等を生成し、ユーザー側と契約します。
また、利用形態がハウジング等であれば、ユーザー側はサーバ等の機器調達費用等も発生します。

データセンター、フロア、ラック等の料金

ハウジングのようなサーバ機器を持ち込む形態を取る場合、データセンターに対して、ラックと電源、外部ネットワーク等の調達を期待します。

金額に関しては、筆者の知る限り指標となる相場的な情報があまりなく、金額も相当ばらけているように感じます。これは立地条件や、担保する瑕疵の内容、その他付加価値などに左右される部分もあるようです。たとえば、ラックと電源の単位で契約を行っている場合、自社のサービスを担保しつつ契約する部分を縮小していけるかがポイントとなります。

また、電気料金に関しては、ラック等の基本契約に含まれたり、従量課金制だったり、あらかじめ決められた容量が提供されていて、それを超える場合は応相談など、さまざまな形態があるように思います。これらは、自宅向けでも構いませんので電気料金の計算に当てはめて比較してみればだいたいの目安がつきます。

一般的な家庭の電気料金の月額は、（⁠おおよそ）以下の式で計算する事ができます。

• 消費電力（kW）×24（時間）×31（日）×単価

単価に関しては、ご自宅にて契約している電気事業者からの情報を参考にしてみてください。

データセンター等にてサーバを稼動させる時も、基本的にはこの考え方と同じです（ただし、契約するデータセンターは事業用電力の括りになることもあるため、一般向けとは異なり安定供給等が約束される代わりに単価が大きく変動する場合もあります⁠）⁠。

さて、上記の公式にあてはめると、たとえば500Wの電源を搭載したサーバの電気料金（W単価）が15円だった場合、1ヵ月の電気代は次のようになります。

• 0.5×24×31×15＝5,580円

あくまでも常に電源の容量を上限一杯まで使い続けた場合ですが、仮に上記の金額で1ラック（42U）に1Uのサーバを42台詰め込んでみた場合、電気利用料金だけでも

• 5580×42＝234,360円

となります。皆様も自宅でサーバ等を開設した際に「なんだか電気料金が上がった」などというご経験があるかと思いますが、正にその通りで、電気利用料金というのは侮れないコストということになります。

実際には1ラック（42U）すべてに機器が搭載できない場合もあります。冷却効率、ラック据え付け電源の容量等を確認し、おおよそ全体でどの程度の電力供給能力があるかは契約前にチェックしなければ、後々ラック自体に空きがあっても電源の関係上機器を搭載する事ができなくなる事があります。

また、これまでであれば、データセンターにラックと電源を確保しただけに過ぎないため、外部に接続するようなサービスであれば、ネットワーク等の契約が必要になります。これらもイニシャル（初期）とランニング（月次）費用を負担する必要があり、コストと言えるでしょう。

保守、監視費用

さて、電力を消費してサービスを提供するサーバがあれば、そのサーバのヘルスを監視したり、万が一の際交換等に対応する必要があります（監視の必要のないくらいスケールで担保するという案もありますが⁠）⁠。

これらのサービスのメニューやそれに付随した金額としては、以下の項目が挙げられます。

サーバ初期費用（一括、分割、レンタルなど）、保守費用（ハードウェア保守）

初期費用と保守費用（ランニング）を同一に括ってみました。

初期費用に関しては、会社ごとに減価償却の考え方が異なることもあるかと思います。また、保守費用に関しては、月次、年次（1年、3年、5年）と、これも会社ごとの予算計上の方式により費用の計上方法が違うかと思います。たとえば、5年分の保守も初期購入時に一緒に計上してしまう方法もあれば、毎年1年ごとの保守（運用）費用の計上と共に消化する事もあると思います。これら自社のシステムがどのような償却方法、予算の確保を行っているか、一度調べてみるのも良いと思います。

たとえば、定価100万円のサーバを50％オフ、年額5万円の保守費用で調達した場合、以下のようになります。

上記より、3年間で［ケース1］では62.5万円、ケース2では57.5万円となる可能性があります。これはメーカ等にもよりますが、初年度のハードウェアの割引率に全てが寄せられてしまうケースで、このようなメニューの場合、初回に保守を可能な限り長くつけることによって、ディスカウントが効くことになります。

どのメーカがどのように対応しているかは、実際に調達管理等で多くのメーカときっちり話ができたかどうかによって変わってくる知識です。このようなメーカのクセ等も理解して、より自社に利益をもたらすことができるかどうかと行った点も、インフラ関連に携わる者として押さえておきたい重要なポイントです。

サーバ監視費用（ハード、ミドル、アプリケーション監視）

こちらはサーバごとに何を期待するか（どの程度まで、何を監視するか？）によって変動すると思います。

同一メーカのサーバ、メーカ関連のIDCや監視ベンダだった場合、費用、ハード保守等も括れる可能性があります。自社内部で対応したいと考えている場合、外部にお願いすると24時間365日の監視で1ホストあたり1万円の監視費用が発生すると算定されると、内部対応で行うか否かを検討する損益分岐台数を割り出すことができます。

たとえば内部で監視要員2名体制を確保する場合、（⁠仮に）単金を100万円／月とすると、年間2400万円となります。逆にハードウェア機器に関しては全てエンタープライズ向けの保守を結び（イニシャル時の予算で清算⁠）⁠、OSや各プロダクト、アプリケーション等の検知を行う仕組み、その際の対応基準を設けた上で1ホストあたり月1万円で監視を委託できるとすると、あとは監視対象マシンの台数と監視システムの初期構築費用を計算し、前者と比較してみると良いでしょう。

電気利用料金が同じでも変わったこと

さて、電気利用料の考え方は今も昔も変わりません。しかしながら、サーバ単体（ハードウェア）の技術革新や工夫等により、1台あたりの処理能力が大幅に向上しているのは皆様ご存知の通りでしょう。このように飛躍的な性能向上で、システムのリソースやロードの遊休などが発生してしまうユーザ側に対して、巨大なリソースのプール等を用意し、利用分に応じて課金していくクラウド的なサービスが出てくるのも納得できます。

CPUなどの性能向上に関しては、CPUメーカ（intel、AMDなど⁠）⁠、サーバハードウェアの性能、電源効率等に関しては、サーバメーカ（富士通、DELL、HPなど⁠）⁠、ミドルウェアのバージョンアップ等による処理性能、効率向上に関しては、ミドルウェアベンダ（Microsoft、Red Hat、Oracleなど）が、それぞれが創意工夫を繰り返し、年々めざましい性能向上を実現しています。性能向上と言えば、RAIDやネットワークのチップ等も比較的クリティカルに性能向上を体感できる所です。

これらのさらなる性能向上や不具合はファームウェア等によって解消できる可能性があったりしますので、関連するようなメーカはこまめにチェックし、情報集や性能向上、予防保守に努めるとよいと思います。

また、別の視点では、電力系の企業（東京電力など）やデータセンター関連の情報収集として、検索サイト等で「契約、コスト」など候補文字の組み合わせにより、インフラエンジニアの幅を広げるべく情報を収集することができます。

おわりに

いかがでしたでしょうか？ すでにご理解しているエンジニアの方々からすればごく当たり前の知識で、その考え方をベース（常識）に対応をしている部分もあるかと思います。

ただ、このあたりの知識は誰に教わることもなく、経験に経験を重ねることで、鋭い指摘や契約交渉等に活かされていくのではないかと考えています。これまで、あまりこのような機会に恵まれることがなかった方々のヒントになれば幸いです。