Elixirでマイクロサービスパターン【前編】～AI・MLとエッジコンピューティングも～

Slide 1

Slide 1 text

2023/8/16 (Web) ElixirImp#34 Elixirでマイクロサービス & エッジコンピューティング Elixirでマイクロサービスパターン【前編】～ AI・MLとエッジコンピューティングも～ Jul. 30, 2022 ver 0.7 created. Jun. 21, 2023 ver 1.0 updated Jun. 21, 2023 ver 1.0 updated 株式会社DigiDockConsulting 常務取締役CTO Elixirコミュニティ「fukuoka.ex」「ElixirImp」「LiveView JP」オーガナイザ国際カンファレンス「ElixirConf JP」ファウンダー AIスクール「AIジョブカレ」福岡校開校講師北九州市立大学「プログラミング論」教授級非常勤講師北九州高等専門学校特命教授 / コンピュータ研究部指導員 piacere / 森正和

Slide 2

Slide 2 text

my favotite technologies & implements Twitter / NeosVR / Discord @piacere_ex Github / YouTube / Qiita @piacerex 40年前からプログラマ（職業のそれは27年）書けるプログラミング言語は158言語小学4年生でゲームプログラミングを始め、現在もプロダクトとOSSを開発し、事業やコミュニティの優位性へと転用するエンジニア／3社の経営者／PO 大手企業をメイン顧客として、IT事業／UX・UI／ D2Cマーケティング／VR・AR／エッジコンピューティングに絡む事業・企画支援、プロダクトを提供技術コミュニティも複数発足・主催しており、毎月イベント開催とLT、ライブコーディングをこなす piacere / 森正和 “piacere” is an Italian word, means “Joy” == == Real Online VR / AR

Slide 3

Slide 3 text

活動 ≒ 事業＋コミュニティ＋育成（エンジニア、学生） ● 北九州市立大学教授級非常勤講師「プログラミング論」 ● 北九州高等専門学校特命教授コンピュータ研究部指導員 ● ラジオFM KITAQ「Technology Cruising Night」パーソナリティ ● 株式会社DigiDockConsulting 常務取締役CTO ● ほかIT企業2社経営、技術顧問3社担当 ● Elixirコミュニティ「fukuoka.ex」創始者 ● Elixir国際カンファレンス「ElixirConf JP」創始者 ● 「ElixirImp」「LiveView JP」ファウンダー ● AIスクール「AIジョブカレ」福岡校開校者 ● Elixirスクール「Elixir |> College」創始者 ● 高知県工業技術センター AI・機械学習研修講師 ● 上級AI開発コミュニティ「IAIFukuoka」発足人 ● 独立行政法人中小企業基盤整備機構コンサルタント

Slide 4

Slide 4 text

Elixirで会員制Webアプリを20分で構築・改造するライブ「ElixirConf Mori」で検索してください (YouTube検索でも) 海外登壇でライブコーディングしています (YouTubeも) https://www.youtube.com/watch?v=t5TT0-mI2O4

Slide 5

Slide 5 text

DigiDockConsulting: 先端技術で世界を改変する企業 SaaS a Box / IoT Distributed System Concurrent System Elixir Data Science Machine Learning Edge Computing VR / AR D2C Digital Marketing Huge Connections Space Data Utilize Low Latency Micro Service Insourcing IT Material Creation Business Optimize Data Analysis HRD Elixir-Prod. Support DX Diagnostic Tool DX / Digitalization

Slide 6

Slide 6 text

DD.デジマパック：AI・MLがWeb最適化し、D2C実現 All in one デジタルマーケティングプラットフォーム DD.デジマパック Web／SNS行動解析 Web／SNS課題抽出 AIによる改善提案改善施策実施改善効果検証 ECサイト制作支援掲載商品撮影支援受注管理支援商品保管、管理支援商品配送支援 ①WebサイトとSNSのファン行動分析から改善施策をAIが自動で提案、効果検証も可 ②ファンとの交流起点となるEC構築と、受注／商品保管／配送の実業務まで全カバー顧客データ分析・管理営業活動支援顧客アプローチ D2C／ファンコミュニティ ③D2Cを立上げ、ファンと共に成長していく世界標準の事業 DD.デジマパック D2Cアドバンストエディション

Slide 7

Slide 7 text

Bright：エンジニアやPM、デザイナーを評価/採用/育成

Slide 8

Slide 8 text

目次 01 2023年のElixir 03 04 05 02 06 2023年のマイクロサービスマイクロサービスパターンとは？マイクロサービス向きなElixir Elixir AI・MLマイクロサービス Elixirエッジコンピューティング 07 Elixir Chip：性能／省電力10倍 08 この続きのお話は… 09 Elixirマイクロサービスパターン

Slide 9

Slide 9 text

9 2023年のElixir 01 9

Slide 10

Slide 10 text

世界的には高額報酬第3位の言語 01 ● ElixirはStackOverflow「TopPayment」で4年間、上位ランカー ○ 日本は遅れまくりだが最近、知らない人がつぶやき始めた

Slide 11

Slide 11 text

Advent Calendar全分野2位+言語1位 01 ● 1ヶ月で計400コラム…「Advent Ranking 2022」で検索

Slide 12

Slide 12 text

Elixirだけで大抵の開発領域はカバー可 ● Web SPAやAndroid／iOS両対応スマホネイティブアプリ開発は勿論、先端AI・MLやIoT／エッジサーバ、低遅延NWサーバなど、作れないものがほとんど無くなったのが2023年のElixir ● 「Elixirに賭けたか」でググってください 01

Slide 13

Slide 13 text

13 2023年のマイクロサービス 02 13

Slide 14

Slide 14 text

改めて、「マイクロサービス」とは？ 02 ● マイクロサービスはいつ頃から始まった？ ○ マーティン・ファウラーが、ジェームス・ルイスと共に 2014年に提唱 ■ 古くから有名な技術ブログ「Bliki」のオーナー ■ 名著「リファクタリング」の著者 ■ PoEAAと略される名著「エンタープライズアプリケーションアーキテクチャパターン」の著者 ■ eXtreme Programmingとアジャイルソフトウェア開発宣言でも有名なエンジニア ※個人的に4番目のプログラマ／エンジニア師匠 →22年前、eXtreme Programmingで心酔

Slide 15

Slide 15 text

マイクロサービスが広く流行った経緯 02 ● そもそも、なぜマイクロサービスは流行ったのか？ ○ 以下5つのトレンドが、黎明期から成長期に向かった結果、それを束ねる／支える筆頭として「マイクロサービス」が開発者たちと起業家に刺さった…と考える ■ ①クラウドの普及 ■ ②スマホの普及 ■ ③SPAの普及 ■ ④API ■ ⑤スタートアップ

Slide 16

Slide 16 text

マイクロサービスが本当に必要なシーン 02 ● 前提：システムが小規模なうちはマイクロサービスは必要無い ○ マイクロサービスを扱う前に、この前提を忘れないように ■ 一度、マイクロサービス化すると、元に戻すのは困難 ● マイクロサービスは「サービス成功」により必要性が発生する ○ サービスが成功すると、システムは肥大化し、以下課題を抱えるため、その解決方法の1つが「マイクロサービス」 ■ システムが複雑化し、把握／改修のハードルが上がる ■ 開発／ビルド／テスト／デプロイが遅くなる ■ 1つの仮想マシンに利用使途／性能要件が異なる機能が併存するため、パワー配分がメチャクチャになりやすい ■ 一部機能がダウンすると、システム全体がダウンする ■ 技術スタック／ver変更 ≒ システム全域の更改 ≒ ムリ

Slide 17

Slide 17 text

マイクロサービスで行う一般的な対応 02 ● ①サービス単位に分割し、独立させる ○ システムをシンプルに保ちやすく、把握／改修が容易に ○ 開発／テスト／ビルド／デプロイが速い ○ 1つの仮想マシンを同一の利用使途／性能要件の機能で固めやすいため、パワー配分が最適化しやすくなる ○ 一部機能がダウンしてもシステム全体は生き延びる ■ ただし、この利点は逆効果もあるため、後半で言及 ○ 技術スタック／ver変更の影響範囲を小さく留められる ○ 各サービスのスタック／verを揃えなくて良くなる ■ ただし、この利点は逆効果もあるため、後半で言及

Slide 18

Slide 18 text

マイクロサービスで行う一般的な対応 02 ● ②サービス間の協調は、HTTP等の中立的な通信で叶える ○ インプットとアウトプットさえ保証すれば中身は問わない ※AWSは、この手法を組織運営まで拡大し、急成長した ● 部署間連携はAPI仕様交換とし、調整MTG等を撤廃 ● ③サービス単位にDBを分割し、独立させる ○ DB構造の変更を他サービスに波及させない ○ サービス毎に機能とDBが1セットで分割される ● ④スケールアップ／スケールアウトもサービス単位で独立実施 ○ サービス毎に要求されるスケーラビリティが異なってもOK ○ リクエスト過多サービスを再マイクロする切り分けも容易

Slide 19

Slide 19 text

一方、マイクロサービスのデメリット 02 ● ただし、マイクロサービスにはメリットだけで無くデメリットも複数ある（下記はその一例） ■ スケーリングが容易になる一方、スループット低下 ■ トランザクション維持／運用／障害解析の難易度上昇 ■ 技術スタックが増えることに伴う負荷上昇／生産性低下 ■ そもそも機能分割が難しく、妥当なマイクロ化できない ● 業務やグロースの未来予測であり技術で片付かない ● 2023年現在、「マイクロサービスはアンチパターン」とまで言う人すら存在する ※このキーワードでググってください ● 必要性も規模も無いのに、マイクロサービスを導入する考え方（≒しようとする人）には問題があり、サービスやPJチームに大きな害をもたらすことも多いため、乱用や妄信はダメ

Slide 20

Slide 20 text

マイクロサービスは「人災」デパート？ 02 ● 機能分割が難しい以前に、不勉強 or デメリットを知らずに「試してみたい」人が人災の原因？ (流行り物あるあるだが) ○ マイクロサービスを雰囲気でしか理解していない選定者が大変さも分からず採用し、PJとチーム全員を地獄行きに😭 ○ 性能トレードオフの設計がマズくて日々、性能問題勃発😭 ○ PJ全体の技術統制に無頓着な人がキメラを生み続け…😭 ● コンウェイの法則：経営サイドや事業サイドが問題な例も… https://speakerdeck.com/eisuke/eight-years-after-the-microservices-declaration-a-look-back-and-a-look-ahead

Slide 21

Slide 21 text

欲しいのはレイヤーサービスだったオチ 02 ● ID（ユーザー管理）基盤や認証基盤、決済基盤、在庫管理基盤といった、あらゆるサービスから必要とされるような共通サービスの提供は、マイクロサービスがバッドパターン ○ これ、30年くらい前にマイクロカーネルでも見たなぁ… ● レイヤーサービスが有効 (STORES他、世界的にも回帰) ○ 2011年の辛かった大規模通信基盤で既に体験してた ● このあたりの近年トレンドについては、続編の方で詳しく扱います https://speakerdeck.com/myahagi/maikurosahisuhua-woqie-rili-sitemonorisutekai-fa-siteiruohua-oyohisonohou

Slide 22

Slide 22 text

何事も、大事なのは「正しく使う」こと 02 ● 下記のような「当たり前のことを当たり前に」すればマイクロサービスは、サービスグロースの良き味方になる ○ 雰囲気で仕事しない ○ 影響範囲／インパクトを想定した上で判断する ○ よく分かっていない／分かろうとしない人が選定をしない ○ 新しいことは正しく理解してから使う ● 今なら「逆コンウェイの法則」でシステムのための組織作りを https://speakerdeck.com/eisuke/eight-years-after-the-microservices-declaration-a-look-back-and-a-look-ahead

Slide 23

Slide 23 text

23 マイクロサービスパターンとは？ 03 23

Slide 24

Slide 24 text

「マイクロサービスパターン」とは？ 03 ● 「マイクロサービス」の「パターン言語」のこと ● 「パターン言語」とは？ ○ ある領域の解決策やデザイン原則の記述のこと ○ 「デザインパターン」もその1例 ○ アジャイル文脈でも出る…でもIT発では無い ■ 出元は、街や建物、建設に関する253のパターン ■ ITよりも都市計画や建築デザインの方が先 ○ デザインパターン等が万能では無いのと同様、万能では全く無い ● 「マイクロサービスパターン」とは？ ○ マイクロサービスでの解決策やデザイン原則の記述のこと

Slide 25

Slide 25 text

Microservices.ioが提示するパターン 03

Slide 26

Slide 26 text

Microservices.ioカテゴリ別パターン 03 ● アーキテクチャの問題領域 ○ Monolithic Architecture ○ Microservice Architecture ○ Database per Service ● サービス分割の問題領域 ○ Decompose by Business Capability 業務毎に分割 ○ Decompose by Subdomain…サブドメイン毎に分割 ● メッセージングスタイルの問題領域 ○ Remote Procedure Invocation … 同期RPC（REST、gRPC等） ○ Messaging … 非同期メッセージパッシング ● 信頼性の問題領域 ○ Circuit Breaker … レスポンスにタイムアウトを設定 ● サービス・ディスカバリーの問題領域 ○ Self Registration … プロセス生成時に名前登録 ○ Client-Side Discovery ○ 3rd party Registration … 代理で名前登録 ○ Server-Side Discovery ※なお本講は最新版のMicroservice.ioより古いです

Slide 27

Slide 27 text

Microservices.ioカテゴリ別パターン 03 ● トランザクショナル・メッセージングの問題領域 ○ Transactional Outbox ○ Polling Publisher ○ Transaction Log Tailing ● データ整合性の問題領域 ○ Saga ● ビジネスロジックデザインの問題領域 ○ Aggregate ○ Domain Event ○ Domain Model ○ Event Sourcing ○ Transaction Script ● クエリーの問題領域 ○ API Composition ○ CQRS (Command Query Responsibility Segregation) ● 外部 API の問題領域 ○ API Gateway ○ Backends for Front-Ends ※なお本講は最新版のMicroservice.ioより古いです

Slide 28

Slide 28 text

Microservices.ioカテゴリ別パターン 03 ● 自動化テストの問題領域 ○ Consumer-Driven Contract Test ○ Consumer-Side Contract Test ○ Service Component Test ● セキュリティの問題領域 ○ Access Token ● 横断的関心事の問題領域 ○ Externalized Configuration ○ Microservice Chassis ● 監視の問題領域 ○ Health check API ○ Log Aggregation ○ Distributed Tracing ○ Application Metrics ○ Exception Tracking ○ Audit Logging ※なお本講は最新版のMicroservice.ioより古いです

Slide 29

Slide 29 text

Microservices.ioカテゴリ別パターン 03 ● デプロイの問題領域 ○ Language-Specific Packaging Format ○ Single Service per Host ○ Deploy a Service as a VM ○ Deploy a Service as a Container ○ Sidecar ○ Serverless Deployment ○ Service Deployment Platform ○ Service Mesh ● リファクタリングの問題領域 ○ Strangler Application ○ Anti-Corruption Layer ※なお本講は最新版のMicroservice.ioより古いです

Slide 30

Slide 30 text

30 マイクロサービス向きなElixir 04 30

Slide 31

Slide 31 text

マイクロサービス向きなElixirの特徴 ①分散／並行・並列に特化した実行単位とメカニズムを標準搭載 ● マイクロサービス構築／解体に重い腰を上げる必要は無いです ○ サービス分割をAPI群やサーバ単位で無く、プロセス単位で ■ さらに「Umbrella」を使えば、サーバ単位移転も可能 ■ ProtoBufより高速なプロセス間通信でElixir以外と接続 ○ 障害切り分けと復旧も、プロセスグループ単位で行えます ● スレッドセーフ対応が根本から不要です ○ ロック自体が不要な並行・並列タスクが実行可能です ○ (後述する③共有リソースのところで解説します) ● クラウド無しでもエッジコンピューティングが構成できます ○ マルチクラスタやマルチマスタ／インメモリDBを標準搭載 ○ (後述する④プロセス単位調整で続きを解説します) 04 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 32

Slide 32 text

マイクロサービス向きなElixirの特徴 ②並行・並列ネイティブでデータ処理に特化された言語／FW仕様 ● イミュータブルなメモリ利用が並行・並列処理を担保します ○ メモリの破壊的更新は並行・並列の妨げだがElixirには無い ● データ処理とその並行・並列・ネイティブコード化が可能です ○ 「Enum」「Stream」「Flow」「Broadway」「Nx」 ● API無しでサーバデータ更新をフロントに直接連携できます ○ 「LiveView」を使えば、サーバデータ更新をAPI無に直接フロント側に反映できます ○ 「ElixirDesktop」によるスマホネイティブアプリも同様 ● 例外等のムダに惑わされず、「本質」に集中して開発できます ○ ループの排除／再帰不要な関数型／プロセスの自動再起動 ■ プロセスクラッシュ時のオートリブートも設定可能 04 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 33

Slide 33 text

マイクロサービス向きなElixirの特徴 ③共有リソースをロック不要で操作できる「アクターモデル」 ● サーバプロセス経由で共有リソースを使うのでロック不要です ○ 副作用は全てサーバプロセスへのメッセージパッシングで処理され、競合やスレッドセーフから開放されます 04 プロセスγ プロセスα プロセスβ 0 add(5) confirm() 5 「状態」 8 + 5 = 5人やって来た 3人やって来た最初の5人もカウント + 3 = add(3) Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 34

Slide 34 text

大半がElixir標準搭載機能で賄える 04 ※Elixir標準搭載機能の多くが、マイクロサービスに向いている ①Umbrella：サービス移動のための仕組み ○ サブPJをPJ間移動するだけでサービス移行できる ②Node／Process：NW内ノードをプロセスが自由に行き来 ○ 「プロセス指向言語」である強み ○ サービスファサード／ワーカー両方を透過的に配置変更可 ③send／receive／call：サービス間協調の高速化に使える ○ REST／GraphQL APIは気軽だが低速 ○ Elixirプロセス間通信はGenServer等で包めばタダの関数 ④cast (GenServer)／async (Task)：非同期サービス協調

Slide 35

Slide 35 text

大半がElixir標準搭載機能で賄える 04 ⑤API generator：仕様からAPI生成 (CRUD同時生成も可) ⑥register_name：ノード横断の名前登録／全ノード検索 ○ :globalモジュールで全ノードを跨ぐ登録 & ディスカバリ ■ register_name：プロセス名の登録 ■ whereis_name：プロセス名でノード横断の検索 ○ ちなみに、Agentでも名前登録可能 ⑦GenStage／Broadway：LB不要のワーカー群 ⑧Mnesia：サービスローカルDBの一部はインメモリで高速化 ○ DBがサービス内部で閉じているマイクロサービス向き ○ Redisのようなクラスタ間共有インメモリと同等に使える

Slide 36

Slide 36 text

大半がElixir標準搭載機能で賄える 04 ⑨LiveView：SPAやスマホのためにAPIをムダに増やさない ○ SPAやスマホのためのAPI化は「技術的制約」でしか無い ■ マイクロサービス向けのAPI化と比べ、必然性が低い ■ その割に、何百本と激増しやすいため、管理も煩雑に ○ LiveViewはAPIが一切無でSPAやスマホアプリを構成可能 ⑩Supervisor：プロセスグループの生存戦略／管理がしやすい ⑪after／kill_after：プロセス間通信のタイムアウト設定 ○ Elixirプロセス間通信は気軽にタイムアウトを設定できる ○ 標準搭載以外に「ExBreak」という専用ライブラリもある ■ https://github.com/jclem/ex_break ○ 「GenStateMachine」もこの目的に使える ■ https://allanmacgregor.com/posts/circuit-breaker-pattern-in-elixir

Slide 37

Slide 37 text

大半がElixir標準搭載機能で賄える 04 ⑫Nx／Axon：高速AI・ML設備が充実している（先端AIも有） ○ Pythonと同等のAI・MLが実装でき、更に分散化も簡単 ■ 「Nx」…NumPy相当 ■ 「Axon」…Keras／PyTorch／TensorFlow相当 ■ 「AxonOnnx」…Python ONNXモデルを実行可能 ■ 「Bumblebee」…Hugging Faceモデル他を実行可能 ■ 「Livebook」…JupyterNotebook／Colaboratory相当 ※LLMを動作させる仕組みも絶賛、進行中（らしい） ○ Livebookによる手軽で柔軟なお試しノード追加も可能 ■ 分散AI・MLの集中管理コンソールとしても機能する

Slide 38

Slide 38 text

38 Elixirマイクロサービスパターン 05 38

Slide 39

Slide 39 text

Elixirマイクロサービスパターン適用 05 ● サービス分割の問題領域 ○ Decompose by Business Capability … 業務毎に分割 ○ Decompose by Subdomain … サブドメイン毎に分割 ○ (Re-compose … 分割をモノリシックに戻す) ● メッセージングスタイルの問題領域 ○ Remote Procedure Invocation … 同期RPC ○ Messaging … 非同期メッセージパッシング ○ (Worker to API … ワーカーをAPI化) ○ (API to Worker … APIをワーカー化) ● 信頼性の問題領域 ○ Circuit Breaker … レスポンスにタイムアウトを設定 ● サービス・ディスカバリーの問題領域 ○ Self Registration … プロセス生成時に名前登録 ○ Client-Side Discovery ○ 3rd party Registration … 代理で名前登録 ○ Server-Side Discovery ①Umbrella ②Node／Process ③send／receive ④cast／async ⑤API generator ②Node／Process ⑪after／kill_after ⑥register_name

Slide 40

Slide 40 text

10月、実際のElixirコード例で解説予定 ● 「Elixir マイクロサービス connpass」でググってください 05

Slide 41

Slide 41 text

Elixirマイクロサービスのデメリット 05 ● スループットやメディア／ファイル処理はあまり高速では無い ○ 必要であればRustやC++でオフロードする ■ 例．Discord、Slack ○ 一方、AI・MLとその周辺は、Elixirの方が高速なケースも ■ Nx／Axon等のバックエンドはPythonと同等（XLA） ■ NumPy／TensorFlow等以外が低速化しやすいも無い ■ 先端のPython AI・MLも呼び出し可能（詳細は後述） ● メッセージパッシングはHTTPほどの中立的な通信では無い ○ マシン間は、Erlangノード同士で無いと接続できない ■ とは言え、マイクロサービスでも共有メモリは中立的な通信で無いものも採用するので、程度問題とも言える ○ 通信が「性能よりも中立さ」を重視するならNG ■ UmbrellaでAPIを移動する…という手段が有用

Slide 42

Slide 42 text

42 Elixirエッジコンピューティング 06 42

Slide 43

Slide 43 text

Elixirはエッジコンピューティング向き ④分散とスケーリングを「プロセス単位」で調整 (PC間移動も) ● エッジコンピューティングネイティブ：クラウド無で分散環境 ○ マルチクラスタが標準搭載で、「libcluster」と組み合わせればオートスケールも実現できます ○ マルチマスタ／冗長対応DBの「Mnesia」も標準搭載で、分散インメモリDBがRedis (Cluster／Sentinel) 無で実現 ○ 前述したプロセス単位のスケーリングも併用が可能です ○ このように、クラウド無でも分散NWシステムを構築 ● クラウド／エッジサーバ／エッジの間を動的プロセス移動も ○ Elixirクラスタ間は「nl」関数でモジュールをデプロイ可能 ■ 動的なクラスタ間プロセス移動を叶えられる ○ CPU利用率やメモリ利用率を見ながら、空きのある筐体にプロセスを移動する先は、スマホやIoTでもOKです 06 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 44

Slide 44 text

Elixirはエッジコンピューティング向き ⑤性能と電力消費のトレードオフが低コストで可能 ● データ処理の性能と電力消費のコントロールを下記で叶えます ○ 性能アップは、通常データ処理 (Enum等) のマルチコア版である「Flow」へと置換する等、マルチコア化が容易です ○ 性能抑制と消費電力抑制は、データフローの制御が可能な「Broadway」でRateLimitを掛けることで実現できます ● 省電力デバイス開発もElixirエコシステムをそのまま使えます ○ 「ElixirDesktop」でSPAをスマホネイティブアプリに変換 ○ IoT開発は「Nerves」で組み込み開発と思えない高度さ ○ Web／クラウド向けに開発した資産を転用できます ○ これらをプロセス移転と組み合わせれば、プロセス単位での省電力デバイスへの部分移行も簡単に叶えられます 06 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 45

Slide 45 text

45 Elixir AI・MLとの組み合わせ 07 45

Slide 46

Slide 46 text

Elixir AI・MLとの組み合わせ ②いつでも並行・分散・マイクロサービス化できて、性能課題を抱えない機械学習／ディープラーニング内臓インフラの実現 ● 前述マイクロサービスメリットと並行・分散をAI・MLと共に ○ Elixirは2022年以降、Stable Diffusion等の生成AIも動作可 ○ APIを生やさなくてもAI・MLをマルチクラスタ化できます ○ 先端Python AIも、Elixirから「ErlPort」で呼べます ● AI・ML以外の処理で性能問題を抱えません 07 ○ Pythonで構築した系のAI部は NumPyがC++で高速な一方、 AI以外は性能課題を抱えやすい ○ Elixirは性能課題を抱えず、作り直しやリファクタリングは不要顔DB 照合顔検出 API API DB Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 47

Slide 47 text

47 Elixir Chipで1桁上の性能／省電力 08 47

Slide 48

Slide 48 text

そんなElixirをCPU化していく ● 現代のコンピューティングでは不可能なレベルの「性能向上」と「省電力」、そしてエンジニアの「工数削減」が叶う期待 ● この着想は分散型ID規格団体「DID Foundation」で活動する Brooklyn ZelenkaさんのPodcastを翻訳した際に芽生えました 08 ● コラムは「Elixir ② Web3」でググれば見つかります ● このコラムの「イミュータブルが分散コンピューティングに有利なElixir」でこのモチベーションおよび背景がご覧いただけます Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 49

Slide 49 text

翻訳コラムを要約し、深堀りすると… イミュータブルな関数型言語はHW化することで、凄まじい性能を持つ分散システムの構築が可能となる ● オブジェクト指向言語は、コードの中に変更可能なメモリ部分 (メンバ変数) を持つため、HW化時に計算ロジックとデータを分離しにくく、メモリ破壊的更新によりキャッシュ制御が複雑 ○ CPU／メモリ間のやり取りが増え、性能劣化と電力消費増を引き起こす (≒フォン・ノイマン・ボトルネック) ○ インスタンス自体もメモリなので、この傾向がより高まる ● Elixirのようなメモリ不変 (≒イミュータブル) で計算ロジックが疎な関数で構成されるものであれば、ハードウェア化が容易でフォン・ノイマン・ボトルネックも回避しやすくなる 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 50

Slide 50 text

例．Elixir Chipはメモリに戻さず処理 ● Elixirのパイプを従来CPUとElixir Chipで比較してみます ○ 従来CPUは頻繁なメモリ操作があるがElixir Chipは最小限 ● ミュータブルな言語はより悲観的 (≒言語が性能と電力に影響) ● こうした概念とテクニックを突き詰めれば、並行・並列／分散とデータの高速処理に特化したコンピューティングが可能 08 従来CPU Elixir Chip メモリメモリ ① ② ③ ④ ⑤ ① ② ③ ④ ⑤ list = [1, 2, 3, 4, 5] list |> Enum.map(& &1 * 3) |> Enum.filter(& &1 >= 8) |> Enum.sum() ① ② ③ ④ ⑤ Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 51

Slide 51 text

はて、CPUって簡単に作れるの？… ● ハード面はFPGA (Field Programmable Gate Array) で気軽に構築／テストすることもできるし、本格的に量産する際は ASIC (Application Specific Integrated Circuit) で構築可能 ○ ASICは一度焼くと書き換え不可だが単価が安い ○ FPGAはプログラマブルで、一度焼いた後に書き換えも可能 08 ● FPGAなら数十ｍＷの電力で駆動させることもできるし、実は高速計算も可能 ● CPUレベルで性能と消費電力を制御できる点が重要 ● ソフト面はRISC-VのようなOSSもあり CPUスタートアップも数社ある位 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 52

Slide 52 text

Elixir Chipが叶える可能性 ①軽量なマイクロサービス構築／解体により、大規模分散基盤とリーンを両立 (性能とオフロード、電力消費制御、耐障害性も) ● 独立高速開発と、気軽にモノリシックへ戻せるメリットの両立 ○ 少量作ってグロースさせていくマイクロサービス本来の姿 ● サーバ300台を10台にできるElixir、Elixir Chipで更に1桁増 08 ○ クラウド月額1,500万円は Elixir化で50万円にでき、 Elixir Chip化で5万円台に ○ Google並の高性能コンピューティング環境を普通の企業が持てる未来を創る Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 53

Slide 53 text

Elixir Chipが叶える可能性 ②いつでも並行・分散・マイクロサービス化できて、性能課題を抱えない機械学習／ディープラーニング内臓インフラの実現 ● 前述マイクロサービスメリットと並行・分散をAI・MLと共に ○ Elixirは2022年以降、Stable Diffusion等の生成AIも動作可 ○ APIを生やさなくてもAI・MLをマルチクラスタ化できます ○ 先端Python AIも、Elixirから「ErlPort」で呼べます ● AI・ML以外の処理で性能問題を抱えません 08 ○ Pythonで構築した系のAI部は NumPyがC++で高速な一方、 AI以外は性能課題を抱えやすい ○ Elixirは性能課題を抱えず、作り直しやリファクタリングは不要顔DB 照合顔検出 API API DB Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 54

Slide 54 text

Elixir Chipが叶える可能性 ③「非データ」…スモールデータ／ミドルデータは変換後データを保存／ロードするよりも都度データ変換した方が省電力になる ● 元のデータさえあれば、後は欲しいデータを計算で生成できる ○ 前述したElixir Chipでのパイプ例は、その典型的な例 ○ 「非データ」とは、写像のみでデータを表現する概念 ■ 「写像」≒「関数で希望するデータへと変換すること」 ○ OOP提唱者のアラン・ケイが約40年前に構想したもので、本来のOOPとは「非データ」と「メッセージング」を指す ■ アラン・ケイが2020年に受けたインタビューで後悔 ● メモリ書き出しせず、NWの向こうにデータを返せる可能性 ○ 「メッセージング」はプロセス間通信で情報伝達する概念 ○ Elixirのメッセージパッシングは、メッセージングそのもの ○ これもElixir Chipで高速再現され、メモリ利用を最小化 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 55

Slide 55 text

Elixir Chipが叶える可能性 ④スマホやドローン等の地表エッジと、衛星やローバー等の宇宙エッジに重要な省電力とオフライン対応、エッジAI・ML化 ● エッジはPCと別世界な省電力とクラウド途絶対応が必須に ○ モバイル電力や太陽光発電は100v程、電力は自由で無い ○ 消費電力を最低限に押さえるため、FPGA製CPUが活躍する ● エッジ側／エッジ単体のデータ分析やGPU無AI・MLも重要 08 クラウドエッジサーバエッジ通信途絶でオフライン ○ 通信途絶時や、データをオフィスに持ち帰る手間を省くために、エッジ側でのデータ処理も重要 ○ 消費電力の観点からGPU が利用不可でも高速行列演算が可能なElixir Chip Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 56

Slide 56 text

さらに次世代のHWによる未来 ● Elixir Chipの本当のポテンシャルを引き出すには、現在のコンピューティングアーキテクチャ (フォン・ノイマン型) やHW 利用の呪縛を解く、下記アーキテクチャ浸透も重要になります ○ これらの研究は、ここ10年で世界の大手や研究機関が開始ａ）フォトニクス … CPU／メモリのバスよりも光NWの方が高速ｂ）メモリ主導アーキテクチャ … JAMStackのような系はHW化されたWebサーバ上メモリとNWで何百倍も高速化 (計算が無い) ｃ）ネイバーフッドコンピューティング … 近所のデータで返すｄ）Lend GPU to Earn … 全世界のスマホはGTX1060級GPUが搭載済 (snapdragon 888やA14以降) でこれらを繋げばクラウドレンダリングと呼ばれるNW経由のGPUパワー提供が可能になる 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 57

Slide 57 text

さらに次世代のHWによる未来 ● 「ネイバーフッドコンピューティング」と「Lend GPU to Earn」はコラム化しています ● 「Elixir Chip」でググってください 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載

Slide 58

Slide 58 text

58 この続きのお話は… 09 58

Slide 59

Slide 59 text

①9/20 ElixirImpでElixir Chip座談会 ● 「Elixir Chip connpass」でググってください ● 本日LTした内容の質疑応答やディスカッション (守秘部以外) ● コンピューティングの課題解決とCPU開発にご興味あればぜひ 09

Slide 60

Slide 60 text

②Discordにチャンネルがあります ● 「Elixir Discord」でググると出る参加ガイドに沿ってご参加 ● 「😈｜elixirimp-芽を愛でる」チャンネルにいらしてください 09

Slide 61

Slide 61 text

③「エリクサーチ」で特集コラムを予定 ● 「エリクサーチ」でググってください ● 本日の続きや詳細をコラム化しようと思います ● エリクサーチには、Elixir入門と、入門後のガイドがあります 09 https://elixir-lang.info

Slide 62

Slide 62 text

④Elixirコミュニティのイベントでも？ 09 ● 「Elixirイベントカレンダー」でググってください ● 様々なElixirコミュニティが開催するイベントが掲載 (月20本以上) されており、今日の続きに相当する情報が拾えるかも？ https://elixir-jp-calendar.fly.dev

Slide 63

Slide 63 text

⑤9/15 生成AI活用セミナー ● 「生成AIセミナー高知」でググってください ● エンジニアの私だからこそ可能なChatGPTやBing等の活用術 ● LivebookやElixirアプリで動かすことも見据えた活用術かも？ 09

Slide 64

Slide 64 text

That’s all for my talk Thank you very much