「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働

個人的には割と大変だったので、その辺をまとめておきます。

ニュースリリースはこちら。
http://www.nautilus-technologies.com/topics/20130409.html

要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。

システムの機能概要
1.売上の確定処理と債権管理
POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。

2.仕入・費用の計上と確定処理、および支払いデータの作成
費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との連携を行っているため、支払については電子データで照合マッチングを「伝票明細単位」で行います。明細単位で処理を行うため、オープン・インボイスは全部取り込みます。結果として一度の処理では三千万件程度のマッチング・バッチが走ります。ミス・マッチ処理の結果は、アンマッチの原因単位でグループ化したあとでユーザー判断を促します。

3.テナント管理、特にフィー計算
テナントマスターの管理と、売上・仕入・経費の計上を確定した上で、契約に合致したテナントフィーの計算を行います。テナント管理は、販売実績を確定させたあとで、費用計上分をネットし、必要な契約スキームを適用することでコミッション金額を確定させます。つまり最長のバッチフローとしては、売上確定->費用確定->テナント・コミッション確定->確定後の費用確定のロングバッチフローになります。これを日次で行います。

4.管理会計一式
上記の管理会計の一式を行い店舗別のSKU単品を論理在庫計算から、粗利を算出し、カテゴリー・店舗・組織別の全部の積み上げ計算を行い、日別・週別・月別・年度別の利益をデイリーで確定します。

（以上の仕組みは、すでに一部はパッケージとして販売・商談を開始しているので、どこかで中身はもっと詳細にでると思います。）

オンラインとバッチシステムの構成です。外部接続のインターフェイス数は600本強、主要画面数で600画面程度、一晩で走るジョブグループ数で200でバッチ本数で3000本弱、この間に処理されるデータ件数は最大で20億件弱に渡ります。開発期間は2年強。投入人月で600~700人月クラス。（最初の企画は3年前ぐらいからスタートで、結局、最後のC/Oまでかかわったのは、自分とSIサイドのPMさんの二人だけでした。のべ人数で200人以上は関わったと思いますが、出入りも激しいプロジェクトでした。）

　バッチ処理は全てHadoopで処理しています。Hadoopでの業務バッチ処理では、おそらく現時点で日本に存在するものの中で、もっとも複雑なものの一つだと思います。ピーク時点では一晩で20億件のデータを業務処理する化け物のようなバッチのカタマリのシステムです。RDBMSだと現実的な時間で終わる事はないと思います。開発はAsakusaなのでできたというシロモノで、Hiveや素のMapReduceでやったら絶対無理です。
　フロント画面はJavaScript。バッチ系はかなりサクッといったのですが、画面系は大苦戦でした。jsはもう少しなんかとしないと、まじでこの世から消えてほしいと関係各者全員が思ったと思います。（jsでの業務画面はどこもうまくは行ってないようですね。・・個別のフレームワークはそれなりにあるのですが、どれも品質やVupやトータルでの仕組みという意味では不十分なようです。）まぁとにかくSIも含めてかなりの大規模な仕組みです。

　当たり前ですが、当初の想定はインフラはオンプレミス・システムです。一応形式上は某社の"クラウド"ですが、実態は専用空間をもらっているので、インフラとしては、ほぼオンプレと見なして構わないと思います。ハードとか丸見えだし。Elasticでもなんでもないし。なお、これだけの規模の仕組みなので、リリースは段階移行です。最初のリリースから9ヶ月経過で、全面C/Oという運びでした。

コイツを一式全部すべて、AWSに上げました。
これだけの複雑かつミッション・クリティカルな仕組みがAWSにあがっているのは、日本では間違いなく初めてでしょう。さらに業務系バックエンドを全面的にHadoopで行ったという例では、現時点では世界でも数が少ないと思います。

　正直に白状しますが、個人的には絶対に「クラウドにあげることは、ない」と思っていました。これだけの大規模かつ複雑にして、ミッションクリティカルなシステムが万が一にもクラウドに、しかもパブリッククラウドに上がるようであれば、オンプレミスの存在価値は、個人的にはゼロです。10数年前であれば、汎用機かオフコンの化け物で動かす仕組みです。オープン系ですらバッチ・パフォーマンスが出ないので躊躇するレベルです。

なんでクラウドなんですか？オンプレじゃ駄目なんですか？
　なんども言うとおり、開発当初はオンプレを想定していました。ところが、最初の段階リリースから、オンプレでのHadoopクラスターの運用（前述の通り某社の国内“クラウド”の一部を利用）がトラブル続き+サーバーのパフォーマンスがあまりに悪すぎました。これをどうにか解決するために、AWSに上げざるを得なかったというところです。順に解説します。

コスト・パフォーマンス
　まずコスト・パフォーマンスですが、少なくとも、今回のシステムについて言えば、オンプレとAWSではほぼ2倍程度の開きがあります。世の中、いろいろなコスト・ベンチマークがありますが、その辺りに転がっているベンチマークは残念ながら、大抵はWeb系のread-intensiveなベンチになっている（またはTPC-CのようなものでもWrite-Readはバランスが取れているもの）ので、今回のようなバッチ処理を阿呆みたいに回すハード・コアなシステムでは参考になりません。この辺の重いシステムであれば、それなりにオンプレも善戦するのでは？というもくろみもあったのですが、蓋を開けてみればオンプレ側には残念な結果になってしまいました。正直、基幹系のバッチ中心のシステムでも確実に2倍〜3倍の開きはあります。これはオンプレ側にしてみると痛い。

運用周り
　それでも、国内のクラウドベンダーがしっかり（クラウド的に）Hadoopを運用して、AWS並の可用性を出していれば、AWSには移行しなかったでしょう。（これはユーザーさんも同意見です。）やはり、Hadoopの運用はなかなか骨が折れます。しかも、このシステムは基幹処理用ですので、処理件数・プログラムともになかなかに強烈です。毎晩かなりの負荷がクラスターにかかります。稼働が一年近くになってくると、さすがにいろいろイカレてくるのですが、どうにも国内の某ベンダーさんは対応できませんでした。
　一番やっかいなのは、ハード・OS系のバグや障害にHadoopの障害が重なるというケースでかつ、なかなか再現しない場合です。これはちょっとどうしようもない感じでした。自分たちはこのシステムとは別にクラウド上で既に業務処理をHadoopを連続で動かしているのですが、彼我の差はイカンともしがたいレベルにまで拡大していることを実感させられました。

　現在、ビッグデータのブームもあり、各地でHadoopをオンプレでやってみるという動きが出ています。Hadoopは確かに導入しやすいので、その流れもあるでしょう。ただし、ミッションクリティカルで運用するには、相当な経験とノウハウが必要です。つまり直裁に言えば、普通は無理です。一部の例外を除き、全然お勧めしません。どうしてもやるなら、最低でも、いろいろと人的なコストが青天井になることは覚悟すべきです。

　すなわち、コスト・パフォーマンスと可用性の両者でオンプレミスはほぼ完全に敗北でした。これでは移行するな、という方に合理的な理由が見つかりません。ユーザーさんとも相当協議をした上での移行です。（ユーザーさんサイドでも相当いろいろと社内調整をして頂きました。かなり大変だったようです。感謝しております。）

　もともと開発はAWS上でずっと行っていたので、システム的な移行は別に作り替えのような大事ではないです。ただし、インフラ周りの整備は全部準備するという感じになっています。当然ですが、ストレートにAWSを全面的に信頼する、というナイーブな作りではありません。AWSのDCが一個丸ごとすっ飛ぶぐらいの障害は織り込んでの検討・構成にしてあります。そーゆー想定がそもそもどーなのよ？という意見はあると思いますが、クラウドで基幹やるならこの程度は想定しないと駄目だと思います。

ちょっと遠目で見ると・・
　Hadoopに限らず今後の分散処理は普通にどこでも使われるようになるでしょう。この場合、オンプレでは日本の国内ベンダーの「現在」の技術力では、残念ながら運用が難しいです。出来たように見えても、結局人依存に加えて、長期運用になれば必ず破綻します。そもそもVupですら大事になってしまいますし、実際そうなっている案件も散見されます。少なくともHadoopのような分散系処理基盤はVupは鬼門だともっと知られてしかるべきです。特にリスク管理という側面からですが。・・ツールがあれば大丈夫だ、という意見も聞きますが、ちょっと考えが甘いと思います。

　また、同時にハードウェアの寿命とソフトウェアの寿命の乖離に最初から手を打っておきたいところでもあります。オンプレの場合はもう5年後を待つ前にハードは間違いなく時代遅れになるでしょう。基幹系のシステムはソフトウェアは間違いなく10年はもちます。この辺りのバックエンドの業務自体は20年ぐらい変わっていないです。さすがにハード更新に合わせて、同じ物は二度と作りたくないのが人情です。正直、やっとこさ周りの改修やらその他いろいろ終わった段階で早速ハードがイカレ始めました、というのが容易に想像できるところです。これは避けたい。特に分散系になった場合に、5年単位でクラスターの入れ替えとか悪夢以外のなにものでもないです。

　本部系の基幹システムは、種々にあるシステムの中でも、もっとも重いシステムの一つです。最後までクラウド化が無理だろうと個人的には思っていました。変な話ですが、いまでも思っています。基本はオンプレで、そもそもアウトソーシングのレベルですら躊躇するのが普通です。単純なWeb系のシステムや、バッチの切り出しのみ、または、ある一定のシステムのカタマリの移行ならともかく、今回は、本部系ほぼ一式というシステム群です。しかもバックエンドがHadoopです。こういったものがクラウドに上がる、いや、上げられるというのは今でもちょっと想像を超える感じです。

　それがクラウドに上がりました。上がってしまいました。それもAWSです。

　もう、オンプレミスのシステムとか要らないですよ。投入コスト・運用コスト・ハード寿命の短縮化等々、まったく割に合いません。ミッションクリティカルなものですらクラウドで動く時代になりつつあります。勿論今回のようなバックエンドの超絶ヘビー級のシステムをすぐにAWSのようなクラウドに上げろとはいいません。（実際問題、「現時点」で出来るベンダーは日本では非常に限られていると思います。基幹系システムというものがよくわかっていて、かつAWSに精通しているところだけでしょう。こんなもんAWSに上げるのは、他のベンダーは、先はともかく現時点では無理だと思います。普通にどうやっていいかわかんないですよ。）ただ、もう普通のサイズのシステムは、普通にAWSで実行できるのが現状です。

とはいえ、そのままAWSに上げられるのか？
　コイツは微妙ですね。実際の今回のケースもあの手この手で工夫をした上での移行です。当たりまえですが、クラウド陣営の大本営発表をそのまま受け取るアホなやり方では、玉砕した時に手の打ちようがありません。信頼性の高い部分はどこか？低いところはどこか？最悪のケースをどうするのか？を考えて準備する事が必要です。
　クラウドベンダーの“営業的”な矛盾は、「クラウドって本当に大丈夫なの？」の質問に答えるために「大丈夫です！」を連呼せざるを得ないところにあります。この「大丈夫ですよ大本営発表」ために、結果として「駄目だったときの対策」を明示できない形になります。駄目だったら対策を提示した途端に、「なにそれ？最初から駄目なことを想定するの？」と突っ込まれること請け合いだからです。これはあまりフェアとは言いがたいのですが、事実なので仕方がないでしょう。
　この辺りは“ミッションクリティカル”の経験があるところのヘルプが必要だと思います。

どのくらいの工数でやったのか？
・・・あとこのインフラ移行をやったのが、うちのエンジニアが約一名です、ってのもちょっと特記すべき事項だと思っています。（当たり前ですが歴年の会社としての経験値が後ろにあるので、一人でやったという言い方はフェアではないですね。あとアプリサイドの移行はSI屋さんがやっています。）正直、個人的にはいくら弊社の守護神とはいえ、普通じゃない感じです。さすがにちょっとハイパーな動き方で、分単位で動きながら同時に五カ所に指示を飛ばすとか、やってました。自分とか周りのヘルプはまぁ逆にいうと指示出す分だけコストになるぐらいの勢いでした。彼の人でないと無理ですね。他の会社（他の人材）でこれができるか？というと、ちょっと厳しいかと。

自分のタスクは、声だしとか、ヤバかったときの切り戻しの交渉と土下座WBSの作成みたいな感じでした。あ、一応大枠のユーザー調整は自分やってます。とほほ。

　これは環境がクラウドだからできた、というのは確かにあります。クラウドは腕のよいエンジニアをとんでもない勢いでレバレッジさせるという好例だと思いました。エンタープライズ（社会インフラ系）経験の豊富なウィザード級のインフラ・エンジニアを2年もAWSに専属で突っ込んでおけば、十分化け物にはなります。そんな感じかと。・・・これが普通になるとインフラの指示待ち人材は完全に仕事がなくなりますね・・・

　企業のバックエンドの基幹システムが一式クラウドで動いている、というのは、個人的な想定よりも4-5年早いです。想定外ですが、世の中は大抵想定外なので、そーゆーことなのでしょうか。何度も言っても言い足りませんが、最後の最後まで躊躇しました。とはいえ、移行が必須だったというのも現実です。

最後に実際に弊社某エースの作業中の独り言だけ書いておきます。「これは・・・一筋縄ではいかないわ（汗」だそうでございます。いろいろありましたよ。そんな簡単じゃないですよ。まじめに。まぁとはいえ、できているという現実は直視すべきでしょう。