ITは必要悪か？その2

大規模会社、特に社会インフラ系の会社で売上も兆に届くところでのITのあり方は、中小規模の会社とは全く違います。システム構築、とくにSI的な観点からは、実際のプロジェクト単位で見たときに大規模システムと中小規模システムを便宜的に一緒にして考察することが多いのですが、俯瞰したときのあり方は、まったくの別ものです。

大規模な会社では情報システムは、大きな組織のバックエンドの一部であると同時に、企業を動かす歯車として欠くことできない存在になっています。「ITがない」という選択肢は企業活動としてありえません。システムのあり方が大企業と中小企業では異なるため、中小企業でITの必要性という点と、大企業でのITの必要性では意味が大きく違います。明確に区別する必要があります。

■あり方
大規模企業の内部において、情報システムはその企業が存続するための重要な機能を担っており、それなしでは企業は成立しません。大規模な企業運営において、顧客・内部組織同士に対して、ある程度の均質的なサービスの提供を効率的に行うためには、個人のオペレーションで品質・水準で誤差がでることを積極的に防止する必要があります。そのためのシステムです。中小企業では、こと日本企業においては、構成人員の同質性（とくに言語とベースの考え方）が高いため、かなりの程度まで、「システム抜き」の人員で、サービスの均質性をカバーアップできる（できてしまう）ため、事情が異なります。別にシステムじゃなくても人手でやればいい、という発想が根強く、また、それが実現できているのが実際です。（今後はわかりませんが）

■特徴
社会インフラ系企業のシステムの特徴は以下になります。

・規模が非常に大きい
基本的にシステムの規模は大きい。データが大きいというよりも、非常に多くのシステム・サブシステムが構成されていて、全体的に強度に複雑です。また同時に関わる人間も非常に多く、その人間間の「仕組み」も複雑です。

・システムに関わる意思決定が奇々怪々になりがち
基本的にシステムに関わる意思決定は多層的になります。たまに例外がありますが、例外は例外です。大方針でこうだ！とぶち上げたところで、全体的なブラックボックス化が進んでいるので、末端まで来るとやるべきことが真逆になっているという、この時代になんの糸電話ですか？ということは、ものすごく普通にあります。要するになんでこうなった？がよくわからないという状態が非常にしばしば（特に末端に行けば行くほど）観察できます。

・普通に肥大化する。
企業規模が大規模になるほど複雑さは、リニアではなく、ログリニアで増大します。企業規模が1000億円企業と1兆円企業では、複雑さの違いは10倍ではなく、100倍近くはあります。結果として、システムが肥大化します。

・メンテナンスが追いつかない
肥大化したシステムの維持管理は、非常にコストがかかります。結果として、新規に開発する、つくるというよりも、維持し、回すという方向に力が働きます。

・にもかかわらず企業の存続という点でミッション・クリティカルなITになっている。
企業活動自体のITへの依存度は実は中小企業よりも高いです。文字通りシステム全体としてはtoo big to failになっています。いろいろ問題が発生して、騒ぎがでかくなると報道機関に記者会見、監督官庁にご報告とか普通にやる羽目になることもあります。基本的に止めるということはできません。結果として投資金額も非常に大きい。

まぁ、上記の話は、普通に社会インフラ系の大規模企業のシステムとしては普通の話で、特に異論もないでしょう。要するに「無い」という選択肢はないし、またかなり大規模複雑になっている、ということです。

■問題点
・実態として「全体の制御」がきわめて難しい
このクラスになると、どれだけ力（政治力・技術力・予算力）があったとしても、システムのあり方は個人でどうにかなるという話（カリスマ的な社長であったとしても）ではありません。システム自体が徐々に“リバイアサン”化してきます。

・多くの人が巻き込まれることになる。
意思決定の多層化、システムの極度の複雑化は、結果としてITの問題を、むしろ積極的に人力で解決するというパラドキシカルな状況になります。多くの人員が関わるので、システムに多少問題があっても修正することが困難です。たとえばこの種のシステムの大規模開発では、開発中止は勿論、計画変更も相当困難です。結果、大抵の人が、これは問題がある、と思っていても手の出しようがない状況にしばしばなります。アジャイル信者の人には良く誤解がありますが、これは「開発方法論」の問題ではありません。意思決定が多層化し、システムが極度に複雑化している場合は、どうしても、すべての動作を「細かく切る」ということがそもそもできません。なんとかしたいので、コンサル頼んで「いろいろと整理する」ということもやっても、そもそも整理作業自体がさらに問題を複雑にすることすら起きます。

・結果としていろいろ消耗する。
本来であれば、企業活動のためのシステムが、逆転して、システムのための企業活動を誘発します。顧客や従業員のためのシステムが、いつのまにやらシステムのための顧客や従業員になるというやつですね。これは結果として関係者（顧客・従業員・IT部門・ITベンダー）を消耗させます。どう控えめに言っても「人には優しくない」ですね。

大規模会社におけるシステムは、取り扱いが困難であり、かつ一種の不経済を発生させる一方で、組織運用には欠くことができない、という意味で、一種の「必要悪」という見方もできます。この手の怪物をどう制御するか？が問題になります。

■組織の問題
結論的に言うと、たいていの場合、この規模のシステムの問題は、組織の問題に帰着します。要するにITとは関係がない部分が大きい。場合によっては「ITとは全然関係ない」ということすらあります。ややこしいのは、IT自体がブラックボックス化するので、この手のシステムの課題が「いかにもITの問題」に見えてしまう、という点です。

中小企業においては、ITはある程度ツールとして割り切ることが可能で、独立した「IT自体の問題」として考えることが可能ですが、社会インフラ系ではそういうことになりません。システムとは組織維持の仕組みそのものであり、ITは「ツール」ではありません。

システムの扱い方は、そもそも大規模な組織をどうしていくか？という問題に近いです。

肥大化した組織運営の効率化は、普通に「分割統治」であることは論を待ちません。意思決定の透明化・簡略化は組織運営自体のスピード・効率を上げ、不要なコミュニケーションの減少は、関係者のストレスを軽減します。なので、システムを組織的に分割して、組織としてメンテできるようにサイズを落としていくという方向が望ましい、

と思うじゃん？（ワールドトリガー風味）

■コストメリット
ところが、ITのような一見「資本集約的な仕組み」（本当は違う）は、できる限り一元化したほうが、コストが安くなります。特に調達コストは普通に単価の桁が変わります。ひどいときには単価が2桁変わることすらあります。開発工数も同じものを複数つくるよりも、単一のもので使いまわしたほうが、少なくとも開発コストは減少するように見えます。

コスト・リダクションという観点で見ると、システムは統合したほうが、確実にメリットがあります。社会インフラ系企業のM&Aでお題目のようにシステム投資の削減といわれるのは、別に根拠がないわけではないです。

よって、システム分割は大企業においては、集約メリットを放棄することに近く、コストメリットが取りづらいのが普通です。なので、通常はむしろ逆に「統合システム」をつくることに執心します。企業内の複数の組織で、“同じような機能”のシステムを開発・メンテすることはコスト的にはデメリットになります。

要するに、システムはそんな簡単に「分割統治」はできないわけですよ。

そこで、例えばITインフラ統合して、その上のアプリケーションを個別開発すればいいじゃん、という形にもっていくのが普通です。ほぼ、すべての社会インフラ系企業のITはこういう形になっていますし、この形であればスケールメリットもとれるし、個別対応のオーバーヘッドを軽減できます。

と思うじゃん？（A級槍使い(ry

■統合システム？
ところがところが、インフラとアプリってのをキレイに腑分けできる、というのはあくまでプログラムの話で、関わっている人間の意図・考え方はうまく手当してあげないと、お互いに伝わりません。ドキュメント・APIで伝わるのは基本的に手段の話であって、考え方ではありません。考え方や考え自体を言語化するトレーニングはIT関係者は普通受けていません。（考え方はAPIとかドキュメントから“読み解け“ってのが普通です。冷静に考えればおかしいのですが、おかしいと思わないところがトレーニングをうけていないサガですね。）

IT屋のドキュメントは生成の仕組みまで含めて「How」の記述に特化しています。肝心の「What・Why」は記述されません。誤解のないように言いますが、ちゃんとしたIT屋は「What・Why」はちゃんと考えます。かなり相当考えます。ただし、業界として、「What・Why」の記述方式にコレといったものがないのと、記述の手法の訓練をIT屋が受けていないことが課題です。

結果、人間系が入らないとトータルにパフォーマンスを出すことが難しくなります。というか、全然パフォーマンスが出ないので、人間系で情報共有を密にやるという話になりがちです。とどのつまりは、組織的には全然分割統治になりません。一見、システムはばらけているように見えても、遠目で人間系の組織とみると、全体的な有機体になっています。

要するに、スケールメリットを安易にとりに行くと、どんなに頑張ってもシステムが実質的にガンガン肥大化するのは防げませんよ、とこういうことです。なので、スケールメリットの享受を捨てても、ある程度、システムを細切れにした方がスピード感や透明性を保つということが可能になり、うまく回すということが可能となります。（細切りにしたからと言って無条件に見通しが良くなるというわけではありません、念のため）とはいえ、細切りにしすぎると、今度はコストがやはり増加します。

■結局
要するにバランスの問題です。

この時に考えるべき一番の要素は「人」です。個々人のあり方、チームのあり方、能力・コストを勘案し、かつそれらを時系列で判断しながら、「適切なサイズにシステムを押さえ込んで行く」ということが必要です。んで、大体できてません。

大規模システムのあり方は、徹頭徹尾、組織論です。開発方法論とか、フレームワークとか、特定実装とか、ERPとか、パッケージで行くとか、クラウドとか、AIとか、そんな話はまったく本質ではありません。勿論、これら技術要素がわからなければ、組織的な適合性が判断できないので、技術要素をちゃんと正確に把握していることは必須条件です。その上で、個々人の有り様・チームビルドのあり方（大事なのは時系列で見るということだと思います。）を、一定のビジョンをもってくみ上げていく、ということが、肥大化するリバイアサンを御することができる唯一の手段に見えます。

んで、そういうことができる人間はなかなかいないので、大抵の大企業ではシステムは人を食い殺していますね。これが現実。

要するに、大規模システムでの設計も実装も運用もわかって、最新の技術要素もわかって、人員の状況も把握し、今後の展開とシステムの在り方を時系列で把握・予想できて、組織運用のイロハがわかっていて、いざとなったらオーバーコストも辞さない覚悟をもっているスーパーマンを情報システムの頭に据えて、相当の権限を与えないと、大規模システムという内なる怪物とは戦えないですよ、ってことです。間違ってないでしょ？（ま、こんなのがいたら普通に営業総責任常務執行役あたりになりますがね）

ITは必要悪か？その1

もともとは2016年の年の初めに書こうかと思っていたことですが、時間も経ってしまっていたところ、アリエルの井上さんとの対談 　IT屋はバズワードを使ってはいけない……のか？ (1/5)：EnterpriseZine（エンタープライズジン） も あって、ちょうどいいので記録的に思うところを書いておきます。

・前提
ここではITと言う漠然とした言い方になっていますが、日本で最もマーケットの大きい、いわゆる業務システムを対象にしています。いわゆるSIの対象になるところです。と言っても一概に言えないので、売上2000億円程度の大規模企業の、下の方から、中小企業までの話にしています。売上が兆円単位の規模の社会インフラ系のシステムは、その2 ITは必要悪か？その2 - 急がば回れ、選ぶなら近道 で考えます。業務システムなのでコンシューマーものは考えてません。

・ITは必要悪という認識
基本的にユーザ企業においては、ITはコストがかかるが必要であり、できればない方がよい、という考え方が主流です。要するにITは必要悪と見なされることが多い。自分が小売流通にいた時には、営業系役員から「この「50円のもやし」と必死で売っている一方で、お前らは5000万、5億という投資を簡単にする。どうなのか？」というのは、よく言われました。それはそうだと思います。業種は異なっても、同じ事を営業系・商品/製造系の役員から言われるCIO的なまたは現場の情報システム部の人間は大勢いるでしょう。

「ITに投資しても売上は上がらないし、それならIT以外の営業資産に資金はつぎ込んだ方がいい」というのが、日本のそこそこの大企業から中小企業以下の経営陣のほぼ共通認識でしょう。間違ってはいないですね。一部のWeb系ならともかく、普通の企業がITに投資したからといって、それが直接売上げにつながるということはきわめてレアケースでしょう。

もっとも、IT以外に投資すれば売上が上がるかと言えば、現状の日本市場は、人口の高齢化もあり、消費自体が伸びていないので、ITでなかろうと、なんであろうと、素直に売上があがるということはありません。が、高齢層の企業の経営陣としては経験的な先入観がどうしても強く、ITは金食い虫で、しかも売上げ貢献が低い、というのは本音ベースでの共通認識でしょう。勿論、ITなしではいろいろ業務は回らない、ということぐらいはわかっています。

・ITの企業における位置づけ
日本のITは、というか、日本の企業はベースとしてITをその中に入れる事を拒んでいる、というか失敗しています。表向きの話はともかく、実態としてITをビジネスの中心においている企業はほぼありません（勿論、Web系の例外はありますが、企業数としては圧倒的に少数です。・・あとは、前述のように、大規模な社会インフラ系企業はのぞきます）。

営業資産はともかく、企業の主たる構成要素の「人間」を見れば、割と簡単にITの取扱がわかります。一般の企業で、ITをそのキャリアの中心（下手すればITのキャリア“だけ”で）にすえて、トップマネージメントになった人間は非常に少ないでしょう。経営層は勿論、現場でもITスタッフのためのキャリア・パスはユーザ企業ではあまり準備されていません。基本的にITはバックエンドの延長線でしかなく、経理・人事・財務とほぼ同じセグメントにあります。よって、その流れのなかでしかキャリア・デザインは提供されません。

現状のITの人材にたいする、ユーザ企業の扱いは、「基本的にアウトソースで調達する」です。主にSI屋・コンサルからの事実上「人材派遣」がベースで、ITリソースを調達しています。よほどの例外を除き、この種の派遣ベースの人間がその企業のコア人材になることはありません。勿論、情報システム部は社内の人材で構成されている、ということが多いとは思いますが、言ってみれば「アウトソースのコントローラ」であり、トータルのデザイン力・細かい設計力・実装力・運用力・障害対応能力・最新のITに対する知見について、専門家ではありません。そもそもITのプロになるために、そのユーザ企業に入社したわけではないので、当然そうなります。

「いまや、ITは社会の隅々まで行き届いて、云々」という話は、毎日のように聞きますが、普通の企業活動で必須か？無いと倒産するか？と言われれば、そうでもないので、まぁそういう取り扱いですよね、って話です。

余談ですが、このあたりが、特に米国のITとのあり方の違いになっている、というかこの20年で大きく開いたところだとは思います。Google, Amazon, Facebookの初期の頃や、AirBnB, Uberあたりもそうですが、彼らはベースがITであり、ビジネスと深く結びついているし、そもそも「必要悪」という発想はありません。Amazonと同じ業種の日本の小売業を比べて見れば、自明でしょう。米国では、ITはむしろないと死ぬぐらいに考えているし、というか過剰すぎるぐらいの企業もあるように見えます。

・で、だから何？って話
その上で、ここ最近のITのバズワードを見てみましょうって話です。ビックデータ・IoT・人工知能で、もう次はFintechですね。これらはそもそも単純な要素技術ではなく、ある種の考え方をベースにおいたITの利用方法でしかないです。ITを血や肉にして、体内の企業の遺伝子としてもっている企業が使う技術とも言えます。ITを必要悪としてしか見なせない日本企業では通り一遍のメリットすら得ることすら難しいでしょう。なにしろ、人材も組織も企業としての考え方も含めて、使いこなすベースがありません。

では現状ではどうしたらよいか？という話でして。そもそもベースがないので、ITのバズワードに乗ったところで大半の日本企業にはメリットはありません、という話なんですが、それでは身もふたもないので。そもそも論から少し考えてみましょうというのが本論。

・そもそも日本企業でITをどう考えるのか？
まず、既存企業でもう少しITを軸におけないか？という話があると思いますが、これはまず無理でしょう。企業は人で構成されています。資本や設備ではありません。従って、人の考え方が変わらない限り、企業は変わらないし、変われません。大抵の企業で働く人間、特に経営層は、ITは基本的にいらないわというよりも無くてもいいわ、と思っているので、ベースのカルチャーは「IT必要悪文化」になっています。具合が悪い事に、企業文化は一種のホメオスタシスとして機能するので、人が一人二人「いやITはコアビジネスに必須だろう」と変わったところで、「是正」が勝手に働きます。

なので、ITをコアにできない、というのはユーザ企業の今までですし、今後も企業の構成人員が変わらない限り、変わりません。つまり、現状の組織構成要素では、ITが血肉になることはまずありません。別にこれはこれでいいと思いますよ。なんども言いますがITに投資しても現状の日本では売上は上がりません。投資効率としてはあまり良くなくて、そんな金があったら、従業員の賞与に回すわ、というのは経営判断としては、多分正しい。

それでもなんとかしたい、ということであれば、以下の二つの考え方があると思います。

・必要悪のITとどう取り組むか？

1)徹底してツールとして見なす。

バズワードが完全に無視する。ITのトレンドは一切無視して、「自分に必要な武装」は何かを自社のなかでちゃんと考える。コンサルとか、ベンダーの提案とか全部無視して、ちゃんと徹底的に考える。惰性ではなく、本当にITは必要なのか？というレベルから見直す。そもそもITが自社のDNAでもなんでもなく、必要悪であれば、徹底的に無くせるところでまで考えて、考えて、必要な部分のみを精錬して利用する。いらないならスパッと捨てる。

カッコつけて「ITは我が社の背骨である」とか言わない。そうなると、他社は？とかトレンドは？とか気にし始める。もともとコアでないものに、なぜ気をつかう必要がある？

削りに削って、どうしても残ったものがあったとする。そこで、それはそもそもなぜ残ったのか？を考える。そこまで残ったにも関わらず「自社の遺伝子」でないとすれば、それはなんなのか？を考える。そこがスタート地点になる。

こういう考え方をしてみるのも手でしょう。

そうなると例えば、「ITは業務の効率化」の手段という発想も逆になります。極端に言えば、「ITで業務を効率化することが、会社の目的です」というぐらいになる。この段階で本当にただのツールか？という話になります。そこから「必要悪」ではなく、「必要なIT」を絞っていくということができると思います。

2)DNAを作る。

ITがないと死ぬ、ぐらいのビジネスモデルを「逆に考えて」会社・企業をつくる。完全独立の子会社？（若干、語義矛盾っぽい）位で、人事交流もないぐらいで作る。そもそもITはツールです。ツールを目的にすることは本末転倒ですが、その本末転倒を敢えてやる。

経営的には、多少IT的に芽が出そうだっていう時点で、案件ごと、自社から完全に切り離して、投資金額とランニングのキャッシュをフリーハンドで渡して、かつ人事的に経営的に完全に分離させることが最低限必要でしょう。バックエンドは面倒なのでシェアードで提供することはありだと思いますが。

これでも成功率は5%以下だと思いますので、こういった試みを20回程度はやらないと駄目でしょう。それだけやれば、ひとつふたつはものになると思います。実はこれはITに限らず、既存企業が新しい市場に対応するために、よくやってきた手です。後付けで「多角化」とか言ってましたが、実際は、市場拡大のための片道切符を渡して、従業員・役員ともども一か八かという賭け。大半は沈没船ですが、気がつけば子会社の方が全然大きくなった、と言う企業もあったりします。生き延びて成長している企業ではありがちな話です。

かなりハードルが高いのですが、そうそう荒唐無稽な話でもない。これだけやればさすがに無理矢理IT軸のDNAを作っていくことはできると思います。

ただしこれは既存組織と完全に切り離すことが必要です。たとえば小売流通だと、これだけAmazonに文字通り「こてんぱん」にやられて、オムニチャネルだと大騒ぎしているにもかかわらず、ITを軸にしたECは全然パッとしません。別に無視しているわけではなく、そこそこ金と人は突っ込んでいるですよね。ところが、順調にいくどころか、大炎上案件や売上としては苦戦するばかりです。なぜか？基本的に人の問題と企業の遺伝子の問題で、「日本の小売流通業」ではITは本質的に必要という認識はないからです。発想が既存の考え方に無意識のうちに制限されてしまいます。・・・そもそも店舗連携とか中途半端なこと言ってる段階で終わってるわけですよ。最後では店舗で巻き取ればいいやというオチになるので、そうなると店舗運営側は「余計なものもってきやがって」となりますわね。既存ビジネスとの分離ができてません。新しい「組織の遺伝子」がやはりできない。これは小売流通の例ですが、同じようなことは他の業界でも枚挙暇がないでしょう。

トップからエンドまでの人間が、少しでも「ITなくてもウチの会社つぶれないし、回そうと思えば回るからね〜」という考えが頭をかすめた段階でもう無理です。AirBnBとかUberとかあたりでは「ITなくてもウチの会社つぶれないし、回そうと思えば回るからね〜」なんて考えはトップからエンドまで1ミリも出てこないことは簡単に想像できると思います。要するにそういうことです。

・結局
上記二案はそれなりに、覚悟のいる話ではあります。

ITに死ぬ気でコミットできないなら、バズワードに踊らずに、「道具としての練度」をあげて、ちゃんと「必要なところだけ使え」って話です。んで、使い方がわからんなら、金かけず、スパっと捨てろってのは、別に普通だと思いますよ。・・・ただし、社会インフラ系はそうは行かないので、これは別掲。

あとは、ITは必要悪だろうというのは、重々承知の上で・・・現状の日本では「どこに賭けても負けゲーム」です。であれば、ITに張っておいても、文句は言われないでしょう、どうせ分が悪いから。・・・ということ、DNAというか企業文化の再構築を試みるのは手だと思います。中途半端に張ってもそもそも失敗するのは明らかなので、本腰いれてやったほうがよい。

実際問題として、それなりの風は吹いていて、今後のITは残念ながら（？）アプリケーションを握っていることが強点（Strong Point）になります。内製・インハウス主体で、がっちりやり込むということのメリットが従来よりも大きくなります。

これは技術的な理由です。

現状ではやはりムーアの法則の限界は物理的にあきらかで、コンピューターリソースの向上は、メニーコア・多ノード化に進み、同時にあらゆるバスの高速化が進みます。これは要するに分散処理技術に「しか」アーキテクチャ的には未来がない、ということです。そして残念ながら分散処理技術は、非常に難度が高く、まだ人類には若干早い。ただし、これは汎用ミドルという点から見た場合で、実は特定のユースケースに限定して、利用する技術を制限的に利用すれば、素晴らしいパフォーマンスをたたき出します。・・これはつまりアプリケーションをちゃんと知っているということが必要ですよ、ということです。あととは簡単に環境の構築・維持ができるクラウドも追い風になります。

ここは実はSI屋では無理があって、ただでさえ技術的に追いついていないところに、パフォーマンスを叩き出せるようにアプリからやり直せってのは、ものすごくオーバーコストになります。だからできないし、やらない。

ユーザが主体で、しっかりアプリケーションを作り込むということが、非常に大事になります。また、ちゃんと徹頭徹尾やりこめばパフォーマンスを出すことができるようになります。（もっとも、踏み込みすぎて自分でミドルの役回りまで作り出すと、ものすごく簡単に破たんします）

こんな感じで軸をつくって、会社として回るようになれば、そこそこにはいくはずです。難易度が高いので、あまりおすすめはしませんが。

追記）そーいえば組み込み・FAはどーなんだ、みたいな話もあるわね、というところですが、そもそもユーザはそれITって意識してるのか？とか、最近だとIoTとごっちゃになって、その意味では必要悪というか、むしろ不要という話もあるみたいで、はて〜という感じです。すんません。

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を縛り続けてきたムーアの法則、というかムーアの呪いが、解けた現在、その影響は普通に考えて地殻変動なみに出てくるだろうな、と思います。これもその流れの一つだろうなとは思いますし、その意味では注意はしておきたい。

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

そんな感じ。

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になる。

2017/7/29追記：正確にいうとversion orderを維持したスタイルでのserializablityの確保のプロトコルをとった場合に、である。version order自体は可変であるので、別のversion orderをとってかつGraphが非循環になるのであれば、問題ない。ただし、その判定がかなり面倒なので、version orderを維持するため（すなわち”壊す”ことができないように）順序を維持する、という言い方がより正しい。

ただし、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処理が展開される場合には、この路線の上で議論はまずまちがいなく展開されるだろう。（逆にこれがわからないと話にならないと思うので、なんか分散TxでMV系の話が合わないなと感じたら、このブログを参照してもらえばいいかもしれない。ほんとかよ。）

上記のように、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の下りは初見では、「まったく」理解できませんでした。あの部分は本当に難しいと思う。あそこがオンサイト一撃（フラッシュは駄目よ）の人は、間違いなく一種の才能があるので、ウチで採用するので連絡ください。まじで。

RSA（Rack-Scale-Architecture)

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

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

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

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

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

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

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

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

その結果が、RSA（Rack-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%のレイテンシー（驚異的なんですがｗ）でアクセス可能とか、いや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ベンダー（というかSAPとMSですかね）が論文とか出しているので、いろいろやってるみたいです。個人的にはHPLabの木村さんがやってるFoedusに注目してます。OSSですしね。この辺はあとでまたまとめます。

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

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

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

でわ。

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のコンセプトを維持しつつ、コンパイラがほぼ全面的に書きなおしになっています。従来の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回ぐらいは更新したいと思います。すみません。

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

要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤に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ビジネスのコストモデルが、旧態依然とした土建屋的なものであれば、クラウド的なサービスを取り繕ったところで、それは限界があるでしょう。手を打つべきは、仮想化やコンテナといった表面的な技術ではなく、根っこにある「基本的なビジョン」にあるような気がします。

そんな感じ。