デライトの隠し戦略・隠し機構について検討し,「KNEST 隠し」を考案,今後の方針として採用することを決めた。これも長らく課題としていたことで,大きな前進だった。
KNEST 隠しでは,各捌き手のプロセス内隠しを KNEST を通して同期する。通信方法はいくつか考えられるが,台数が少ないうちは単に外部から空了出来るようにするだけでも十分だろう。
これまで,デルンではプロセス内隠し(xtd::cch_)を使って月庭の高速化にある程度成功していたが,プロセス・捌き手間での同期の問題があり,使える場面は限られていた。
Memcached の導入なども検討したことがあるが,どうも帯に短し襷に長しという感じが否めず,デライトにぴったりな解決策が見つかっていなかった。
15日6歩で,libxpo.Pg を利用して PostgreSQL を隠し捌きとして使ってしまうことも考えた。それはそれであってもいいが,やはりウェブ捌きで制御したいことも多々あり,根本的な解決策にはならなかった。
KNEST 隠しは,プロセス内隠しという密を HTTP という疎でゆるやかに連携させるという手法であり,デライト運用に必要な拡縮性を上手く確保出来そうだ。
デライトの拡縮性における最後の問題がウェブ捌きの水平拡大だったため,これによって安定拡大戦略を支える技術が出揃ったとも言える。
出場捌きの水平拡大はとりあえず履複化でいいとして,ウェブ捌きの水平拡大における同期は KNEST を通して行なう。これは接渉管理にも応用出来るだろう。あとは流量制御しつつ,適宜 CDN などを利用する。請い手側では PWA を軸に高速化していく。
戦略が定まったことにより,目先の最適化に着手しやすくなった,というのも大きい。どう作業していくかについて迷いが消えた。こんなことを考え始めたのも,デライトの宣伝を本格化させる前に,性能の課題に対する見通しをつけておきたかったからだ。
早速,KNEST::cch_T の実装に取りかかることにした。