また親しい人にもアドバイスを受けた。
今やっているプロジェクトは基幹系システムを刷新して、クラウド上に載せ替えるというものである。基本的には業務要件はAS ISのままで、それをクラウドに載せ替えるというものである。むろん汎用機からオープン系のシステムかわるので、言語が変わったり、アプリケーションサーバーとDBサーバーという今時の構成への変更はある。
自分の担当は、夜間バッチの部分で基本的にはJavaで作ることになる。
この夜間バッチが相当曲者で、これをJavaでやるとなると
- DBからデータを持ってくる
- データを加工する
- データをDBにもどす
という順番の処理になる。汎用機時代はフラットファイルなので、夜間バッチには相当強くて、100万件だろうが200万件だろうが平気で処理を行う。一方オンライン処理には、それほど強く無いのではと想像する（今の時代のオンラインのトランザクション量は半端ないので、まえの現場は秒間200トランとか、、SNSとかスマホゲームはもっと多いだろう）
夜間バッチだと、30万件でもいま結構苦労している。（計算上で）
本当ならストアドプロシージャでやりたいのだが諸般の事情でそれはできない。
記録しておきたいことは、そんなことではなくて（関係なくはないが）、今まで自分はマイクロサービスというものに否定的であった。しかし現プロジェクトでいろいろ経験することで考えを改めることに至った。またアーキテクチャについても思うところがあった。
今のプロジェクトは、クラウドに乗せるといっても、基本的にはクラウド前のオープン系のアーキテクチャをそのまま踏襲している。
よってサーバーのインスタンスをクラウド上にいくつか立てて、それぞれをアプリケーションサーバーにしたり、DBサーバーにしたりしている。なので詳しいことは聞いていいが、アプリケーションサーバー間のロードバランスの仕組みを導入したり、DBサーバーをHOT-COLD構成にしたりしている。
当初はこれに疑問を持っていなかった。
しかしクラウドの利点の一つは、「スケーラブル」なことである。ロードバランスの仕組みや、DBの対障害性もクラウド側が機能としてもっている。
またクラウドの課金は、CPUの動いた時間である。（認識間違っていないかな？）
いまのお客様は、オンライン処理はそれほどでもなくて、夜間処理が非常にきつい。
しかしアプリケーションサーバーは、24時間動いている。すかすかの昼間も着実に課金されている。DBもHOT-COLD構成だが、COLD側もOSレベルでは動いているはずなので課金されることになる。
よって、クラウドにシステムを乗せるときは、できるだけ夜間バッチという考え方を捨てるべきとの考えに至った（そういうアドバイスを先輩にも受けた）
つまりできる限りCPUを効率的に使うため、
夜間バッチで行う処理は、マイクロ（でなくてもいいが）サービスで、バックグラウンドで個々のトランザクションで処理する。（集計できる形にまで、一気にオンラインで持っていって、集計とかだけ夜にする）
また少なくともDBサーバーを個々に立てるという考えも捨てるべきとおもったCOLD分のリソースがもったいない。クラウド側が持っているDBのサービス（Amazon RDSとか分散処理や、スケーラビリティもクラウド側が保証してくれる）を使うべきと思う。
本当にミッションクリティカルなシステムだけクラウド側の保証を超えて、独自の耐障害性の仕組みをADDするべきと考えた。
以上が記録したいことになる。過去の経験だけにすがって考え方の転換を図らないとすぐに知識は陳腐化するといういい経験になったと思う。
※ちなみに単純に仕組みを考えると単一の処理で200万回インサート文を投げることになるので、うまいこと考えないとと騒いでいたら。汎用機しか知らない人に、「200万件レコード追加するだけでしょ。そんなのなんでしんどいの？」と言われた。
