ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■クラウド＆インフラストラクチャ
2022.05.13 2024.03.06 約5分
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「エッジ・フォグコンピューティングとこれから」です（開催日：2020年 10月23日）。本記事は登壇者の菊地さんの基調講演からエッジコンピューティングの内部構成や実現するための技術、ネットワークインフラのこれからについて紹介します。Q&A ではまつもとりーさんを交えて視聴者からの質問に回答しているので、是非ご覧ください。
「エッジ・フォグコンピューティングの成り立ちと、ネットワークインフラのこれから」は2部構成です。1部はこちらです。
菊地 俊介
さくらインターネット株式会社
さくらインターネット研究所 上級研究員
松本 亮介
さくらインターネット株式会社
さくらインターネット研究所の上級研究員、京都大学博士(情報学)、複数社の技術顧問。インターネット技術に関するミドルウェアからOS辺りの研究開発やエンジニアリング、組織整備や組織文化醸成、EM、PdMも専門。2018年 Forkwell技術顧問就任。
エッジコンピューティングは、現場で遅延やリソース量の制限なく、コンピューティングが使える状況を目指しています。そのためにコンピューティングの場所、あるいはネットワークの使い方を変化させ、手前まで持って来ようとするのがエッジコンピューティングです。
それを実現するために、エッジとクラウドをシームレスに使えるようにコンピューティング環境を作る必要があります。
また、エッジとクラウドの特徴を活かすことも大事です。具体的にはクラウドをエッジに延伸していく。そしてクラウドの一部のようにエッジのサーバーを使う技術を作る必要があります。
さらにリソースの選択をスペックだけでなく、場所なども含めて自由に選べるようにする必要があります。そして選んだらつながるようにしなければいけません。ここまではクラウド技術の延長でやらなければいけないことです。
一方で、現場側のアクセスネットワークの工夫が必要です。
これがエッジコンピューティングを作るときに必須の項目です。
クラウド側のエコシステムを現場側に伸ばすことを、AWS や Azure がプロジェクト名をあげて、こういう風にやりますよ、システムがあります、作ってますと宣伝をしています。
Azure Stack HCI はクラウドと同じような使い勝手で、エッジ側に置いたサーバーが使えるようにするための技術であり、プロジェクトです。それがインフラとしてあるうえで、Service Mesh や KubeEdge などは、具体的なプログラムをエッジ側のサーバーにもデプロイできるようにする技術です。
Service Mesh は、クラウドのなかに別々にあるプログラムやシステムをつなぐものでしたが、場所がクラウドとエッジに分かれても使えるようになっているはずです。そういうものを使って、クラウドとエッジをシームレスにつないでいきます。
Nerves についても触れておきます。特に IoT の領域で、低コストでロケーションを意識せずとも、いろんな場所にプログラムを置いて、それを互いに連携させることを考えたときに、既存の Webサービスベースのシステムではない新しいアーキテクチャが必要になるかもしれません。
そういうのに向いている新しいシステムが Nerves です。これは、Erixir言語を使ったものですが、Pub/Subベースのメッセージングを使うので、インフラの上でこういうものを動かせばエッジコンピューティングの実現に近づくかもしれません。
問題はアクセス網側です。端末の移動をサポートするのは非常に難しいです。
それをやるためには 5G のがっつりした技術が必要ですし、ルーティングも、かなり工夫しないといけないので、IP Anycast という方法がありますが、これも今サーバーファーム側でクラウド側で使うものですが、これをエッジ側にも展開して、エッジ側、サーバー側にアクセスするのにユーザー側に意識させないことを実現するなど、いろんなことをやってく必要があります。
次に移動への対応方法を紹介します。
移動のスキームについてですが、サーバー側はエンドユーザーの近傍でサーバーのプログラム、ジョブ、タスクを持ってきて動かすことがマイグレーションだったり、エッジ側に、そのコンテナをデプロイする Service Mesh など、いろいろあります。
ところがエンド側のデバイスの移動は非常に難しいです。ポイントは以下2つです。
携帯電話は当たり前のようにできてますけど、LTE だったり 5G では、それを苦労して作ったわけです。昔は MobileIP もありましたが、結局使われることはありませんでした。端末のモビリティのサポートは、携帯電話側のシステムに依存しています。
もう一つ、移動は携帯網がやってくれるとしても、インターネットとの接続はどうでしょう。あなたの近傍にあるエッジサーバーはどれですか？そのアドレスは何ですか？そこのアドレスに向かったパケットを送るにはどうしたらいいんですか？こういった点が非常に難しくて 、IP Anycast でやるのか？ DNS でやるのか？などいろいろなことがありますが、スッキリした解決策はなく、今まさに検討している段階と認識しています。
移動のサポートはかなり難しいですが、さらにいうと、監視はどうやってやるの？という状況にあると思います。
難しい理由は、携帯電話がインターネットとつながっている接続点が1箇所しかないからです。なので、携帯電話網のなかにエッジサーバーがあればつなげられますが、外にあるサーバーにつなぐことはできません。
これが大きな問題になっていて、ここの網をどうやっていくんだということが、今まさに議論の対象になっています。
今後はアクセス網側の組み換え、地域での横のつながりや、地域ネットワークを再編していかないと、効率のいい低レイテンシでつながるという、エッジの特徴を出せません。
エッジを意識したクラウド技術の拡張もやる必要があります。エッジがある前提で不確実性を想定して、現状の Webサービス系のアーキテクチャではない、アーキテクチャを導入していく方向に変わるかもしれません。
どこにでもコンピューティングリソースがあり、自在に利用できるような時代になってほしいので、そこに向けてインターネットインフラの革新が進んでいくことに期待しています。
クラウド側につなぐとレイテンシなどの問題があるので、ユーザーの近傍にサーバーを置く解が求められて、エッジコンピューティングができました。
エッジサーバーを置く場所は、アクセス網の構造に依存するので、主要プレイヤーは、クラウド事業者、携帯事業者、IIC の3通りしかありません。現状では、そのなかでもクラウドベンダーの取り組みが進んでいます。使い道としては、Micro-DCタイプ、自動車タイプ、センサ収容タイプ、エッジAIタイプなどがあります。
エッジコンピューティングを作る観点でいくと、サーバー側でエッジサーバーをユーザーの近傍に置き、ゾーンを増やしていくだけでは足りません。アクセス網を超えて、通信していく仕組みを入れて、網構造の変革をおこなわないと、エッジコンピューティングは進んでいかないので、現状はそこに向けて進んでいます。
Q&A
菊池：大きく変わってほしいと思います。ただアクセス網のなかに、エッジサーバーを置くだけではダメです。例えばドコモの網のなかに置いたら、ドコモのユーザーしか使えないエッジコンピューティングができてしまいます。
東京に置いてあるのであれば、東京のユーザーはアクセス網に関わらず、エッジサーバーにアクセスできるようになってほしいわけです。
そのようにインフラ、特にネットワークの構造は変わってほしいですが、現実的には難しいかもしれません。各キャリアのエッジコンピューティングができて、そのユーザーしか使えない状況になる可能性はあります。
まつもとりー：5G がこれまでと違う点はどこですか？
菊池：携帯電話網のなかを作る仕組みが、 4G の LTE から 5G に変わろうとしています。例えば福岡からパケットを出しても、携帯電話網からのインターネット網は東京と大阪にしかないので、必ずパケットはどちらかを通ります。
しかし、5G では携帯電話網からフレッツ網や他の網に出ていくことが可能になるので、福岡のそばに置いてあるエッジサーバーにアクセスできるようになります。これが 5G の大きな違いです。
まつもとりー：4G では移動に適応したり、その移動に合わせてコンピューティングを移動しているものに寄せていくのが困難でしたが、それが 5G では実現可能になるのですね。
菊地：既存レベルではないですね。理想的には、最寄りのサーバーまで到達する時の応答遅延時間が一番短いところを選ぶ、あるいは物理距離を取得して、距離が短いところを選ぶのが理想的です。
しかし、そこまでは最初のうちにできないので、最初のうちはスタティックな、決め打ちの網構造を取るんだと思います。地域やエリアをあらかじめ決めておいて、このエリアのユーザー、ここに収容されてるユーザーは、このサーバーにたどり着くようにします、みたいなものをあらかじめ設計して作るんだと思います。
それでもインターネットを抜けてデータセンターを往復するよりはずっと早いですよというのをやってみて、そこから動的にコンフィグを切り替えて使うみたいな形に進化していくのではないかと思います。
まつもとりー：僕が参加している国際会議では最適化問題に置き換えて解くやり方が、ホットだと感じました。
まず、MEC型とクラウド延伸型は、くっついてやるのが前提でモバイルで処理する性能、あるいは、そこからもう少し距離の近いエッジのリソースで処理します。
さらに、そこでできないことをオフロードするために、クラウドのリソースを使うような階層構造があるなかで、通信時間や距離、エッジのコンピューティングに対して、アプリケーションをデプロイするときのエッジの許容量や、エッジのコンピューティングのなかで提供可能なリソースがどれぐらいあるのかを、価格やリソースの観点、あるいは事業者側や利用者側の求める性能の観点などを仮定します。
かつ、階層構造になっているなかの通信時間や距離、リソース、そこで求められるレイテンシ、レスポンスの性能をパラメーター化し、最適化問題に置き換えて解くという発表が多くありました。
菊地：それは、おそらく2ステップ目だと思います。1ステップ目は、選択肢がないと思います。エッジサーバーしかないところからスタートして、エッジサーバーではこの処理をして、それ以外の処理はクラウドでやりますよ、といった決めうちの設計を作るフェーズが最初にあると思います。
次にどのサーバーにするかの選択肢が複数あり、そこで出てくる組み合わせ最適化問題を動的に解きましょうという形に進化していくと思います。
菊地：比較的パワーのある node を少し置く、マイクロデータセンタータイプしかないのでは？と思います。理由はエッジサーバーを置くのに、お金がかかるからです。小さい node をエンドデバイスのそばにたくさん置ければいいのですが…。
例えば、信号機の上に小さい node があり、そこに Bluetooth で接続して、衝突回避するなど、自動運転で Uber Eats みたいな荷物を運んでくれる車が動いたらいいですね。
しかし、そのインフラを誰が打つのかと考えた時に、小さい node を置いていくのは、成り立たないと思います。ある程度の規模のものを置くところから始めるしかないと思います。
一方で、現場に置いてあるデバイスは Arm や RISC-V が増えます。それなのに、エッジ側からデータセンターが Intel ですといってもアーキテクチャが合いません。そこのコンバージョンにコストがかかります。もっと安いものがバラバラと撒かれている未来のほうが面白そうだなと思いつつ、「現実的には厳しそうだな」と思っています（笑）
菊地：答えは YES です。携帯電話網の 5G で、ようやく外に出る口が複数になると説明しました。しかし、そのときのアドレスは IPV6 です。 IPV6 が前提になってくると思うので、これからは IPV6 がくると思います。
まつもとりー：そういう風になっていくと研究者としてもやりやすいですし、IPアドレスがフラットになると、やりやすくなることがたくさんあると思います。
「エッジ・フォグコンピューティングの成り立ちと、ネットワークインフラのこれから」は2部構成です。1部はこちらです。
Forkwellは「成長し続けるエンジニアを支援する」をコンセプトに勉強会を開催しています。Infra Study Meetupは、インフラ技術の「これまで」と「これから」を網羅的に学ぶイベントです。インフラ技術の各分野に精通した講師を招いた講演や著名エンジニアによる発表を実施しています。
当記事に掲載されている全ての情報は、イベント実施日時点の情報であり、完全性、正確性、時間の経過、あるいは情報の使用に起因する結果について一切の責任を負わないものとします。
