熱脳しゃちょのブログ -8ページ目

熱脳しゃちょのブログ

おせっかい焼SE兼プログラマ兼……の辛い日々と、思う事なぞ

脳みそってAIより省エネで、高性能なんだよ。

 

人間の脳はたった20ワットで様々なことができるが、現在のAIモデルは嘘つきのくせにその10万倍から100万倍ものエネルギーを消費する。
効率化の余地は非常に大きいとはいえ、今の延長線上にゴールが存在するかといえば、非常に疑わしい。

一つの個体が学習したら、その内容は他のすべての個体にコピーできる。
ってのが利点だという研究者もいるが、裏を返せばそういう均一性が「ポリコレに染まる」とか「人種選別(ジェノサイド)のような選択的実行を行う」とか「プロパガンダを撒き散らす」とかいう、「支配者による価値観の強制」が容易に行えるというディストピアを招く結果にしかいきつかないと考えている。

大事なのは、独立した個体の多様性と、検証のあるゆっくりとした情報の伝達で、それは「人間の脳みそ」であり、人間の脳みそは体のフィードバックによって現実が認識できるからこそ有用であって、その性能を上げるための「教育」だ、と、情報系大学院の学生に話して理解してもらえなかった時から25年も経ってる……。

AIと話するより、人間と話する方がよっぽど面白いし刺激的だ。
おいらの友達には、小学生から引きこもりで中卒という、勉強以外に才能を持つ人から、世間的にいえば低学歴と言われる人も多いし小説書きとかもいる。
交流があった中には全くもってつまらん、教科書ガイドアチーブメントテスト適応型の東大システム系クソエンジニアまでいるが、テストという単一の評価軸上以外の人の方が面白いんだよ。

 

だから、おいらには、ジェミナイじゃなく、ジェミアルが大事なんだ。

 

データストアの選択と実装ミス。

 

新しいDBが出た!

 今までのDBの100倍速いんだよ!!

これ、使うっきゃねぇ!!!

第一人者になれるチャンスだ!!!!

 

って導入してるところが多い。
多すぎる。

具体的なプロダクト名を上げると差し障りがあるんだけど、多分、どのプロダクト名を入れても、90%成り立つ。

 

でも「比較して速い」って主張してくる場合、比較元の得意な処理で比べてるはずがない。

比較元が苦手で、かつ自身のプロダクトの得意な処理で比べる。

例えばカラムナDBの場合、カラム方向にデータを圧縮して保存できるので、カラムのカーディナリティが低いデータの場合(例えば性別:男/女など)、そのカラムだけで集計しようとすると、データ転送量に圧倒的な差が出る(通常の行単位で保存するDBの場合、1行まるまる転送してこなければいけない)。これで「集計が早い」とアピールするわけだが、カラムごとにデータを分けて保存するので、「1行追加」の負荷が高く、複数のカラムに条件をつけて集計しようとすると、途端に処理速度が遅くなる。

分散型DBなんかだと、データの転送量が多い集計処理で、旧来型DBでは当然メインメモリから溢れて、SSDからいちいち読み出さないといけないところを、各Nodeにデータを落としておくウォーミングアップを行なった上で処理するとか、オンメモリDBならオンメモリにインデックスまで展開できる範囲内で旧来型だとディスクイメージでのキャッシュからちまちまと処理させる、とかいう、かなり特殊なシナリオでの比較だったりすることがほとんどだ。
KVSが出始めた頃は、同時アクセス数が、KVSが有利になるところからグラフにしてたりしたなぁ……。

 

通常のDBで十分で、自身のプロダクトでは苦手な処理については、一言も言及しない。

そこで躓く。
ありがちすぎ。


実装/リリース当初は、そういうピーキーなDBでも、データ量が少ないから、苦手な処理でも誤魔化せる。
でも、利用者(テナント)が増え、テナントの規模がデカくなり、1テナントで増えるデータがどんどんデカくなり、スラッシング(ローカル/ネットワーク)が起きるとか、シャッフルが発生するとかいう「処理速度が爆下がる閾値」をいきなり超える。
ある朝、突然、
「日次バッチが朝9時になっても終わらない」
「新しいデータが上書きされ始める」

「処理を取り合ってさらにバッチが遅くなって終わらない」

「先行バッチが終わってないのに次のバッチが走り始める」

とかいう事態に陥る。
バッチを強制終了して、順番調整して再処理して、データチェックして……。

ってのがその日から毎日毎日続く。

 

その裏で、営業は「売れ売れ売れ〜っ!!」って、どんどんでかいターゲットにかかっていって契約をとってきて、データはさらに膨れ上がる。
「分散型DBで処理性能が高いから、全テナントを1箇所にまとめられる!」

「だって、Webページにそう書いてあるから!!」
とか深く考えず、テーブル内でテナントIDのカラム追加するだけで全テナントデータを突っ込むから、重いテナントを隔離もできない。
しかも「PKはUUIDを使うのがセオリーってWebページに書いてあったから!!!」とか、データ空間にデータをぶちまけて、有効データ濃度を爆下げさせているから、処理の大部分がデータ転送になって、どんどん遅くなっていく。
 

で、「インスタンスでかくします」「ノード増やします」って始まるわけだ。

物量(水平垂直スケーリング)≒札束で解決した気になってるんだよね。
それ、解決じゃねーから。

にも関わらず「スケーリングが成功した。設計通りだ」とか鼻息荒く、経営層に報告してたりする。

経営層は「どうしてこんなに経費が爆上がりしてるか、さっぱりわからん……」けど、何が正しいか、誰に聞いていいかわからんから、何も言えない。不満だけが溜まり続ける。

なんて事態が発生する。

なぜこれがスーパーエンジニアなのか。

まじこれ、わけわからん。
 

その頃には、新しいDBを導入して混乱を引き起こした連中は、出世して現場から離れているか、この功績を土産に新天地に逃げ出してる(だいたいこのタイミングで、オイラは炎上現場に入る)。

当然、そういうエンジニアを「スーパーエンジニア」として高給で雇い入れてる会社があるってわけで、その会社でも同じ光景が繰り広げられる、って話だ。
だからそういうプロダクトが増える。

完成して、テナントが増え始めるまで、致命的な失敗をしているって、誰も気づかないから。
 

この辺り指摘すると、「常に正論が正しいというわけじゃない」とか「ブリリアントジャーク」とか「最新動向に疎い」とか言われるんだけどさぁ。

この場合の正論は正しいんだよ。

少なくともシステムの世界では、設計実装した通りに動くから、正しく設計実装してなければ、正しく動かないから。

動いてないだろ?
自分の間違いを、正論を受け入れられない、謙虚さが足りない「なんちゃってエリート」「なんちゃってスーパーエンジニア」が問題なんじゃね?
実際に、そのせいで成長機会を奪われてる企業が呆れるほどたくさんあるんだから。


経営者も、もう少し考えるとか、外部に聞くとかした方がいいと思うぞ。