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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 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構想が切り拓く未来

Slide 3

Slide 3 text

© NTT Communications Corporation All Rights Reserved. 3 クラウドコンピューティングの現状と課題クラウドコンピューティングは、大量のデータ処理や柔軟なストレージ拡張を可能にする一方で、現場での迅速な意思決定やセキュリティリスクへの対応が課題になっている。特に、高帯域幅を活用したデータ送信が可能でも、通信遅延やデータ漏洩のリスクは依然として存在する。パブリッククラウド/データセンタリージョンA リージョンB 全てのデータをパブリッククラウド/ データセンタへ伝送生成AI VR/XR DX 交通高セキュリティ現場での迅速な処理が求められる！！低遅延・高速もっと大量のデータ処理を実施したい高帯域情報漏洩が心配だなぁ通信網

Slide 4

Slide 4 text

© NTT Communications Corporation All Rights Reserved. 4 MEC MEC MEC MEC エッジでデータ処理を行うクラウド集中型 (エッジコンピューティングなし）クラウド/データセンタ全てのデータをクラウド/データセンタへ伝送トラフィック必要なデータのみクラウドへ伝送クラウド/データセンタオンプレミスエッジ網内エッジ (MEC) エッジコンピューティングありエッジコンピューティングとはクラウド集中型の特徴ネットワーク帯域の逼迫クラウド/データセンタへの通信量をが増大センター依存による情報漏洩リスク全データをクラウドで処理するため漏洩リスク増高遅延によるレスポンス低下リアルタイム性が問題 1 2 3 エッジコンピューティングの特徴ネットワーク負荷の軽減クラウド/データセンタへの通信量を削減情報漏洩リスクの低減重要な情報を事前に処理低遅延の実現リアルタイム性を向上 1 2 3 クラウド集中型では通信量の増加、遅延、情報漏洩リスクが顕在化する。これに対し、エッジコンピューティングはデータを端末近くで処理することで、通信負荷を削減しリアルタイム性とセキュリティを確保できる。中でもMEC（Multi-access Edge Computing）とオンプレミスエッジをネットワーク内に配置することで高効率な分散処理を実現する。

Slide 5

Slide 5 text

© NTT Communications Corporation All Rights Reserved. 5 パブリッククラウド/データセンタリージョンA MEC リージョンB MEC クラウド経由じゃ遅すぎる、現場（エッジ側)で即時に処理したい高負荷時はGPUリソースを一時的に増強し、処理性能を最大化したい負荷に応じてスペックを柔軟に引き上げたいリソース不足高速処理処理の増大管理が複雑になってめんどくさいなぁオンプレミスエッジ複数拠点にまたがる環境では、MECやオンプレミス装置の管理が煩雑化しやすく、運用負荷が高まる。また、ユーザごとに処理ニーズが異なる中で、リソースの柔軟な割当や自動スケーリングが難しく、負荷増加時の処理性能確保が困難となる。エッジコンピューティングの課題 +αの新しい何か？業務時間外はアプリを自動停止し、無駄なGPUリソース消費をゼロにしたいサービスの柔軟性

Slide 6

Slide 6 text

© 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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 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 通信網採用ソフトウェア

Slide 9

Slide 9 text

© 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 兼用

Slide 10

Slide 10 text

© 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をゼロ化しリソースを節約、使用時は最適に配分。

Slide 11

Slide 11 text

© 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" 特徴をさらにわかりやすくまとめると

Slide 12

Slide 12 text

© 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トンネル内で対象サービスがあるクラスタへルーティング処理を行う

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 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 サービス公開おお！大阪でやっていたアプリケーションが東京でもできるぞ！？最高！具体例:

Slide 16

Slide 16 text

© 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

Slide 17

Slide 17 text

© 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カメラ

Slide 18

Slide 18 text

© 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 通信網採用ソフトウェア

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© NTT Communications Corporation All Rights Reserved. 20 従来のクラウドベースメタバースの課題現行のメタバース構成では、 1. アプリケーションがクラウドに配置しており、レンダリングの品質がNW性能に依存してしまう 2. アプリケーションが常時起動のため適切なリソース割り当てができずコストが割高になるクラウド配信用サーバ WebRTC Rendering エンジン東京リージョン沖縄リージョン

Slide 21

Slide 21 text

© 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空間 ✓ メタバースのレンダリング機能をエッジにオフロードすることにより、高品質なメタバースソリューションを実現。 ✓ 利用者の位置や利用状況に応じた最適なエッジリソースの配置を実現。

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© NTT Communications Corporation All Rights Reserved. 23 5G通信網ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤配信用サーバ WebRTC Rendering エンジン外部GPU基盤 EaaS基盤 EaaS基盤沖縄リージョン Rendering エンジンユーザワークロードユーザユーザの増加に応じてレンダリングエンジンのスケールアウトが行われるユーザがアクセスしていないので0スケールされている

Slide 24

Slide 24 text

© NTT Communications Corporation All Rights Reserved. 24 5G通信網ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤配信用サーバ WebRTC Rendering エンジン外部GPU基盤 EaaS基盤 EaaS基盤沖縄リージョン Rendering エンジンユーザユーザユーザワークロードが逼迫拠点のユーザ増加により、MEC内のワークロードが増加ユーザの増加に応じてレンダリングエンジンのスケールアウトが行われる

Slide 25

Slide 25 text

© NTT Communications Corporation All Rights Reserved. 25 5G通信網ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤配信用サーバ WebRTC Rendering エンジン外部GPU基盤 EaaS基盤 EaaS基盤沖縄リージョン Rendering エンジンユーザワークロードが逼迫ワークロードの削減 AMQPトンネル Rendering エンジン必要に応じて一時的に外部GPU 基盤にワークロードの分散を行うことで、MEC内のワークロードの削減ユーザユーザ MEC内のレンダリングエンジンは一時的に停止

Slide 26

Slide 26 text

© NTT Communications Corporation All Rights Reserved. 26 5G通信網ポイント１の詳細 MEC 東京リージョン MEC EaaS基盤外部GPU基盤 EaaS基盤 EaaS基盤沖縄リージョン Rendering エンジンユーザワークロードが逼迫ワークロードの削減 Rendering エンジンアクセス減少によりワークロードが減少すれば、MEC内の処理に切り替え配信用サーバ WebRTC Rendering エンジン

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© NTT Communications Corporation All Rights Reserved. 30 5G通信網ポイント2の詳細 MEC 東京リージョン MEC vGW vGW EaaS基盤配信用サーバ WebRTC Rendering エンジン外部GPU基盤 EaaS基盤 EaaS基盤沖縄リージョン Rendering エンジンユーザ配信用サーバを沖縄リージョンに展開することで、拠点を跨いだメタバースソリューションの利用が実現 AMQPトンネル配信用サーバ WebRTC ユーザは意識することなく、東京リージョンのメタバースが利用可能

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 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実装環境

Slide 33

Slide 33 text

© NTT Communications Corporation All Rights Reserved. 33 ◆RAG（検索拡張生成）の実装 ※RAGとは：外部データベースから関連情報を取得し、質問やプロンプトに対する回答を生成する仕組み 1_ 汎用的な用語ではなく、会社独自の用語に対し、マニュアル情報などを指定し、ベクトルデータベースへ保存。 2_ 生成AI上で上記に関する問い合わせを実施すると、内部でベクトルデータベースへ問い合わせ、その出力結果を解答として表示する。ベクトルDB ユーザ ③ 会社独自の用語に関する質問を実施 ① 会社独自の用語に関する社内情報を保存 ④ 会社独自の用語に関する問い合わせが来た際はベクトルDBへ問い合わせ ⑤ 問い合わせに関する情報をベクトルDBから収集。その結果をユーザへ応答社内データがローカルに閉じて処理できるドキュメント生成AI ②ドキュメント情報をベクトル化し、DBへ保存 ※ベクトルDBはテキスト検索や質疑応答に利用される（参考資料）RAGについて

Slide 34

Slide 34 text

© 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 背景

Slide 35

Slide 35 text

© 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の一体型提供によりお客様によるインフラ運用管理が不要

Slide 36

Slide 36 text

© 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

Slide 37

Slide 37 text

© 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の実装イメージ

Slide 38

Slide 38 text

© 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

Slide 39

Slide 39 text

© 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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© NTT Communications Corporation All Rights Reserved. 41 エッジの最適解だから、あらゆるユーザの嬉しいを実現！？使うときだけ動き、拠点を越えてつながる―そんなシンプルで強いインフラの実現に向けて、拠点間通信、GPUの分散活用、サーバレス処理、エッジデバイスなど最新のエッジアーキテクチャを掛け合わせることで簡単に実現管理者/運用者:GPUを含むリソースを“必要なときだけ”自動最適配置。 → 稼働時間＝コストの完全従量モデルへ。 → DX施策のROIを数値で可視化し、効果が高い投資に資源を集中。ユーザ:あらゆるアプリを “簡単に・安く・早く” 利用可能に。 → オンデマンドでMECに接続、ローカルで完結する低遅延処理 → クラウドや本社システムに依存せず、真のエッジ体験を実現安くアプリを利用だー。サクサク動くし、AIとかも安く運用できるぞ！？無駄な常時稼働を排除。 GPUも必要なときだけーユーザの嬉しいを実現=エッジの最適解はここにある！？ Edge-as-a-Service 構想 MEC/オンプレミスエッジの管理も楽々！ AI処理がさくさく動くぞ。。

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 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 エッジでクラウドをさらに強くする。