この記事は、Elixir Advent Calendar 2024 シリーズ3 の14日目です
昨日は、@RyoWakabayashi さんで 「KinoStlViewer で Three.js による 3D コンテンツを表示する」 でした
piacere です、ご覧いただいてありがとございます 
前回 は、IBMのエッジコンピューティングレポートを土台に、エッジコンピューティングのメリットやアーキテクチャ、資源特性、クラウド／エッジデバイス／エッジサーバーによって発展する未来について紐解きました
その一方、現実問題として、クラウド無を前提とするエッジコンピューティング開発において、「クラウドが無いと開発できない」という現在の開発／プログラマ事情に対し、「Elixirであれば、短期間でエッジコンピューティングを攻略できる」というシンプルな着想を挙げました
今回は、Elixirによる実践的なエッジコンピューティングの構築例で、まずElixirエッジサーバーを構築するところからスタートします
本シリーズの全体像は、下記になります
There are 13 Elixir Advent Calendar, making for a hot winter!
Over the past 7 years, Elixir has consistently been a top-ranking language in the programming category of the Advent Calendar, claiming the #1 spot last year. This year, too, Elixir is sure to stay at the top.
We’re feeling the excitement again this year… Please support or subscribe!
https://qiita.com/advent-calendar/2024/elixir
https://qiita.com/advent-calendar/2024/ranking/feedbacks/categories/programming_languages
リアルタイム性：エッジコンピューティングに真っ先に求められるもの
IBMレポートにあるエッジコンピューティングの最も顕著なメリットの1つ目に、「リアルタイム性」が挙げられています
このリアルタイム性は、下記に挙げる点で損なわれやすいです
これらは、一般的なWeb開発やAI開発での「常識」や「当たり前」と捉えられているものが多い故に、その正反対を求めるエッジコンピューティングの推進／構築において、「認識上の壁」や「盲点」、「阻害要因」となりかねないものばかりです
-
① クラウドで処理すると損なわれる
- 通信にかかるオーバーヘッドで損なわれる
- アジア諸国やアフリカ等では通信速度が原因でリアルタイム性が劇的に劣化する
- クラウドの多くが北米や北欧に配置されているため
- ローカルリージョンの設備は北米や北欧と比べ、劣化しているケースが多い
- アジア諸国やアフリカ等では通信速度が原因でリアルタイム性が劇的に劣化する
- 通信の不安定さでMTBF／MTTRが悪化して損なわれる
- クラウドはインターネットを使うことで通信が不安定になりやすい
- クラウドは共有利用のベストエフォートのため、他システムの負荷でスローダウンしやすい
- 通信にかかるオーバーヘッドで損なわれる
-
② とは言え、クラウド相当が無ければ担保が大変
- 分散コンピューティング
- ECS／EKSやGKE、App Runner、Cloud Run、AKSのようなマルチクラスタサービス
- LambdaやCloud Functions、Azure FunctionsのようなFaaS
- 分散DB／ストレージ／キャッシュ／キュー
- AuroraやCloud Spanner、Cosmos DBのようなマルチリージョンDB
- S3やGCS、Filestore、Blob Storage、Azure Filesのような分散ストレージ
- ElastiCacheやMemorystore、Azure Cacheのような分散キャッシュ
- SQN／SNSやCloud Pub/Sub、Azure Service Bus、Event Gridのような分散キュー
- 分散コンピューティング
-
③ データ変換／加工のパイプライン／ストリーミングが最適化できないと損なわれる
- データ処理の並列化による高速化
- バックプレッシャーによる効率良いデータストリーミング
- パイプライン上のデータ操作最適化
-
④ エッジ側の処理負荷を柔軟に調整できないと損なわれる
- 負荷上昇時のエッジデバイスからエッジサーバーへのオフロード
- 負荷軽減時のエッジデバイスからエッジデバイスへのデオフロード
- エッジサーバーが抱え切れない大量データのクラウドへのオフロード
- 上記をコントロールするロードバランサー
-
⑤ 低遅延／高速プロトコルが気軽に採用できないと損なわれる
- WebSocket
- TCP／IPよりも高速な通信プロトコルの利用
- TCPよりもUDPを重視
-
⑥ 耐障害性が高くないとMTBF／MTTRが悪化して損なわれる
- 外形監視／再起動に頼らない内形監視／再起動
- プロセス異常時の復帰やリカバリー
- （上記した分散コンピューティングによる冗長性の実現）
-
⑦ 無停止アップデートが出来ないとMTBF／MTTRが悪化して損なわれる
- ホットリロード
- ブルーグリーンデプロイ
-
⑧ その他、性能向上策が取れないと損なわれる
- より高速かつ分散に向いた処理系でのコード書き換え
- リアルタイムOSの採用
- FPGAのような非ノイマン型コンピューティングへの載せ替え
クラウドを使わずにエッジコンピューティングを叶えるElixir
上記①のクラウド利用を避けつつ、上記②のクラウド相当の分散コンピューティングを提供し、上記③～⑦も叶えるという「いいとこどり」をElixirでは、ごく普通に行っています
と言うのも、ElixirのコアであるErlangVMは、クラウドが出現するよりも何十年前の1986年と言う時代に、クラウドと同等かソレ以上の分散コンピューティングを電話交換機向けに実現するため、下記イディオムを備えています
- EPMD：ノードを識別し、相互接続可能とするためのメカニズム
- 複数ノードを同一マシン上の操作のように透過的に扱える
- 名前付きプロセスでノードを意識しないプロセス連携が可能
- リモートノード上にもローカル同様、プロセスを生成可能
- ノードを跨いでプロセス同士を監視可能
- メッセージパッシング：各ノードに散らばるプロセス同士の協調
- 同期メッセージング
- 非同期メッセージング
- GenServer：メッセージを扱うプロセスの定式化／簡略化
- Mnesia：ノード間で共有／冗長化されたDB
- Supervisor：プロセス監視と再起動のメカニズム
これらの恩恵と、その標準バンドルにより、Elixirは、他言語と全く異なり、クラウドやコンテナを使うことも無く、分散コンピューティングをいとも容易く叶えます
以降のシリーズコラムにて、具体的なコードを示しつつ、これらイディオムを試していくとしましょう
終わりに
今回は、エッジコンピューティングのリアルタイム性担保のために、最も重要な「クラウド無しでの分散コンピューティング」をElixirで叶える方式について解説しました
この土台を中心に、上記①／②に求められるクラスタリングや冗長化されたマルチマスタ分散DBの実現や、上記⑥の耐障害性とコンピュートエンジンの冗長化など、エッジコンピューティングに求められる「リアルタイム性」をElixirは容易に叶えます
次回からは、具体的なコードにより、クラウドを使わないElixir分散コンピューティングの基礎を実践 していきます
p.s.このコラムが、面白かったり、役に立ったら…
にて、どうぞ応援よろしくお願いします
明日は、 @ytnobody さんで 「Ash Frameworkに入門しようとしたら準備がちょっと大変だったので、devcontainerを整備して簡単に始められるようにした」 です