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

Transcript

1. 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 / 森 正和
2. 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
3. 活動 ≒ 事業＋コミュニティ＋育成（エンジニア、学生） • 北九州市立大学 教授級非常勤講師「プログラミング論」 • 北九州高等専門学校 特命教授 コンピュータ研究部指導員 • ラジオ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」発足人 • 独立行政法人 中小企業基盤整備機構 コンサルタント
4. Elixirで会員制Webアプリを20分で構築・改造するライブ 「ElixirConf Mori」で検索してください (YouTube検索でも) 海外登壇でライブコーディングしています (YouTubeも) https://www.youtube.com/watch?v=t5TT0-mI2O4
5. 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
6. DD.デジマパック：AI・MLがWeb最適化し、D2C実現 All in one デジタルマーケティングプラットフォーム DD.デジマパック Web／SNS行動解析 Web／SNS課題抽出 AIによる改善提案 改善施策実施 改善効果検証 ECサイト制作支援 掲載商品撮影支援 受注管理支援 商品保管、管理支援 商品配送支援 ①WebサイトとSNSのファン行動分析から改善施策をAIが自動で提案、効果検証も可 ②ファンとの交流起点となるEC構築と、受注／商品保管／配送の実業務まで全カバー 顧客データ分析・管理 営業活動支援 顧客アプローチ D2C／ファンコミュニティ ③D2Cを立上げ、ファンと共に成長していく世界標準の事業 DD.デジマパック D2Cアドバンストエディション
7. Bright：エンジニアやPM、デザイナーを評価/採用/育成
8. 目次 01 2023年のElixir 03 04 05 02 06 2023年のマイクロサービス マイクロサービスパターンとは？ マイクロサービス向きなElixir Elixir AI・MLマイクロサービス Elixirエッジコンピューティング 07 Elixir Chip：性能／省電力10倍 08 この続きのお話は… 09 Elixirマイクロサービスパターン
9. 9 2023年のElixir 01 9
10. 世界的には高額報酬第3位の言語 01 • ElixirはStackOverflow「TopPayment」で4年間、上位ランカー ◦ 日本は遅れまくりだが最近、知らない人がつぶやき始めた
11. Advent Calendar全分野2位+言語1位 01 • 1ヶ月で計400コラム…「Advent Ranking 2022」で検索
12. Elixirだけで大抵の開発領域はカバー可 • Web SPAやAndroid／iOS両対応スマホネイティブアプリ開発 は勿論、先端AI・MLやIoT／エッジサーバ、低遅延NWサーバ など、作れないものがほとんど無くなったのが2023年のElixir • 「Elixirに賭けたか」でググってください 01
13. 13 2023年のマイクロサービス 02 13
14. 改めて、「マイクロサービス」とは？ 02 • マイクロサービスはいつ頃から始まった？ ◦ マーティン・ファウラーが、ジェームス・ルイスと共に 2014年に提唱 ▪ 古くから有名な技術ブログ「Bliki」のオーナー ▪ 名著「リファクタリング」の著者 ▪ PoEAAと略される名著「エンタープライズアプリケーシ ョンアーキテクチャパターン」の著者 ▪ eXtreme Programmingとアジャイルソフトウェア開発 宣言でも有名なエンジニア ※個人的に4番目のプログラマ／エンジニア師匠 →22年前、eXtreme Programmingで心酔
15. マイクロサービスが広く流行った経緯 02 • そもそも、なぜマイクロサービスは流行ったのか？ ◦ 以下5つのトレンドが、黎明期から成長期に向かった結果、 それを束ねる／支える筆頭として「マイクロサービス」が 開発者たちと起業家に刺さった…と考える ▪ ①クラウドの普及 ▪ ②スマホの普及 ▪ ③SPAの普及 ▪ ④API ▪ ⑤スタートアップ
16. マイクロサービスが本当に必要なシーン 02 • 前提：システムが小規模なうちはマイクロサービスは必要無い ◦ マイクロサービスを扱う前に、この前提を忘れないように ▪ 一度、マイクロサービス化すると、元に戻すのは困難 • マイクロサービスは「サービス成功」により必要性が発生する ◦ サービスが成功すると、システムは肥大化し、以下課題を 抱えるため、その解決方法の1つが「マイクロサービス」 ▪ システムが複雑化し、把握／改修のハードルが上がる ▪ 開発／ビルド／テスト／デプロイが遅くなる ▪ 1つの仮想マシンに利用使途／性能要件が異なる機能が 併存するため、パワー配分がメチャクチャになりやすい ▪ 一部機能がダウンすると、システム全体がダウンする ▪ 技術スタック／ver変更 ≒ システム全域の更改 ≒ ムリ
17. マイクロサービスで行う一般的な対応 02 • ①サービス単位に分割し、独立させる ◦ システムをシンプルに保ちやすく、把握／改修が容易に ◦ 開発／テスト／ビルド／デプロイが速い ◦ 1つの仮想マシンを同一の利用使途／性能要件の機能で固め やすいため、パワー配分が最適化しやすくなる ◦ 一部機能がダウンしてもシステム全体は生き延びる ▪ ただし、この利点は逆効果もあるため、後半で言及 ◦ 技術スタック／ver変更の影響範囲を小さく留められる ◦ 各サービスのスタック／verを揃えなくて良くなる ▪ ただし、この利点は逆効果もあるため、後半で言及
18. マイクロサービスで行う一般的な対応 02 • ②サービス間の協調は、HTTP等の中立的な通信で叶える ◦ インプットとアウトプットさえ保証すれば中身は問わない ※AWSは、この手法を組織運営まで拡大し、急成長した • 部署間連携はAPI仕様交換とし、調整MTG等を撤廃 • ③サービス単位にDBを分割し、独立させる ◦ DB構造の変更を他サービスに波及させない ◦ サービス毎に機能とDBが1セットで分割される • ④スケールアップ／スケールアウトもサービス単位で独立実施 ◦ サービス毎に要求されるスケーラビリティが異なってもOK ◦ リクエスト過多サービスを再マイクロする切り分けも容易
19. 一方、マイクロサービスのデメリット 02 • ただし、マイクロサービスにはメリットだけで無くデメリット も複数ある（下記はその一例） ▪ スケーリングが容易になる一方、スループット低下 ▪ トランザクション維持／運用／障害解析の難易度上昇 ▪ 技術スタックが増えることに伴う負荷上昇／生産性低下 ▪ そもそも機能分割が難しく、妥当なマイクロ化できない • 業務やグロースの未来予測であり技術で片付かない • 2023年現在、「マイクロサービスはアンチパターン」とまで 言う人すら存在する ※このキーワードでググってください • 必要性も規模も無いのに、マイクロサービスを導入する考え方 （≒しようとする人）には問題があり、サービスやPJチームに 大きな害をもたらすことも多いため、乱用や妄信はダメ
20. マイクロサービスは「人災」デパート？ 02 • 機能分割が難しい以前に、不勉強 or デメリットを知らずに 「試してみたい」人が人災の原因？ (流行り物あるあるだが) ◦ マイクロサービスを雰囲気でしか理解していない選定者が 大変さも分からず採用し、PJとチーム全員を地獄行きに😭 ◦ 性能トレードオフの設計がマズくて日々、性能問題勃発😭 ◦ PJ全体の技術統制に無頓着な人がキメラを生み続け…😭 • コンウェイの法則：経営サイドや事業サイドが問題な例も… https://speakerdeck.com/eisuke/eight-years-after-the-microservices-declaration-a-look-back-and-a-look-ahead
21. 欲しいのはレイヤーサービスだったオチ 02 • ID（ユーザー管理）基盤や認証基盤、決済基盤、在庫管理基盤 といった、あらゆるサービスから必要とされるような共通サー ビスの提供は、マイクロサービスがバッドパターン ◦ これ、30年くらい前にマイクロカーネルでも見たなぁ… • レイヤーサービスが有効 (STORES他、世界的にも回帰) ◦ 2011年の辛かった大規模 通信基盤で既に体験してた • このあたりの近年トレンドに ついては、続編の方で詳しく 扱います https://speakerdeck.com/myahagi/maikurosahisuhua-woqie-rili-sitemonorisutekai-fa-siteiruohua-oyohisonohou
22. 何事も、大事なのは「正しく使う」こと 02 • 下記のような「当たり前のことを当たり前に」すればマイクロ サービスは、サービスグロースの良き味方になる ◦ 雰囲気で仕事しない ◦ 影響範囲／インパクトを想定した上で判断する ◦ よく分かっていない／分かろうとしない人が選定をしない ◦ 新しいことは正しく理解してから使う • 今なら「逆コンウェイの法則」でシステムのための組織作りを https://speakerdeck.com/eisuke/eight-years-after-the-microservices-declaration-a-look-back-and-a-look-ahead
23. 23 マイクロサービスパターンとは？ 03 23
24. 「マイクロサービスパターン」とは？ 03 • 「マイクロサービス」の「パターン言語」のこと • 「パターン言語」とは？ ◦ ある領域の解決策やデザイン原則の記述のこと ◦ 「デザインパターン」もその1例 ◦ アジャイル文脈でも出る…でもIT発では無い ▪ 出元は、街や建物、建設に関する253のパターン ▪ ITよりも都市計画や建築デザインの方が先 ◦ デザインパターン等が万能では無いのと同様、 万能では全く無い • 「マイクロサービスパターン」とは？ ◦ マイクロサービスでの解決策やデザイン原則 の記述のこと
25. Microservices.ioが提示するパターン 03
26. 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より古いです
27. 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より古いです
28. 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より古いです
29. 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より古いです
30. 30 マイクロサービス向きなElixir 04 30
31. マイクロサービス向きなElixirの特徴 ①分散／並行・並列に特化した実行単位とメカニズムを標準搭載 • マイクロサービス構築／解体に重い腰を上げる必要は無いです ◦ サービス分割をAPI群やサーバ単位で無く、プロセス単位で ▪ さらに「Umbrella」を使えば、サーバ単位移転も可能 ▪ ProtoBufより高速なプロセス間通信でElixir以外と接続 ◦ 障害切り分けと復旧も、プロセスグループ単位で行えます • スレッドセーフ対応が根本から不要です ◦ ロック自体が不要な並行・並列タスクが実行可能です ◦ (後述する③共有リソースのところで解説します) • クラウド無しでもエッジコンピューティングが構成できます ◦ マルチクラスタやマルチマスタ／インメモリDBを標準搭載 ◦ (後述する④プロセス単位調整で続きを解説します) 04 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
32. マイクロサービス向きなElixirの特徴 ②並行・並列ネイティブでデータ処理に特化された言語／FW仕様 • イミュータブルなメモリ利用が並行・並列処理を担保します ◦ メモリの破壊的更新は並行・並列の妨げだがElixirには無い • データ処理とその並行・並列・ネイティブコード化が可能です ◦ 「Enum」「Stream」「Flow」「Broadway」「Nx」 • API無しでサーバデータ更新をフロントに直接連携できます ◦ 「LiveView」を使えば、サーバデータ更新をAPI無に直接 フロント側に反映できます ◦ 「ElixirDesktop」によるスマホネイティブアプリも同様 • 例外等のムダに惑わされず、「本質」に集中して開発できます ◦ ループの排除／再帰不要な関数型／プロセスの自動再起動 ▪ プロセスクラッシュ時のオートリブートも設定可能 04 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
33. マイクロサービス向きなElixirの特徴 ③共有リソースをロック不要で操作できる「アクターモデル」 • サーバプロセス経由で共有リソースを使うのでロック不要です ◦ 副作用は全てサーバプロセスへのメッセージパッシングで 処理され、競合やスレッドセーフから開放されます 04 プロセスγ プロセスα プロセスβ 0 add(5) confirm() 5 「状態」 8 + 5 = 5人やって来た 3人やって来た 最初の5人もカウント + 3 = add(3) Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
34. 大半がElixir標準搭載機能で賄える 04 ※Elixir標準搭載機能の多くが、マイクロサービスに向いている ①Umbrella：サービス移動のための仕組み ◦ サブPJをPJ間移動するだけでサービス移行できる ②Node／Process：NW内ノードをプロセスが自由に行き来 ◦ 「プロセス指向言語」である強み ◦ サービスファサード／ワーカー両方を透過的に配置変更可 ③send／receive／call：サービス間協調の高速化に使える ◦ REST／GraphQL APIは気軽だが低速 ◦ Elixirプロセス間通信はGenServer等で包めばタダの関数 ④cast (GenServer)／async (Task)：非同期サービス協調
35. 大半がElixir標準搭載機能で賄える 04 ⑤API generator：仕様からAPI生成 (CRUD同時生成も可) ⑥register_name：ノード横断の名前登録／全ノード検索 ◦ :globalモジュールで全ノードを跨ぐ登録 & ディスカバリ ▪ register_name：プロセス名の登録 ▪ whereis_name：プロセス名でノード横断の検索 ◦ ちなみに、Agentでも名前登録可能 ⑦GenStage／Broadway：LB不要のワーカー群 ⑧Mnesia：サービスローカルDBの一部はインメモリで高速化 ◦ DBがサービス内部で閉じているマイクロサービス向き ◦ Redisのようなクラスタ間共有インメモリと同等に使える
36. 大半が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
37. 大半が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の集中管理コンソールとしても機能する
38. 38 Elixirマイクロサービスパターン 05 38
39. 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
40. 10月、実際のElixirコード例で解説予定 • 「Elixir マイクロサービス connpass」でググってください 05
41. Elixirマイクロサービスのデメリット 05 • スループットやメディア／ファイル処理はあまり高速では無い ◦ 必要であればRustやC++でオフロードする ▪ 例．Discord、Slack ◦ 一方、AI・MLとその周辺は、Elixirの方が高速なケースも ▪ Nx／Axon等のバックエンドはPythonと同等（XLA） ▪ NumPy／TensorFlow等以外が低速化しやすいも無い ▪ 先端のPython AI・MLも呼び出し可能（詳細は後述） • メッセージパッシングはHTTPほどの中立的な通信では無い ◦ マシン間は、Erlangノード同士で無いと接続できない ▪ とは言え、マイクロサービスでも共有メモリは中立的な 通信で無いものも採用するので、程度問題とも言える ◦ 通信が「性能よりも中立さ」を重視するならNG ▪ UmbrellaでAPIを移動する…という手段が有用
42. 42 Elixirエッジコンピューティング 06 42
43. Elixirはエッジコンピューティング向き ④分散とスケーリングを「プロセス単位」で調整 (PC間移動も) • エッジコンピューティングネイティブ：クラウド無で分散環境 ◦ マルチクラスタが標準搭載で、「libcluster」と組み合わせ ればオートスケールも実現できます ◦ マルチマスタ／冗長対応DBの「Mnesia」も標準搭載で、 分散インメモリDBがRedis (Cluster／Sentinel) 無で実現 ◦ 前述したプロセス単位のスケーリングも併用が可能です ◦ このように、クラウド無でも分散NWシステムを構築 • クラウド／エッジサーバ／エッジの間を動的プロセス移動も ◦ Elixirクラスタ間は「nl」関数でモジュールをデプロイ可能 ▪ 動的なクラスタ間プロセス移動を叶えられる ◦ CPU利用率やメモリ利用率を見ながら、空きのある筐体に プロセスを移動する先は、スマホやIoTでもOKです 06 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
44. Elixirはエッジコンピューティング向き ⑤性能と電力消費のトレードオフが低コストで可能 • データ処理の性能と電力消費のコントロールを下記で叶えます ◦ 性能アップは、通常データ処理 (Enum等) のマルチコア版 である「Flow」へと置換する等、マルチコア化が容易です ◦ 性能抑制と消費電力抑制は、データフローの制御が可能な 「Broadway」でRateLimitを掛けることで実現できます • 省電力デバイス開発もElixirエコシステムをそのまま使えます ◦ 「ElixirDesktop」でSPAをスマホネイティブアプリに変換 ◦ IoT開発は「Nerves」で組み込み開発と思えない高度さ ◦ Web／クラウド向けに開発した資産を転用できます ◦ これらをプロセス移転と組み合わせれば、プロセス単位で の省電力デバイスへの部分移行も簡単に叶えられます 06 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
45. 45 Elixir AI・MLとの組み合わせ 07 45
46. 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＠マネーフォワードオフィスより転載
47. 47 Elixir Chipで1桁上の性能／省電力 08 47
48. そんなElixirをCPU化していく • 現代のコンピューティングでは不可能なレベルの「性能向上」 と「省電力」、そしてエンジニアの「工数削減」が叶う期待 • この着想は分散型ID規格団体「DID Foundation」で活動する Brooklyn ZelenkaさんのPodcastを翻訳した際に芽生えました 08 • コラムは「Elixir ② Web3」でググれば見つか ります • このコラムの「イミュータ ブルが分散コンピューティ ングに有利なElixir」でこの モチベーションおよび背景 がご覧いただけます Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
49. 翻訳コラムを要約し、深堀りすると… イミュータブルな関数型言語はHW化することで、 凄まじい性能を持つ分散システムの構築が可能となる • オブジェクト指向言語は、コードの中に変更可能なメモリ部分 (メンバ変数) を持つため、HW化時に計算ロジックとデータを 分離しにくく、メモリ破壊的更新によりキャッシュ制御が複雑 ◦ CPU／メモリ間のやり取りが増え、性能劣化と電力消費増 を引き起こす (≒フォン・ノイマン・ボトルネック) ◦ インスタンス自体もメモリなので、この傾向がより高まる • Elixirのようなメモリ不変 (≒イミュータブル) で計算ロジック が疎な関数で構成されるものであれば、ハードウェア化が容易 でフォン・ノイマン・ボトルネックも回避しやすくなる 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
50. 例．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＠マネーフォワードオフィスより転載
51. はて、CPUって簡単に作れるの？… • ハード面はFPGA (Field Programmable Gate Array) で気軽 に構築／テストすることもできるし、本格的に量産する際は ASIC (Application Specific Integrated Circuit) で構築可能 ◦ ASICは一度焼くと書き換え不可だが単価が安い ◦ FPGAはプログラマブルで、一度焼いた後に書き換えも可能 08 • FPGAなら数十ｍＷの電力で 駆動させることもできるし、 実は高速計算も可能 • CPUレベルで性能と消費電力 を制御できる点が重要 • ソフト面はRISC-VのようなOSSもあり CPUスタートアップも数社ある位 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
52. Elixir Chipが叶える可能性 ①軽量なマイクロサービス構築／解体により、大規模分散基盤と リーンを両立 (性能とオフロード、電力消費制御、耐障害性も) • 独立高速開発と、気軽にモノリシックへ戻せるメリットの両立 ◦ 少量作ってグロースさせていくマイクロサービス本来の姿 • サーバ300台を10台にできるElixir、Elixir Chipで更に1桁増 08 ◦ クラウド月額1,500万円は Elixir化で50万円にでき、 Elixir Chip化で5万円台に ◦ Google並の高性能コンピ ューティング環境を普通の 企業が持てる未来を創る Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
53. 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＠マネーフォワードオフィスより転載
54. Elixir Chipが叶える可能性 ③「非データ」…スモールデータ／ミドルデータは変換後データ を保存／ロードするよりも都度データ変換した方が省電力になる • 元のデータさえあれば、後は欲しいデータを計算で生成できる ◦ 前述したElixir Chipでのパイプ例は、その典型的な例 ◦ 「非データ」とは、写像のみでデータを表現する概念 ▪ 「写像」≒「関数で希望するデータへと変換すること」 ◦ OOP提唱者のアラン・ケイが約40年前に構想したもので、 本来のOOPとは「非データ」と「メッセージング」を指す ▪ アラン・ケイが2020年に受けたインタビューで後悔 • メモリ書き出しせず、NWの向こうにデータを返せる可能性 ◦ 「メッセージング」はプロセス間通信で情報伝達する概念 ◦ Elixirのメッセージパッシングは、メッセージングそのもの ◦ これもElixir Chipで高速再現され、メモリ利用を最小化 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
55. Elixir Chipが叶える可能性 ④スマホやドローン等の地表エッジと、衛星やローバー等の宇宙 エッジに重要な省電力とオフライン対応、エッジAI・ML化 • エッジはPCと別世界な省電力とクラウド途絶対応が必須に ◦ モバイル電力や太陽光発電は100v程、電力は自由で無い ◦ 消費電力を最低限に押さえるため、FPGA製CPUが活躍する • エッジ側／エッジ単体のデータ分析やGPU無AI・MLも重要 08 クラウド エッジサーバ エッジ 通 信 途 絶 で オ フ ラ イ ン ◦ 通信途絶時や、データを オフィスに持ち帰る手間 を省くために、エッジ側 でのデータ処理も重要 ◦ 消費電力の観点からGPU が利用不可でも高速行列 演算が可能なElixir Chip Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
56. さらに次世代の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＠マネーフォワードオフィスより転載
57. さらに次世代のHWによる未来 • 「ネイバーフッドコンピューティング」と 「Lend GPU to Earn」はコラム化しています • 「Elixir Chip」でググってください 08 Elixirで宇宙衛星／エッジコンピューティング／Web＠マネーフォワードオフィスより転載
58. 58 この続きのお話は… 09 58
59. ①9/20 ElixirImpでElixir Chip座談会 • 「Elixir Chip connpass」でググってください • 本日LTした内容の質疑応答やディスカッション (守秘部以外) • コンピューティングの課題解決とCPU開発にご興味あればぜひ 09
60. ②Discordにチャンネルがあります • 「Elixir Discord」でググると出る参加ガイドに沿ってご参加 • 「😈｜elixirimp-芽を愛でる」チャンネルにいらしてください 09
61. ③「エリクサーチ」で特集コラムを予定 • 「エリクサーチ」でググってください • 本日の続きや詳細をコラム化しようと思います • エリクサーチには、Elixir入門と、入門後のガイドがあります 09 https://elixir-lang.info
62. ④Elixirコミュニティのイベントでも？ 09 • 「Elixirイベントカレンダー」でググってください • 様々なElixirコミュニティが開催するイベントが掲載 (月20本 以上) されており、今日の続きに相当する情報が拾えるかも？ https://elixir-jp-calendar.fly.dev
63. ⑤9/15 生成AI活用セミナー • 「生成AIセミナー 高知」でググってください • エンジニアの私だからこそ可能なChatGPTやBing等の活用術 • LivebookやElixirアプリで動かすことも見据えた活用術かも？ 09
64. That’s all for my talk Thank you very much