CEP抜きのイベントドリブン型システムへの挑戦

高速処理のシステムで利用されるCEPエンジンですが、

現実問題かなり高額になります。

今回のプロトタイプシステムは全てのオブジェクトをメモリ上に展開する前提である為、

プロパティ等を利用して必要な計算のトリガーを全て発生させられるかの検討も考えています。

CEPエンジンの様に汎用性は全く無いですが、

決まった処理をあるイベントをトリガーにして全オブジェクトに展開して行けば、

理論的にはCEPエンジン無しで完全なリアルタイムシステムが構築可能になります。

但し、

不要な重複処理の防止

システム全体での無限ループの可能性排除

同時発生のイベントに対する非同期処理

一定時間でのデータ制御　等、

考慮しなければ行けない要素が多くある為、

180日間の試用期間を考えると試作は難しいかも知れません。

最初からイベントドリブン型でプロトタイプを構築する方法もありますが

その形を採用した場合には、個々の計算が自動で走ってしまう為、

当初の大量データ／大量計算での有効性が検証しにくくなります。

出来る限り色々な可能性を試したい反面、

限られたリソース（構築に充てられる作業時間）と葛藤しています。

「富豪的プログラミング」

今回のプロトタイプ開発のテーマは、「富豪的プログラミング」になりました。
※プログラミングの世界では、有名な話なので興味ある方は検索して見て下さい。

通常は、限られたハードウェア制限の中でシステム構築をするので、
・効率的なメモリ使用方法
・データ転送のバックグラウンド化
・計算回数の最小化
等を考慮に入れた設計をしますが、今回はハードウェアがふんだんに使えます。


普段行う設計思想はリソース仕様の効率は良い為、
システム全体として構築費用を抑えられますが、
その対価としてコードレベルで難しくなってしまいます。


特に、拡張性や再利用性に関しては
・データの同期／非同期、
・データタイプの最小化、
・モジュールサイズの最小化
がコードレベルで反映されてしまい一定水準の技術が必須条件となる為、
技術者の確保が必要になってしまう点から、低いと言わざる得ないです。

出来る限り、想定される仕様を推測して最初から考慮する様にする事で、
拡張性の低さをカバーする様にしていますが、
本来であれば、拡張性や再利用性が高いコーディングであるべきです。

また、複雑な処理を省く事で不具合の発生率も下げられる為、
今回、システムとしての商用販売は考えていませんが、
検証用に作成したモジュール郡は再利用を考えている為、
実用に耐えうる品質は担保したい。

これらの点から、
不要な工夫を排除したシンプルなコードによるシステム構成。
また、それによってもたらされる拡張性や品質に関しても、
検証対象とする事にしました。

開発環境整備中

プロトタイプの開発環境を構築中です。

OS上はメモリを正しく認識しているみたいです。
このCPUをフルで使い切るのは、やはり悩みます。

しかし、流石サーバーOSです。
殆どアイドルだけなのにメモリの使用量が多い。

PCが届きました！

先日発注したPCが届きました！

SSDやHDDはケースの横に貼りつくタイプです。

中身はCPUクーラー以外、殆どスカスカ状態です。

ちなみに、マザーボード（Asus Z9PE-D16）はワークステーション用らしく、温度計が付いています。

どうやって確認するのか・・・目視？という疑問はありますが。

さて、これを使ってどこまでの物が構築出来るか
夢は膨らみますが、現実的なレベルを探りつつ構築していきます。

グリッドやクラウドにおけるデータ共有に関して

スケールアウト(水平拡張)における「データ共有」の問題点の記載になります。

複数のノードで処理を行う為、処理によってはノード間で「データ共有」の必要性が発生します。

共有データ量自体を抑える形で構築するアプローチもありますが、
プロト開発の目的とは外れる為、今回は割愛します。

さて、一般的にノード間の「データ共有」のボトルネックは「データ転送」と思われがちです。


しかし、実際のスループットの阻害要因としては、「データ転送コスト」よりも、
ネットワークを経由での共有データ同期時に発生するレイテンシの比重が大きくなります。


つまり、スループットが頭打ちなのに、CPUもネットワーク帯域も余裕がある状態が発生します。


データ転送だけに限って言えば、
NUMAのような共有バスがあれば、見かけ上の転送は発生しません。

しかし、ネットワーク速度(100M/1G/10G)が早くなっても、
同期の為のレイテンシは特殊な機器を使わない限り早くなりません。
また、経由する機器によっては最大数10msの遅延が出るため、
同期するべきデータの件数、更新頻度、分散ノード数が乗数効果で効いてしまいます。

その点、単一ノードの場合には、更新データの同期が不要であることはもちろん、
発生する可能性があるレイテンシも最大でも数μsであるため、水平分散機構のそれとは比べ物になりません。