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

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

2014-01-26

2014年のSIビジネスとかそのあたり

というわけで2014年に突入ですが・・・

景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。

とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減(または横ばい)というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よくわからないシステム」の赤字案件が急増する感じです。その兆候はいろいろ出始めています。

案件獲得については、いろいろとリスクチェックの仕組みが各SI屋さんには当然あるとは思いますが、金を積まれればやらざるを得ないわけです。やってみたらハマッタなんてのは、よくある話です。景気も良くなれば営業サイドもがんばります。そんな感じで「いろいろと無理があるぞ」プロジェクトが量産されます。というか、されています。その辺に結構転がってるし。いや、まじで。

まぁ人がいないわけです。特にできる人材不足が顕著です。これは一つは、技術的に検討することが増えていることが原因のひとつです。まぁとにかくやらなければいけないことは増加の一方ですからね。もう一つはそもそもの若手不足です。全日本的な人口減のボディーブローが効き始めてます。

本来的に言えば、ユーザーサイドである程度自衛策的に内製化的な動きをやっておくべきでしたが、残念ながら時間切れな感じです。この景気の上方回帰の流れの中で、システム投資はやれるときにやっておけ圧力が強くなりますが、とはいえ人員強化ほどの強烈なトレンドにはなりません。よって、ユーザーサイドではSI屋依存が、残念ながら強化されます。SIサイドも強い引き合いは久しぶりの機会なので、頑張って案件は取りにいくでしょう。表面上の需給バランスの一致はマーケットメイクをより強固にします。そして、この流れは、いろいろな問題を完全に先送りします。

他方、現場を見てみれば、このような状態になってくると、なかなかリスクのある新技術は採用したくないのが人情です。「だって、回らないプロジェクトさらに回らなくしてどーすんのよ」的なPMの愚痴モード全開です。案件の数だけは増えますからね。

腕のあるPMにしてみれば、今時のクラウド技術やら新技術とやら試しておきたいのが本音でしょう。SI屋自身のR&Dはほぼ削減の一直線のなか、エンジニア的には自力救済的に自分の技術力を上げておかないとまずいです。特に、今後の「新技術」はトレンド見る限り、クラウド方面からしか出てきません。ということは、クラウドの主戦場が分散処理に移っている以上、新しい技術トレンド分散処理がベースになってきます。これをSIで利用する、というのは相当ハードルが高いというか、無理がかなりあります。というか無理ですよ。普通のSIですら回らないのが現状です。

さて、割とデッドロックな感じのSI所属や業務系のエンジニアはどうするのか?というのがたぶん今後の話題になります。というか、既に各所でなっているみたい。見切りをつけて某携帯ゲームさんに鞍替えした方々は、途端に土砂降り状態で手持ちの傘がないという状態のようですし。

んで、どーすんだって話しなんですが・・・まぁ実も蓋もないのですが、見ていて思うのは、結論的には「転職含めて進路をじっくり考える」機会到来かなと思います。お前が言うな、って話はあるんですが、新年なんで書いていいかと。

予想ではありますが、今後5年は国内のエンジニア転職のチャンスだと思います。おそらくここ20年で一番の機会ではないかと。主として理由は以下です。なお、行く先どこよ、って話ですが、まずは回復基調にあるユーザー企業さんになるでしょう。

1.景気の上向き時は人・もの・金が動くので、転職自体がしやすくなる。
これは異論はないと思います。選択肢が単純に増えます。

2.SI限界を目の当たりにしたユーザー企業の自衛策も(それなりに)出てくる。
良質SIの減少はまさに、悪貨は良貨を駆逐するがごとく不良案件が増大してきます。自社体制の増強は各ユーザー企業にとっても焦眉の急です。ある程度内製化を考えるところでは人を取り始めるでしょう。(まぁそう簡単にうまく行かないと思いますが・・)

3.ユーザー企業自体の統合が進むので、IT部門の強化や投資需要が増大し、人員許容のキャパが増える。
今後の景気回復は、特に労働集約的産業でのM&Aを加速させます。人手が足らないという流れは、間違いなく賃金上昇圧力になり、そのまま人件費の高止まりどころか上昇になります。各企業は、その賃金上昇に見合うだけの労働生産性の向上が必要になりますが、これは当然投資余力があるところに限定されます。要するに、なんとかぎりぎりなところは、「注文はくるが、その量とそのコストでは捌ききれない」という状態になります。結果、業界のトップエンドがどんどん成長するが、二位以下は突き放されるという結果になるでしょう。当然の結果としてM&Aが進みます。これは情報システム部門の統合にそのままつながります。トップエンドでは人員の増強に入るでしょう。(統合された方は必要な人材を残してリストラ対象)

そんなわけで、人は動く時期が来るかなとは思います。では、今後の方向性として、どう考えればよいか?ということですが・・・

■完全安定志向の人
えっとですね。この場合は、移動不可です。SI屋に張りついてどう生き残るか?に徹するべきです。ただし、基本的にじり貧は覚悟すべきです。消費税は上がります。実質可処分所得は減少します。また、管理職以上のポストは老年層の独占になり、結果、出世と給与の上昇はきわめて厳しいです。しかしながら、SI市場はデスマが増加するとはいえ、マーケットとしては強固ですのでそれはそのまま残ります。そのレベルでの生活は保証されるでしょう。土方で頑張る。デスマで生きる。これも人生です。職業に貴賎なし。ローリスク・ローリターン。余計な邪魔はしないでください。これも選択です。

■ある程度リスクは仕方がないという人
ハイリスク・ハイリターンとか、ローリスク・ローリターンだと普通に死ぬので、ミドルリスク・ミドルリターンな人。まぁこんなご時世です。リスクフリーが一番良いけど、そんなこと言っても、ないものねだりですし。
こういう場合は、各マーケットのトップエンドに近いユーザー企業あたりが一番いいと思います。市場は広がってくるかなと思います。ただ、特にユーザー企業に軸足を移す、という人は老婆心ながら以下に留意された方がよいかと。

1.エージェントは使わず、自分でちゃんと探すこと。
エージェントは使っても情報収集程度にする。必ず自分の手で「十分に調べる」ことが重要です。会社の雰囲気。トップや経営陣の資質。情報システム部の評判。時間はかけて構いません。最悪数年は調査にかかる位の気持ちが必要です。焦る必要はないと思います。「従業員をちゃんと採用します。」というところと話を継続的にすべきです。特にユーザー企業に移るのであれば、とにかく調べるというスタンスが大事です。

2.中規模以下の企業に行くときにはそれなりの理由が必要。
上記のように、中途半端な立ち位置の企業は、トップエンドに近い将来吸収されます。転職先がいきなり吸収・合併されて、速攻で追い出されましたでは立つ瀬がまったくありません。今後の5年は今まで以上に凄い勢いで「惰性で生きてきた」企業は姿を消すでしょう。強いアゲインストや、強いフォローの風では企業の経営の巧拙は、顕在化しません。「若干フォロー」という状況は企業のスタンスがまともに差にでます。しかしながら、敢えて自ら中小企業+業界で随一のものがある、ところは別です。それは別に考えた方がいいですね。こういうところのITはそれはそれで面白いので、選択肢としては考えるべきでしょう。

3.朝ちゃんと起きるということができるようになっておくこと。
これ実はエンジニアにはハードル激高いというのは現実ですが・・まぁユーザー企業で働くには普通にできないといけません。転職時には気力・体力が削られますので、朝早く起きてジョギングでもして、体力をあげておくということもよろしいかと。まぁ、大抵のエンジニアの方はこの辺でアウトですが・・・単純に「郷に入りては郷に従え」ってだけです。

4.当たり前ですが「自分に投資しておくこと」が今まで以上に重要。
当たり前ですが、「自分を売りに出す」ということは「自分の売りものはなにか」ということを明確にすることになります。ユーザー企業に行って自分は何ができるのか?気がついたら、外注管理とパワポ・ワード職人でしたって人はやはり厳しい。とにかく、手を動かすようにしておく。PMになってくるとパワポやワードはうまくなりますが、あっと言う間に手が動かなくなります。コンサル系の仕事は、よほどその業界の事情に詳しくない限り、ユーザー企業に移った段階でSI屋叩きの仕事専従になります。

お勧め案は
・とりあえずクラウドが使えるようになっておく。これは便利。
・簡単な数学ぐらいはマスターしておく。別にデータサイエンティストとかイラン
・要件をどう切り出すかの手法は自分なりの方法を確立しておく。
・運用でヤバイところはどの辺かアタリがつくぐらいの経験は積んでおく。
・せめてjavaと普通のSQLは使えるようになっていてください。お願いします。

趣味みたいなプログラミング言語とかマスターせんでいいから、上の内容を押さえておけば、来てくれというユーザーはたくさんありますよ。すげー、あります。

■一攫千金の人
ハイリスク・ハイリターンですよ。え、なんでSI屋にいるのかって?それはトレーニングとノウハウの吸収ですよ。捲土重来・虎視眈々、機会を見て旗揚げですよ。という人は、まず上場しそう会社に潜り込んでください。すげー増えてるみたいです。(遠い目
運が良ければストックオプションでウハウハです。また、その他にもいろいろわかると思います。正直、(自分の立場は置いておいて)いきなりの起業はお勧めではないです。先の起業まで考えている人は、まずは転職先で、できれば営業をやってみてください。如何に自分や周りがいままで看板で食えていたかわかります。その上でどうするか考えるべきです。

まぁなんというか、デスマ警報を逃さないようにしつつ、いろいろ調べてみっか、という季節になりそうですね。自分的に他人に転職指導とかしている場合じゃないのですが、某雑誌にお先真っ暗なエッセイとか書いてしまったので、そのフォローでございます。どうぞご自愛ください。

2013-12-24

AsakusaはなぜAsakusaというのか

このエントリーは、Asakusaアドベントカレンダーの24日目ですね。
http://www.adventar.org/calendars/200

いろいろ各所で聞かれる内容であるので、一応、非公式記録として残しておきます。諸説あってどれが本当か、もはや今となっては記憶も定かではないわけです。

前提)Asakusa系の名前は、放っておくと勝手に開発者のTwitterアカウント名がつけられて相当ヤバイことになる。

Asakusaの開発でもっとも工数がかかるのが名前付けであります。(誇張なし。)これは理由は簡単で、命名は大抵は合議制なんですが、あんまり関わりはしないのに「いや、その名前だけは許せん」という発言者が多いということと、実際、かなりイマイチな名前が最初はつけられることが多いためです。結果、工数がかかる。

(ただし、中の人の性格がきわめてひねくれている人が多いので、アレ系の場合は、瞬発で決まりますね。例えば、Monkeyなんとかがいろいろとアレだったので、その代わりに作られたJenkinsでのジョブ管理Plug-inが「Monkins」という名前になったわけですが。体感で5秒ぐらいで決まった気がします。これはひどい。)

まぁ、いずれにしろ、ネーミングはもめるので、時間切れの場合は、その方のTwitterアカウント名がプロダクト名になることが決まっているわけです。んで、そのままだと某御徒町方面になりそうな感じもあったのですが、いや、それは待て、ということでAsakusaに決まったわけです。(時間切れの例はAshigelコンパイラ

んで、由来ね。

通説多数説)
1.とりあえず一般(ユーザー部門とか、一部海外とか)受けしそうな名前にしてみた。
これは全日本的にですが、なるべく覚えてもらえる名前、というのはいろいろ便利ではあります。「浅草」という地名を知らない日本人は多分いないし、外人でも知っている人は知っていると思われるので、そのあたりを狙ってみた。これは実際にはそこそこに成功しており、海外はともかく、国内では、開発元のノーチラスは知らなくても、Asakusaという名前は(中身はわかんないけど)聞いた事がある、という感じでは人がちょくちょくいたりします。

2.Aで始まる
ABC順・あいうえお順で頭にくるというのは、アピール度合いでは、かなり有効である、というのは昔から聞く話ではあります。ので、「A」または「あ」で始まる名前を命名しました。対抗は実は、Akasakaでして、こちらは前から読んでもAkasaka 後ろから読んでもAkasakaというアピールポイントもあるので、捨てがいたいものがあります。とまれ、「A」または「あ」で始まる名前に一般に目立ちます。

3.そもそも地名は商標上トラブルにならない
地名商標登録できません。はい。よって、逆手にとってトラブルになりにくいということになります。誰も登録できないので、もめ事になりにくい(例外はなんかあるようですが。ナイヤガラなんとかとか)ので、事前にそのあたりを回避するという作戦をとったりしてます。ただし、これは諸刃の剣で、SEO対策としては最悪に近い。一般にAsakusaはググらビリィティが低いと言われますが、それはそーです。普通にAsakusaでググれば、「浅草」がヒットしますわ。この辺は痛し痒しかと。

4.関連商材が多いので、割とサブプロジェクトの命名が楽
浅草は観光名所ですので周りにいろいろあるわけで、そのあたりがいろいろ関連プロジェクトの命名の、もとネタを考える時に結構楽だということがあります。実際、Asakusaの入出力管理は、浅草への入り口ということで、雷門から取っています。すなわちThunder Gate。んで、雷門守護神風神雷神なので、Thunder Gate/ Wind Gateがサブモジュールとしてあります。あとは、インストーラーとして、Jinrikisha(人力車)がありますね。今後も、人形焼き・花屋敷・スカイツリー仲見世とかいろいろあるので、それなりに命名を考えるときは便利です。

少数有力説)
1.首謀者が単にその近所に住んでいる
首謀者の某御徒町方面が、上野浅草御徒町方面に、かなり長く住んでいるので、そのあたりの愛着もあるということのようですね。この界隈はまぁとにかくいろんなものがあるので・・・フルスタックフレームワークとしても、ちょうどいいかと。業務系ITは、理屈で割り切れるものではなく、それなりに関わった人の匂いがするものです。なので、Asakusaという名前は、その対象から考えてもなかなかマッチしている気がしますね。
どうでもいいですが、浅草は日本で唯一毎日寄席をやっている場所でもあります。落語の噺は、いろいろとアナログ的な利用ができるので、IT屋的にも覚えておくといいです。オブジェクトの等価性と粗忽長屋とか。

2.Hadoop関係の飲み会が浅草近辺で多かった
うむ。これはまぁ仕方がないですね。以前のHadoop大忘年会とやらも浅草米久」でしたし、中年Hadoop愚連隊(成員は内緒)の地獄の焼き肉大会とかもAsakusaだったりして、気がついたら浅草ビューホテルの地下のバーで、飲み過ぎて終電なくなっちまいました的なアレも多かった感じです。まぁ必然かと。

以上、どうでもよいネタでしたが、Asakusa今後ともよろしくお願いします。

2013-11-10

ノーチラス二年目終了して三年目へ

二年経過したので記録として置いておく感じで。

ということで気がついたら設立から二年経過していました。正直、まだ二年しか経過していないのか、という感じがします。この一年は二年分ぐらいの時間感覚でした。まじで時間経過が速すぎて死ぬかと思った。去年の今頃はAsakusaの立ち上げで、特にSI屋向けのサポートに力を入れていた時分で、今と状況がまるで違う状況でした。この一年では大きな試行錯誤を二回ほどやった感じになっていて、現在ではAsakusaの向こう側の違う方向性の模索し始めているところです。

大きな方向性としては、この一年で以下が大きく違ってきていると思います。

1.クラウド・コミットが普通になってきた、とはいえ、一方でまだまだというところも実情。
元々クラウド上で構築や作業や環境の獲得は普通にやってきましたが、やはり、春先の西鉄ストアさんの基幹業務系をAWSで動かしたというのは、それなりのインパクトがあったと思います。日本でのファーストケースになった実績という対外的な意味もありますが、社内的には「AWS?いや別に業務系で普通に使えるけど?」という感覚になっています。(社内にいると普通に常識になっているけど、この感じは日本ではまだまだ多分特殊だと思います。)

一方で、日本での業務系のクラウド受容はまだまだ、という感じも受けています。まずは文化的な問題が一番大きいでしょう。「クラウドを使わない」という選択は、本来的にはクラウド固有のメリット・デメリットを把握しつつ、いろいろ試行錯誤した結果としての、積極的な非選択という形が望ましい(おそらく海外ではそういった流れになっていると思う)のですが、日本では、触りもしないで評論・敬遠する人も未だにおおいのが実態です。ただ、今後はクラウドを実際に体感した上で、「選択しない」という方向も出てくるでしょう。いろいろ体感した上での選択と、評論家的な選択では意味はまるで違うのですが、表面上は同じに見えてしまうな、と思っています。あまり良いことではないですね。

可用性の強化や運用負担のコストの低減、ソフトウェアをハード環境から引き剥がすことによるライフサイクルの管理強化等、業務システムのクラウド化は相当のメリットはあるわけですが、そこまで進むのはまだまだですね。ということがよくわかる一年ではありました。

クラウド化については、今後はどうなるかはちょっと不透明だなと思っています。クラウドのメリットは非常に大きいけど、その一方で、サポート問題も含めて業務系で使うには、それなりの課題があるのも事実です。大規模業務で使いこなすには技量と経験が必要でしょう。

2.ユーザーさんの試行錯誤のコストが異様に高いこともわかってきた
これは間違いなくユーザーさんのIT部門の弱体化が原因だと思います。SI屋さん以上に、ユーザー側の弱体化のほうが致命的になりつつあるな、という感じがします。正直、人を削りすぎた後遺症が発生している感じです。先に向けての試行錯誤ができていません。

スタッフ部門の役割はバックエンドの事務処理ではありません。フロントとは別の視点からビジネスを俯瞰して、会社の戦略・戦術案を経営層に提示することが仕事であるはずです。これはIT物流・人事・調達すべてにおいてそうなるはずなのですが、全般的に人手が足りなくて機能不全になりつつあります。まわすので精一杯という感じです。

人員削減の埋め合わせとして期待したSI屋さんへのアウトソーシングも、SI屋さん自身の技術向上の劣化がキャップになり、ただの人員派遣になりつつあります。アウトソーシングは、ソーシングがなくなってしまって、ただのアウトだろ・・というところもあります。

スタッフ部門の人員不足は、以前はリストラ的な意味合いでの積極的な人員削減がベースにあったのですが、最近はむしろ、優秀な若年就労層の縮小で、そもそも補充が効かなくなっている気がします。ユーザーサイドでは、この現状について有効な手を打てていないどころか、問題として認識すらしていないところもあり、先はなかなかに厳しいでしょう。

僕らのようなエンタープライズで勝負しているベンチャーは、このあたりの状況には積極的に対応していかないとまずいわけですが・・・いままでもこれからもこれは課題だと思います。

3.ビッグデータの「次」がポイントになってきた。
本来、Asakusa等は「ビッグデータ」とは違うドメインにいるわけですが、プラットフォームとしてHadoopを利用している手前、どうしても「ビッグデータ」ブームの流れには巻き込まれてしまいます。場違い的に呼ばれることもしばしばありましたし、今もあります。とはいえ、分散環境の普及は自分らにとっても歓迎すべきことではあるので、一応距離を取りながらフォローしているという状況です。んで、この一年を見てみると、かなり進み方が変わったな〜と思います。

現状の「ビッグデータビジネス」は、世の中で期待されるサイズには届かない一方で、そこそこビジネスになっているところもあるね、という一年だった気がします。従来のCRMや分析的なマーケットよりは、確実に拡大しているけど、少なくとも二倍以上にはなっている感じはしません。いわんや、マスコミの方が言われるマーケットサイズにはまったく届いていません。うまくマネタイズしているところもある一方、まったくお金にできてないところも多いです。なんとかビジネスになっております、というぐらいが関の山でしょう。

全体の傾向としては、「もっとデータをちゃんと使った方がいいわね」という非常に当たり前の結論が、当たり前になってきているところが、ここ一年で確実に違ってきている点だと思います。ただし、この「データをちゃんと使いましょう」という発想は従来からもあったわけでして。それがうまく回らなかった理由は様々にあったわけですが、その反省はされていません。なので、また肝心なところで詰まる可能性は高いと思うし、実際詰まっていますね。

現在のビッグデータの利用での成功は、かなり限定的でリコメンデーションや不正検出のフィールド等の一定のドメインに限られていると思います。これらが成功している理由は簡単で、サービスのデリバリーに「不必要に人間の介入がない」からだと思います。データを利用した業務向上は、データ分析の結果をどのように業務に反映させるか、という点が大切です。これは40年間変わっていません。このためには、携わる人間のマインドセットを変える必要があり、これは非常に難易度が高い。

データをちゃんと見ましょうということを業務に活かすのであれば、現場、管理職、経営上位層のすべての階層にわたってマインドセットを変えていく必要があり、統計解析ができる人間をそろえればよい、という話ではまったくありません。ビッグデータ系のIT屋・コンサル・評論家・書籍・データサイエンティストな人たちを見ていると、意図的に、この「マインドセットを変える」という論点を避けているように見えます。曰く「それはユーザーさんの仕事です。」それができれば苦労はないです。

そもそもビッグデータに限らず、なんらかの業務メリットをとるために、関わる人間のマインドセットを変える必要があるIT技術は、導入にハードルが高いのが相場です。その上、中間管理職が壮年層から老年層に移りつつあり日本では、「マインドセットを変える」コストはさらに天井知らずです。なおさら導入が困難なのが実態でしょう。

要するに今の路線ではうまく行きません、ということも明確になったと思います。とはいえ、データを利用していきましょうという機運はあるわけで、また成功している事案もないわけではない。観点もそれなりにある。よって「ビジネスにするには、何がまずくて、どうすればよいか?」を模索していく段階になっていると思います。まぁ次の一手を考えましょう、とそんな感じかと思いますので、この辺は横目に睨みながらいろいろ考えるというのが今後ですね。

4.次に向かっていかないといけませんね。
んで、3年目のノーチラスはどーすんだ、という話ですがAsakusa-Hadoopはそれはそのまま拡大路線は続けていきます。ユーザーさんも確実に増えていますし、「ま、バッチ処理時間は短いにこした事はないし、確かに分散させればそれは速いよ」という結論は出たと思います。これはこれでいいと思います。

Asakusa-Hadoopの導入だと「分散環境を準備するための、まず環境コストが高い」という課題があったため、ここ半年ぐらいは、Asakusaの実行環境としてのクラウドを開発、提供してきました。んで、そのフィードバックとして前述のように業務系のクラウド移行が事前の想定よりもなかなかハードルが高いということも見えてきているので、オンプレ・クラウドの両者を見ていく必要があるな、と今はそういう感じです。

それに加えてもっと「ユーザーよりの方向」に進めて行きたいと思っています。もともとそちらが自分の得意なフィールドではあったので、そちらに軸を打つ方向で次の年は進めたいと思っています。個人的には業務系処理で重要なのは「データ量」ではなくて、「計算量」だとおもっているので、ちょっと現在のビッグデータ的な流れとは違う目線で進みたいなと・・「分散処理を業務に利用するとこんなこともできますよ」ってのを出せればいいな、と思っています。

 例によって一緒にやっているメンバーとは
「こんなんあるとオレ的に画期的だけど、どう思う?」
「オレ的に画期的の意味がよくわかりませんが・・・それができればそれはそうでしょ」
「技術的にはギリできそうな気がするけどw」
「技術的にはギリ無理そうな気がしますがw」
なんて会話しながら3年目に突入してます。

いろいろやり方が試行錯誤できるのがいいところなので、そんな感じです。この試行錯誤も「もっと早くやれ」とか「もうちょっと様子見ろ」とかいろいろ意見がありまして。このあたりは・・まぁ苦労しています。いやはや。まずは体調第一で。

というわけで3年目なので、今後とも宜しくお願い申し上げます。

2013-09-23

業務系システムのクラウド適用の現状

2013年の夏・秋の状況の整理として記録しておきます。数年したら変わっているか、そもそも自分の仮説が違うかわかるのでそのポイントとしても記述しておきます。

4月以降、「業務系システムのクラウド化」ということで、顧客各社やマーケットへのヒアリングを行ってきています。対象はいわゆるWeb系は除いてあります。曖昧な言い方になりますが一般に「IT業界でエンタープライズ」と言われるセグメントにフォーカスしています。結果としてわかったのは、企業のクラウド利用についての意識は、言われているほどには高くはない、というのが現状です。ただし、これは一様に低い、ということではなく、かなり業界やセグメントや企業規模によって違いがあります。この違いの要因と今後どのようなところに影響するのか、というのが興味の焦点です。尚、これは自分個人の印象や某社でのヒアリングの整理のみをよりどころにしているので、たかだか200社弱程度のサンプルでしかないです。そんなわけで合っているかどうかは各自で勝手に判断してください。

また、クラウド利用については、特に「バックエンドの業務系の仕組み」のクラウド化に絞っています。Web系のフロントの仕組みとしてのクラウド利用については、ここについてはそれほど異論は見受けられません。単純にフロントのサイトだけを立てるという意味ではレンタルサーバーの延長線上(というかほぼ同一)の見方としてクラウドを利用する、というスタイルは普通のユーザー企業で一般的です。

この種のクラウド利用は、エンタープライズ企業においては「とりあえずクラウド対応しておけ」という経営陣のいかにもな指示に現場がとりあえず応えたというものが散見されます。特にB2Cのビジネスに強くコミットしているのでなければ、フロントに対外的な強力なサーバーを立てる必要もないので、とりあえず使ってみたいという要望にはうってつけというものが多いですね。よってその用途で使われるという事になります。また情報システム部経由だと予算や稟議の兼ね合いで社内処理が面倒なので、広報等の部署が費用化できる範囲でアウトソースの一つとして利用しているケースもあります。

いずれにしろここでは、このレベルではクラウドを利用しているとは言わないとします。

企業がクラウドを利用している、という意味では後段のバックエンドの仕組みとして利用しているか、どうかが大きな試金石になります。逆に言うと、バックエンドでクラウドが利用できないのであれば、企業ユースでのクラウド利用はインパクトはあまりないですね。(あくまで個人の意見です)

それで、バックエンドの業務系の仕組みの実行基盤としてクラウドを見た場合ですが、まず企業レベルでそもそも意識がかなり異なります。大手企業においてクラウドに注意を払っていない企業はない、というくらい意識はあるように見えます。実際に「検討はすべきではある」という声も多いです。その一方で中規模会社においては、その存在すらも視野の外、というのも現状です。これは、中規模以下の企業の、情報システム部のそもそも実態がきわめて弱い、ということが原因として大きいです。

[中規模会社以下]
中規模以下の企業については、ヒアリング・営業をした先では、件数として多かったのはERPやパッケージを導入かつ、SI屋に丸投げという状況です。クラウド以前の話として、そもそもIT投資自体も主導権がない、という企業もかなりの確度で散見されています。遠目で見ると、結果として資本装備率が低く、よって労働生産性の向上の余地が少ないように見えます。

本来的には低い資本装備率でも稼働できることがクラウドの一つのメリットなんですが、この前提にはそれを使いこなす人材の存在があります。中小規模企業ではそもそも人材の確保が出来ていません。よって、クラウドでのレバレッジのメリットは、中小規模企業では現状のままでは享受することが難しいという印象です。クラウドにしろ、SaaS(公共系の某SaaSが典型ですが)にしろ、初期コストが不要で、中小規模企業向きというメリットがあると喧伝されていますが、実態としてはその受け皿の中小規模企業は自社の人材のアウトソースをSI屋に丸投げしているため、まったく利用できない形になってしまっているようです。

余談ですが、個人的には、この現状は今後の中小規模の企業の行方の試金石に見えています(もちろん、外れる可能性も大ですが)。日本の産業構造的には、今後の労働市場では就業人口の供給が少なくなることが容易に推定できるため、景気の上向き時には賃金上昇圧力はかかることが想像されます。この場合は中小規模会社では、賃金上昇に見合う生産性向上が本来は必須なのですが、投資余力がなければ対応ができません。たしかにIT投資としては、そのひとつの例にしか過ぎないとは思います。しかし、今後の物流ITへの投資能力が、各企業の投資余力のリトマス試験紙であることが多いことを考えると、今後の公共投資を中心とした(闇雲の)景気回復はむしろ中小企業にとっては決してプラス要因にはならないでしょう。むしろ、(現状よりもさらに)統合を促すことになるような気がします。逆に言うと、中小規模であってもクラウドを利用するようなレバレッジを効かせられる企業であれば、生き残る機会はあるかもしれません。が、現在はこのような企業は例外でしかない印象です。ま、個人的な印象です。

いずれにしろバックエンドのクラウド化というのは、中規模以下の企業のセグメントでは一部の例外的な扱いになるでしょう。例外的な企業やユースケースをピックアップして、「クラウド化は進んでいます」という声も”いろいろな思惑”から聞こえますが、少なくとも自分らの現場の素直なヒアリングの結果は正反対になっています。

ということでは問題は以下。

[大規模会社]
大手企業におけるクラウドの位置づけ
セグメントによって大きく異なる、というのが現状のとりあえずの結論ですね。しかもかなり、あからさまに違います。これは各産業の歴史的・文化的な背景が大きいという印象があります。もちろん、ま、社内でも異論はかなりありますが、個人的な経験にも一致する印象なので、それほど間違っている気もしません。

金融証券・保険、および社会インフラ
 ベースとしてクラウドの利用はあまり考えていませんねw。勿論例外はありますが、例外に過ぎません。現状では数社程度でしょう。(繰り言になりますがバックエンドでの利用という意味です。フロントエンドでの利用であれば、なんらかの形で利用しているところもそれなりにあります。)それ以外は利用は毛頭考えていない、というのが現状です。

 勿論、当局の規制、という側面はあります。実際、当局サイドの指導がなければ検討したい、というところもあるにはあります。が、では当局がゴーサインを出したとして、積極的に利用するか?ということに関しては疑義が残ります。(実際のところ、当局は明示的かどうかは別としてゴーサインはすでに出しているという話もあります。)

背景はそもそも以下ですね。

・そもそもインフラでは困っていない
 金融・社会インフラをはじめとした規制産業は、例外を除き基本的に保護産業としてスタートしているため、コスト意識が相対的に低いのが現状です。異論は各種あるとは思いますが、少なくとも、後述する流通サービスのセグメントに比べるとその差は残念ながら歴然です。
 したがって、多少のオーバーコストであっても社内にインフラを持つことが可能であり、良くも悪くも、インフラコストが一気に増加しないのであれば、既存のインフラを保持する方向を選択することが最初の選択になります。この点でクラウドの利用は積極的ではありません。

・あくまで自分のコントロール化で情報システムを管理することが責務であるという意識が強い。
 当局が要求する過当競争からの保護の見返りは、社会コストの負担です。その一部は間違いなくすべての顧客をちゃんとサポートしろ、ということに帰着しています。したがって顧客情報・個人情報の維持は企業としての責務であり、情報流失のリスクが最終的に定量化できないクラウドは一義的には敬遠されます。もちろん、セキュリティレベルが自社とクラウドでどちらが高いのか?という第三者的な定量的定性的な分析では、一概に言えない(むしろクラウドの方がリスクが低い)というオピニオンは出ていますが、自社でリスク管理を行うことが社会的要求という背景がある以上、本来的にクラウドは使いにくいという側面は常につきまといます。
 また、クラウドセキュリティの「セールス・トーク」の大半がワールドワイドでFUD的な印象が強いのも腰が引ける要因に見えます。

○大規模製造業
・そもそもバックエンドに大きな仕組みが必要か?という問題もあります。IT的なバックエンドとして、FA的なものとの一体導入という意味ではERPが非常に浸透しており、同時にSI屋依存も強いです。その点ではバックエンドがクラウド化に進むのか?という問題はERPベンダー依存になっています。もちろん、販社のような組織体を同時に持つようなケースもありますが、この観点からは、後述する流通・サービスにその性格が近いでしょう。

・生産管理的な側面から見ると、ITのあり方としては、「巨大装置産業のデータ処理」という位置づけが強いですね。この場合、そもそもデータ量と処理能力がオンプレミスでまかなえるのか?という話が主軸になります。ここでクラウドの利用についての検討が始まる可能性があります。特にデータの取り扱いは、「よりリアル(というか細粒度と多層化)」というざっくりした方向性がマーケットの要請になってくるため、粒度感はともかくレイヤーリングは従来のようなSCM的な「横のつながり方」ではなく、より上位・下位に多層化し、より複雑化していく可能性があります。この場合は、さすがにオンプレミスでの計算空間ではサポートができません。この分野はまだまだ検討の余地があり、クラウド利用の可能性は高いと思われます。実際にそのような用途でクラウドをちょいちょい試しているという話も聞けてはいます。

ただしこの場合のクラウド要求は、従来とは異なり以下の二要素が求められている気がします。

・インスタント的な要素
収縮性はいらない、Elastic性は必須ではない、ということです。要するにまとめて計算機をある期間貸してくださいよ、とこういう要求に見えます。この場合はなるべくその期間で「いきなりスムーズに」借りられるということが大事ですね。そういうスキームが必要とされているように見えます。現行のクラウドのサービスとはちょっと違う感じです。「大量のレンサバを一気に簡単に借りる」という方向の方がむしろ近い気がします。

・貸しスタジオ的な要素
ある程度のテイラードのサービスをやってちょうだい、というニーズ。これ現行のクラウドと全然違います。ベア・サービスではなく、とはいえフルカスタムでもなく、ASPでもない、なんというか一種の「簡単なSI」なんですけどね。こういうニーズが強いように見えます。現行のSI屋さんだとこれは間接オーバーヘッドが強すぎてコストが合わないのですが、専門のブティック的なところだとうまく回るので、中小のSIがうまく回せるチャンスがある気がします。現行、徐々に中小規模のクラウドSIが頭角を現している現状も背景としてはマッチしてると思います。

○流通サービス
 前述の金融・社会インフラと対照的に、流通・サービスのセグメントの大手企業でのクラウドの積極的な利用は、各産業別に見た場合は群を抜いています。現状の業務系システムのクラウド利用の事例のほぼ80%がこのセグメントに集中しているのは故なきことではありません。確かに表に出ている絶対件数は少ないと思いますが、少なくともクラウド利用に対する抵抗感のなさは異常とすら言えます。

・非常にコストコンシャス
金融等の保護産業とは異なり、流通サービス業はむしろ当局から「規制される産業」であり、今現在もその流れにあります。常に競争に晒されており、また、競争優位になった途端に手足を縛られるということ方が多いのが実態でしょう。結果として、コスト的な余裕はまったく取れない環境におかれているようです。そのため、産業として相対的にコストコンシャスであり、その意味でクラウドへの注目が非常に高いです。曰く「一円でも安く」というカルチャー。コストコンシャスな割にはデータが量が多い、ということもこのセグメントの特徴です。

・使えるモノはなんでも使え
産業的に、使えるモノはなんでも使うという文化も背景にあります。これは過剰競争からの顧客ファーストの発想の延長線上に、手段よりも目的を重視しないとやっていけないという文化があるためです。目的達成のためなら手段の重要性は下がる、というプラグマティックな発想ですね。ま、このため、正直、オンプレとクラウドの区別はまったくしていない、というユーザーもかなりの確度で存在します。金融・社会インフラ業界とは好対照です。

という感じで、各セグメントでのバックエンドのクラウド利用のスタンスは、かなり異なるという印象です。

以下はこういう文化的な差がどうなるか?という個人的な予測です。たぶん外れます。が、こうなる可能性はなくはないです。

クラウドを技術的な位置づけから見たときに

現状のIT側の新技術はハード・ソフトを含めて、ほぼすべてクラウド・サイドから供給されつつあります。したがって、IT技術へのキャッチアップはクラウド上で発達した技術を自分のモノにするということの延長線上にあります。その意味では、クラウド親和性のある流通サービスや製造業IT技術選択の先端に進む可能性もなくはないですね。つまり、現在の各セグメントにおけるIT技術の使い手としての優位性が、従来の金融系・社会インフラ系のセグメントから、流通や製造のセグメントに移る可能性があると思っています。

確かに汎用機・オープン系の採用や検討実績は、間違いなく試験研究のレベルではよりコストをかけられる産業の方が技術優位であることは間違いありません。実際にユーザー・セグメントから見た場合に、ITの先端性は金融・社会インフラ・通信と言った産業が常にリードを取っています。現状のスタッフィングや技術をドライブする能力、評価・実装・維持メンテ能力の人材のトップノッチは、間違いなく、金融をはじめとした社会インフラ系に人材が偏っているのは事実です、これはあと10年は変わらないでしょう。

とはいえ、技術選択・維持の能力は、採用している全体の環境に制限されます。いかに優秀な人材を抱えていても、新技術の発現ドメインに業務として直接コンタクトできないのであれば、総合的な技術力の向上も鈍化します。その意味では、普通に行けば、ITにおける従来の金融・社会インフラ製造業・流通サービスの構図というのは変わらないのですが、クラウド技術の利用という点では、この図式は変わる可能性もあると思っています。このあたりのユーザー・セグメントへの勢力図はITセグメントのあり方にも一石を投じるかもしれません。

こんな印象を漠然ともっています。今後どうなるかですね。・・・

・・・・・・・・・・

以上は、実は現行のクラウドオンプレミスのあり方の構造が大きく変わらない、という前提での観察なのですが、この話とは別に“オンプレミス”の位置づけが「対クラウド」という意味で変わってくるかもしれないな、と最近思っています。

「今のところの新技術」は残念ながらクラウドからしか出てきていないということで、クラウドベンダーの技術優位がはっきりしているのは間違いないのですが、これは実は例外があってユーザーそれ自身がクラウド的なものを“オンプレミス”で実装し始めるということになると話は全然変わる、と思っています。えっと、誤解のないように言っておきますが、これはいわゆる“プライベード・クラウド”と今言われているものではないです。まったくの別ものです。本来であれば別の言葉を当てるべきですが、今のところは適切な言葉がないですね。

クラウドベンダーと「オンプレミス」ユーザーの競争について

ここが現在の興味のある部分です。日本企業はユーザーとベンダー両者含めて、残念ながら(一部を除いて)この競争の圏外なので、もっぱら海外での話になります。

現行のクラウドベンダーの技術的な最大の競合は巨大ユーザー企業になる可能性があると思っています。もっとも、そもそもクラウドベンダーとは名ばかりで、オンラインでの大規模小売と広告業が代表選手で、実際は巨大ユーザー企業ですよね?ということであればその通りなのですが。・・・ま、一応俯瞰で見れば、MSIBMAWSGoogleクラウドに負けたという図式は、ピュアITがユーザーITに負けたという絵ずらにも見えるわけでして。んで、その勝者たるAやGに対抗するところはどこか?といえば、要するに別のでかいユーザー企業が本気出したとき、というのはあり得る話ではあります。

要するに、まだ登場していない(実際は登場してますが、ステルスモード全開っぽいです・・)別の巨大ユーザー企業がクラウド的な技術を「オンプレミス」的に発展させて、突然技術競争のトップに出てくるという、そんな話です。現在のクラウドベンダーの本質的な弱点は、アプリレイヤーからハードの下の建屋や土地までの一気通貫での最適化が難しいということです。そこをつくことができるユーザーは確かにいるでしょう。何しろ業務系アプリケーションの性格・必要性・課題を全部手元にもっているのがユーザーなので。ま、クラウドベンダーの人たちは鼻で笑うかと思いますが、いろんなプレイヤーが暗躍しているように見えます。油断大敵かと。

クラウド系の技術の一角は大規模分散系処理であることは間違いないです。前提としてはある程度の大数の法則が効くレベルのサイズが必要ですが、そのような本当の意味で“ビッグ・データ”を持っているグローバルのユーザー企業はいくらでもあります。(極東の某国ではデータを持っていないユーザー企業が多いので、マスコミやその手のコンサルタントの方々が、なんとか商売にするために、”ビッグ・データ”を矮小化する傾向が特に強いのですが、本質的に間違っていると思います。非常に退行的で褒められたものではないです。)特に、ある程度「現実をシミュレートする」という方向でデータ利用が進むのであれば、明らかにデータ量が級数的にふえるでしょう。したがって、そういう前提条件が現実に満たされる可能性は確かにあると思います。

また、その一方で大規模分散系処理は一般に制御が困難です。特に制約条件をつけないのであれば、まともに動かす事すら困難でしょう。よって、「どのような制限を、アプリからハードまで、垂直につけるか」ということは非常に大切です。能力のあるユーザー企業は、間違いなくこの制約については熟知しているわけで、そういったユーザー企業が、制限をうまく設けられない現状の「オールド・クラウド」に対して、新しい形のクラウド的なものあり方を追求し始めると、それはそれで別のゲームが始まるように見えます。

そもそも、某国のITベンダーは、海外のクラウドベンダーに数光年の差をつけられてますね、ということはもはや周知の事実ですが、ユーザー・セグメントのITにおいても同じ轍を踏みかねない状況かな、とちょっと思ったりもしています。いずれにしろ、「オンプレvsクラウド」といういかにもな対立軸だけを観点にしていると、いつの間にかゲームのルールが変わっていたということになるような気がしています。

とりあえずそんな感じで。

2013-08-18

Replicated Serializable Snapshot Isolation解説

ちょっと諸般の事情で放りだしてあったのですが、まとめておかないと忘れるので、記録的においておきます。あとでたぶん自分でも見直すと思うので。
このエントリーは完全にトランザクションの人向けです。現時点これが本当に必要な人は世界でたぶん50人ぐらいだと思います。全日本的には絶対わかんないとまずいという人はたぶん5人ぐらいです。

ただし、分散DBガチの人はわかっていた方がいいと思うので、おいておきます。

論文はこちら
http://sydney.edu.au/engineering/it/~hyungsoo/vldb2011.pdf

内容はSerializable Snapshot Isolation (以下SSIと略記)の分散環境下への適用に関する論文です。一応実装もあってベンチマーク結果が出ています。SSIについては下記エントリーを参照にしてください。
http://d.hatena.ne.jp/okachimachiorz/20130331/1364709005

まず、SSIの前提のSI自体の分散適用は別のエントリーをみてください。
http://d.hatena.ne.jp/okachimachiorz/20130512/1368344294
要するにFirst-Commit-Winルールの適用でクリアしています。

以上が前提です。以降はこれらがわかっている前提で進めます。論文もほぼ同じ前提を引いています。

このエントリーの目的は、同論文の特にAppendixの解説になります。本文じゃなくてAppendixかよって話もあると思いますが、こっちの方が大事だと思います。本文は予備知識の想定が半端ないので、論文自体がabstractっぽくなってます。(こんなんでよくVLDB通るなというか、いや内容的には通って当然なんですけどね・・・)ということでAppendixが重要ですが、初見だとなんかの判じ物にしか見えないというか、最初見たときにもちょっとギョッとなったので、ここで自分向けの解説書いておきます。

分散DBはおおよそこの辺まで来ている、ということでいいかと思います。この論文がほぼ2年前なので、最新の状況はもう少し先を行っていると思います。

・・まずざっく概略を記述すると、現時点でConsistency(ここでは1-Copy-Serializableを仮置きでおきます)の達成手段としてもっとも有望なSSIの分散replication下での実装の方法を述べています。最大のポイントはやはりDangerous Structure(論文ではDescending Structureという言い方になっています)の検出になります。

分散環境下でのDescending Structureの検出、すなわち、GlobalなDependency Checkの方法としてGlobal Dependency Check Protocol(以下GDCP)の実装がポイントになります。

誰でも考えるように単純にAnti-dependencyのあるTxの情報を持ち回ってチェックすればいいのですが、特にReadSetの持ち回りは対象がまるまるテーブル一つになったりすると、相当やばいことになります。すなわち非現実です。よって、どうするのか?ということが最大の問題になります。結論から言うと、コンフリクトのあるWriteSetだけを持ち回るという方法を選択しています。

したがって、暗黙のうちに、細かいWriteがバラバラ来るという処理が多いというドメインを前提にしています。全データの一斉更新とかはさすがに無理ですね。これをトランザクションにして分散処理すると、間違いなくストップ・ザ・ワールドになります。(そもそも、全データの一斉更新のトランザクション処理は、単ノードだろう分散だろうとストップ・ザ・ワールドの「バッチ処理」になります。)

とはいえ、readとwriteが混在したOLTP的な処理を分散環境下で行い、かつ一貫性を担保する手法として、きわめて有用手法のひとつと言えると思います。

さて・・・

まず、従来のSSIのDangerous Structure(以下Descending Structure)、の検出を、Latest Snapshotを基準に引き直します。基本的にSSIの証明と同じです。ただしlsv (Latest Snapshot Version)を利用して、よりエレガントになっています。結果としては、実装しやすい簡易な形になっていると思います。証明は以下になりますが、結果は割と単純なので、おまじないのように覚えておくといいかもしれません。

Definition
[Descending Structure]
三つのTxを想定する。それぞれTp・Tf・Ttとする(peak, follow, trailからとっている。ややこしいことにこの証明でのTpはTx peakの略で、論文の後半で出てくるTpはTx pendingの略です。混同しないように。)
また各Txで読み込むSnapshotはTx開始時点で最新のものとし、lsv(Tx)とする。

・Anti Dependencyのグラフを想定する
・すなわちTp→rw→Tf  Tf→rw→Tt
このとき
・lsv(Tf)≦lsv(Tp) かつ lsv(Tt)≦lsv(Tp)とする
このグラフをDescending Structureとする

Theorem
・Readはすべて先行するSnapshotからとする
・WriteはFirst-committer-winルールを適用する
このとき
・Descending Structureがない場合
そのTxの集合はSerializableである。

Proof(以下Appendix A)
まずLemma

・Readはすべて先行するSnapshotからとする
・WriteはFirst-committer-winルールを適用する

とすると以下が成立する

・Ti→wr→Tj ならば commit(Ti)≦lsv(Tj)
・Ti→ww→Tj ならば commit(Ti)≦lsv(Tj)
・Ti→rw→Tj ならば begin(Ti)<commit(Tj)

順に説明
・Ti→wr→Tj ならば commit(Ti)≦lsv(Tj)
これはSnapshotからのReadを前提にするので自明です。後続するTxは常に最新のSnapshotを読むという前提になっている。

・Ti→ww→Tj ならば commit(Ti)≦lsv(Tj)
これはFirst-committer-winルールから導きます。まず書き込みが成立しているので、Ci<Cjになります。その結果、Ci≦snapshot j<Cjになります。Ci≦snapshot j≦lsv(Tj)<Cj よって、commit(Ti)≦lsv(Tj)

・Ti→rw→Tj ならば begin(Ti)<commit(Tj)
Ti→rw→Tjなので、TiではXkなるなんらかのTi開始以前に作られたversionを読んでいる。TjではW(Xj)となり、なんらかのversionを生成する。TiではTjでのversionは見えてしまうと、Ti→rw→Tjにはならないので、cjよりも以前のversionをTiで読むことになる。したがって、begin(Ti)<commit(Tj)

以上で準備を完了してProofにはいる
方針として対偶を利用する。
すなわち「Serializableでなければ、必ずDescending Structureが存在する」ことを証明する。

・Serializableでない場合は、Txの依存関係でなんらかの循環が発生する(循環がない場合はtopological sortでserialize可能なので矛盾)
・循環するTxの中でもっとも最新のlsvを読んでいるTxを取り出す。これをTpとする
・その後にシーケンスにつながるTf、Ttを取り出す

さて、ここで最新のlsvをTpが読んでいるので、当然、lsv(Tf)≦lsv(Tp) かつlsv(Tt)≦lsv(Tp)になる。んで、ここで、Tp→Tf Tf→Ttがrwであることを示せばDescending Structureの存在を示したことになる。どうするか、っていうと、Tp→Tf Tf→Ttがwwまたはwrではない、ということを示す。

まず、Tp→Tfについて

もし、wwまたはwrであれば、Lemmaより commit(Tp)≦lsv(Tf)
ここで、当然に、lsv(Tp) <commit(Tp)なので、lsv(Tp) <commit(Tp) ≦lsv(Tf)になり、よって、lsv(Tp) <lsv(Tf) よって矛盾。よって、ww-wrではありえない

したがって、Tp→Tfはrwのdependencyになる。

ここでLemmaを利用して、Tp→Tfがrwであれば、begin(Tp)<commit(Tf)になる。
よって、lsv(Tp)< begin(Tp)<commit(Tf)が成立。

さて次は、Tf→Ttがrwであることを示す。
同様に、もし、wwまたはwrであれば、Lemmaより
commit(Tf)≦lsv(Tt)

ここでlsv(Tp)< begin(Tp)<commit(Tf)なので、lsv(Tp)< begin(Tp)<commit(Tf) ≦lsv(Tt)
よって、lsv(Tp)<lsv(Tt)になる。これは矛盾。よってww-wrではありえない。

したがって、Tf→Ttはrwのdependencyになる。

以上より、Tp→Tf Tf→Ttはrwであり、Descending Structureが存在する。
よって、Serializableでなければ、必ずDescending Structureが存在する
よって、Descending Structureが存在しなければ、Serializableである。
以上、極めてクリアです。

なので、分散の系の中で、あるTxがcommitできるかどうか、SIでのread-fromと、first-commit-winルールを適用している限りにおいては、Descending Structureの存在をチェックすればよい、ということになります。

さて次に、肝心のDescending Structureの存在チェックの実装になります。

が、その前に、どういう環境なのか、何をしようとしているのかざっくり書いておきます。

前提としては、複数のプロセスノード)があり、クライアントはあるプロセスにアクセスし、そのプロセスのデータの読む込み・書き込みを自由に行う環境を想定します。その結果、各プロセスTxが発生します。

プロセスは、それぞれの下位にDB層をもちローカルデータの保存/読み出しを行います。また、データはすべてのプロセスで共有化されようにします。すなわち、あるプロセスで書かれた内容は、他のほかのプロセスに伝播する仕組みになります。当然、その結果として各データの不整合が発生する可能性があるので、それを裁量する必要があり、それをserializableな形に処理することが目標になります。(いわゆる、Read-One-Write-AllのROWAを想定しています。)

また、各Txの全順序は保証されているものとしています。この仮定は微妙ではありますが、SSIを前提にしている以上、TO(Timestamp Ordering)の確保は基本になるので、仮定としては、それほどでたらめな話ではありません。

課題は、あるローカルのデータセットに書き込み要求があったときに、その書き込みがコミットできるどうか? できたとして、それを他のプロセスではどう扱うべきか、ということに帰着します。

課題の解決は、大きく二つのラウンドで行われます。

最初のラウンドは、各プロセスが、自分で保持しているTxにおいて、自分のローカルのWriteSetへの書き込みが可能かどうか?を各ノードに問い合わせを行い、可能(Serializable)であればcommitするというものになります。

次のラウンドは、commitした結果を各ノードに通知して、各ノードで更新処理を行うと同時にコンフリクトのあるリモートTxの処理を各ノードで処理させるというものになります。

よって2 roundの処理になっています。この手の分散処理は大抵は2 roundの処理になることが多く、RSSIでも同じになっています。トラディショナル手法では2PL+2PCが主流であるのに対して、RSSIはロックフリーで、2PCも行いません。まったく異なったアプローチで分散コミットを行います。

コミットレベルではeagerとlazyの中間ぐらいに見えますが、厳密にいうとlazyでしょうね。とりあえずcommitの前に全ノードに聞いているので、その時点はeagerっぽいのですが、commit後のデータ更新伝播なので、その意味ではlazyでしょう。

データ一貫性を担保するのであれば、eagerが望ましいのですが、いかんせんかなり非現実的な話になります。事前の問い合わせでconsistencyがとれていれば、ローカルコミットは可能であることと、そもそも該当Txがpending状態であることがリモートサイドでも認識できているので、lazyでも不都合はないでしょう。まぁ、確かにそーゆー解決法は現実的ではあります。

では、Algorithm1 で疑似コードが提示されていますので、そのあたりから・・・
正直まじめにわかりづらいです。大雑把につかむとそれなりにシンプルにはなっていますが・・・。

[1]まずは分散環境でのDescending Structureの存在チェックのために、持ち回るデータセットを定義します。

構成要素は以下。
Wi Ri := (あるローカルでのTxである)TiでのRead setとWrite set
Tc :=コミットされたTxのログ
Tp :=ペンディングになっているTxのログ
Tl,c :=Tcのうちでローカルなもの
Tl,p :=Tpのうちでローカルなもの

lsv := latest snapshot versionのTimestamp
Tiでアクセスされるもっとも値の新しいsnaphotのversionを示す。したがって、lsv(Ti)<=begin(Ti) (等号はlsvを生成したTjのコミットのタイミングとTiの開始のタイミングが一致して、かつTjのwsとTiのrsで共通部分がある場合のみ成立)

Df,c := Ti(よってRi)からrw-dependencyをもつTc(Writeをもつ)の、TxのIDとlsvのペアの集合
Df,p := Ti(よってRi)からrw-dependencyをもつTp(Writeをもつ)の、TxのIDとlsvのペアの集合
Dt,c := Ti(よってWi)へのrw-dependencyをもつTc(Readをもつ)の、TxのIDとlsvのペア。後述するように該当Tcについては最新のlsvのみが重要なのでこれは単一ペアでよい。
Dt,p:= Ti(よってWi)へのrw-dependencyをもつTp(Readをもつ)の、TxのIDとlsvのペアの集合

以上より{Wi Df,c Df,p Dt,c Dt,p 終端記号}のデータセットをつくる。

[2]最初のブロードキャストの準備
前提)基本的な流れは、自分のローカルのWriteSetを飛ばして、ほかのノードでのWritesetを受け取って、自分のところのReadSetとチェックをする、という形になる。

まずWiとRiの獲得。これはローカルから取得
Df,cの作成。コミットされたTxのなかから「Tiからのanti-dependency」のあるものを探す。んで、ヒットしたらそのlsvをとってきてセット。
Df,pの作成。ペンディングになっているTxのなかから「Tiからのanti-dependency」のあるものを探す。んで、ヒットしたらそのlsvをとってきてセット。
・Dt,cの作成。コミットされたTxのなかから「Tiへのanti-dependency」のあるものを探す。んで、ヒットしたらその最大のlsvをとってきて、TxのIDと当該lsvセット。またこのlsvをlsvmとしてセット。なお、Dt,cはこのTiについては最新のsnapshotを利用しているエッジがクリティカル(それより前は問題ではない。Descending structureの要件が、Tp→rw→Tf  Tf→rw→Ttの時のlsv(Tf)≦lsv(Tp) かつ lsv(Tt)≦lsv(Tp)なので、Tp/Tfについては(ここではDt,c)については最大のもののみが問題になる。すでにコミットされているので、最大のものだけを基準にするということになる。)なので、最大のものをそのままペアとして処理する。
・Dt,pの作成。ペンディングになっているTxのなかから「Tiへのanti-dependency」のあるものを探す。さらに、そのTxのlsvがlsvmよりも最新である場合に、当該TxのIDとlsvをとってきてセット。これはまだコミットされていないので、まずい可能性があるものをすべて列挙しておく必要がある。最大のlsvになる可能性があるものはすべて押さえておくということになる。

[3]最初のチェックとブロードキャスト
まず、この状態で、Df,cとDt,cで共通しているものがあれば、abort処理する。そうでないものはペンディングにして、Tl,pにアペンドする。その上で、{Wi Df,c Df,p Dt,c Dt,p 終端記号}で構成される構造をブロード・キャストする。
なお、終端記号は該当するWiについて、commit可能かどうかの判断が終わっているかどうかを表す。論文では未定の場合は⊥、終わっている場合はDECIDEという記法を用いている。最初にキャストする時は全部⊥になる。

[4]次に、このグラフ構造を受け取った場合の処理
処理のパターンとしては2種類ある。一つは終端記号が未決のもの(⊥)と、終端記号が決定済みのもの(DECIDE)になっているもの。後者のケースは後述。まず最初に受け取るものは通常は未決状態のもになる。なお、終端記号はデータセット自身にセットされるものと、Dt,cにセットされるものの二つがある。前者は処理が可能かどうかを示し、後者はTxが循環しているかどうかを示す。(後者の終端記号は、⊥,⊥になっている)

[4-1]データセットの終端記号が未決(⊥)の場合
この場合、まずWiを検査して、自分のローカルTxかどうか確認する。

[リモートの場合]
まず、Dt,cが終端記号(⊥,⊥)でない場合は、Tpのリストにアペンドしておく。その上でリモートの場合は、ローカルのコミット済みTxでリモートのTxのDtになるものがないかどうかチェックして、ある場合でかつlsvがより大きい場合は、Dtにappendする。Wiがローカルではないので、ローカルサイドではread側のTxがローカルにあるかどうか判断するということになる。(これ重要!)
なお、それがDfである場合は循環になる。(2Txで循環するケース)ので、不可という判断をする。
同時に、構造を確認して、循環の場合は、Dt,cに終端記号をセットする。それから次にブロードキャストする。

つぎに、同じリモートでも終端記号(⊥,⊥)がある場合は、すでに循環になっていて、かつ自分のローカルでは関係がないので、そのままブロードキャストする。

[ローカルの場合]
これはメッセージが全ノードを回って戻ってきたことを意味する。Dt,cに終端記号(⊥,⊥)がある場合は、循環しているので、ローカルTxをabortする。その上で、ペンディングTxをTl,pから該当分を除去する。
さらに、グラフ構造に終端記号をDECIDEにして、ブロードキャストする。二周目を開始する。

なお、このときに循環がなければ、Tp上のデータセットについてはDECIDEになるので、後続のgdcpDeliverプロセスで、コミットの優先権(Tpキューの最初に該当するローカルTxが存在)があればコミット処理される。つまり、結果として、一周目の終了でローカル・コミットになる。優先権がない場合は先行するTxが更新可能状態になったその時点でコミットされる。この場合は一周目の終了がしたからと言ってコミット可能というわけではないことに注意。・・・なのでeagerとはいいづらい部分もあるというのが感想で、ただし、理論上はデータセットのルーティングの追い越しがない場合は、必ず二周完了時点には完了するわけで、ということで、平均すると1.5周ぐらいでコミットになる・・・

最後に、Tpを処理するプロセス(gdcpDeliver())を起動する。

[4-2]つぎに、データセットの終端記号が決定済み(DECIDE)になっている場合
[ローカルの場合]
WiがTl,pに含まれている場合は、ローカルなので、Tl,pの該当するTiをDECIDEとマークし、データセットの更新処理をする。(データセットの更新であり、ローカル・データの更新ではない)
[リモートの場合]
単純に該当するTiをTpに加えて、次にブロードキャストする。

最後に、Tpを処理するプロセス(gdcpDeliver())を起動する。

[5]結果の処理(gdcpDeliver())
Tpを処理するプロセスになる。このプロセスでローカルへの書き込みを実行する。
前提として、Txの全順序が保証されている。すなわちTpのキューは、TOでソートされている。first-commit-winルールでも必要なので、これは前提としては“できるかどうかは別として”妥当。
Tpのキューを最初から取り出して、そのマークがDECIDEである場合は、順に処理をしてDECIDEでないところまで進める。よって、例えば、最初のTxがDECIDEでない場合は、何もしない。
処理を行う場合、Descending Structureがない場合はローカルの場合はcommitを行い、リモートの場合はupdateを行う(別にcommitでもよい)ことになる。

この辺は、すごく良くできていて、たぶん理論的に抽象度をもっと上げるときれいな数式で表現できるはずなのですが、ここでは実装優先で理論をつくっているので、ちょっとごちゃごちゃしてます。

ここまで流れの解説がAppendix Bにあるのですが、(かなり)わかりづらいので、わかりやすくした(つもりの)ものを下につけておきます。ちょっとアレしていますが、冷静にゆっくり読めばわかるはずです。はずだ。はずに違いない。・・実際、わかると「なるほどー」ということになります。相互に直接連絡することなく、それぞれのプロセスで整合性をもってコミットできるので、これはこれで手品みたいな感じですが。

f:id:okachimachiorz:20130818123923j:image

f:id:okachimachiorz:20130818123924j:image

f:id:okachimachiorz:20130818123925j:image

f:id:okachimachiorz:20130818123926j:image

このアルゴリズム自体は、割と実装寄りのアルゴリズムになっている感じで、やるべきことは割とシンプルになっています。最大のトリックはTpキューの全順序による結果反映で、今までは割と実現が難しいところでしたが、例のSpanner以降は実際に実装が可能になってきています。その意味ではかなり現実的な解だと思われます。

以下、補足事項
・データ転送の手順について
基本的に、Ring topologyを利用していて、使われている手法はLCRです。詳細は以下
Throughput optimal total order broadcast for cluster environments
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.167.868
ACMからDLした方がいいかと思います。

このあたりは、何度も議論されているところなので、論点としてはあるとは思いますが、今回は省略。

GC
不要なTxのlogのGCですが、基準としては、そのTxのcommit以前に開始されたPending Txがなくなった時、ということになります。これはTpのもっとも最初のTxbegin timestampになるので、各ノードがその値を通知し、その中でもっとも古いものを選択する方式を採用しています。その値以前のTxのログを除去するということになります。

・障害対策
まず対応は単純なstop-failureについて。あんまり冴えた方法はなくて、そもそもこれローカルにDBがあるので、そこに書いておいて、復帰時にマスターレプリカから更新して、Ring topologyに復帰して、継続処理開始になる。

なお、Byzantine障害については
Practical Byzantine Fault Tolerance and Proactive Recovery
Zyzzyva: Speculative Byzantine Fault Tolerance
を参考にして適当に手をうつ、とか書いてあります。まじですか。この逃げ方は業界のデファクトですか的なアレですか。

・全体的なパフォーマンス
比較すべき対象は、rwを片っ端からabortして、retryさせる手法になりますが、そのベンチマークの結果も出ています。この場合、偽陽性が陽性の3倍出て、RSSIのオーバーヘッドが2倍程度なので、RSSIの勝ちとか出てますね。正直、オーバーヘッドの縮小は、環境やら実装で相当削れるアルゴリズムなので、片っ端からabortする手法よりは、より効率がよい、というのは、その通りではないかなと思います。

・課題
論文にあるとおり、持ち回るデータセットを少なくしているとはいえ、全体の環境としては、低遅延が望ましいのは間違いないでしょう。したがって、DC間のようなレイテンシーが高いものはさすがにちょっと無理があります。せめて、round数を減らす方向でいかないとまずい(のでMDCCとかあっちの方向にいくという展開かと)と思われます。

・とはいえ
とはいえ、低遅延環境が保証される複数ノードクラスター分散Tx処理で、1-copy serializableを達成する仕組みとしては、最有力候補の一つであることは間違いないでしょう。DC内部での複数ラックにまたがるようなサイズでの分散Txはもう技術的に可能ですね、ということだと思います。

今後の話題としては、DC間の分散TXになると思います。個人的には、そのレンジになると、2 round処理ではコミットが間に合わないので、1 round+αぐらいで決着をつける、方向になるのでは?とか思っています。

・・・というわけですよ。これでSSIについてはほぼ完成系じゃないかと思います。あとは持ち回りの工夫だけなので、これを超える仕組みはまったく違う理論でくみ上げないと駄目だと思います。そんな感じ。gdcpについてはもっとリファインできる気がするので、誰かやってFekete大先生に送りつけるといいかもしれません。