CDNエッジコンピューティング

CDN業界でエッジコンピューティングが騒がれています。ただし、CDNのエッジコンピューティングは、一般的な(広義の)エッジコンピューティングの(制限の強い）サブセットです。今回は、このあたりも含めた詳細をまとめます。

定義

広義のエッジコンピューティング

分散コンピューティングの粒度を細かくしたもの。
- クラウドのインスタンスを市町村やモバイル基地局単位で実行できる
メリット
- 低遅延
  - エッジで処理を行うため、遅延が少ない
  - 例：モバイル・エッジ・コンピューティング
    - モバイル基地局上の仮想インスタンスとして各種処理を実行する
      - 国内基地局数：ドコモ単体でも国内26万局以上
      - 各種処理の実行：永続的実行(インスタンスは常に起動されている)
      - 最初の実装：2014年ごろ(イスラエルSaguna networks?)
- 通信量の抑制
  - エッジで処理を行うため、通信量を減少できる
  - 例：エッジAI
    - 各種データ(映像等)の特徴識別をエッジ側で行うことにより、通信量を減少させる技術

CDNのエッジコンピューティング

ユーザからのリクエスト処理をCDNサーバ上で実行できるもの
- 動作例：リクエスト毎に処理インスタンスが一番近いCDNサーバ上で時間制限(XXマイクロ秒以下等)付きで起動される

CDNエッジコンピューティングの制限

機能面

インスタンス粒度と遅延(レイテンシ)
- CloudflareやFastlyの場合、国内3、4か所にしかサーバがない。そのため、北海道などでは20ms程度かかってしまう。本来のエッジコンピューティングの売りである遅延の低さ(例えば5ms以下)は実現できない
通信先
- 処理依頼(リクエスト)送信先の選択ロジックが地理的距離しかない(負荷の一番小さい所、ストレージ残量の大きな所、CPUの早いところ等の選択が出来ない）
- インスタンス間(P2P)通信が使いずらい(個別のインスタンスを明示的に指定した通信ができない）
永続性
- インスタンスの永続的実行ができない
- インスタンス毎の永続的なローカルストレージがない(実行処理の途中結果は、すべてセンターサーバに保存する必要がある。そうでない場合はデータが消える)。
計算量
- 軽量なプロセスしか実行できない

実現できないアプリケーション

IoT
- IoTデバイスのデータを吸い上げつつ、統計処理を行い、適切な指示をIoTデバイスに送信しながら、センターサーバに統計データをアップロードし続けるというような処理をエッジ上で実現できない。これにはインスタンスの永続性、ローカルストレージの永続性が必要となる。
エッジAI
分散協調処理(Web 3.0)
- インスタンスの協調動作ができない(インスタンス間通信ができない）。基本、CDNエッジコンピューティングで実装できる実行ロジックは、インスタンス上の単独ロジックか、センターサーバにおける集中ロジックしかない。協調ロジックも実装できるが、センターサーバ経由の非効率なものでしかない。

実装のジレンマ

本来の意味での(低遅延な)エッジコンピューティングを実現するには、最低でも県単位ぐらいでサーバを配置したい。しかし、CDN事業者として、ユーザにコンピューティング環境を提供するには、配信よりも強力かつ堅固なサーバを用意する必要がある。ここでジレンマが発生する：

CloudflareやFastlyのようなエニキャストベースの集中型CDN
- もともと少数(国内など数か所)の強固な配信拠点をベースにサービスを行っており、エッジコンピューティングを実装しやすい。
- ただし、AWSののようなクラウドサービスでも国内数か所の拠点を持っており、遅延でみると、クラウドもCDNエッジコンピューティングも差が無い。
- つまり、CDNエッジコンピューティングは、(国内のみでサービスしている場合)遅延的にはメリットが無く、実際にはCDNによるフロントエンドコンピューティングしか実現できない

Akamaiのような分散型CDN
- 国内でも50か所以上に配信拠点を持っており、この上でのコンピューティングを提供できれば、本来の意味での低遅延なエッジコンピューティングを提供できる。
- しかし、各拠点についてはサーバ数台等の小規模なものでありコンピューティングを提供できる余裕が無い。

国内における可能性

アプリケーション開発者視点

集中型CDN(CloudflareやFastly)が提供するエッジコンピューティングでは遅延に関するメリットは少なく、積極的に使う理由とはならなそうである。つまり、もともと国内遅延は小さいため、これが半分になっても効用は少ない。そして、集中型CDNの国内拠点は3～4か所しかなくAWSのようなクラウド(国内2拠点)と大差ない。また、低遅延を前提としたアプリケーション構築に関しては、最も遅い遅延をベースにする必要があり、集中型CDN(東京↔北海道：20ミリ秒程度)ではメリットが出ない。

一歩、実際に効果の出そうなのは、オリジンサーバのCPU負荷オフロードであると思われる。つまり、アーキテクチャとしてCPUエッジコンピューティングは、タスク粒度がクラウドより細かいため、CPUリソースを高能率に使い切れる可能性がある(ただしコンテクストスイッチングのコストも大きいため、十分なコスト検証が必要)。また、アクセス集中時におけるピーク性能についてもCDN側にオフロード可能であり、オリジンに要求されるピーク性能も低くなる。CDNエッジコンピューティングの単価が十分に安ければ、アプリケーション開発者にとって非常に有効なコストカットになると思われる。

ただし、特定のCDNに依存したサービス実装は、CDNがダウンするとサービスの全断となる。サービス断による損害額とオリジンコスト低減のトレードオフを見極める必要がある。直感的には億単位のビジネスが動いているアプリケーションであれば、特定CDNへの依存は避けるべきであり、と思われる。

ユースケース

行動ログ収集APIサーバのFastly Compute移行
- https://speakerdeck.com/htamakos/xing-dong-rogushou-ji-api-sabano-fastly-compute-yi-xing-gao-sukerabiritei-gao-xin-lai-xing-gao-mentenansuxing-womu-zhi-site
- 行動ログ収集のフロントエンド処理をAWSインスタンスからCDNエッジコンピューティングへ移行し、AWS EC2コストを大幅に削減
- ログ収集は、CDNエッジコンピューティングにフィットしたアプリケーション
  - 処理：軽量、リクエスト数：大、データの重要性：小～中
- また、この程度の処理であれば、CloudflareとFastlyのマルチCDNエッジコンピューティング化も難しくないと思われる。マルチCDN切り替えは、アクティブ・アクティブ運用で、リクエスト数が大幅に減少した場合、そのCDNを切り離すぐらいで良いと思われる。

インフラサービス提供者視点

CDNエッジコンピューティングレベルの粗粒度サービスであれば、国内事業者であっても、比較的容易に実装可能かもしれない(要詳細検討)。

また、基地局レベルの細粒度MEC(国内数十万拠点)については、パブリッククラウド型のサービスとしては運用が困難である。つまり、細粒度MECは、モバイルオペレータが自社でIoT管理を行うようなクローズドなサービスしか商用化は困難である。

一方、(地方CATVやローカルIXを活用した)市町村単位ぐらいの中粒度エッジコンピューティングについては、パブリッククラウド型のサービス展開も可能である。国内事業者が上手くサービス展開できれば、CloudflareやFastlyのような粗粒度(集中型)CDNに対して競争力のあるサービス展開が可能である。