Introduction-べき論を追い求めて機械学習を個人でやろうとした者の末路

現実的な目標も持っていた 

(自分は今でも、挙げている条件さえ満たせば実現出来ると思っている。)

本当は初めての投稿の中に書くつもりだったが、

あまりにも長くなってしまった内容だったため、独立させた。

■前提知識

べき論:こうあるべき。そうするべき。と、本来の意味で正しいシステム構成を押し通そうとすること。
    実際の運用に乗せるとなると色々な整合性が取れなくなって破綻することが多い。多くのSI企業では煙たがられる。
    古の日本企業に所属している場合はこの論調になっていないかは気を配る必要がある。
    しかしながら、本来正しいのは「べき論」で語られている姿のシステムであり、べき論ベースの成果物イメージを共有している開発者が集うととても素晴らしいシステムが出来る(IT  のアベンジャーズ)。
    べき論を上手くシステム構築・運用に取り込めると多少、炎上も少なくなるかもしれない。
    また、べき論の運用には、理想を求めつつも、相手の事情・立場を考慮できる優しい心が不可欠だ。
対義語:同調圧力。

自分で書いといてなんだが、

多少炎上が少なくなるかもしれないってなんやねん。

当記事に登場する難しめの言葉については必ずそのうち、別の記事でフォローするので、わからないところは軽く読み飛ばしてください。

開幕からごめんね。

よくわからない時はイマジナリー芹沢あさひを頭の中に召喚して「あははーわけわかんないっすー」と言わせておくと色相が濁らずに住みます。

(聡明な読者諸君はお気づきだろうが、自分はシャニマスPである)

これは、一人のシャニマスPga自分の考える理想の機械学習を行おうとした、その時の記録である。

■具体的に何をしようとしたのかを説明させてください。

・機械学習の結果を表示するWEBアプリを作る

・可能であればその学習結果とアルゴリズムを企業に売って金にしたい。

・そして、その経験を元に転職して、ほどほど仕事をこなして生活し、余った時間で作曲をしたい。

というものだった

当時は夢と現実の折衷案だと思っていた。

そして、現実性だけはあったと信じている。(ただし、いくつか足りないものがあった)

「学習アルゴリズムの概要とインフラアーキ図、必要なAPIのリスト、課題と懸念」は頭の中にあった。絵も描いた。コードも書いた。難産な部分もあったが、やった。

自分に足りなかった「アプリ側に関する詳細な知識と具体的な処理内容」は本を読みつつ頑張った。

プログラマーではないため、プログラミングがあまり出来なかった。

自分はインフラ屋として知っている知見から、Pythonにて機械学習することにした。

Webアプリ部分はNode.jsにて画面処理を作ることを適当に決めた。

(個人的には、本当はGoがやりたかった。が、少しだけど書き方を知ってて少しでも学習のしやすいPythonにした。)
(また、プログラミング屋じゃないので、Pythonのどこが機械学習に強いのかと聞かれてもそらではいえない。正直、憧れのフルスタックになるためにいつか網羅したい)

苦労したところ

プログラム自体より、それぞれのマイクロサービスの組み合わせがシステムになるように調整するのが大変だった。

アーキそのもの、はとにかくシンプルさを追求した

コンテナやAPI単位で考えても、
再利用できることを重視
RESTに則るように
イメージ化して
いい感じに処理を流すようにマニュフェストを書いた。

(RESTについても、いつか書きたいですね。あれもなんというか難しいですし。べき論になっちゃうかもですが。)

(マニュフェストはイケてるコンテナ管理ツールのなんかいい感じの設定ファイルです(適当))

さて

そうして

システムは形になりつつあった。

マイクロサービスアーキテクチャと複雑になりがちな小規模開発はかなり相性がいい。

・小さなプログラムの数珠繋ぎであるため、それぞれの要素の開発単位が大きくならない

・また、好きで技術を学びたい、将来的に会社を飛び出して楽にいい金かせぐために色々知りたい「だけ」だった

・加えて一人しかいないため、今後SIerの癌になるチーム制(アプリTm,運用Tm,保守Tm,デプロイTm Lib管 etcetc)が存在しない[最後にまとめて記載]

(マイクロサービスとマイクロサービスアーキテクチャについては非常に誤解が生まれやすいため、追々記事を作成する予定。ここでは何となく独立した機能がいっぱいあって、それぞれが連携してシステムを作る。みたいな感じ)

(いつか、マイクロサービス時代のシステム開発とチーム構成についても書きたいな)

そして、システムを試作した。まだ機能部は足りていなかったが、ほぼ基礎組が完成した。

試作だったが、「マイクロサービスアーキテクチャべき論全開」というチーム制だと絶対に実現できない、とても愉快な思想で設計を行ったため、再利用性もマシマシだった。

流石に少し橋渡しするサービス作る必要があったけど。

最終的には既存のマニュフェストを宛先だけ変更したものを作って、機能部を増やして、(少しだけ新しくAPIを書いて)、(Twitterからの)データを食わせるAPIを走らせれば、全システムを動かせる。

というところまで出来た。

人工知能ちゃんは、最初は右も左もどうやって学習すればいいかもわからないため、手で判断基準を教えてあげるための雑なお世話用画面も用意した。

上手いこと昼働いて、夜にシャニマスやりつつ生放送見つつ、学習の方向性を指示するだけで、きっといいお金と経験になる。そう思った。

UTまでしかやる余裕がなくてシステムが爆発することはあるかもだったけど。

まぁ、しっかり べき論 で作ったし、どっかで詰まっても詰まった箇所のイメージを叩いていけば直せば治せるだろうと。最悪めちゃ時間かかっても、別にいいやくらいの軽い感じ。

時間をかけた愛の結晶(オ○ニーやんけ)がとうとう受肉するところまできた。

とりあえずシステムの一部を一日動かしてみようと、思った。次に3日。次に一週間、二週間、一ヶ月。そんな感じ。

上手くいくといいな。

かかるリソース費用は一日でもそこそこな値段。まぁボーナスあったし。苦肉の策だが課金を控えるというジョーカーもある。

動かす。

まぁコケた。

コケまくった。

個人の限界を感じた。次は誰かとやろう。そう思った。

直し続けて、ようやっと分析に使うテーブルにデータが入った

あとはマニュフェストを複製して、学習用テーブルを増やして、学習処理を多重化すれば理論上は、最高になれる。

どの程度手での補佐は必要なのか。何回学習用テーブルをロールバックさせるのか。そもそもDynamoのロールバックはかなり面倒なんだが。などなど問題は山積みだったが、そのためのシェルも作ったから時間はかかるが、やってやれないことはない。

しかし、そこには、超えられない実現性の問題があった

その問題は最初の懸念点の中にも上がってはいた。

超シンプル。

ここで知能指数が一気に下がる。

金が足りない

以上

機械学習をするのには金がかかる。という話だ。

簡単なシステムなら、そうでもなかったんだろうが、求めているものに対して全力でやりすぎた。

そして、

仕事の案件なら絶対確認する見積もりを超サックリ行っていた。

そう。超乱雑に、やってはいた。

これが派遣契約なら全手戻りで納期超過、契約終了だ。まぁ個人研究みたいなもんだからこそ適当にやったんだが。

各サービスを想定の目一杯使った月額も出していた(最初はサービス利用者が自分しかいないため、ユーザー向け機能の一つは停止同然の状態なのにその分も計算した。まぁ最初だから処理受けてパンクしない程度の大きさだったけど)

しかもその時あったのは、システム全体ではなく、3分の1の仮組みである。単純にリソース使用量は三倍になると思っていた。

今となると、本当にやっていることが正しかったのかとか、実は裏で見えていない処理がコケてないかとか。色々気になる点はある。

Twitterのデータを汲み取ってを有効化する処理を流すと、想定どおりの数のリクエストがシステムにかかった。

スロットルしない程度の余裕を持たせていた。

問題ない。

内部で複数回呼ばれるLambdaへのリクエスト 分析に使うQuery そして、Dynnamoの書き込み・読み取り要求が跳ねた。とてつもない勢いで。

システムの最終的な想定では、「ある程度手でフォローしてロールバックもはさみつつ自由に学習させたい、というコンセプトだったし。息子よ ナンドデモ、チャレンジシテイイノデスヨ 的なノリだった」

@学習コンテナくんA 分からないからって好きにやりすぎ。

@学習コンテナくんC CAさんが動かなきゃいけないくらいに増えるな。

@学習LambdaくんA いや、上限緩和しなかったのは悪いけどそこまでする?

時間経過で処理が落ち着くこともあったが、分からないことがあると好き勝手にDynamoに書き込んで読み込んでいるようだった

その時、

今回の人工知能はコストによって頓挫することを悟った

学習が進めば落ち着くだろうが、

開幕こうなるとは。軌道に乗るまで資金がもたない

まぁ、金が無限にあったなら、これを実現させてもっとデカい金を作れた可能性はある。

そもそも金があるならIT企業版のアベンジャーズでも組織する。

まあ、そんだけ金をかけられる金があるならそもそもこんなことはしてなかったかもしれない。

システムについてシャニマスへ向けるような愛がなかった。

欲だけで超えられる壁ではなかった。

さて

というわけで、機械学習で一儲けしようという話はひとまず凍結したわけだ

今回の教訓と学び

■学び

・機械学習はとてもお金がかかる

・レビュアーはいたほうがいい

■教訓

とりあえず、分からない人はイマジナリー芹沢あさひを脳内に召喚して「この人なに言ってんすか?あははー」と相槌を適当に打たせながら流し読みしすることを推奨します。

あさひかわいいよ。

これからの開発に関する問題点と課題

・これからのシステム開発における主戦場となるマイクロサービスアーキテクチャは旧態依然のチーム体制で運用出来ないと考えている。既存のチームという枠組み自体を解体しないと運用しづらくてしょうがない。[運用Tm 監視Tm デプロイTm プロビTm]→それぞれが複数の分野をフォローする一枚岩のインフラTm

・やはり資金を確保するために 会社に所属し、複数人の体制を敷くことは必要。しかし、お堅い企業にいる限り、旧来のようなチームを構成しようとする圧力からは逃れられない。新しい形のチームを構成できたとしても、それに対応できる人材は多くない。学習コストも多くかかる(↓に追記)。

☆そもそもk8sやサーバーレス、RESTに関する認識、マイクロサービスとマイクロサービスアーキテクチャについて。など(呪文かな?)に関する学習は理想を言えば、共通認識としたい。しかし、自分も大筋しか理解出来ていない。もちろん網羅しているとはいえない。

というか分かる人はAmazonかGoogleに入るか、Youtuberになってこれからの時代の迷える民衆を導くべき。

・また、それぞれの概念について分かりやすく説明されているドキュメントは世に出回っていないと認識している(技術同人界隈のすごい人、誰かお願いします)

そして、ある程度、

これからのチーム編成についても考えています。

・アプリケーション開発はインフラ寄りの知識を、インフラ側はアプリケーション寄りの知識を学習する必要が出てくる。

・前述した通り[運用Tm 監視Tm デプロイTm プロビTm]→それぞれが複数の分野をフォローする一枚岩のインフラTm

 メンバの育成にとても時間がかかる。それに何人月賭けるつもりなのか。というすぐに解決できない大きな問題が発生する。
 さてどうしたものか。
 出来る人を外部から連れてきて開発する?文化が分からない場所にいきなり来てチーム回しながら雛鳥を育成するなんて自分なら絶対にしたくない。

。。。。。。

。。。。

。。

これだけで2万文字は軽く書けるから今はやめておこう。

今回は無能なシャニマスPの残念な記録について語らせてもらった。

久しぶりの出社に備えようと思ったら気づいたら朝でした。

やばい。基本リモートの体制は続くけど。

続きは、今度別記事で上げます。無料にするから読んでね。

次の記事は、自分がどんな人物で、何が夢で、どんなことをする人間か、
軽く触れさせてほしい。

次回、
我輩は考えるシャニマスPである

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます!励みになります!よかったらまた来てくださいね。
考えて整理して分析して考察する。 その営みの結果をここに残す。 その営み自体がしたくて、誰かが見てくれるかもしれない場所を探していて、ここに辿り着いた。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。