エッジ活用の最適解とは？ 新しいエッジ処理アーキテクチャ「Edge-as-a-Service」構想について

エッジ活用の最適解とは？

本セッションでは、Skupper・Knative・Kubernetes・GPU Operatorを活用し、MEC拠点をクラウドネイティブに進化させる「Edge-as-a-Service」構想をご紹介します。使うときだけ動き、拠点を越えてつながる―そんなシンプルで強いインフラの実現に向けて、拠点間通信、GPUの分散活用、サーバレス処理など最新のエッジアーキテクチャを解説します。

🎯 こんな方におすすめ
・エッジコンピューティング技術に興味がある方

💡 セッションで得られること
・“動くときだけ動く”、超効率アーキテクチャについて
・GPUを複数拠点でシェアしながら低コスト・高性能を両立させる方法
・拠点をまたぐスケーラブル＆セキュアなエッジAI設計の秘訣

🔧 注目技術の役割
・Skupper：VPN不要で拠点間をセキュアに接続＆GPUを複数拠点で共有
・Knative：リクエスト時のみ自動起動＆ゼロスケール
・Kubernetes：MECを含むサービスを一元管理
・GPU Operator：GPUを自動管理、AI推論を即時実行可能に

Transcript

1. © NTT Communications Corporation All Rights Reserved. エヌ・ティ・ティ・コミュニケーションズ株式会社 エッジ活用の最適解とは？ 新しいエッジ処理アーキ テクチャ「Edge-as-a-Service」構想について 新谷 翔 上出 葵
2. © NTT Communications Corporation All Rights Reserved. 2 アジェンダ 1. クラウドコンピューティングの現状と課題 2. エッジコンピューティングとは 3. エッジコンピューティングの課題 4. エッジ活用の最適解? : Edge-as-a-Service構想とは？ 5. Edge-as-a-Serviceを支える中核技術群 6. 実用ユースケースのご紹介 ユースケース1：「Edge-as-a-Service」 Metaverse ユースケース2：「Edge-as-a-Service」 生成AI 7.Edge-as-a-Service構想が切り拓く未来
3. © NTT Communications Corporation All Rights Reserved. 3 クラウドコンピューティングの現状と課題 クラウドコンピューティングは、大量のデータ処理や柔軟なストレージ拡張を可能にする一方で、現 場での迅速な意思決定やセキュリティリスクへの対応が課題になっている。特に、高帯域幅を活用し たデータ送信が可能でも、通信遅延やデータ漏洩のリスクは依然として存在する。 パブリッククラウド/データセンタ リージョンA リージョンB 全てのデータをパブリッククラウド/ データセンタへ伝送 生成AI VR/XR DX 交通 高セキュリティ 現場での迅速な処理が求 められる！！ 低遅延・高速 もっと大量のデータ処理 を実施したい 高帯域 情報漏洩が心配だなぁ 通信網
4. © NTT Communications Corporation All Rights Reserved. 4 MEC MEC MEC MEC エッジでデータ処理 を行う クラウド集中型 (エッジコンピューティングなし） クラウド/データセンタ 全てのデータを クラウド/データセンタへ伝送 トラフィック 必要なデータのみ クラウドへ伝送 クラウド/データセンタ オンプレミスエッジ 網内エッジ (MEC) エッジコンピューティングあり エッジコンピューティングとは クラウド集中型の特徴 ネットワーク帯域の逼迫 クラウド/データセンタへの通信量をが増大 センター依存による情報漏洩リスク 全データをクラウドで処理するため漏洩リスク増 高遅延によるレスポンス低下 リアルタイム性が問題 1 2 3 エッジコンピューティングの特徴 ネットワーク負荷の軽減 クラウド/データセンタへの通信量を削減 情報漏洩リスクの低減 重要な情報を事前に処理 低遅延の実現 リアルタイム性を向上 1 2 3 クラウド集中型では通信量の増加、遅延、情報漏洩リスクが顕在化する。これに対し、エッジコン ピューティングはデータを端末近くで処理することで、通信負荷を削減しリアルタイム性とセキュリ ティを確保できる。中でもMEC（Multi-access Edge Computing）とオンプレミスエッジをネット ワーク内に配置することで高効率な分散処理を実現する。
5. © NTT Communications Corporation All Rights Reserved. 5 パブリッククラウド/データセンタ リージョンA MEC リージョンB MEC クラウド経由じゃ遅すぎる、現場 （エッジ側)で即時に処理したい 高負荷時はGPUリソースを一時 的に増強し、処理性能を最大化 したい 負荷に応じてスペック を柔軟に引き上げたい リソース不足 高速処理 処理の増大 管理が複雑になって めんどくさいなぁ オンプレミス エッジ 複数拠点にまたがる環境では、MECやオンプレミス装置の管理が煩雑化しやすく、運用負荷が 高まる。また、ユーザごとに処理ニーズが異なる中で、リソースの柔軟な割当や自動スケーリ ングが難しく、負荷増加時の処理性能確保が困難となる。 エッジコンピューティングの課題 +αの新しい何か？ 業務時間外はアプリを自動 停止し、無駄なGPUリソー ス消費をゼロにしたい サービスの柔軟性
6. © NTT Communications Corporation All Rights Reserved. 6 Edge-as-a-Service構想とは、前述したエッジコンピューティングの課題を解決するために弊 社が着想した技術構想。Edge-as-α-Service構想を実現することにより、使うときだけ動き、拠 点を越えてつながる―そんなシンプルで強いインフラの実現が可能となる。 エッジ活用の最適解？： Edge-as-a-Service構想とは +αの新しい何か？=Edge-as-a-Service? クラウド/データセンタ リージョンA MEC リージョンB MEC MEC、オンプレミスエッジを 一元管理 重い処理を一時的でクラウド/ サーバ上にオフロード サービスを必要な時だけ起動 GPUを一時的に利 用可能 拠点を超えた意識しない シームレスな接続 交通 VR/XR 生成AI DX Controller Controller 通信網 例：AWS オンプレミスエッジ クラウド/データセンタ 網内エッジ 例：オンプレミスエッジ 例：MEC MEC
7. © NTT Communications Corporation All Rights Reserved. 7 Edge-as-a-Serviceを支える中核技術群
8. © NTT Communications Corporation All Rights Reserved. 8 Edge-as-α-Serviceを実現するために、kubernetes / K3s を軸に、GPU Operator、 Knative、Skupper などのクラウドネイティブソリューションを融合。さらにRancher を用 いることにより、あらゆる拠点でのクラスタやアプリケーションの統一管理を実現。 Edeg-as-a-Service構想の「システム構成」 Controller オンプレミスエッジ クラウド/データセンタ 網内エッジ 例：オンプレミスエッジ 例：MEC MEC 例：AWS Kubernetes/k3s GPU Opereator knative skupper Rancher クラウド/データセンタ リージョンA MEC リージョンB MEC MEC、オンプレミスエッジを 一元管理 重い処理を一時的でクラウド/ サーバ上にオフロード サービスを必要な時だけ起動 GPUを一時的に 利用可能 拠点を超えた意識しない シームレスな接続 交通 VR/XR 生成AI DX Controller 通信網 採用ソフトウェア
9. © NTT Communications Corporation All Rights Reserved. 9 Kubernetes/k3s Edge-as-a-Service Edge-as-α-Serviceでは、網内エッジ(MEC)にはKubernetes、オンプレミスエッジデバイスには K3sという棲み分けを前提に設計。 Kubernetesのフル機能性と安定性を活かしながら、K3sの軽量性と展開性であらゆる場所に展開可 能なハイブリッド構成を採用。 クラウド クラスタ(Kubernetes) 網内エッジ(MEC) クラスタ(Kubernetes) Master/Woker 兼用 Master/Woker 兼用 Master/Woker 兼用 網内エッジ(MEC) クラスタ(Kubernetes) Master/Woker 兼用 Master/Woker 兼用 Master/Woker 兼用 オンプレミスエッジ クラスタ(K3s) Master/Woker 兼用 網内エッジ(MEC)には kubernetesを配置 オンプレミスエッジには k3sを配置 オンプレミスエッジ クラスタ(K3s) Master/Woker 兼用 オンプレミスエッジ クラスタ(K3s) Master/Woker 兼用
10. © NTT Communications Corporation All Rights Reserved. 10 Knative Edge-as-a-Service 簡単デプロイ RegionA 負荷分散 RegionB 使用しない時は0 使用する時は、 最適なリソース の調整 簡単接続 apiVer sion: ap ps/v1 kin d: Deployment metad ata: na me: hellow orld-go spec: replicas: 3 selector: matchLa bels: app : hellowo rld-go template: metad ata: la bels: app : hellowo rld-go spec: containers: - na me: hellow orld-go im age: gcr.io/knative- samples/hellowor ld-go por ts: - containerPo rt: 80 80 apiVer sion: v1 kin d: Ser vice metad ata: na me: hellow orld-go spec: selector: app : hellow orld-go por ts: - pro toco l: TCP por t: 80 targ etPort: 8 080 type: ClusterIP apiVer sion: au toscaling /v2 kin d: Horizo ntalP odAutosca ler metad ata: na me: hellow orld-go-hp a spec: sca leTar getRef: apiVer sion: ap ps/v1 kin d: Deployment na me: hellow orld-go mi nReplicas: 1 maxReplicas: 1 0 metri cs: - type: Resource resour ce: na me: cpu targ et: type: Utilizatio n avera geUtilization: 50 Deployment の YAML Serviceの YAML HPAの YAML apiVer sion: servin g.knative.dev/v1 kin d: Ser vice metad ata: na me: hel low orld-go spec: template: spec: containers: - im age: gcr.io/kna tive-samples/hellow orld- go au toscaling.kn ative.dev/minScale: "0" au toscaling.kn ative.dev/maxS ca le: "10" Knativeは、複雑な設定なしでアプリを簡単デプロイ・簡単接続でき、トラフィックに応じて自動で スケール調整。未使用時はPodをゼロ化しリソースを節約、使用時は最適に配分。
11. © NTT Communications Corporation All Rights Reserved. 11 Knative Edge-as-a-Service 簡単デプロイ RegionA 負荷分散 RegionB 使用しない時は0 使用する時は最 適なリソースの 調整 簡単接続 Control & Operation Kubernetes API Knative User Interface User time Resources Knative あり time Resources リソース使用量 Kantive なし リソース要求 リソース不足 リソース過多 要求に応 じた柔軟 なリソー スの提供 が可能 1. 簡単にkubernetesを利用 2. 需要に応じた柔軟なリソースの提供 apiVer sion: ap ps/v1 kin d: Deployment metad ata: na me: hellow orld-go spec: replicas: 3 selector: matchLa bels: app : hellowo rld-go template: metad ata: la bels: app : hellowo rld-go spec: containers: - na me: hellow orld-go im age: gcr.io/knative- samples/hellowor ld-go por ts: - containerPo rt: 80 80 apiVer sion: v1 kin d: Ser vice metad ata: na me: hel low orld-go spec: selector: app : hellow orld-go por ts: - pro toco l: TCP por t: 80 targ etPort: 8 080 type: ClusterIP apiVer sion: au toscaling /v2 kin d: Horizo ntalP odAutosca ler metad ata: na me: hellow orld-go-hp a spec: sca leTar getRef: apiVer si on: ap ps/v1 kin d: Deployment na me: hellow orld-go minReplicas: 1 maxReplicas: 1 0 metrics: - type: Resource resour ce: na me: cpu targ et: type: Utilizatio n avera geUtilization: 50 Deployment の YAML Serviceの YAML HPAの YAML apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go spec: template: spec: containers: - image: gcr.io/knative- samples/helloworld-go autoscaling.knative.dev/minScale: "0" autoscaling.knative.dev/maxScale: "10" 特徴をさらにわかりやすく まとめると
12. © NTT Communications Corporation All Rights Reserved. 12 Skupperは、異なるKubernetesクラスタ間をまるで1つのネットワークのようにつなげる通信基盤。VPN 不要でサービス同士を直接接続でき、拠点が違ってもアプリ同士がローカルのように通信可能。Edge-as- a-Serviceではこの柔軟性とシンプルさが決め手となり、Skupperを採用。 Skupper Edge-as-a-Service 概念図 VPNやファイアウォールなしで、複数のKubernetesを 跨いだアプリケーション間でセキュアな通信の提供。 クラスタA Kubernetes L7トンネル Source app Skupper router クラスタB Kubernetes Destination app Skupper router ユースケース例 クラスタA上の GPUリソースが IoT端末で容易に 利用できる L7トンネル クラスタA Kubernetes Source app IoT端末 Destination app 1.デバイス上から拠点AにGPUリソースをオフロード 2.拠点間でのワークロードの連携(負荷分散、DB同期） クラスタA Kubernetes クラスタB Kubernetes アプリ クラスタAとクラスタBを 跨いだ負荷分散を実現 ユーザ アクセス 50% 50% L7トンネル Master DB 仮想 DB slave DB クラスタ間でのリア ルタイムなDBの同期 拠点Aにマイグレ 拠点Aにマイグレ 同期 Destination app Source app ユーザ ①SourceappをL7トンネル経由で Destinationappとして拠点Bへ公開 ②クラスタBの ユーザが Destinationapに アクセス ③skupper routerはアクセスを受信する とL7トンネル内で対象サービスがあるク ラスタへルーティング処理を行う
13. © NTT Communications Corporation All Rights Reserved. 13 大阪 Kubernetes Source app router 東京に出かけたいなぁ よし！今すぐ支度してLet’s go! User 具体例:
14. © NTT Communications Corporation All Rights Reserved. 14 大阪 Kubernetes Source app router 東京 Kubernetes Skupper router router 東京に来たのはいいんだけど、大阪 のアプリケーション使えないなぁ泣 User 具体例:
15. © NTT Communications Corporation All Rights Reserved. 15 Skupperで簡単にサービスを公開！ ※An open source software developed by Red Hat 東京 Kubernetes Skupper router router 大阪 Kubernetes Source app router Inter-cluster (inter-site) communication Destination app Layer 7 Tunnel サービス公開 おお！大阪でやっていたアプリケー ションが東京でもできるぞ！？ 最高！ 具体例:
16. © NTT Communications Corporation All Rights Reserved. 16 GPU Operator Edge-as-a-Service GPU Operator の導入により、GPUリソースを動的に割当・解放・マイグレーション可能な柔軟な基盤 を実現。GPUを複数の仮想GPU※として分割し、複数アプリが効率よくGPUをシェアできる環境を構 築。 Edge-as-a-Serviceではこの仕組みにより、拠点やハードウェアの制約を意識せず、必要なときにGPU を活用できる。 https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html#supported-gpus クラスタA テナントA ユーザA GPUの分割: GPU１枚を２ユーザに0.5枚 として分割が可能。 テナントB ユーザB ※GPUの種類によってはMIG対応、非対応がある パターン1:１枚のGPUを分割 パターン2:複数GPUの分割 クラスタA テナントA ユーザA GPUの分割: GPU2枚を２ユーザに1枚とし て分割が可能。 テナントB ユーザB
17. © NTT Communications Corporation All Rights Reserved. 17 IoT GW Rancher Edge-as-a-Service Rancherは、複数クラスタを一元的に管理できるKubernetesマネジメントの中核ツール。Edge-as-a-Service では、地域ごとに分散したクラスタを“ひとつのインフラ”として運用するために、Rancherを採用。 GUIベースでの操作・統合監視・アクセス制御などにより、大規模エッジ環境をシンプルかつセキュアに統括。 Rancher（Edge Controller） ・Appの配信 ・CI/CDの実装 ・リソース監視 ・コンテナ環境への遠隔ログイン ドローン オンプレミス エッジ IPC/PLC AG V オンプレエッジ経由でEdge Controllerと疎通が可能 WAN NW (LTE,Wi-Fi) LAN NW (Local 5G,Private LTE) k3s,k8s ホストOS App HW オンプレミスエッジ の構成 検証実績低HWスペック (例 Raspberry Pi) CPU：4core memory：4GB Disk：64GB MEC AIカメラ
18. © NTT Communications Corporation All Rights Reserved. 18 いいとこ取りのアーキテクチャを実現するために、kubernetes / K3s を軸に、 GPU Operator、Knative、Skupper などのエッジネイティブ技術を融合。 クラスタ管理には Rancher を用い、あらゆる拠点での即応性・柔軟性を実現。 Edeg-as-a-Service構想の「システム構成」(再掲) Controller オンプレミスエッジ クラウド/データセンタ 網内エッジ 例：オンプレミスエッジ 例：MEC MEC 例：AWS Kubernetes/k3s GPU Opereator knative skupper Rancher クラウド/サーバ リージョンA MEC リージョンB MEC MEC、オンプレミスエッジを 一元管理 重い処理を一時的でクラウド/ サーバ上にオフロード サービスを必要な時だけ起 動 GPUを一時的に利 用可能 拠点を超えた意識しない シームレスな接続 交通 VR/XR 生成AI DX Controller 通信網 採用ソフトウェア
19. © NTT Communications Corporation All Rights Reserved. 19 ユースケース1: 「Edge-as-a-Service」 Metaverse
20. © NTT Communications Corporation All Rights Reserved. 20 従来のクラウドベースメタバースの課題 現行のメタバース構成では、 1. アプリケーションがクラウドに配置しており、レンダリングの品質がNW性能に依存してしまう 2. アプリケーションが常時起動のため適切なリソース割り当てができずコストが割高になる クラウド 配信用サーバ WebRTC Rendering エンジン 東京リージョン 沖縄リージョン
21. © NTT Communications Corporation All Rights Reserved. 21 「Edge-as-a-Service」 Metaverse 外部GPU基盤 EaaS基盤 MEC EaaS基盤 東京リージョン AMQPトンネル 配信用サーバ WebRTC Renderingエンジン Renderingエンジン MEC EaaS基盤 ポイント② EaaSの拠点間通信技術を利用すること で、拠点に跨いだワークロード分散を実現 ポイント① EaaSのサーバレス技術を利用する ことにより、必要に応じたworkloadを瞬時起動 沖縄リージョン 5G通信網 移動→ 移動→ クラウド EaaS基盤 配信用サーバ WebRTC 3D空間 ✓ メタバースのレンダリング機能をエッジにオフロードすることにより、高品質なメタバースソリューショ ンを実現。 ✓ 利用者の位置や利用状況に応じた最適なエッジリソースの配置を実現。
22. © NTT Communications Corporation All Rights Reserved. 22 ポイント1について
23. © NTT Communications Corporation All Rights Reserved. 23 5G通信網 ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤 配信用サーバ WebRTC Rendering エンジン 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ ワークロード ユーザ ユーザの増加に応じてレンダリングエ ンジンのスケールアウトが行われる ユーザがアクセスしてい ないので0スケールされ ている
24. © NTT Communications Corporation All Rights Reserved. 24 5G通信網 ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤 配信用サーバ WebRTC Rendering エンジン 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ ユーザ ユーザ ワークロード が逼迫 拠点のユーザ増加により、MEC内の ワークロードが増加 ユーザの増加に応じてレンダリングエ ンジンのスケールアウトが行われる
25. © NTT Communications Corporation All Rights Reserved. 25 5G通信網 ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤 配信用サーバ WebRTC Rendering エンジン 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ ワークロード が逼迫 ワークロード の削減 AMQPトンネル Rendering エンジン 必要に応じて一時的に外部GPU 基盤にワークロードの分散を行 うことで、MEC内のワークロー ドの削減 ユーザ ユーザ MEC内のレンダリングエ ンジンは一時的に停止
26. © NTT Communications Corporation All Rights Reserved. 26 5G通信網 ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ ワークロード が逼迫 ワークロード の削減 Rendering エンジン アクセス減少によりワークロー ドが減少すれば、MEC内の処理 に切り替え 配信用サーバ WebRTC Rendering エンジン
27. © NTT Communications Corporation All Rights Reserved. 27 ポイント2について
28. © NTT Communications Corporation All Rights Reserved. 28 5G通信網 ポイント2の詳細 MEC 東京リージョン MEC vGW vGW EaaS基盤 配信用サーバ WebRTC Rendering エンジン 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ ユーザが東京から沖縄へ移動。
29. © NTT Communications Corporation All Rights Reserved. 29 5G通信網 ポイント2の詳細 MEC 東京リージョン MEC vGW vGW EaaS基盤 配信用サーバ WebRTC Rendering エンジン 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ
30. © NTT Communications Corporation All Rights Reserved. 30 5G通信網 ポイント2の詳細 MEC 東京リージョン MEC vGW vGW EaaS基盤 配信用サーバ WebRTC Rendering エンジン 外部GPU基盤 EaaS基盤 EaaS基盤 沖縄リージョン Rendering エンジン ユーザ 配信用サーバを沖縄リージョンに展開 することで、拠点を跨いだメタバース ソリューションの利用が実現 AMQPトンネル 配信用サーバ WebRTC ユーザは意識することなく、 東京リージョンのメタバー スが利用可能
31. © NTT Communications Corporation All Rights Reserved. 31 ユースケース2：「Edge-as-a-Service」 生成AI
32. © NTT Communications Corporation All Rights Reserved. 32 ユースケース2: 「Edge-as-a-Service」 生成AI 背景 ➢ 生成AIはクラウド上に実装されているケースが多い ➢ クラウド上で生成AIを実装する問題点-その1 • RAGを実装するための社内データやModelデータをクラウドへアップロードする際のセキュリティリスク ※RAGとは：外部データベースから関連情報を取得し、質問やプロンプトに対する回答を生成する仕組み ⇨生成AIを実装する環境としてセキュアな環境が求められている ➢ クラウド上で生成AIを実装する問題点-その2 • マルチモーダルを実装するために必要な画像、映像、音声などのデータをクラウドへアップロードすることによる 通信帯域の逼迫及び通信コストの増大 ⇨オンプレ環境で生成AIを実装することで、上記問題を解決することができる。 リンク：https://www.tjsys.co.jp/focuson/edge-ai-approach/index_j.htm クラウド RAGを実装するために必要なModelデータや 社内データをクラウドへアップロードする マルチモーダルを実装するのに必要なデータ （画像、映像、音声） 第三者による社内データのハッキング ユーザ ユーザ 第三者 容量が大きいデータを 扱うことで帯域の逼迫や 通信コストの増大を引き起こす 生成AI実装環境
33. © NTT Communications Corporation All Rights Reserved. 33 ◆RAG（検索拡張生成）の実装 ※RAGとは：外部データベースから関連情報を取得し、質問やプロンプトに対する回答を生成する仕組み 1_ 汎用的な用語ではなく、会社独自の用語に対し、マニュアル情報などを指定し、ベクトルデータベースへ保存。 2_ 生成AI上で上記に関する問い合わせを実施すると、内部でベクトルデータベースへ問い合わせ、 その出力結果を解答として表示する。 ベクトルDB ユーザ ③ 会社独自の用語に関する質問を実施 ① 会社独自の用語に関する 社内情報を保存 ④ 会社独自の用語に関する問い合わせが 来た際はベクトルDBへ問い合わせ ⑤ 問い合わせに関する情報を ベクトルDBから収集。 その結果をユーザへ応答 社内データがローカルに閉じて 処理できる ドキュメント 生成AI ②ドキュメント情報をベクトル化し、DBへ保存 ※ベクトルDBはテキスト検索や質疑応答に利用される （参考資料）RAGについて
34. © NTT Communications Corporation All Rights Reserved. 34 Edgeデバイス 生成AI_v1 OS ユーザ 生成AI_v2 CI機能 アプリを更新する際、生成AIの ソースコードを変更する 必要が発生し、その度手動で アプリの動作確認テストを実施 する必要がある CD機能 更新したアプリを手動で 配信する必要がある ➢ オンプレ上で生成AIを実装する問題点 • 生成AIを支えるマネージドなオンプレ環境がない状況 • オンプレ環境では、生成AIとModelデータを自動更新する環境が整っていない • サーバの調達や保守などを含むインフラ運用をお客様自身で対応する必要がある ⇨ 生成AIに対し、CI/CDのようなライフサイクルマネジメント環境を実装する必要がある ⇨ 社内データを含むModelデータはローカルで格納できる環境を提供する必要がある 運用管理が大変 クラウド 社内情報を含むModelデータはローカルで処理すべき Modelデータ _latest Modelデータ _latest ストレージサーバ 生成AI _latest ユースケース2: 「Edge-as-a-Service」 生成AI 背景
35. © NTT Communications Corporation All Rights Reserved. 35 リンク：https://www.tjsys.co.jp/focuson/edge-ai-approach/index_j.htm 比較項目 生成AI on Edge as a Service 生成AI on 既存On-Premise Server （仮想化基盤も含む） 生成AI on Cloud Modelデータにおけるセキュリティリスク ◦ ローカル処理のためリスクが低い ◦ ローカル処理のためリスクが低い × アップロードが必要なためリスク大 ModelデータにおけるWAN環境の帯域 ◦ WANトラフィックなし ◦ WANトラフィックなし × トラフィックが多くなる Modelデータの配置場所 ◦ ローカル/クラウドの選択可 ◦ ローカルのみ × クラウドのみ インフラ運用 ◦ App+HW一体型で管理不要 × お客様による管理が必要 ◦ 管理不要 AppのCI/CDの実装 ◦ 実装可能 × 環境構築が必要 ◦ 実装可能 リソース容量 △ クラウド比で劣る △ クラウド比で劣る ◦ 優れている Modelデータ LLM HW k3s Ubutnu NFS Container Registry 生成AI Rancher（Edge Controller） ユースケース2: 「Edge-as-a-Service」 生成AI ➢ オンプレ上で生成AIを実装 • LLMに対し、CI/CDのようなライフサイクルマネジメント環境を実装 • 社内データを含むModelデータはローカルで格納できる環境を提供 • App+HWの一体型提供によりお客様によるインフラ運用管理が不要
36. © NTT Communications Corporation All Rights Reserved. 36 生成AIソリューションの構成 ➢ 構成内容 ・NFS上にModelデータ:v1を配置 ・Repositrory上にHelm ChartとModelデータのパス情報を含むfleet.yamlを配置 ・Container Registry上にImage tag:0.0.1を配置 ・Edge ControllerのCD機能を用いて、HelmChartの情報を元に、Image tag:0.0.1をEdge Deviceへデプロイ ・Edge ControllerのCD機能を用いて、fleet.yamlの情報を元に、Modelデータ:v1を生成AIのpodへ実装 Rancher Edge Controller / Fleet Edge Device Container Registry Repository NFS Server Helm Chart fleet. yaml K3s Cluster 生成AI Pod Pod Pod Pod deploy CDの設定を登録する Image tag:0.0.1 Model データ ：v1 イメージの情報（イメージ名、タグ）は、 fleet.yamlにHelmチャートのパラメータ として記載しておく。 ① ② CDの設定に従い、 Repositoryから情報 を取得する。 ③ ④ Helmチャートで生成されたマニフェスト に従い、Image tag:0.0.1が取得されデ プロイされる。 ➄ Helmチャートのパラメータとして、 マウントするNFSサーバの情報を記載 する。 ⑥ パラメータに従い、Modelデータv1 がマウントされ利用される。 GitRepo
37. © NTT Communications Corporation All Rights Reserved. 37 1_ Container Registry上にImage tag:0.0.2を配置 2_ Edge ControllerのCD機能により、イメージの更新を検知し、Edge Device上に実装されている生成AIの バージョンを0.0.1⇨0.0.2へ更新 Repository A fleet. yaml Rancher Edge Device Container Registry NFS Server Helm Chart fleet. yaml K3s Cluster 生成AI Pod Pod Pod Pod deploy Model データ ：v1 Fleetにより、新しいイメージ（tag: 0.0.2） の情報でファイルが更新される。 ※更新対象のファイル/更新箇所は指定可能。 ① ② ③ ➄ 更新されたマニフェストに従い、 Image tag:0.0.2が取得されデプロイされ る。 ④ Repository Aの 更新を検知する。 Image tag:0.0.2 update 新しいイメージを登録する。 Edge Controller / Fleet Image Scan機能が新しい イメージの登録を検知する。 Image tag:0.0.1 Edge as a Serviceを用いたAppに対するCDの実装イメージ
38. © NTT Communications Corporation All Rights Reserved. 38 1_ fleet.yamlファイル内のパス情報をModelデータ:v1⇨Modelデータ:v1_02へ変更 2_ Edge ControllerのCD機能により、fleet.yamlの更新を検知し、デプロイされた生成AI PodはModel データ:v1_02をマウントする Repository A fleet. yaml Rancher Edge Device Container Registry NFS Server Helm Chart fleet. yaml K3s Cluster 生成AI Pod Pod Pod Pod deploy Model データ ：v1 ② ④ 更新されたマニフェストに従い、 デプロイされる。 ③ Repository Aの 更新を検知す る。 update Edge Controller / Fleet Model データ ：v1_02 ① 新しいModelデータ を配置する 利用するModelデータの情報（NFS サーバの情報）を手動更新する。 ➄ 新しいパラメータ値に従い、 Modelデータ:v1_02がマウント され利用される。 社内データを含むModelデータが エッジ環境で処理できる Edge as a Serviceを用いたモデルデータの更新イメージ Image tag:0.0.2
39. © NTT Communications Corporation All Rights Reserved. 39 オンプレとMECのハイブリッド運用 MEC VM Cluster(K3s) ns-skupper Edge端末 ns-AI skupper- router skupper- controller Pod C Pod D Cluster(K3s) ns-AI skupper- router skupper- controller Pod A Service D Service C GPU Pod B Service B expose Service D Service C Service B Service worker Service controller Service api NFS model Edge端末 Cluster(K3s) ns-AI Pod A NFS model Pod C Pod C Pod B MEC活用なし MECを活用し 一部コンポーネント をマイグレ • リソースに制約のあるオンプレ上では、Appの実装に限界があるため、skupperを活用し、オンプレ上で動作しているコンポーネントを MEC基盤へマイグレーションする • 必要に応じて、必要なMECリソースをユーザへ開放し、従量課金を実現する • マイグレをユーザに対し完全に隠蔽し、複雑な設定が不要になる ⇨Edge as a Servcieを活用し、Edgeリソースの最適化を実現 MEC VM Cluster(K3s) GPU
40. © NTT Communications Corporation All Rights Reserved. 40 Edge-as-α-Service構想で何が嬉しいの？
41. © NTT Communications Corporation All Rights Reserved. 41 エッジの最適解だから、あらゆるユーザの嬉しいを実現！？ 使うときだけ動き、拠点を越えてつながる―そんなシンプルで強いインフラの実現に向けて、拠点間通信、GPUの 分散活用、サーバレス処理、エッジデバイスなど最新のエッジアーキテクチャを掛け合わせることで簡単に実現 管理者/運用者:GPUを含むリソースを“必要なときだけ”自動最適配置。 → 稼働時間＝コストの完全従量モデルへ。 → DX施策のROIを数値で可視化し、効果が高い投資に資源を集中。 ユーザ:あらゆるアプリを “簡単に・安く・早く” 利用可能に。 → オンデマンドでMECに接続、ローカルで完結する低遅延処理 → クラウドや本社システムに依存せず、真のエッジ体験を実現 安くアプリを利用だー。サクサク動く し、AIとかも安く運用できるぞ！？ 無駄な常時稼働を排除。 GPUも必要なときだけー ユーザの嬉しいを実現=エッジの最適解はここにある！？ Edge-as-a-Service 構想 MEC/オンプレミスエッジ の管理も楽々！ AI処理がさくさく動くぞ。。
42. © NTT Communications Corporation All Rights Reserved. 42 Edge-as-α-Service構想で目指していきたいこと
43. © NTT Communications Corporation All Rights Reserved. 43 Edge-as-a-Service 構想 Edeg-as-a-Service構想の可能性と今後の展望 使うときだけ動き、拠点を越えてつながる ―そんなシンプルで強いインフラの実現に 向けて、拠点間通信、GPUの分散活用、 サーバレス処理など最新のエッジアーキテ クチャを掛け合わせることで簡単に実現 ユースケース From Vision to Reality エッジでユースケースを 形にする。 生成AI VR/XR DX 交通 エッジ市場の盛り上げ エッジコンピューティングを盛 り上げたい！ Empowering the Cloud with the Edge エッジでクラウドをさらに強くする。
44. © NTT Communications Corporation All Rights Reserved. 44 Thank you for your attention.