さくらインターネットが構築した、データセンターの要素すべてを対象とした精緻な原価計算システムの仕組みとその背景
さくらインターネットは、Apache SparkとAsakusa Frameworkを用いた原価計算システムを導入しています。
データセンターの土地代から電気代、トラフィック量などサービスに関わる膨大な要素とそのコストを細かく計算し、同社が提供しているサービスやユーザーごとに儲かっているのかどうかまで把握できるという興味深いシステムです。
その原価計算システムの概要が、11月27日にOSSコンソーシアム主催で行われたイベント「2015 Asakusa Framework Day」で行われたさくらインターネットのセッションで紹介されました。内容を紹介しましょう。
さくらインターネットにおける原価計算とそのシステム構築について
さくらインターネット 須藤武文氏。

まず弊社の概要からご紹介します。弊社は1999年創業、従業員が約300名、売上高が約105億円。
提供しているサービスは大きく分けて「ハウジング」と「ホスティング」の2つです。ハウジングはデータセンターにお客様の機器を持ち込んでいただき、回線や電源、空調などを提供します。ホスティングは弊社が所有する機材にアクセスしていただき、お使いいただくサービスです。
2つの事業の割合は、おおよそハウジングが24%、ホスティングが67%、その他が9%。利用者数は個人が約20万、法人が約15万で、合計35万。

データセンターは、東京と大阪、そして北海道石狩にあります。東京と大阪はアクセス至便の都市型データセンターで、何かあればお客様がデータセンターに駆けつけられます。一方、石狩は郊外に安い土地を求めて設置した郊外型データセンターです。

バックボーンネットワーク。弊社が所有しているネットワークは、ほかのネットワークと接続している回線容量が国内トップクラスです。
そして、データセンターの建設やバックボーンネットワークの接続など、これらインフラはすべて投資です。例えばバックボーンの他社さんとの接続では、キャリアさん並の高価な機器などを使います。
世の中は「所有から利用へ」というトレンドがありますが、誰かが所有せずに利用するということは、別の誰かがそれを所有しているわけです。弊社はその「持つ経営」をしていると。

そして「国内でコストパフォーマンスがよいサービスは、さくらインターネットだよね」と言われるようになるには、規模も追求しなければなりません。
というような商売を弊社はしているわけです。
これまでは原価をExcelで計算していた
弊社では規模を追求する「持つ経営」をしてるので、成長することイコール所有するものが増えるということになります。特に石狩データセンターを開設以降、資産がどかっと2倍以上増えました。それ以降も右上がりに資産が増えています。

すると不安も出てきます。投下した資本は計画通り回収できているのか、資産を収益につなげられているのか? 黒字に転換するのはいつ頃になるのか、予定通りなのか?
そうしたことを知るには、サービスを提供するのにどれくらいのコストがかかっているのか、を算出しなければなりません。

もちろん、そうした計算はこれまでもやっていました。
しかしExcelを使って人間が計算していたので、入力を間違えたり十分なデータが収集できなかったり。計算はバックオフィスの人間が担当しているため、例えばSQLを発行しなければ取得できないデータにはアクセスしにくいとか、細粒度のデータは多すぎてExcelに入りきらないといった課題もありました。
また、「いつのデータなのか」という問題もあります。手作業で計算すると1週間や2週間は計算にかかるので、数字と実際のずれが生じるということにもなります。
つまり、これまでの計算は俗にいう「どんぶり勘定」でした。
そんなときにノーチラステクノロジーズさんにお会いして、なにか一緒にやりましょうということで、原価計算のプロジェクトが2013年11月にスタートしました。
原価計算を細かくやる意味はあるのか?
原価計算をそれほど細かくやる意味はあるのか、という反論は社内にもありました。また、競争力の源泉にならない原価計算にそれほどコストをかけるべきなのかという議論もありました。
すでにそれなりにできているわけだし、経営にとって致命的なアラートさえ見逃さなければそれでいいのではないかと。
でも、競争力の源泉ではないからといって、原価計算をしなくていいという理由にはなりません。これまでもそれなりにできていたといっても、どれだけの誤差があったのかも分かりません。間違った数字を見ている可能性もあるわけです。
また、売り上げが下がってきたときに原価計算に取り組もうとしても、すでに余裕がなくなっているかもしれません。余裕があるいまのうちに取り組まないと、なかなか実現できないだろうと考えました。

この時点での原価計算の課題は、計算そのものに時間がかかり、精度も低いことでした。またコスト計算のルールも未整備で、データの収集が十分行えないこともありました。
そこでプロジェクトの目標として設定したのは、精緻化と迅速化です。サービスの原価となる要素すべてを計算対象とし、日次で計算すべきものは日次で完了させることで、経営に資する迅速かつ正確な情報提供を目指しました。

プロジェクトの体制は、プロジェクトオーナーが社長と副社長。実務担当は私ともう1人。ノーチラステクノロジーズさまからは常時6~7名を担当としてアサインしていただいているので、全体で10人くらいです。
このくらいの人数だと打ち合わせも5人くらいでやることが多く、意思決定が迅速で助かります。原価計算というのは恣意性が高い面があり、人によって「ああしたい」「こうしたい」というのが入り乱れるとなかなか決まりませんから。
2013年11月からのプロジェクトのフェーズ1では、石狩データセンターの「専用サーバ」を対象にし、次は2014年5月くらいからフェーズ2で石狩データセンターの主要なサービス「VPS」「さくらのクラウド」などに対象を拡大しました。いまいちばん資本を投入しているのは石狩データセンターなので、石狩を重点的にやりました。
2015年4月からのフェーズ3から、こんどは東京と大阪のデータセンターにも対象を広げて、終わりつつあると。
かかった予算は、原価計算に何億円もかけるのはよくないねと当初から話していて、その通りに推移しています。
さくらインターネットにおける原価計算の仕組み
原価計算のためのシステムについて。システムといってもそんなにすごいというものではなく、主にデータを集めてくる「データ収集レイヤ」と、集まったデータを処理する「アプリケーションレイヤ」があります。
アプリケーションレイヤにSparkやAsakusa Frameworkがあると。
原価計算のざっくりとした考え方ですが、サーバはいろんなコストからなり立っています。サーバの価格や電気代、通信費や建物代、土地代、設備代とあるのは、それを置く場所のコストがこれらからなり立っているからです。
それをツリーモデルに落とし込んでいきます。例えば、土地を使っているのは建物なので、建物に土地のコストを与える。建物で使っているのは設備ですね、電気設備や空調設備に建物のコストを与えて、ラックというのはそれら2つを使っているので、それらのコストを与えてと、コストを低レイヤから上位レイヤ、発生源からサービスに向かって流れていくという仕掛けです。

これだけでも1つのサービスに過ぎません。
これが各サービスにあって、全体で15~16個このバリエーションを持っていないと原価計算ができないことになります。
で、コストを構成する情報をこんどは収集すると。土地や建物、空調設備や電気設備などは、固定資産台帳に登録があります。ラックやサーバやネットワーク機器も同様です。
電気代は電力会社からの請求書やフロアを借りてデータセンターを運用している場合にはフロアの賃借料に電気代が含まれているとか。通信費はキャリアからの請求書に入っているよねとか。
こういうものを集めてきて、コストの受け渡しに関してこういう処理をしようと配賦ルールを決めていくことになります。

これを全部のフローに対して当てはめると原価計算バッチができますねと。

物理サーバ30台のオンプレミスで実行
データ量は大体1日あたり300GB、いまはもう少し増えてるかもしれません。処理の特長は各種台帳をなめるとか時系列ログをなめるとか、とにかくなめる処理のオンパレードで非常にI/Oインテンシブです。
この原価計算を行うサーバインフラは、基本的にオンプレミスシステムです。なんといっても弊社、「サーバは売るほどある」ので。ただ、開発中にリソースが不足する際などには「さくらのクラウド」を併用したりもします。
オンプレミス部分の規模としては物理サーバ30台、総物理コア数200、総メモリ容量1.6TBといったところです。フェーズの進行に応じてクラスタ部分を増強しており、これは割とアドホックに行っています。今後も計算量の増加が見込まれるため、フェーズ4でもさらに増設を予定しています。

原価計算は一般企業ではふつうにやっていることだと思うので、今後さらに精度を出したり、便利にできたりといったことをやっていきたいと思っています。
あわせて読みたい
ひとつのPaaSでWindows ServerとLinuxの共存を可能にした「Cloud Foundry 1.6」。主要開発メンバーが新機能とロードマップを語る
≪前の記事
MS「Visual Studio Code」をオープンソースで公開/「PHP 7」登場、実行速度は2倍/RESTful APIの記述標準化を目指すほか、2015年11月の人気記事