MECを活用したアプリケーションデザインパターン

#この記事は
NTTドコモテクニカルジャーナルVol.29No.1["MECを活用したアプリケーションデザインパターン"](https://www.nttdocomo.co.jp/corporate/technology/rd/technical_journal/bn/vol29_1/008.html)の筆者による解説記事です。
#MECって？
Mobile Edge Computing もしくは Multi-access Edge Computingを略したもので、遅延要件の厳しいアプリケーションでも、ネットワークのエッジに近い場所に置かれたコンピューティングリソース（サーバなどのこと）によって、**遅延を短くすることが出来る技術**です。NTTドコモだと[ドコモOIC](https://www.nttdocomo.co.jp/biz/service/doic/)、AWSだと[Wavelength](https://aws.amazon.com/jp/wavelength/)（日本だとKDDIが提供）などが有名です。

#なんで必要なの？
世界中のモバイルキャリアが推し進めている5G(第5世代移動通信システム）には以下の3つの特長があります。

- 高速大容量（eMBB:enhanced Mobile BroadBand）
- **超高信頼低遅延（URLLC:Ultra Reliable and Low Latency Communications）**
- 多数端末同時接続（mMTC:massive Machine Type Communications）

このうち**低遅延性については、従来のようにインターネットの先のサーバに対して接続をすると、せっかくの低遅延性が損なわれてしまいます。**そこでより低遅延にするために、できるだけ端末（スマホやモバイルルータ）に近い位置にサーバを配置する必要があります。そこで、**モバイルキャリアはネットワークの中にサーバを置いて、みなさんが使えるようにしました。それがMEC**です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263125/33fa5e35-615b-e444-d5ac-a2b4602449cb.png)
出典：[ドコモの5Gネットワーク展開戦略 P.21](https://www.nttdocomo.co.jp/corporate/ir/binary/pdf/library/presentation/200825/200825_qa.pdf)

#MECのメリット
遅延を短くできるMECですが、遅延を短くする以外にも、ネットワークの中にコンピューティングを置くことによって下記のメリットがあると言われています。


<details><summary>トラフィック最適化、ネットワークでの折返し</summary>端末同士のP2P（Peer to Peer）通信時に、地理的に近いサーバにアクセス、もしくはトラフィックを経由させることで、非常に低い遅延での通信が可能になり、かつサーバからは大容量のデータを流すことができます。ゲームなどで応答時間の要求条件が厳しいものに対して利用が期待できます。</details>
<details><summary>低遅延、ゆらぎの抑制</summary>地理的に近いサーバにアクセスさせることで、5Gの特長を活かした低遅延での接続が可能になります。また、インターネットとは異なり閉域網での提供になるために、遅延におけるゆらぎの要因が少なくなり、ゆらぎに弱いストリーミングなどで利用が期待できます。</details>
<details><summary>セキュア・プライベートネットワーク構築</summary>インターネットなどの外部ネットワークに出ることがないため、安全な接続を提供できます。SIM認証でのプライベート接続なども可能になるため、秘匿性の高い情報を扱うネットワークとしての利用が期待できます。</details>
<details><summary>コンピューティングパワーの提供、端末機能補完</summary>端末では処理ができないような高度なAI処理や高精細な3D画像の生成など、負荷が大きな処理をエッジコンピューティング側で実施することができます。ゲームや3D CAD（Computer Aided Design）、XRなどでの利用が期待できます。</details>

#MECアプリケーションデザインパターン
アプリケーションデザインパターンとは、アプリケーションを構築する際に、典型的なデザインをパターン化してまとめたものです。特にMECは上記の特長がありますが、**今までにない**サービスであったために、**具体的にどう使えばいいのか**の考え方が整理された物がありませんでした。そのため、アイデアを整理していったのが**MECアプリケーションデザインパターン**です。
###基本的な考え方
MECは、地域に分散してサーバを構築するという性質上、**対障害性や堅牢性の面で、集約型データセンタで運用されるシステムとは異なります。**そこで、MECではDesign for failureと呼ばれる、パブリッククラウドコンピューティングにおける、**故障することを前提とするシステムの構築法を踏襲**します。例えば、**MEC上でのデータ永続化は保証されません。**これは、データの永続化のためには相当数の冗長性をもつ必要がありますが、この冗長性が分散化されたシステムでは取りにくいためです。そのため、**データ永続化はMECのレイヤではなく、上位のパブリッククラウドや他のストレージサービスで実施するのが好ましい**です。

ほかにも、MECにおける前提条件を下記の通り置いています。

- MEC単体での**堅牢性、可用性は共に低い**。
- コンピューティング（CPU、GPU、FPGA：Field Programmable Gate Array）、およびそれらを動作させるためのブロックストレージをもつ
- データの永続化が期待されるようなPaaS（Platform as a Service）サービスを極力もたない。
- 一方で、コンテナ管理サービスのようなポータビリティを向上させる機能は具備する。
- DNS（Domain Name System）サービスが提供される。

#具体的なアプリケーションデザインパターン
詳細はこちらの記事：[NTTドコモテクニカルジャーナルVol.29No.1"MECを活用したアプリケーションデザインパターン"](https://www.nttdocomo.co.jp/corporate/technology/rd/technical_journal/bn/vol29_1/008.html)にまとめていますので、御覧ください。

## 高速大容量アップロードパターン
**5Gの高速性を活かしたアップロードを実現する方法**として提案しています。MECで中継することで、ACKの遅延を短くし、より高速にアップロード出来るようにしています。使い方としては、映像のアップロードなど、大きなデータのアップロードをすることを想定しています。

工夫するポイントは、**MEC上で一度アップロードを終端させ、一時ストレージとして利用すること**です。しかしそのままでは永続化が出来ないので、それをキュー（例えばAWSのSQS)を使うことで、パブリッククラウド上のストレージサービス（例えばAWSのS3）に非同期的にアップロードします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263125/3b449d54-1c87-0d90-cfc5-2929b864d299.png)

## 超低遅延メッセージング、ステータス管理パターン
5Gの低遅延性を用いたメッセージング、Pub/Subの実現です。MEC上で[Kafka](https://kafka.apache.org/)などの**メッセージングサービスを置くことで、低遅延のメッセージングサービスをスマホなどに提供すること**が出来ます。使い方としては、対戦型ゲームやオープンワールド系ゲームの端末同士の状態同期、IoTデバイスの状態同期などを想定しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263125/f358f04d-bf02-2d81-ae1a-bfcfdc0d0ed4.png)

## Webサービスキャッシュパターン
最も基本的なアプリケーションのデザインとして、Web三層構造がありますが、このうち**アプリケーション層をMECに置いて高速化を実現する**パターンです。データベース層についてもリードレプリカやキャッシュ機構をMEC上にもつことで高速化を実現します。

工夫するポイントは、**データベース層をパブリッククラウド側にもって来る**ことです。MEC層にデータベース層を置くと、永続化が難しくなり、また広域での一貫性（Consistency）が保てなくなるため、**キャッシュだけをアプリケーション層の近くに置いて**います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263125/567f7541-c23d-b653-c603-17a785872a63.png)

## IoTデバイス用軽量プロトコルの実装パターン
IoT機器の中には能力不足のために、セキュリティに関連する機能を実現できないものがあります。そういったものでもこのパターンを踏襲することで**高いセキュリティと低遅延を実現することが出来ます。**具体的にはIoT機器向け軽量プロトコルMQTTなどを安全にモバイルネットワーク内で終端することで実現します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263125/4a476803-4fd5-f4b4-3f51-5174d55218c8.png)

##その他
他にもこんなパターンが考えられますので、まとめて載せておきます。

|パターン名|課 題|デザインパターン|
|:----|:----|:----|
|CDNパターン|動画やストリーミングサービスにおいて、オリジンサーバ（配信サーバ）への負荷軽減をしたい。 オリジンサーバへのネットワークのゆらぎなどにより品質の劣化を防ぎたい。 超高速・超大容量でのサービス提供は上位ネットワークほど負荷が集中し、品質が劣化しやすい。 できるだけ映像をリアルタイムで提供したい。|通常のCDNシステムと同様にDNS側で最も近い場所を返すようにすることで最も近いサーバを判断することができる。CDN側では最も近い場所のキャッシュを取りに行くことができる。各CDNサーバは変更がある場合に、オリジンサーバ（例：パブリッククラウド上のWebサーバや、ストリーミングサーバ）から最新情報を取得する。 ストリーミングでHLSなどを使っている場合も同じロジックで適用可能なため、汎用性が高い。|
|折返しによるP2Pトラフィックの最適化パターン|ローカルエッジネットワークにおける折返し通信により、P2Pトラフィックを最適化し、安定した高品質のサービスを提供したい。 例えばビデオ通話などをローカル限定で折り返すことにより、最適化を図りたい。|5G/4GのローカルNW上で折返しトラフィックを網内で最短ルーティングすることで低遅延での端末間通信を可能にする。MEC上にシグナリングサーバを配置することでWebRTCやVoIP(SIP)などを実装することが可能になる。シグナリングサーバを広域に展開する場合はMEC上でなくても良い。|
|ローカルセキュアネットワークパターン|ローカルネットワークを端末間で実現し、VPNなどを使わずにセキュアなネットワークを構築したい （ファイルサーバなど）。|VPNサーバをMEC上に配置することで、好きなNWを作ることができる。また、高速大容量を実現できるため、ファイルサーバなどへのアクセスも安全かつ容易に構築できる。|
|地理的制約を利用したセキュリティ実現パターン|特定の地域外からのアクセスを防止し、よりサービスを安全に提供したい 。|MEC上に特定の地域のみにファイルサーバを配置し、そのシステムには特定地域のシステムからのみサーバのアクセスを許可する。 DNSで地域のMECサーバを特定し、そのサーバにアクセスする。 MEC上にはその地域でしかアクセスできない情報、もしくは認証方式を用いてアクセスする。 パブリッククラウド上にストレージ、もしくはDBを配置し、堅牢性や可用性はそちらで担保する。 可用性を担保するためにMEC上ではLBを配置し、二重化しておく。|


#おわりに
いかがでしたでしょうか。MECのより具体的な使い方のイメージが湧いていただければ幸いです。他にも**MECを使うことで様々な課題が解決出来ることがあるかも**しれません。是非皆さんもMECアプリケーションデザインパターンを考えてみただければ幸いです。