ブログトップ 記事一覧 ログイン 無料ブログ開設

急がば回れ、選ぶなら近道

2016-01-21

Storage Class Memory

ACMの2016 Jan.の会報の記事に上がっていたので、面白かったのでちょっとまとめておきます。
http://cacm.acm.org/magazines/2016/1/195724-non-volatile-storage/abstract

前提として、SCM(Storage Class Memory)について書いておくと、いわゆる不揮発性メモリー(Non-Volatile memory)で、次世代の主流になるだろうとは言われています。DRAMまでのレイテンシーは出ていないので、DRAMのリプレースにはならないと思われる(のが今の常識)ですが、ストレージとしては最速で、一般にDiskの1000倍(3桁)は速い。が、値段は30倍と言われていますね。

ハイライト
ハイライトは以下
・The aged-old assumption that I/O is slow and computation is fast is no longer true
要するに「I/Oが遅いものだ」という今までの前提はあまり通用しないということかと。特にSCMを考えればそれはそうなるとは思います。まぁ今までは、メモリーと比較されるレベルのレイテンシーストレージというものは、そもそも想定しませんからね。

・The relative performance of layers in systems has changed by a factor of a thousand over a very short time
これは特にSCMでのパフォーマンスの向上が1000倍とかそんな単位ですぐに来てしまうので、システムレイヤーでのパフォーマンス・ギャプの絵面が変わるという意味ですね。

Pile of existing enterprise datacenter infrastructure – hardware and software – are about to become useless (or, at least, very inefficient).
結果として、特にDCの既存資産は、まぁゴミになると言っています。割と極端なものいいですが、それだけSCMのインパクトが強いということでしょう。

・概要
詳細は直接エッセイを読んでもらうとして、内容を要約すると大体以下の考え方になっています。

SCMレイテンシーはかなり低減されていて、Diskは遅いという話は過去のものになるだろう。概ね、既存Disk比で1000倍(IOPS)は違う。(このあたりは、そもそもSSDでもその位は行っていた気がするので、それよりも向上していると思いますけど)

SCMを導入するときに問題になるのはコスト。これが高い。特に対CPU比になると、従来はCPUが高くてDiskが安い、という話が前提だったが、むしろ逆転するレベル。すなわち「CPUの方が安い」ということになる。この場合は、投資対効果(特にDCのような場合)を考えると、どれだけSCMのIOを使い切れるのか?ということの方が重要になってくる。

その上で、以下の四つのポイントを提示しています。

1.Balanced systems
まずボトルネックストレージI/OからCPUに移ることになる。処理待ちのデータをメモリーに保持するために、かなりのRAMを必要になってしまう。というかRAM上のデータが単純に処理待ちで手持ちぶさたになる。CPU仮想化のようにストレージの仮想化が必要になるかもしれない。ストレージの利用率を上げることが必要になるので、ワークロードに見合ったバランスのよいCPUや適切なメモリーが提供されることが必要になる。ただ、まぁこれは結構難しい。

2.Contention-free I/O-centric scheduling
ハードウェアのバランスが整っても次に時間軸の問題がある。これはNWの高速化の時のスループットを上げる手法と同じように、できるだけinterruptedさせない手法もやり方としてはあるだろう。勿論複数のコアで並列処理はするようにはなるとは思うが、できるだけ競合しないようにスケジューリングする必要がある。うまくシリアル化しないと、簡単にロックしてパフォーマンスがでない。SCMドライブのサチュレーションをさせながら、クライアントとのやりとりを邪魔しないやり方が必要になる。

3.Horizontal scaling and placement awareness
これは単一ストレージではなくて、まとめてクラスター的に扱った場合の話で、JBODのような単純な仕組みではなくて、分散ストレージ的に扱わないと無理って話です。

4.Workload-aware storage
SCM特性が実際のワークロードには当然合わない、ということがあるので、うまくtiringした方がよい、という話です。まぁNUMAのように同じデバイス層で複数のレイテンシーがある場合は、データ管理はある程度階層化するのは普通にある話です。シーケンシャルな処理が得意なストレージとの組み合わせも確かにあるでしょう。


いずれにしても、今までのように「単純なストレージデバイス」として扱うと、コストに見合うだけのパフォーマンスが得られない。したがって、可能な限りの工夫をしなければならない、というのが趣旨です。

・思うところ

SCMの導入により、ストレージレイテンシースループットは今までのIOボトルネックを(というか、他にボトルネックが他に移るほどに)解消できるほどに向上するが、その分コストがあがる、よって、それを「使い切る」アーキテクチャにしなければ、見合わないという考え方は、面白いと思います。

コストあたりで見たときにストレージI/Oを使い切るために、うまくCPU資源の利用を考える、という発想はあまりなかったと思います。(正確にいうと大昔にはあったと思いますが。・・そもそも高速ストレージ自体が貴重だった時代には確か、そんな話があったとうっすら記憶しています。もっともおそらく30年以上前ではないかと思いますが・・・)

ここ10数年の流れは、ストレージ(disk)はどんどん安くなるからデータはどんどん置いておけ、というコンテクストが主流でした。そのなかでビックデータとかIoTとか、クラウドとか、そういった「アーキテクチャ」の台頭があったと思います。そのアーキテクチャの一環として、増えたデータを一気にロードする仕組みとしてHadoop/Sparkとかその手の仕掛けが出てきたことには異論はないでしょう。

その流れが変わりますよ、とそういう話ですね。

正直、個人的にはNVMはストレージとして見るのは、ちょっと割が合わないなぁ〜とは思っていました。“超高級”超高速SSDじゃねーの、と。SCMは大量のデータの置き場としては、コストが全然ペイしないでしょう。むしろミドルの、今までのストレージではパフォーマンス的に合わないクリティカルな部分への導入にちょうどいい(たとえばlog管理・snapshotの置き場)ぐらいで、他に用途はないだろうと思っていたので、ここまでの発想はちょっとありませんでした。

また、ストレージに対して「相対的にCPUコアのコストが下がる」というのは、そもそも従来の発想とは真逆の考え方だと思います。CPUは貴重だし、処理能力も高い。よって、割と単純な単一タスクだけでは割が合わないので分け合いましょうというのが、今までの流れです。汎用機時代のTSSや、現在の仮想化技術も同じコンテクストにあるでしょう。

翻って見れば、ムーアの法則の限界は、コア出力の向上の終焉になります。他方、確かにストレージメモリーの技術は進化が進んでいます。この半世紀はCPUコアの出力の伸びに対して、ストレージの向上は相対的には微々たるものでした。まぁ、そのストレージがメモリー並のパフォーマンスになるまで向上するのであれば、今後の考え方にも影響があるでしょう。

その意味では今後主流になるアーキテクチャがバス周りやストレージ周りを強化する方向に倒れるというのは、必然で(代表的なものがRSAみたいなものですね。)、かつ、そのときにコスト構造のコアがNVM・SCMである、という読みは多分正しいと思います。確かに高いですよ。むしろCPUは安い。

データの有りようも、基本的に「Small Big Data」のような感じになっているのがまぁ常識になっている現状で、この中でSCMを考えるのであれば、なるほど、どうコストを回収できるように使い倒すか?というのは考え方としてはアリでしょう。

ど安めのストレージにだらだらデータを放り込んだところで、結局、利用する場合は絞ってレイテンシー勝負になるのは、もうその辺にいくらでも転がっている話です。テープの代わりにDiskを使って適当にクレンジングしたあとはSCMにベースをおいて、スピード(レイテンシースループットも)勝負という図式は、特にビジネスのレスポンスを上げるという意味では普通に考えることでしょう。

この進展の場合、いろいろポイントがあると思います。

1.基本的にミドルとアプリの問題はでかい。

まず、現時点でSCMをきっちり使い倒すミドルウェアがないですね。一応、この手のバス強化の話の研究は死ぬほどあり、どの実装も工夫はしていますが、現実にパフォーマンスが一気に1000倍あがるというような場合は、既存のものは全く役に立ちません。ので、いろいろ再検討になります。使えなかった方式が復活したり、新しく別のコンセプトが出てくると思います。当然、ミドルは全面見直しです。アプリレイヤーからさらに、という話であれば、現状ではあまり現実ではないと思います。

ミドル屋から見るとこれは相当危なっかしい話にも見えます。この手のアーキテクチャはいままでの通例だとH/W依存が高いので、結果アプライアンスや特定パッケージにソリューションが集中するようにも見えます。この場合、ユーザサイドから見た場合は、あまり選択の余地がない可能性にもなると思います。アーキテクチャの大きな曲がり角では、主導権争いは常に起きるものですが、どうなるかはちょっと見えない感じです。

普通に考えるのであれば、まずは小回りの効く割と単純な仕組みで、まずは組み上げて、うまく特定のアプリケーションに乗せる、というのが一番近道には見えます。ツボにはまれば凄まじいパフォーマンスをたたき出す「システム」が構築できると思います。(それが構築仕切れないユーザーは、ウン十億払って割と中途半端なアプライアンスを買う羽目になるかな?)

2.DCの問題はある

既存のDCでは問題になると思います。オンプレで個別に構えている場合は、まぁこの手のアーキテクチャの変更は、ある意味エイヤでやれますが、特にクラウドになってくるとそうは行かないでしょう。

まぁ単純に超速いIO(桁が3っつ違う)が提供されて、それをうまく共有化できる仕組みができて、その上でサービス化(たとえばDB)されれば、ま、普通にそっち使うだろうって話です。単価が高いのでどう使い倒すかが鍵になるでしょう。

ある程度、資本力の差がでるかな、と思います。既存のハードを相当一気に入れ替えることができないと、「入れかえることができるクラウドベンダー」に対して、価格どころか、そもそもユーザに提供できるパフォーマンスが、おそらく平均で2-3倍は違うということになるでしょう。これは厳しい。しかもハードを単純に入れただけではペイしないので、うまく使い倒すミドルを開発?する必要が出てくるでしょう。(某国のクラウドベンダー群の実態を見る限り、これは絶望的に厳しい)

3. いずれにしても

それなりに課題があるので、そうそうすんなりいかないと思います。ただし、数十年にわたって、ITを縛り続けてきたムーアの法則、というかムーアの呪いが、解けた現在、その影響は普通に考えて地殻変動なみに出てくるだろうな、と思います。これもその流れの一つだろうなとは思いますし、その意味では注意はしておきたい。

奇しくも、データ爆発の流れで分散処理やクラウド的なものが一般化(というか精神的なハードルが下がった)し、同時期にムーアの法則が終焉しているという事情は、汎用機→オープン化に続く、大きなパラダイムシフトの幕開けと見て、それほど間違いではないでしょう。

そんな感じ。

2016-01-04

Multi-version Conflict Serializability

1.目的

今後の分散DBでは、前提が分散ノードから分散コアに主体が移る。ムーアの法則の限界は、メニーコア化とノードの高密度化を推し進める。分散ノードではリードロックの問題とノード分散の相性の良さでSnapshot Isolation(以下SI)がほぼ前提であったが、RDMA等のハードウェア技術革新レイテンシーが改善されるのであれば、SILOのような(表面上は)単ノードのS2PLの改良版も有りになってくる。

そうなってくると理論的な背景も、SIを前提という話ではなくて、通常のConflict Serializability (以下CSR)も頭に置きながら話をおっていかないと理解が厳しい。

SI「だけ」であれば、なんとなくまぁセオリーでr-w依存での循環グラフだよね、ということを前提において議論を追いかけて、r-w依存はあとで復習して調べとけばなんとかやり過ごせる。が、通常のCSRも混線してくると、そもそもなんでr-wなんだっけということが、スルッと出てこないといちいち話を巻き戻す形になって、議論についていけなくなる。要するに途中でわけがわからなくなる。

結論から言うと、SIの理論はmulti-versionになっていて、Multi-version View Serializability (以下MVSR )が下敷きになっている。なので、conflictはr-wの話になる。その一方で例えばSILOのようなものは一見するとr-wのconflictの話をしているように見えるが、実際は通常のCSRでの延長で話をしている。そのためにS2PLが持ち出されているし、そこで決着をつける形になっている。(ただしSILO自体はそんな単純な話ではないので、それはまたあとでまとめる)

実装はCSRでもMVSRでも両者ともどもエッジグラフでのvalidationになるので、結果としては「同じ」read-setとwrite-setのintersectionの話になっているところがややこしい。やっていることは似ているが、導かれているクライテリアは異なるということだ。(大抵の教科書はCSRまでの定式化までしかしないので、その理屈だけで行く人が多いと思うが、そうなると議論についていけなくなる。)

なので、SIをserializabilityの議論のなかで、しっかり定式化して置く事が肝要になる。これを身につけておかないと、今後のTx系論文の深いところの理解は覚束ない。ので、ちゃんと整理しておく。

2.Multi-versionでの serializability

multi-versionのserializabilityは、通常の単一スケジューリングのserializabilityとは異なる。通常の単一スケジューリングでは、CSRが基本になるが、multi-versionでは、VSRすなわち、View Serializabilityが基本になる。SIの話にしろ、なんにしろ、multi-versionの話になったときに、correctnessのクライテリアはVSRですよね、とガツンと路線を切り替えないと話が脱線する。

特にVSRの場合、read-fromの依存関係がserializabilityのキーファクターであり、これは「どのreadが結局はどのバージョンのwriteを読むか?」ということに依存することを考えれば、multi-versionのコンテクストでは、CSRよりはむしろVSRのcorrectnessのクライテリアに近い事は容易に想像できる。

multi-versionでのserializabilityは、通常multi-versionでのconflict serializability、すなわちMulitiversion Conflict Serializability(通常MVCRと略する)のことをさすが、このconflict serializabilityは、通常のCSRスケジューリングのconflict ではなくて、VSRでのconflictの延長にある。通常のCSRでのconflictは w-w w-r r-wの三種類になるが、MVCRではr-wだけになる。これはVSRの延長から来ていることによる。

以下表記は、ri(xj)は、transaction iにおいて、verion jのxをreadするということを意味する。wi(xi)は自明であるが、mono-verisonと区別するためにxiを記述する。なお、順序は全順序が前提。

3. MVSRの定式化

3-1 version order と mono-version

version orderとはそのversionが作られた順番そのものではなく、serialization orderを決定する際に利用される、各書き込まれたversionの順序をさす。

mono-version とは単一のバージョンによるmulti-versionのスケジュールをさす。要するに普通のスケジュールになる。multi-versionでreadが直前のupdateのversionを読む制約を加えるとmono-versionと同じ属性を有することになる。multi-versionにおいて、read-fromの依存関係を維持したままで、各operationをスケジュール内で交換し、mono-versionに投影した時にserialなmono-versionのスケジュールを作る事ができれば、それはserializableということになる。

3-2 Serializability

判定はMulti-version Serialization Graph (MVSG)を利用する。このグラフはread-fromの依存関係からtransactionの依存グラフ(dependency graph)を作成し、そのgraphが非循環かどうかで判定する。非循環の場合はトポロジカルソートにより、serialなスケジュールを作る事が可能になる、というかできるはずという事になる。

MVSGのグラフのエッジは以下の条件により作成される

あるxについて、wj(xj), rk(xj), wi(xi)を想定した場合、まずrk(xj)があるので、
1. tj->tkの依存エッジが必ず存在する。
2. xi->xjのversion orderの場合
wi(xi)->wj(xj)が存在し、よってti->tjのエッジが存在する
または
xj->xiのversion orderの場合、
wj(xj)->wi(xi)となり、そもそもwj(xj)->rk(xj)であるので、xj->xiならば、必ずrk(xj)->wi(xi)になる。
よってtk->tiのエッジが存在する。


4. MCSRの定式化

MVSRのサブクラスになる。グラフがより簡易になるので、整理しやすい。
ややこしいのは、MCSRは以下の通りSIとは異なる。なので、ここでは本筋ではないが附随的な議論として置いておく。今後MCSRがロジックとして持ちだされた場合に必要なので、その理解のために整理しておく。

MVSRのサブクラスとして、MCSRを定式化する。
これはMVSRのdependencyをさらに簡潔にする。dependencyとして考慮するのは、rk(xj)->wi(xi)だけになる。MVSRの依存が、wj(xj), rk(xj), wi(xi)で判断することに対して、wj(xj)を判断しない形になる。まぁ、rk(xj)があるということは、wj(xj)が先行している(はず)と考えておく。先行していない場合は初期値(すなわちj=0)を除けば、そもそもスケジュールとして成り立たない。

なお、このグラフをMulti-version Conflict Graphといい、このグラフが非循環の場合をMulti-version Conflict Serializable といい、通常MCSRと称する。

直感的な説明は以下

1.そもそもwi(xi)-wj(xj)がなぜ依存関係ではないか?
これは後続のreadの対象の問題であるので、別段、xiとxjになんらかの関係があるわけではない。(これはMVSRも同じ)

2.wj(xj)-rk(xj)がなぜ依存関係ではないか?
仮にrとwを交換しようがしまいが、version orderには影響がない。よって、依存関係があるわけではない。そもそもスケジュールで読めていたということはread-fromが成立しているということなので、そのようにverison orderを維持することが可能だ。
(厳密にいうと、readの前に既にwriteがあるので、r-wに交換しても それがserializableならば そもそもw-rもserializable になるはず。readできる選択肢は交換することで減る。)

3.rk(xj)-wi(xi)
r-wについては、仮に交換すると、rの前にwを持ってくることになる。この場合、交換前のversion orderと異なるversion orderを「強制的に」つくることができる。要するに”壊す”ことが可能になる。読めるversionを「追加」することになるので、後続readでいくらバージョンを指定しても、事前にあったversion orderを、交換後の操作で上書き(versionではなくてversion orderの上書き)する事が可能になってしまい、version order自身を維持(というか担保)する事ができない。よってconflictになる。

ただし、abort検出の際にMVSRにできるがMCSRではないものを擬陽性で検出するリスクはある。wi(xi)wj(xj) rk(xj)の形が取れて、かつそもそもversion orderがserialに作れれば、MVSRになり、実際はserializableになる。これは、MCSR<MVSRの例。(偽陽性といえば偽陽性ではあるが、これは判定コストの問題をどう考えるかによる。)

(なお、個人的感想だけど、この部分のちょっと(かなり)わかりづらい。Tx本の解説でも本自身が認めている有様だ。この部分に関してはグレード的には辛めに見ても5.13はあると思う。とほほ)

5. SIの定式化

1.各readに対するversionの割当は当該readのTxが開始される時点で、最も最近にコミットされたwriteのものを割り当てる。
ri(x) mapped wj(x) であるときに
wj(x)<cj<bi<ri(x) かつ( wh(x)<bi and cj<ch<bi )であるwh(x) chは存在しない cはcommit bはbegin

2.二つのconcurrentなTxのwrite setは交わらない
任意のtiとtjについて、bi<bj<ciまたはbj<bi<cjであれば、tiとtjは共通のobjectについて書き込みをしない

SIはmulti-versionである。「あるreadに対して特定のwriteのversionの割当を行う」という意味でSIがMVSRの特殊ケースである。ではあるが、SIはMVSRよりもwrite-setの交差を制限するという意味でより制限的である一方で、MSVRで要求されるread-fromの要件、すなわち該当するserialな単一versionでのスケジュールでのread-from(w-rのconflict)との互換性は、要求されない。この点でMVSRよりも制限的ではない。これらの意味で、非互換である。

依存グラフすなわちSnapshot Isolation Serialization Graphは以下に定式化できる。

1.すべてのrj(xi)について ti->tj

2.すべてのrk(xj)とwi(xi)について
ci->cjであればti->tj
cj->ciであればtk->ti

ここでMVSRと比較してみる。

1.についてまったく同じである。これはmulti-versionに共通のconflictである。

2.SIではcommit orderであり、MVSRではversion orderであるので、本来であれば別物であるが、
MVSR: xi->xjであればti->tj または xj->xiであればtk->ti
SI: ci->cjであればti->tj または cj->ciであればtk->ti

readしたものを後続(ここの後続の意味がSIとMVSRで違う)の別のTxがwriteする場合は、readのTxとwriteのTxでの依存関係が発生し、commit orderまたはversion orderが逆順の場合は、write Txとread するversionを書いたTxについての依存関係が発生するという意味では同じである。すなわち、メタレベルのセマンティクスは同一であることがわかる。

6. まとめ

以上のように、MVSR/MCSR/SIのserializationには、一定の共通したセマンティクスがあることがわかる。これは単一スケジュールのCSRとは別物であることも明快だ。今後MV系のTx処理が展開される場合には、この路線の上で議論はまずまちがいなく展開されるだろう。(逆にこれがわからないと話にならないと思うので、なんか分散TxMV系の話が合わないなと感じたら、このブログを参照してもらえばいいかもしれない。ほんとかよ。)

上記のように、SIといってもMVSRと交差するコンセプトであり、かつおそらくMVSRの方が広い。証明はともかく、直感的にはcommit orderを考慮しない方がconcurrentなhistoryの選択の余地はある(と思う)ので、例えばLTT(long-time transaction)とSIの共存にMVSRを取れば、変なlockをとらなくてもserializableにできる可能性もあると思う。可能になればDBの使い勝手は非常に広がる。このように現行のDB最先端であっても、まだまだ発展途上で有ると思う。transactionはベースが数理論理学なので、理論的には可能だがまだ道が発見されていない、または発見された道が割とイマイチ、というものが簡単に見つかる。個人的には本当に興味が尽きない。

なお、上記の元ネタはほとんどが、Tx本なので、そこを参照してもらえればよいけど、MVが5章で、SIが最終章なので、鬼の3-4章を突破して、さらに最後まで読まないと無理なので、がんばってください。白状しますと、なんとか3-4章はクリアした後の、5章の特にMCSRの下りは初見では、「まったく」理解できませんでした。あの部分は本当に難しいと思う。あそこがオンサイト一撃(フラッシュは駄目よ)の人は、間違いなく一種の才能があるので、ウチで採用するので連絡ください。まじで。

2015-12-25

RSA(Rack-Scale-Architecture)

一応、Asakusaのアドベントカレンダーのネタです。
いろいろ今後のAsakusaの対応について、現状を踏まえて一回まとめます。

1.ビックデータの敗北
まず、現状のビックデータの現状はちゃんと踏まえておきたい。というのは、いままでの分散処理の技術革新は、クラウド・ビックデータ関連を中心で進んできたわけで、当然次の流れはその「歴史」を考慮しなければ、ビジネス的な先はないでしょう。

まず、経験的には日本での「ビックデータ」の実行基盤としての大規模クラスターの展開はほぼ全滅に近いと思います。特に、日本ではPByteを越えるデータはその辺に転がっているものではありません。もちろん何百台・何千台ものクラスターを構成・運用しているところもありますが、おそらく十指を越える程度でしょう。日本の企業数が5万としても、99.9%の企業はそんなクラスターは持っていません。ただし、企業数が多いので結果としてのデータ総量はチリツモで相当な量にはなっていると思います。このあたりの傾向は世界的にも似たようなものかな、と思います。図にすると以下になるかと。

f:id:okachimachiorz:20151225160911j:image

日本では大抵の企業は左端に位置します。そしてHadoop・Spark等の分散処理のOSSは基本的に右端の企業から出てきています。これは結果としてアーキテクチャのミスマッチが発生します。右端の大規模クラスターの仕組みは、左の小規模クラスターの運用には「いろいろと過剰」です。結果、余計なコストがかかります。つまりパフォーマンスが落ちます。具体的に何か?といえばいろいろあるのですが、ざっくり言えば、大規模クラスターでは実行処理中にノード(というかクラスターの構成要素)の障害が顕在化することが多いので、その障害対策をかなり入れています。小規模クラスターではそうそう簡単に障害が顕在化することはないので、処理の度に大きな障害対策のコストを払うことは割に合いません。

では、単ノード処理でいいのか?というとそういうわけにはいきません。大抵のデータは線形に増加しているのが現状です。要するに今の単一ノードのシステムでは問題ですが、数百ノードは不要というのが実態です。ただし代わりの仕組みがないので、ないよりはましで、HadoopとかSparkを利用しているのが現実です。
(別の見方をすれば日本は完全にIT後進国で、自国の情勢にあったITインフラを利用することができていない、ということにもなるのですが・・今まではトップエンドの技術の「おこぼれ」を一種の量産効果化後に、自己で投資をせずに安く利用してきたというメリットもあったが現状は逆になりつつあるということですかね?)

要するに日本もそれなり既存の仕組みではちょっと回らないな、という感じになりつつも、利用手段が合っていないのであまり効率が宜しくない、という状態が分散環境の現状でしょう。

話は逸れますが、現実問題として、アーキテクチャ云々というよりも、「ビックデータも思ったほどビックでもないし、なんかイマイチだよね」というのが普通の感覚ではないでしょうか。結局、従来のCRMと何が違うのか?といえばそれほど大差はないわけでして。
いまや、ビックデータというワードは、一般の会社では「ウチの”ビックデータ”君」という風にインプットの書類を机に山のように積み上げ、ゴミも集まれば宝の山になるといいつつも、まったくアウトプットの出ない人のことを揶揄する言葉になっていたりします。まじで。・・つぎはレポート上の数字が芳しくない営業課長あたりが苦虫かみつぶして「ウチの”データ・サイエンティスト先生”呼んでこい!」と怒鳴る感じになるかと。

2.ムーアの法則の限界とRSA
もう一つの押さえておくポイントは、さんざん言われているムーアの法則の限界です。要するにCPUの微細化が限界で、コア出力が上限に達しつつあります。この結果として、メニーコアが進んでおり、当然そのコア間をつないだり、メモリー周り・IO・NW等を強化する方向に開発が進んでいます。

その結果が、RSARack-Scale-Architecture)です。

この言葉自体はIntelが提唱していますが、別にIntelのオリジナルというわけではなく、たとえばHPあたりはTheMachineという形で進めています。複数のノードを「高密度」にRack内部で組み上げて凝縮性をあげて、ラックベースの一つのコンピュータと見なすアーキテクチャのことです。結果として、数千のコア数と10~100TクラスのDRAMを持つモンスターマシーンができあがります。スーパーコンピューターダウンサイジング版と考えてよいと思います。

実は、このRSAの利用するデータサイズが、数百ノードでは多すぎるが、単ノードでは辛いという「現状の日本市場」にはサイズ的にはマッチすると思います。RSAはスタートは最小構成は1ノードです。この場合はRSAいう意味はほとんどないのですが、それから普通に2,3,4と増やして行くことが可能です。別にラック満載のモンスターにする必要もなく、4-5台で100コア前後でメモリー数Tというあたりがよい感じではないとか思います。尚、上限はラックベースなので30~40台がぐらいが現実線でしょう。ちなみにRack-Overも当然あります。

まず、データサイズはちょうど良い案配でしょう。メモリーもそんなTByteも使わないよっていうところもあるのと思いますが、実は処理が複雑になると一時的に中間データが膨らむこともあり、これをDiskに書き出さずにメモリーで処理できるのは大きいです。まぁいい感じに見えます。また、複雑な処理はやはり数百ノードで展開するには、いろいろとオーバーヘッドがかかり過ぎます。細かいデータのやりとりは特にスループットよりもよりレイテンシーに振られることが多いので、高密度化は「余計なことをしなければ」有利に働くのが普通でしょう。

3.RSAの内部構造
ではそのRSAとやらは一体なんですか?ということになるのですが、RSAの特徴は、以下の二点につきます。(とりあえずメニーコアは前提になっている)

1.RDMA (Remote-Direct-Memory-Access)
要するにRemoteのDMA。一般にNUMAに属します。端的に言うと「他のコア配下のメモリーに別のコアが直接アクセスする」ということです。まぁ普通に考えると分散・並列処理でのデータの受け渡しでは理論上最速ですが、ただしうまくやらないとかなり簡単にヤバイことになりますね。このあたりの技術はかなり枯れつつあって、実際にHPC系では普通に使われている技術になっています。研究や試行錯誤はかなり長く、とにかくパフォーマンスが出ないというのが相場でしたが、そのあたりがハードの向上でいろいろ変わりつつあるというのが実態のようです。
ぶっちゃけいろいろ調べていますが、とにかく、言われている数値のばらつきがいろいろで、上はremoteがlocalの+30%のレイテンシー(驚異的なんですがw)でアクセス可能とか、いや30倍かかる(これでもかなりマシ)とか、実際は300倍ならマシな方だとか、いろいろあって実際にベンチやらんとなんとも言えません。ま、とにかく今急ピッチで競って開発されています。

これは展開は以下のようになることが、ほぼ決まっています。というかそういう選択肢になるしかないのが現実です。

・NW経由での接続
remoteのアクセスがNIC経由になります。
まぁ一回相手(別のノード)に電話かけて会話する感じになりますかね。
この場合はlocalとのレイテンシー比で相当に(1000倍以上かな・・)は遅いと思います。既存のハードウェアプラットフォームを利用することが可能なので、わりと形だけなら作ることができます。現在の開発のエミュレーションはこれで行われていることが多いですね。
この形で一旦製品としてリリースされるでしょう。

・直接のバスを結線する
メッシュ状に各コア・各DRAMを直接インターコネクトする仕組みです。これが本命。
要するに脳みそと脳みそを直接つなげるくらいの感じでしょう。
localレイテンシー比で50倍以内にはなると思います。目標は10倍くらいが現実路線でしょう。localのレイテンシー比で+30%というのもあながちデタラメではないと思います。ただし、バスから何から作る必要があるので、そうそう簡単にはできませんね。ただ製品として確実に出てくるでしょう。

2.NVM (Non-Volatile-Memory)
不揮発性メモリー。これは個人的には「RSAをそのままのH/Wで」という意味ではRSAの構成要素として必須である気がしません。この場合は、高速のSSDでしかないでしょう。実際、現状ではNVMを単純により速いストレージデバイスとしか見ていないのが、今のマスコミ一般の見方でしょう。ただし、RSAの制御ミドルから見た場合は、まったく別の見方になり、割と必須の機能になります。

基本的にRSA分散並列の仕組みです。この場合、障害対策、特にメタデータやそれにまつわるデータの保全は非常に厄介です。この部分の実装は、分散ミドルの肝になることが多く、実装にひどく骨が折れます。その部分を不揮発性メモリーを利用して一気に解決してしまおう、というのがトレンドです。ログ管理やMVCCのイメージ管理、障害復旧の手段ですね。これは大きい。これはこれでまたどっかでまとめます。

要はRDMAの利用と制御用にNVMを利用する、というのが今のRSAのコアになります。あとはバックプレーンの共有化とかバスの高速化とかありますが、それはブレードサーバでもあるし、普通にどのNW構成でも行う話なので、RSA特有というわけではないですね。

4.技術論
さてでは、RSA上のミドルウエアの話になります。このあたりが我々のフィールドなので。ます、複雑なアプリケーションをミドルなしでRSA上に書くことはたぶん人間にはかなりハードルが高い、というか無理ですね。無理。なのでミドルの出番。

RSAのミドルは個人的には三つのカテゴリーになると思っています。(だんだん書くのが疲れてきた。)

1.仮想制御基盤
まぁRSAコンピュータリソースの効率のよい利用環境を目的としたミドルですね。VM管理とかそのあたりの制御です。流行のクラウド基盤が行きたい感じだと思いますが、いろいろともめる気がします。NW周りがまるで違うし、そもそもRDMAとかどう考えるのか、正直イメージが沸きません。NUMAなんぞかなり昔に倒したわという基盤がいろいろ登場するとは思うのですが、まぁ当時とかなり環境が違うので、はてさて。そもそもこの場合OSの位置づけもかなり意味がわからない感じになる気がします。単純なレイヤリングというわけにも行かないでしょう。正直、この辺はよくわからんので、専門家の人とか頑張ってください。

2.分散DB
今一番熱いのが、このカテゴリーになります。分散OLTPですね。RDMAでのパフォーマンスがあがると、分散Txはかなり現実的になります。現状の分散Tx疎結合ノード分散を前提にしているのでSerializableにするには、いろいろread/writeのvalidationで工夫する必要があり、できても制限的だ、というのが実態です。これがある程度解決することに加えて、厄介なリカバリー分散ARIESみたいな、ナニソレ?みたいなアクロバティックなこともしなくてもNVMからのリカバリーで一発です、ということになります。実際、いろんなRDBMSベンダー(というかSAPMSですかね)が論文とか出しているので、いろいろやってるみたいです。個人的にはHPLabの木村さんがやってるFoedusに注目してます。OSSですしね。この辺はあとでまたまとめます。

3.DAGの実行基
この辺でやっとAsakusaの話になります。現在、Fixstars社の方々と共同でC++ベースの実行エンジンを開発中です。AsakusaDSLで書いたアプリケションをリコンパイルするだけで、RSA上で高速に動かす予定です。現在は単ノードメニーコア特化ですが、RDMAが対応できれば、基本的なアーキテクチャの大幅な変更なしで、対応できると思います。前述のように、日本のデータサイズやプログラムの複雑性にはマッチする上に、HadoopやSparkのような余計な荷物を背負っていません。普通に高速にDAGの処理が終わります。まぁいい感じです。

んでじゃー、最後にデータがもっと増えたらどうなんだということになりますが、Asakusaであれば、そのままSpark・Hadoopでやってくださいね、とこういうことになります。そんな感じです。

今後はこんな流れが進んでいくだろうな、と思っています。

でわ。

2015-07-08

Asakusa on Spark

Asakusa on Spark

AsakusaがSpark上で動くようになりました。
Asakusa on Spark (Developer Preview) — Asakusa Framework Developer Preview 0.2.2 documentation

すでに実際に本番に利用しています。
ノーチラス・テクノロジーズがさくらインターネットにAsakusa Frameworkで開発した大規模データの高速処理基盤を導入し、顧客単位での精度の高い原価計算を実現高速処理基盤はApache Spark™で構築 | NAUTILUS

OSSとしての公開を行いましたので、内容や位置づけをまとめておきます。例によってノーチラスは社内でいろんな意見は当然出ていますが、今回は概ね一致している感じです。

  • パフォーマンス

概ね「業務バッチ処理という観点で見れば、すべからくHadoopMapReduceより、Sparkのほうが高速に処理を終えることができる」というのが結論になっています。ノーチラスの持っているユースケースでは、ほぼすべてのケースでパフォーマンス改善が見られました。おおよそ3倍から5倍の程度の実行時間の短縮が達成されています。これは一度のバッチで処理するデータサイズが、概ね数百GByte以下程度で、かつ、かなりの程度で複雑な処理になっているケースでのパフォーマンスになっています。さすがに非常に単純な処理(例:単純集計一発だけ)で、一度に処理するデータサイズが概ね500Gbyte以上のケースでは、MapReduceに軍配があがると思いますが、そのケースですらSparkもそれなりのパフォーマンスが出しつつあります。

なぜSparkにパフォーマンス優位があるか、というと、これは割と単純にHadoopMapReduceのオーバーヘッドが大きく、これをSparkでは取り除いているということにつきるでしょう。巷では(というかSparkの公式サイトでは)オンメモリー処理によりパフォーマンスが出ているといわれているが多いのですが、実際はそうでもありません。もっともIOコストのかかるノード間のシャッフルデータ転送時のディスク強制書き出しはHadoopMapReduceと同じであり、同じようにコストがかかります。Sparkでいうところの、オンメモリー処理というのは、繰り返し処理のときに明示的にキャッシュが使えるということだと思いますが、現実の処理では同じデータの繰り返し処理が中心でできているバッチがそうそうあるわけではなく、繰り返し処理で明示キャッシュが使えるからといってパフォーマンスが一般に10倍とかになるわけがありません。冷静に考えれば普通におかしいとわかる話なのですが、トレンディーな技術や会社が、VCからお金を集めるときにはよくあるストレッチの話なので、まぁ仕方がない話ですわね。

課題になっていたHadoopMapReduceのオーバーヘッドとは何かというと、自分の見るところでは大きく二つあって、一つはすべての処理を無理矢理Map・Reduceの形にしなければならない、という点です。これはよく言われるところではありますが、HadoopMapReduceではすべての処理をMap・Reduceの形に変形し、かつこの順序で実行する場合はどうしても無駄が発生します。もちろん、これはMap/Reduceの形にすることによって並列分散処理が実行しやすい、というメリットの裏返しですが、いろいろな処理をしていくようになってくると、さすがにデメリットが目立ちます。二つ目はMap・Reduceのタスク処理が実態としてはそれぞれが独立したjvmアプリケーションになっている点です。Map・Reduceのタスクが行われるたびにアプリケーションの起動・終了が行われるわけで、jvmの再利用オプションがあるとはいえ、このオーバーヘッドはかなり大きい。

上記の二点は大規模データに対する単純処理であれば、それほどコストになりませんが、DAGベースで1000ステージを超えるようなケースであれば、下手をすると総コストの5割がこのオーバーヘッドになることがあります。Sparkでは、上記の課題をきれいにとりはらっています。すなわち、処理を無理にMap・Reduceの形での順序実行をしているわけでもなく、またジョブ実行自体を普通に一つのアプリケーションとして管理しています。したがって、単純にHadoopMapReduceからSparkに変更するだけで、オーバーヘッドのコストが削減されることになってしまっています。

  • HadoopMapReduceの終焉

かなりの大規模なデータ処理のセグメントを除いて、現状のSparkはHadoopMapReduceと比較する限りにおいては、ほぼ一方的に優れていると言って良いでしょう。今後はHadoopMapReduceで動いているほぼ大部分の業務系の処理はSparkに(可能であれば)移行すると思います。Hadoopが登場した時分では、大規模データ(特にweblogやlifelog)の一斉集計が主要用途でしたが、現状では、データに対する操作は単純なGroupByではなく、さまざまな操作を要求されつつあります。このような状況で、パフォーマンスで見れば、HadoopMapReduceで動かし続けるデメリットは余りにも大きい。MapReduceに対する改善はすでに小規模なもののみとなっており、Sparkから比べて処理時間が3〜5倍かかることを鑑みても、HadoopMapReduce上でのアプリケーションに継続投資を行うことはあまりにも効率が悪い。もちろん大量データの単純集計であれば、まだまだHadoopMapReduceに分があるので、そのような仕組みはそのまま運用していればよい話で、無理やりSparkに移行する必要もないでしょう。

特に、我々がフォーカスしているような、特に企業の業務系のバッチ処理ではHadoopMapReduceを利用するメリットはほぼゼロです。データサイズや処理の複雑性から見ても、Sparkに軍配があがります。仮に、HadoopMapReduceからSparkに移行できないとすれば、それはあまりに大量の処理を裸のMapReduceで書きすぎたということになるのではないでしょうか? 4年前のAsakusaのリリース当初から、MapReduceを裸で書くことはアセンブラで処理を記述することとそれほど大差はなく、ほどなくメンテできなくなるだろうし、デメリットがどんどん大きくなりますよと、わりと声を大にして言ってきたが、現実となりつつある感もします。HadoopMapReduceは、ほぼいわゆる「レガシー資産になりつつあります。

  • Sparkは無敵なのか?

ではSparkはそれほど無敵なのか?ということですが、当たり前ですが、無敵ではないです。(むしろHadoopが隙だらけだったという方が正しい)

・設定やチューニングが面倒
現状ではたいていの場合は、パフォーマンスが出ずに玉砕することが多いでしょう。加えて安定して稼動させるには経験が必要です。これはもうHadoopMapReduceのメリット(設定が分散処理基盤のわりには簡単)とデメリット(パフォーマンスの上限が割りと簡単に出てしまう)の交換に見えます。Sparkではパフォーマンスを出すために、アレやコレやパラメータを設定して、パフォーマンスを出すために試行錯誤する必要があります。これをアプリケーションごとに行う必要があります。さらにYarnで実行させるには、Yarnの設定も重要になる、ということで、これは確かに面倒です。広範囲にわたって整合性のとれた設定が必要であり、これはなかなか難易度が高いです。徐々にノウハウが共有化されていますが、できることが増えるということのデメリットはゼロにはならないでしょう。とはいえ、これはまさに時間の問題ですね。

・基本的なアーキテクチャの問題。
これはいろいろ意見がありますね。

ひとつは各処理の論理的な出力ポートがひとつであることです。ほぼ似たようなミドルのTezは複数取れますね。処理をブランチさせるようなフロー制御を行う場合は、基本的に無理が発生します。実際、Asakusaの実行基盤のターゲットとするときも問題になりました。Asakusaではあの手この手で解決しているが、普通に実装するのはかなり無理筋になります。

ふたつめはShuffle時点の強制書き出し。言うまでもなく、これはいちいちコストがかかるので。とはいえ、賛否両論です。特に処理の終盤で、前半戦で利用したデータをもう一度使うような場合があれば、書き出しは有効です。放っておけばそのままメモリーを占有してしまうからね。また、改めて言うまでもないですが、ノード・フェイルにも当然強い。そもそもRDDの発想からすると、書き出しは発想の根本にあるものなので、反対するやつは使うなという話にもなるようです。(んじゃー、サイトに堂々とin memory 処理とか書くんじゃねーよ、とか思いますが・・。実際、早とちりしている人も多数いますし)

とはいえ、どこで何を使うかは処理全体をコンパイルする時点である程度目星はつくので、ちゃんと見渡せる仕組みがあれば、Shuffleをいちいち書き出すのは無駄であることは間違いないでしょう。必要なときだけ書ければ十分だと思います。今後のメモリーの容量は太陽系の大きさ(比喩)まで広がる可能性があるので、plannerが賢くなった、しっかりした分散処理の管理基盤がでてきれば(まだないけど)たぶんSparkはわりとあっさり負けます。・・・当分先だと思いますが、具体的にいうとRack Scale Architectureベースのメニーコア前提の、割とかっちりした処理基盤が出たときには、かなり簡単に水を空けられるよなあ・・・とか思います。もちろん、その場合はHadoopは文字通り象なみのスピードの扱いになるとは思いますが。

さて、今回はAsakusaの開発陣の頑張りもあって、かなり大幅なアーキテクチャの変更が行われています。従前のAsakusaのコンセプトを維持しつつ、コンパイラがほぼ全面的に書きなおしになっています。従来のAsakusaはAsakusaDSLから最適なMapReduceプログラムを生成する仕組みになっていましたが、新しいコンパイラは一旦、DAGの中間構造を生成し、そのDAGの中間データからSparkに最適なバイトコードを生成する仕組みになっています。つまり、今後Spark以外の「より高速なDAGの実行エンジン」が出てきたときには、Sparkのバイトコード生成部分のみを入れ替えるだけで、新たな実行環境に対応することが可能になっています。現状、ノード分散環境化での実行形式の標準がDAGになりつつあるのは、周知の通りであり、DAGの実行エンジンはTezやFlinkを見るまでもなく、今後もいろいろ出てくるだろうとみています。Asakusaはそのエンジンに対応しやすくするために、今回根本のアーキテクチャを再構築しています。

これは、Asakusaの意味合いの変化をもたらすと思っています。ユーザーはAsakusaDSLで処理を記述しておけば、今後、より高速な処理エンジンが開発されてきたとしても、Asakusaが対応しさえすれば、そのメリットを享受できるということになります。特にソースコード・テストデータを「まったく変更することなし」に新たな高速環境に移行できるというメリットは非常に大きい。個人的には、テストデータ・テスト環境をそのまま持ってこれるのは、大きいと思っています。これは業務系アプリケーション投資可搬性を大幅に向上させることになります。Asakusaにより業務システム投資サイクルと分散環境のライフサイクルのギャップを埋めることが可能になると思っています。

  • 今後

まぁこんな感じです。我々としては、Better HadoopとしてSparkを利用している、というのと、Sparkに対応するのと同時に、その先も見ながらAsakusaのアーキテクチャを予定通りに変えました、というところです。正直ベースで、Spark、かなり速いです。予想よりもいいですね・・・

Sparkをはじめ、今後の分散環境は高速化がますます進むでしょう。いろいろとできることが増えると思います。ベースデータレイヤーとしてのHDFS-APIは鉄板だと思いますので、HDFS互換にデータ溜めておいて、処理基盤だけほいほい取り替えるとパフォーマンスが勝手にあがるという感じになるでしょう。とはいえ、アプリケーションレイヤーから見るとシステム投資のライフサイクルと実行基盤のライフサイクルのギャップが進行しますが、その辺を埋めるのがAsakusaって感じになるといいなぁと思っています。


・・・って気がついたら一年ぐらい放置してたので、ちょっと反省してます。某プロジェクトにどっぷりだったので・・・
今後はできれば2ヶ月に1回ぐらいは更新したいと思います。すみません。

2014-06-22

データセンターの原価計算について〜「クラウド」の別側面として

要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤にHadoop(MapR)を利用しています。(一応予定ではSparkに移行するつもりで、開発も始まっています。)

さて、いろいろやっていて思うところがあるので、現時点での考え方をまとめておきます。機微な部分はNDAになるので書きませんし、以下は自分の「個人的な」意見であり、特定のサービサーの話をしているわけではありません。基本的にInteropで公にしゃべった話のまとめです。

■現状認識
現在、国内DCはほぼ乱立状態に近いと思われます。ここへ来て春先のAWSの値下げのインパクトもありました。今後は、より競争的なマーケットになるでしょう。退場する企業やM&Aも活発化していくでしょう。生き残りをかけて各社は「次の一手」を打っていかないとあっという間に行き詰まるの業界の共通認識のようですね。

次の一手を打つ前に当然考えなければいけないのが、「それで今、いくら儲かっているだっけ?」という判断です。投資が有限である以上、回収して利益を出していかないと企業活動は停止に追い込まれます。勿論、「採算度外視で、まずはシェア優先」という戦略もあるでしょうが、それは前提として「採算の状況が正確にわかっている上での無視」が基本です。"わかった上での無視"と"わからないので無視"では意味が全然違う。

実は日本のDCはほとんどの場合、後者に近いのが現状です。要するに「いくら儲かっているだっけ?」が正確に把握できていない。いや、勿論簡単などんぶり勘定無敵のエクセルワークシートはありますが、それ以上のものはほとんどないでしょう。これは、サービサーの当事者に問題があるだけではなく、背景にある制度会計にも問題があります。この種のCostingを問題にしている人は中には多数いるとは思いますが、まず打つ手がないはずです。

■現状の「ざっくり原価計算
DCビジネスは投資中心のビジネスです。従って、儲かっている=投資回収ができている、のスキームです。この回収計算は大抵は以下のロジックで行われます。

初期投資:固定資産=土地・建屋・電力設備等・空調設備等・NW機器・サーバー・その他のサービス系設備(セキュリティ・事務・防災)・付随する工事
ランニング:電力・空調・トラフィック人件費

まず、初期投資額を提供可能なラック数または坪数で割り、ラック単価・坪単価を算定します。次にランニングを過去のトレンドから推定して、適当な指標を作り割り当てます。さらに収入サイドとして、ラック建値・坪建値を見積もり、稼働率や実際の見通し・実績を割り当てます。最後にラック(または坪)単位での収入から想定ランニングコストを引き、限界利益を算出して、期間累計でラック・坪単位で回収できていれば黒、ダメなら赤。以上です。

非常にシンプルです。結果として、やるべきことはラックの稼働率・坪効率の向上になります。あとは、できればラック単価・坪単価の値上げのための「付加価値戦略」の追加です。(尚、コストでは勝負にならないので、人手をかけた高サービス、ってな言い方をサービサーが言いますが、これは根本の投資回収ビジネスが変わっていない以上、付け焼き刃の後追い施策でしかないです。Costingを見ればすぐにわかる話です。)

この原価計算の最大の問題点は、「ラックベース・坪単位にユーザーを紐付けることができないクラウド型のサービス」では、ユーザー単位での収益性が文字通り「まったくわからない」ということです。無論、ハウジングなりコロケーションなり、ある程度ユーザーアカウントが特定のサーバ・ラック・敷地に「制限する」ことができているのであれば、この割とざっくりしたコストモデルでも、適用できます。実際、そうしてやってきたの現状でしょう。

ところが状況は変わりつつあります。クラウドベースのサービスは、リソース配分がハードベースからソフトベースに抜本的に変わります。本来であれば、ハードベースのコストモデルは役に立ちません。言われてみれば、当たり前です。しかし、現実にコストモデルを仕組みから変えていくというのはかなり厳しい。

■そもそもリソースコストの配分が変わりつつある。
さらに言うと、発生コストの負担割合が変わりつつあります。Interopでのセッションでも竹中工務店の方が話していましたが、「現状のDCでは初期投資よりも電力コストの割合の方が増えつつあります」。サーバ・ディスクの単価も下がりつつあるのは周知ですし、NW機器についてのコスト低減も時間の問題でしょう。しかしながら電力コスト(+結果としての空調コスト)や人件費は、上がることはあっても、下がることはないです。というか確実に上がってます。

従って、とりあえず初期コストが回収できて、あとは「ほっておけばなんとかなる」というスタイルはそもそも、かなり微妙になるでしょう。リソースコストの側面から見ても従前のコストモデルは早晩役に立たなくなります。

■現状のDCのコストモデルはそもそも限界
つまり「ざっくりの投資モデル」というコストモデルは通用しない状況になりつつあります。普通に考えても、現実にこれだけ市場が競争的になれば、打つ手としては、より細かいサービスでしのぎ、細かい「利益」を積み上げて行く方法しかないでしょう。要するにロングテール。いまさら感もありますが。

では、それに合わせたコストモデルや原価計算の仕組みに変えればいいんじゃね?という話ですが、それができれば苦労はないわけです。以下のハードルがあります。それも相当高い。

・制度会計
要は特定のユーザーやアカウント単位でのCostingが必要になります。UsageベースやActivityベースの計算ですね。しかも多層的な構造になります。まともな会計プロフェッションならこの話を聞いた段階で「相当な厄ネタ」と判断するはずです。屍累々。

一般的にいって、というか制度会計的に、DCの主要コストの電気・空調を直接費にカウントするのは相当無理があります。普通に間接費なんで恣意的な配賦計算になります。まぁ要するに適当になります。私見ですが、現状の制度会計、特に原価計算は、DCに限らず一般的に、「現在」の日本企業ビジネスモデルにまったく合っていません。半世紀前の「ものづくり」的な発想が中心であれば、通用するのでしょうが、現在はうまくマッチしません。特に間接費的と直接費の間にある微妙なコスト、一般的な販管費よりもアカウントや製品・サービスに直接結びついて、しかし製造の直接費ほどその連関がはっきりしないコスト、は今後の企業活動では非常に重要なファクターです。が、現在のところ今の日本の原価計算の仕組みは、この手のコストファクターの管理にはかなり辛い。

つまり、DCのコストモデルを見直す、と言ったところで現行の会計の仕組みは何もしてくれません。つまり自分で一から考える必要があります。むしろ役に立たない制度会計が強制されている分だけ厄介です。

・ハード環境
ActivityベースやUsageベースの考え方が敬遠されてきた直接の原因は、データ取得の運用の困難さです。継続してコスト・ドライバーの動きが計測できない、またはそのデータの取得にコストがかかり過ぎる。結果、発生コストの配分ができず、勢い適当な基準になってしまいます。この対応策は、ある程度のデータ収集の自動化なのですが、当然ハードコストがかかります。また仕組みを構築する必要があります。

・ソフト環境
仮にこの手のActivityやUsageのデータがとれたとしても、普通に相当のデータ量になります。DCだと要するにトラフィックや電力のトランザクションデータですが、普通に「おい、ちょっと待て。それそんな簡単な話ではない」というのが相場でしょう。

要するに「本当のビックデータ(PCとかUSBメモリーとか俺のスマホに入らない)」になります。この手のデータを業務システムで扱うのは、ある程度の仕組みが必要ですが、そんなものはその辺に転がっているものではありません。マスコミコンサル各位のビッグデータ統計分析→”データサイズは関係ない”という矮小化の結果、今の日本のITでは「普通のビックデータ」を処理する基盤・技術・ノウハウがたまらないという皮相的な状況になってしまっています。要するに環境や運用技術が一般的ではない。

アプリケーション
そしてこれもないですね。コストモデルの実装がない。簡単に言うと多重的なコストツリー(ってそもそも末端のノードから見て、親が複数ある段階で「ツリー」じゃなくて、もっと複雑な別の何かですね。まぁDAGはDAGなんですが。循環とかないので。)なのですが、現状のRDBMSベースで構築すると、よほどうまく設計して実装しないと、奇妙奇天烈な巨大SQLのカタマリになり、ウンともスンともいいません。普通にSI屋に頼むと目玉飛び出る見積もりに加えて、なんか動くのかそれは?的なものができあがります。

・文化
そして実は一番大きなハードルは、たぶんこれです。「そんな細かい原価計算とかしても、仕方がないじゃん。要は投資が回収できていればいいだろ。それだけの話」という「ざっくり文化」です。これは相当強いと思われます。これによりコストモデルの変更ができない。

そして実は現状の日本のDCビジネスが根本的にクラウドになっていない理由もここにあります。要するにですね。発想が土建屋です。徹頭徹尾。特にマネージメント層に顕著に見えます。個々のお客さんにサービス要素と様々コストスキームの組み合わせを適用して、収益なり利益を稼ぐ、というのはサービス・ビジネスの基本です。「とりあえず投資して、頭数で割ればいい」ってのはですね。サービス・ビジネスではないです。この辺から切り替えていかないと厳しい。逆にここが切り替わるといろいろと打つ手が出てくる。上記の環境や手段の話は、この文化の問題に比べれば、大きな問題ではないですね。

■解決策
以上の解決策は課題が明快な分、実は自明です。簡単に言うとサービスベースに見合う、コストモデルを作って、必要なデータ収集・計算環境をつくって、マネージメントレベルでちゃんと運用しろ、ってことです。それだけの話です。あとは手段の問題でしかないです。

情報収集については、最近はbuilding management systemは相当に優秀ですし、トラフィック・データの収集はそれこそプロレベルの人も多い。分析環境もHadoopならなんやらのおかげで実行可能になっています。あとはコストモデルの設計ですが、これはそのDCビジネスのエース級を当てれば、なんとかなります。(なるはずです。いずれにしろSI屋さんはダメっすね。無理です。)

実際のアーキテクチャとかコストモデルとか、実装とか運用とかいろいろ書けばキリがないのですが、ざっくりの背景や大枠は以上の感じです。(これから先は、各Prjの詳細にどうしても触れざる得ないので割愛)

■本当にDCビジネスはスケールメリットのビジネスなのか?
とまぁ最後に、現在個人的に思うところとして、一般に言われる「DCビジネスはスケールメリットのビジネスである」のテーゼにはちょっと疑義を感じます。確かにこれは真実だと思いますが、それほど自明でしょうか?

これは前提にDCでのスケールメリットが特定の企業に寡占され、しかもそのコストメリットがビジネスに対して支配的であることがあります。私見ですが、それほど市場は単純に見えません。まず、スケールメリットの寡占ですが、この手のIT技術は見ている限り常にビジネス的にはカウンターバランスが働きます。少なくとも「圧倒的」というレンジには届かないと思います。というか、メリットの享受はフォロワーにも必ずあるはずです。

さらに、スケールメリットにより発生するコストメリットが支配的という前提も崩れつつあります。要するに電力・エネルギーのコストの問題。これは規模のメリットはあるにはあるのですが、それほど寡占優位ではないです。

要するにそれほど単純には見えません。にもかかわらず、卑近の例だと、日本でのDCビジネスについては、確かにAWSあたりが圧勝の勢いです。果たしてこれは「DCビジネスはスケールメリットのビジネスである」ということの証左なのでしょうか?

なんとなく感じるのは、・・・日本のDCビジネスを仕切っている「土建屋気質」そのものが問題のように感じます。日本勢は打つべき手が打てていない。その根っこの部分は、文化的なものを感じます。どんなビジネスモデルにもその裏側には、表には出ない、しかしはっきりとしたコストモデルがあります。現状の日本のDCビジネスのコストモデルが、旧態依然とした土建屋的なものであれば、クラウド的なサービスを取り繕ったところで、それは限界があるでしょう。手を打つべきは、仮想化やコンテナといった表面的な技術ではなく、根っこにある「基本的なビジョン」にあるような気がします。

そんな感じ。