0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kakerucc(kakeru Shintani)

CloudNative Daysで話したEdge-as-a-Service構想をAWSと既存サービスから考える

0
Posted at

はじめに

以前、CloudNative Days Summer 2025で、「エッジ活用の最適解とは？ 新しいエッジ処理アーキテクチャ『Edge-as-a-Service』構想について」 という内容で発表しました。

CloudNative Days Summer 2025 は 2025年5月23日開催の Hybrid イベント で、Cloud Native の広がりや実践知が共有される場でした。最近は Kubernetes だけでなく、生成AI・GPU・エッジ・ローカル5G といったテーマとの接続もかなり強くなってきたと感じます。

この記事では、その発展版として次を整理します。

  • Edge-as-a-Service とは何か
  • AWS で実装するならどうなるか
  • 既存の類似サービスと何が違うか
  • これからどこに向かうのか

なお、Edge-as-a-Service は AWS の公式製品名ではなく、筆者のアーキテクチャ構想です。

記事はこちら
エッジ活用の最適解とは？ 新しいエッジ処理アーキテクチャ「Edge-as-a-Service」構想について
https://speakerdeck.com/kakerucom/etuzihuo-yong-nozui-shi-jie-toha-xin-siietuzichu-li-akitekutiya-edge-as-a-service-gou-xiang-nituite

まずは公式データで見る「なぜ今か」

CNCF 公式サイトでは、現在のエコシステム規模として以下が示されています。

指標 値
Projects 224
Contributors 310K
Contributions 21M
Countries 193

加えて、CNCF Annual Report 2025 では、CNCF は 230超のプロジェクトと 30万人超のコントリビューターを抱えるとされています。

さらに、CNCF Annual Cloud Native Survey では、コンテナ利用者の 82% が Kubernetes を本番利用しているとされています。

つまり今は、

  • Kubernetes が「試すもの」から「本番の共通基盤」になった
  • AI ワークロードもクラウドネイティブ基盤に寄ってきた
  • 次はクラウドだけでなく、エッジも同じ作法で扱いたい

というフェーズだと思っています。

Edge-as-a-Service とは

ひとことで言うと、エッジ拠点の計算資源・GPU・アプリ・接続性を、クラウドのように必要なときだけ使えるようにする考え方です。

従来のエッジでは、現場にサーバを置いて終わりになりがちでした。しかし実運用では次の課題があります。

  • 拠点ごとに管理が必要
  • GPU を常時起動すると高コスト
  • アプリ更新が面倒
  • 拠点間通信が複雑
  • 使っていないリソースが無駄になる
  • クラウドとの役割分担が曖昧

そこで、エッジを「現場サーバ」ではなく、クラウドの延長として扱うのが Edge-as-a-Service の狙いです。

全体像

ポイントはシンプルです。

  • 軽い処理はエッジ
  • 重い処理はクラウド
  • 必要時だけ起動
  • 運用は一元化

1リクエストの流れ

実際の処理フローは、次のような「まずエッジ、足りなければクラウド」という流れになります。

この構成にすると、レイテンシ・コスト・データ保護のバランスを取りやすくなります。

技術スタック

レイヤ 主な技術 役割
実行基盤 Kubernetes / K3s エッジ・クラウドの共通基盤
サーバレス実行 Knative 必要時のみアプリ起動
拠点間接続 Skupper サービス単位で接続
GPU管理 NVIDIA GPU Operator GPU 利用の共通化
配信・管理 GitOps / Fleet / Argo CD 多拠点への継続配信

特に重要なのは Knative 的な「使うときだけ動く」設計です。
エッジはリソースが限られるため、常時起動よりもリクエスト駆動が効きます。

AWSで実装するなら

AWS の公式サービスをこの構想に当てはめると、主に次の対応になります。

AWSサービス 役割 この構想での位置づけ
Amazon EKS クラウド側 Kubernetes GPU 推論や集約処理の実行基盤
Amazon EKS Anywhere オンプレ / エッジ K8s 拠点内 K8s 基盤
AWS Wavelength 通信事業者設備上の AWS 超低遅延が必要な処理
AWS Local Zones ユーザ近接の AWS 低遅延なクラウド実行
AWS Outposts オンプレに AWS を延伸 データを外に出しにくい現場
AWS IoT Greengrass 小型エッジ実行 センサーや軽量推論向け

AWS 公式の見え方をざっくり整理すると

  • Wavelength: 通信事業者パートナーのデータセンター上で AWS を使い、低レイテンシ・データレジデンシー・耐障害性の要求に対応
  • Local Zones: ユーザやワークロードに近い場所で実行し、1桁ミリ秒レベルの低レイテンシを狙える
  • EKS Anywhere: 独自インフラ上に Kubernetes クラスタを作成して運用できる
  • Greengrass: クラウド処理やロジックをエッジデバイスにローカル導入できる

AWS構成案

パターン1: エッジにK3s、クラウドにEKS

一番わかりやすい構成です。

向いている用途:

  • 生成AI推論
  • RAG
  • 映像解析
  • 一時的にGPUを使いたいAPI

パターン2: 超低遅延なら Wavelength / Local Zones

向いている用途:

  • XR / VR
  • リアルタイム映像解析
  • ローカル5G
  • インタラクティブな低遅延処理

パターン3: データ主権が強いなら Outposts / EKS Anywhere

向いている用途:

  • 社内データを外に出せない
  • 工場 / 現場系システム
  • 閉域で動かしたいAI処理

類似サービスとの違い

すでに似た方向のサービスは存在します。

サービス 提供元 特徴
AWS Wavelength AWS 通信事業者網に近い超低遅延基盤
AWS Local Zones AWS 都市圏近接の低遅延基盤
AWS Outposts AWS オンプレに AWS を延伸
EKS Anywhere AWS 自前環境で EKS 流儀の K8s
IoT Greengrass AWS デバイス寄りの軽量エッジ
KubeEdge CNCF Kubernetes Native な Edge 基盤
Akri CNCF Edge デバイスを K8s リソース化

ただし、Edge-as-a-Service が違うのは、**単体製品ではなく「組み合わせ前提の設計思想」**という点です。

観点 既存サービス単体 Edge-as-a-Service
実行場所 特定基盤に依存 クラウド / オンプレ / MEC を横断
起動方式 常時起動が中心 必要時のみ起動
GPU利用 個別最適 共通化・オフロード
通信 ネットワーク中心 サービス中心
運用 サービスごとに分断 GitOpsで統合

どんなユースケースに合うか

1. 生成AI / RAG

社内文書は拠点に置きつつ、必要なら AWS 側 GPU に逃がす構成。

2. 映像解析

一次判定はエッジ、異常時だけクラウド。通信量とコストを抑えやすいです。

3. XR / ローカル5G

低遅延が重要なので Wavelength / Local Zones と相性が良いです。

4. 工場 / 現場システム

データ保護、断線耐性、継続稼働が重要な領域に向いています。

今後の未来

今後の論点は、単に「どこでアプリを動かすか」ではなく、次のようなテーマになっていくと思います。

  • AI 推論をどこで動かすか
  • GPU をどう共有するか
  • データをどこに置くか
  • 回線断でもどう継続するか
  • クラウド / エッジ / オンプレをどう一貫運用するか

CNCF の公式調査でも、Kubernetes はすでに本番の共通基盤になっています。
次は、その共通基盤をクラウドの外側まで伸ばすフェーズです。

つまり、

Cloud Native + Edge Native = 次の分散アプリケーション基盤

だと思っています。

まとめ

Edge-as-a-Service の本質は、エッジにサーバを置くことではありません。

本質は、

  • データの近くで処理し
  • 必要なときだけリソースを使い
  • 足りなければ AWS や別拠点へ逃がし
  • それをアプリやユーザに意識させない

ことです。

CloudNative Days で話した内容は、単なるアイデアではなく、CNCF と AWS の公式動向を踏まえると、かなり現実味のある方向性になってきたと感じています。

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?