この記事は@piacerexさんの[[翻訳] ①Web3＋DID＋エッジコンピューティング Brooklyn Zelenka and The Exciting World of Edge Computing](022/3/6に配信された解説動画、
パラダイムシフトはもう始まってる！半径0～5mのエッジコンピューティングの自分用の復習メモです。
動画は[11:25～] 惑星間ファイルシステムをElixirで作っちゃった人のお話の続きです。
@piacerexさん（右）はNeosVRから配信しています
左は私のアバターです。
事前に
- わかりやすさ、解説の面白さは動画にぎゅっとつまっているので、動画を見に行きましょう。
- パラダイムシフトはもう始まってる！半径0～5mのエッジコンピューティング
- この記事は動画中のすべてを言語化しているわけではなく、飛ばしているところもあるので、やっぱり動画を見ましょう。
翻訳文に対する解説
5:31〜 「物事をエッジに押しやる」
DI：では、エッジアプリにいきましょう。分散コンピューティングの話ですが、あなたは様々な方法で、物事をエッジに押しやっていると言っていました。あなたにとって、それはどのような意味を持つのでしょうか？
そもそも「物事をエッジに押しやる」ってどんな意味？
クラウドコンピューティングの場合はいろんな処理をエッジ（スマホ、IoT、ないしはPCなども含まれる）ではなく、クラウド上で構築している。AWSやGCP、Azureなどのクラウドコンピューティングは使っている方が多いと思います。
この場合はエッジ側、スマホやIoTデバイス、PCなどに処理をもっていくという意味。
また、クラウドとエッジデバイスの間のエッジサーバに処理をもっていき、クラウドに処理をリクエストするより高速に処理ができる。例えばカメラで撮影した画像を近くのエッジサーバでリアルタイムでマシンラーニング、データ処理したい場合、北米やヨーロッパより高速だったり、なんだったら東京やアジアリージョンより高速に処理できるようになる。
エッジデバイス自体にリッチな処理を載せることも。今のスマホはGPUも良い性能のものを搭載しているので、スマホ上でAI、マシンラーニングの処理をさせることもできるようになるかも。
こういうクラウドではなくエッジデバイス、エッジサーバに処理をまかせることを翻訳の文中で「エッジに押しやる」という表現をしている。
これこそが分散コンピューティング、エッジコンピューティングの中核になっている。
利用者の近くで処理を行うことでネットワーク負荷の減少にもつながる。
IoTデバイスも「物事をエッジに押しやる」ようになる
Fitbitといったようなアクティブトラッカーも運動情報や睡眠情報を集めているが、こういったデバイスもよりリッチな処理ができるようになり、必要なときだけクラウドにアクセスするようになる。
エッジコンピューティングはすでに実現している
例えばデータを集約して何らかの処理をするといったものはエッジには不向き。
近くのエッジデバイスが軽量な処理を行い、クラウドに渡すといったやり方も。
スマホのカメラアプリでフィルター加工や軽量化などの前処理をして必要に応じてクラウドにアクセスする、というのは実はエッジデバイス、エッジコンピューティングの考え方！
すでに実在している技術でもあり、エッジサーバ、エッジコンピューティングという概念、名前でも呼べる。
エッジコンピューティング
エッジコンピューティングとは、広義には、全ての主要なリソース、つまりストレージや計算などをユーザの近くに移動させ、より高速な体験を提供します。
なぜなら、光速に近いスピードで移動するメッセージの遅延を待つ必要がないからです。
前半は言葉の通りですね。後半の光の速度ってなんだ…？
「光に近い速度」？
Fussionは科学方向、理論物理学のワードが散りばめられていて、「光の速度」は理論物理学でよく出てくるワード。これはゼレンカさん風の示唆に富んた例えかも？
光の速度で通信するものといえば、光ファイバーが代表。光学を使った通信（赤外線など）、電波を使った通信に比べればコンピュータを使った通信は遅いよね、の意味かも。
（例えば、コンピュータの世界ではネットワークの速度は速くはない。それより高速なものだとCPUとメモリの間のデータ転送や、CPUの中のL2キャッシュ、L3キャッシュ、CPU内のパイプラインに乗っているときの処理などより遅い。）
21:41〜
すべてのサーバがアメリカの東海岸に置かれているとしたら、そこに行くのに数百msec、戻ってくるのに数百msecかかりますし、そのサーバがダウンするとインターネット全体が壊れてしまいます。
もし、もう少し分散して、ユーザの近くにあれば、数Km以内のブロックや、極端なことを言えば、私達が取り組んでいるようなデバイスに直接接続することで遅延をゼロにすることが可能です
「デバイスに直接接続することで遅延をゼロにすることが可能」…？！
極論になりますが、エッジデバイスにハードウェアそのものを物理的につないでしまえば通信しないので遅延ゼロになる…！物理で解決する手もある。
例えば上りで50ミリsec、下りで100ミリsecだと通信だけで150ミリsecかかる。
Webサーバ内部だとさほど大きくないDBであれば参照するのに30ミリ、20ミリsec、なんならナノsecで処理をしていることもある。
ただ、通信することで数百ミリsecのようなキャップがつくのが、いわゆるWeb2.0やクラウドの限界になるのでは。
ハードウェア性能がいくら上がっても通信でくってしまう。
25:32〜
次のコラムでもっとよりどういうふうな社会現象になるのか出てきます。
また、例えば5Gの文脈で、５Gの設備網の中にエッジコンピュータを置いて、それをモバイルエッジコンピューティングやMECと呼んだりする。
このキャリア網の中だったらとても高速なサーバやレスポンスの、まさにエッジコンピューティングを使える。
そういう設備を各キャリアが出しています。
2020年頃には実証実験が行われ、2021年頃にデモを公開したりしています。5G、AIマシンラーニングの文脈でデモをしたり、日本でもデモを見られる機会が増えている。
※例えば「docomo MEC」で調べるとドコモイノベーションクラウドがヒットします。
https://developer.dev-portal.d-oic.com/
エッジコンピューティングやDIDで構成されるWeb3で、よりネットが身近（というか侵食に近いかも？）な世界になる。
コンピュータをコンピュータとして意識せず、現実世界に溶け込んでしまったような現象や事象として、でも実は裏で動いている時代が我々が生きている間に起きるでしょう。
WebやECが生まれてかれこれ25年くらい経っていますが、既存の世界観ではない進化を実感してほしいし、これから開発していくことができるのがエンジニアの領域だということを知ってほしい、そのためにコラムを配信している、また翻訳に書かれている以外の内容も合わせて伝えることで補足をしたいそうです。
34:14〜
これはウェブアプリではあまり研究されていませんが、ネイティブアプリでは非常に高速に動作します。例えば、iOSやAndroidデバイスのアプリは、その多くがすでにこの方法で動作していますよね？ Webでは、つい最近までAPIが無かったため、実現が困難でした。クライアントデバイスまで到達する分散型DBを構築する技術は、かなり新しく、最先端を行くものです。ですので、それを推し進めることにしました
Webの世界とエッジコンピューティングはまだ隔絶されているが、アプリの世界ではもう浸透している。
Webの世界だと、代表的なものにReactやVue.js、Elixir PhoenixのLiveViewあたりはリッチな処理をフロントでするよう試みたり、エッジ側にビューをもっていく代表。
Keras.js（JavaScriptでマシンラーニングの処理を動かす）はエッジの処理をローカルで動かす代表例。
36:50〜
このモデルは、Phoenix LiveView（訳注：サーバサイドでリアルタイムフロントが書けるElixirフレームワーク）の正反対と大まかに考えることができるのではないでしょうか？ LiveViewでは、すべてのデータを送信し、DB内に信頼できる唯一の情報源があり、ある状態への更新を計算してから、差分データやHTMLをネットワーク経由で送り返します。全てがサーバで行われ、その中から少量のデータが戻ってくるのです。エッジコンピューティングでは、全てをローカルで行い、同期を維持するために必要な少量のみを他のユーザ送信します。つまり、信頼できる唯一の情報源はもうありません
ReactやVue.js、Elixir PhoenixのLiveViewなどを使ったとしても、エッジ側で多くのデータを扱っておらず、サーバ側で唯一の情報源であるデータをストアしている。エッジコンピューティングの観点からすると、せっかくリッチな処理ができるのに、データの唯一性を守るためにクラウドにいかねばならず、都合がよくない。
データの唯一性を守るためAPIをクラウドに対して呼ぶところがエッジコンピューティングではない世界になるためボトルネックになる。
エッジとエッジの間でやりとりをするとか、エッジサーバが点在する状態でぶらさがるデバイスがあり、その間だけで通信を行い、クラウドには唯一のデータとしてアクセスされない、エッジ間だけで同期をとるとよい。
既存のDBを中心とした設計や開発と考え方が変わる、パラダイムが変わる。
エッジコンピューティングの世界では既存のDBを中心とした設計がバッドパターンになる。
マルチリージョンでのDB、グローバルDBはクラウドをエッジコンピューティングと言い切ってしまえばエッジコンピューティングと言えなくもないが、それはそのクラウドの近隣のユーザーだけ。クラウド設備のない地域のユーザーにとってはそうではない。
45:34〜
コラボレーションアプリを使用している場合、またはデータをどこかにプッシュする必要がある場合は、全員が全状態を共有します。自分のマシン用にアップデートをするために必要なものだけが、完全にローカルで、オフラインで、接続が悪くてももはや問題ではありません。
あなたのマシン、つまりiPhoneでもラップトップでも何でもいいのですが、そのマシンにすべてが組み込まれているのですから。また、エッジ・インフラストラクチャ、つまりエッジ・データセンターやエッジ接続点（PoP：Point of Presence）のようなものを使っている場合、それは文字通り、あなたのすぐ近くのブロックにあるかもしれません
コラボレーションアプリはデータを分散するタイプのアプリだと思ってください。エッジで処理したデータをどこかにプッシュしたい。そうすると、プッシュしたマシンにもそうでないマシンにもマルチキャストしたりブロードキャストしたりして同じ状態を同期したい状況が発生する。全員が同じ状態を共有したい。
エッジ同士の通信でオフラインは難しいかもしれないが、通信はインターネットとは限らない。本当に近隣にいるエッジ同士であれば赤外線だったり電波による通信でもかまわない。構内のみの外には出ないネットワークでもよく、途絶したネットワークでもインターネットが回復したら通信できればいい。
56:52〜
このようにデバイスに落とし込むと、もう1つのメリットは、スタック全体を学習する必要がなくなることです。
これはマイクロサービスを進化させたようなもの。
バックエンドやDBのメンテナンス、DevOps、Kubernetesなどの学習が不要です。これらは全て、自分のマシン上にあり、直接、データを同期させることができるのです。
クラウド設備を使わなくなれば、DevOps、Kubernetesなどは関係ないですね。
なんならバックエンド、API、DBも知らなくてよい。ただ、エッジにおいての設計スキルは必要になるが、従来のミドルウェアは必要なくなるので、これらの学習は不要になるかもしれない。
これは明らかに現在の仕組みとは大きく異なるので、多くの人の頭を混乱させることになると思います。繰り返しますが、これはこの分野の最先端なのです
まさに今の私。
動画中のコメント
32:48〜 Michaelさんのコメント「のトレーディングにエクスチェンジのエッジでやりたい。」に対して
そうですね、トレーディングはすごく速度が要求されますね。まさに数ミリsec、数ナノsecの世界で価格がずれちゃったりするので、エッジコンピューティングで出来る世界観があるといいですね。
金融はトランザクションをきれいにさばくのにクラウドでやらない設備でやるのが難しく、プロトコルも制定しなければいけない困難があるものの、それができたら時間を気にする商売を時間を気にせずにできるようになる、そういう世界観ができるかもしれない。
55:07〜 Michaelさんのコメント「Change is the only thing that remains the same.」
この記事を書きつつ動画を振り返りながら、たしかにそのとおりだなと思いました。ウッ(´；ω；｀)
56:15〜 Aliceさんのコメント「そっかぁ、同じ設備、同じレイテンシとも限らないのか...」
北米などのリージョンと東京リージョンに性能差があるという話。
北米にいるユーザーが北米リージョンを使うのと、東京にいるユーザーが東京リージョンを使うとき、同じサービスレベルではないそうです。
感想
エッジコンピューティングの考え方、特にデータを中央ではなく分散して扱う、ということになかなか思考が追いつくのが大変でした。自分の関わるプロダクションで扱うことになったら？と考えるとドキドキしますね。
エッジコンピューティングは考え方を大きく変える必要があります。インターネットの時もクラウドの時も大変でしたよね…。バージョン管理やGitが出現したときも。
いきなり考え方を変えるというのは難しいので、今から少しずつ慣れていくと良いかも。