Now you can watch the keynotes that took place during the OpenInfra Summit in Berlin!
この 10 年間、集中型クラウドコンピューティングは標準的な IT サービスプラットフォームとなっています。クラウドコンピューティングは至る所にありますが、新たな要件や作業負荷に対しては限界が見えてきています。強力なデータセンターの中心的な見解では、コンピューティングとストレージのリソースが比較的豊富で集中化されている場合、サポートするハイパーバイザーと管理プラットフォームのフットプリントの最適化についてはほとんど考えられてきませんでした。信頼性の低いネットワーク接続や帯域幅が制限されたネットワーク接続でしかアクセスできない制約付きノードをサポートするために必要な要件を真剣に検討しているクラウド開発者は少なく、非常に高い帯域幅、低いレイテンシ、または多くのサイトにわたって広範囲の計算能力を必要とするアプリケーションのニーズを考えていました。
新しいアプリケーション、サービス、コンピューティングタスクは、分散インフラストラクチャーを直接サポートするために構築された新しいアーキテクチャーをますます要求します。リモートサイトにおける可用性とクラウド機能の新しい要件は、 今日の要件 (小売データ分析、ネットワークサービス) と明日のイノベーション (スマートシティ、AR/VR) の両方をサポートする必要があります。進化する要求に対応するためには、クラウドの成熟度や堅牢性、柔軟性、およびシンプルさを複数のサイトやネットワークに拡張する必要があります。
企業は最近、複数のサイトとネットワークにまたがった分散インフラに対して、シンプル化された管理とクラウドコンピューティングアーキテクチャーの柔軟性を適用してきました。組織は、 WAN ネットワーク全体にまたがってクラウド機能を活用し、ネットワークエッジにおける適用をますます小規模にしたいという新しいニーズを持っています。このアプローチは初期段階にありますが、多くの新しいユースケースとシナリオが分散アーキテクチャーから恩恵をうけるようになるのは明らかでしょう。
このペーパーでは、私たちはこの新しいニーズを調査します。このニーズは分散クラウドや fog computing,、第 4 世代データセンターといった多くの名前を持ちますが、このドキュメントの目的にかなうため、私たちは共通で簡単に理解できる用語であるクラウドエッジコンピューティングという言葉を使います。
OSF Edge Computing Group はこのクラウドコンピューティングの変革を、大変刺激的だと見ていますが、一方で OpenStack の機能はクラウドエッジコンピューティングをサポートするには初期段階であるということも認識しています。OpenStack Summit Boston で確認された初期のコミュニティーの関心に基づいて、2017 年 9 月に 2 日間のワークショップが開催され、200 人以上のユーザーと開発者が関連するユースケースを定義し、それらをサポートするために必要なツールやアーキテクチャーを検討するというハードワークを開始しました。概念実証が実行され、コミュニティーは早期のデプロイメントをいくつか行いました。 OSF Edge Computing Group は、完全な機能を持ったエッジコンピューティングクラウドインフラについて、基礎要件を記述するという挑戦を現在行おうとしています。
このドキュメントでは、私たちはいくつかの重要なタスクを達成することを狙っています。
私たちの目標を達成するためには多くの作業が必要です。オープンソースコミュニティー全体が、クラウドエッジコンピューティングの新しい要件を満たすためツールを作成し、適用する努力と機会の両方に加わることを歓迎し、奨励します。
エッジコンピューティングの定義には多くの重複と、時にはいくつか矛盾が存在するということは強調する価値があります。— エッジコンピューティングの意味は人によって様々です。エッジコンピューティングのもっとも成熟した見方は、アプリケーション開発者とサービス提供者に対し、クラウドコンピューティング機能と同様の IT サービス環境をネットワークのエッジに提供することです。
その狙いは、コンピューティング、ストレージ、帯域幅をデータ源やエンドユーザーの近くで提供することです。エッジコンピューティング環境は、全サイト間の潜在的な高遅延と信頼性の低い小さな帯域幅に特徴付けられます。さらに、一般的なデータセンターの集中型クラウドリソースでは提供することができない、特有のサービス配信とアプリケーション機能の可能性にも特徴付けられます。処理機能の一部または全部をエンドユーザーまたはデータ収集ポイントに近づけることによって、アプリケーション上の遅延影響を最小限に抑える効果により、広域分散の影響を抑制することができます。
エッジコンピューティングは、WAN ネットワーク上でネットワークサービスを仮想化することによって初めて登場し、データセンターから離れる一歩を踏み台ました。初期のユースケースは、クラウドコンピューティングユーザーが使い慣れた柔軟でシンプルなツールを提供するプラットフォームを使いたいという要望によって推進されました。
新しい形のエッジコンピューティングが登場するにつれて、コンピューティングへの見方が変わりつつあります。もはや集中的なデータセンターを構築する必要性に縛られることはありません。代わりに一部のアプリケーションでは、エッジコンピューティングが仮想化とクラウドコンピューティングの知見を活用し、数千台規模の数を潜在的に持つ分散ノードを持つことで様々なユースケースに対応する可能性を生み出しています。例えば、産業用の IoT や、リアルタイムで水資源の使用量を数千、数百万の場所で監視するネットワークなどです。
分散クラウドに依存することなく、独自開発もしくはオープンソースのエッジコンピューティングが既に存在しています。いくつかのベンダーはこれを「デバイス・エッジ」と呼んでいます。この手法のコンポーネントには IoT ゲートウェイや NFV アプライアンスが含まれています。しかし、アプリケーションはクラウドの様々な機能をエッジに必要としますが、分散型エッジインフラを構築するためのツールやアーキテクチャーはまだ初期段階です。我々は、市場がエッジコンピューティングに対して優れた機能を求め続けると考えています。
エッジコンピューティングの能力は、限定されてはいませんが次のようなものがあります。
エッジコンピューティングにおける「エッジ」とは、分散されたデータ源やエンドユーザーに可能な限り近い、管理ドメインの外の領域を示します。このコンセプトは通信事業者のネットワークや、小売業のような分散した出張所を抱える大規模エンタープライズ、もしくはその他の、特に IoT の文脈で語られるアプリケーションに当てはまります。
エッジコンピューティングの特徴の一つに、アプリケーションはエッジの位置に強く結びついているということがあります。通信事業者にとって「エッジ」とは、エンドユーザーに近くありつつもプロバイダーが制御できる場所を示すでしょうし、潜在的にはエンドユーザーの持つ機器上で動作するワークロードという要素も含むでしょう。大規模エンタープライズにとっては、アプリケーションやサービスまたはワークロードが利用される場所 (例として小売店や工場) のことを示します。この定義の目的からいうと、 IoT やセンサー機器のように、最小のクラウドアーキテクチャーをサポートするためだけに極端に能力を制限された終端機器はエッジではありません。エッジコンピューティングに絡む議論の多くが、この差異を明確にしていないため、このことは熟慮すべき事項です。
以下のような点でエッジコンピューティングは、データセンターコンピューティングと類似しています。
エッジコンピューティングは、大規模データセンターのコンピューティングと次のような違いがあります。
エッジコンピューティングのコンセプトは、エッジサイト (例としてコンピュート、ネットワークやストレージのインフラストラクチャー) だけでなく、エッジサイト上で実行されるアプリケーション (ワークロード) の双方をカバーすべきです。エッジコンピューティング環境におけるどんなアプリケーションも、クラウドが提供する機能ーすなわちコンピュート、ブロックストレージ、オブジェクトストレージ、仮想ネットワーク、ベアメタルやコンテナといった機能のいくつか、あるいは全てを潜在的に利用しなければ価値がないのです。
エッジコンピューティングをクラウドコンピューティングから分別する、必要不可欠な特徴とは次のようなものです。
それではエッジコンピューティングについて、私達が今のところ知る特徴、ユースケース、そしてシナリオはどんなものでしょうか。
クラウドエッジコンピューティングを前に推し進める典型的なニーズは、ユーザーやエンドポイントのデータ源に向かってより近づけようとするサービスデリバリーからくるものです。エッジコンピューティング環境はコア容量と結合して動作します。一方でエッジコンピューティングは、不必要なコアとの接続要求を除外し、改善されたユーザーエクスペリエンスを提供します。改善の結果は、次のようなものからもたらされます。
しかし、ここにはトレードオフがあります。エッジコンピューティングを提供するということは、デプロイメント数の莫大な増加が必要不可欠です。このことは、広域に拡散されたエッジのデプロイメントのための重要なチャレンジにつながります。一つのクラウドを 10 チームで運営するとすると、組織は数百あるいは数千の小さなクラウドを協調させれうためどのようにすれば良いでしょうか？いくつかの仕様は次のようなものを含みます。
恐らくユースケースを分類する方法はたくさんあるでしょうし、このペーパーは完全なリストを提供するには短すぎるでしょう。しかし、考え方の整理を助けるいくつかの例と、コラボレーションのための重要な機会をここに掲載します。
分散アーキテクチャーから利益を受ける主要な 4 つのワークロードは、分析、法令遵守要件、セキュリティーと NFV です。
IoT は、ここではごく小さなサイトの大きなネットワークから常にデータ収集を行うものを言いますが、エッジコンピューティングから利益を受けるアプリケーションの一例です。大量のデータを、しばしば制約が発生するネットワーク越しに集約型データセンターの分析エンジンに転送することは非効率的でしょう。この方式は恐らくレスポンスが悪いでしょうし、過度な遅延要件が求められるでしょう。さらに貴重な帯域の無駄遣いになります。エッジ装置はテラバイト級のデータを生成することも出来るため、分析機能をエッジ上にあるデータ源に近づけ、データ源近くで分析し、要約された小さな情報だけを集約型システムに送り返すことで、よりコスト効率を上げることが出来ます。この方式は、トレードオフが発生します。すなわちコアにデータを転送するためのコストと、いくつかの情報が失われることのバランスをとることになります。
不幸なことに、携帯ハンドセットや IoT センサを含むエッジ装置の急増により、エンドポイントの急増を利点とする新しい攻撃手法が現れてきています。エッジコンピューティングはセキュリティー要素を攻撃者に近づける能力を提供します。この能力は、セキュリティーアプリケーションのより高い性能を実現し、抜け穴やリスクに対するコアの防御を助ける何層もの防御層の数を増やします。
法令遵守は、広い要件をカバーします。ジオフェンシングから、データ主権、著作権の施行までが含まれます。地理的、あるいは政治的な境界に基づいたデータへのアクセス制限、すなわち著作権の制限に従ってデータストリームを制限したり、特定の規制に従った場所にデータを格納したりすることは、全てエッジコンピューティングインフラを使えば達成可能かつ実施可能です。
ネットーワーク仮想化 (NFV) は、本質なエッジコンピューティングアプリケーションの中心的なものです。なぜなら、エッジコンピューティングはインフラ機能を提供するからです。通信事業者は彼らのサービス提供モデルをエッジコンピューティングインフラの一部、あるいは最上位レイヤとして仮想ネットワーク機能を動作させることで変革しようとしています。効率の最大化や、コストや複雑さの解消のため、NFV をエッジコンピューティングインフラで稼働させることは意味を持ちます。
リアルタイムアプリケーション、すなわちAR/VR、コネクテッドカー、遠隔医療、ネットワーク経由の触覚通信を使ったインダストリ4.0、そしてスマートシティーは、数ミリ秒以上の許容できない遅延があると実現できません。そしてこれらは極めてジッターや遅延の変化に敏感です。例えばコネクテッドカーは、低遅延や広帯域を必要とし、ユーザーに近い場所での計算やコンテンツキャッシュに依存するでしょうが、これらの要件を達成するにはエッジ機能が不可欠になります。多くのシナリオ、とりわけ閉じられたループの自動化は、高可用性と数十ミリ秒単位のレスポンスが求められてきましたが、エッジコンピューティングインフラがなくては要件を満たせないものです。
Edge computing expands bandwidth capabilities, unlocking the potential of new immersive applications. Some of these include AR/VR, 4K video, and 360° imaging for verticals like healthcare. Caching and optimizing content at the edge is already becoming a necessity since protocols like TCP don’t respond well to sudden changes in radio network traffic. Edge computing infrastructure, tied into real-time access to radio/network information can reduce stalls and delays in video by up to 20% during peak viewing hours, and can also vary the video feed bitrate based on radio conditions.
Many applications are not sensitive to latency and do not require large amounts of nearby compute or storage capacity, so they could theoretically run in a centralized cloud, but the bandwidth requirements and/or compute requirements may still make edge computing a more efficient approach. Some of these workloads are common today, including video surveillance and IoT gateways, while others, including facial recognition and vehicle number plate recognition, are emerging capabilities. With many of these, the edge computing infrastructure not only reduces bandwidth requirements, but can also provide a platform for functions that enable the value of the application—for example, video surveillance motion detection and threat recognition. In many of these applications, 90% of the data is routine and irrelevant, so sending it to a centralized cloud is prohibitively expensive and wasteful of often scarce network bandwidth. It makes more sense to sort the data at the edge for anomalies and changes, and only report on the actionable data.
今日においても、多くの環境は、制限付きで、信頼性に乏しいか予測不可能なネットワーク接続を持っています。これらの中には輸送業 (飛行機、バス、船舶) や鉱山業 (石油掘削装置、パイプライン、鉱業) 、電力インフラ (風力発電所、太陽光発電所)、そして典型的には良いネットワーク接続を持つべき店舗のような環境も含まれます。エッジコンピューティングは、半自律性と機能性を維持することで、必要とされた時やネットワークが使えなくなった時も、このような環境をきちんとサポートします。このアプローチの一番良い例は、一時的なネットワーク不良が起きるケースも想定した、小売店の POS システムを保守するためのニーズでしょう。
企業はワークロードや接続性の制限のほか、プライバシーについてもエッジコンピューティング機能のニーズを持つかもしれません。例として、個人的な医療情報の匿名化を行う必要のある医療アプリケーションが挙げられます。これらの情報をクラウドに送信する前に、このアプリケーションはエッジコンピューティングインフラを使い、この作業を行います。
クラウドエッジコンピューティングから恩恵を受けられるような要件を確認するための他の方法は、エッジコンピューティングをデプロイを行う会社のタイプで区別するというものです。事業者ー例えば通信事業者のアプリケーションは、エッジコンピューティングインフラ上で実行されるワークロードですが、事業者によって構築され、運用されます。サードパーティのアプリケーションは、他社のエッジコンピューティングインフラを活用するために、既存のエッジインフラ上で動作します。コンピュート、ブロックストレージ、オブジェクトストレージ、仮想ネットワーキング、ベアメタル、コンテナーといったクラウドによって提供される機能のすべてや一部を、どのアプリケーションでも活用できることに注意してください。
エッジコンピューティングのパラダイムにおける基本的な特徴は、インフラがエンドユーザーに近いところに位置しているということであり、サイト分散の規模が大きく、エッジノードは WAN 接続されているということです。いくつかのシナリオを更に深く調査することは、ユースケースに紐付けられる現在の機能を我々が検討するのに役立ちます。それはまた、弱点を強調したり、改善の機会を得るのにも役立ちます。
1. 小売/金融/遠隔地 「箱の中のクラウド」: アプリケーションパッケージをサポートするエッジコンピューティングインフラは、特定の企業や産業向けにカスタマイズされます。企業に利用される場合には大抵、アプリケーションパッケージとエッジコンピューティングインフラは究極的に統合されて分散インフラとなります。その目的は、ハードウェアの大きさを抑え、複数拠点のデプロイメントを標準化し、エッジに位置するアプリケーションの交換作業に大きな柔軟性をもたらし (さらにハードウェアの違いにかかわらず同じアプリケーションを動作させ)、迅速に起動し、そして断続的な WAN 接続という心配事にも配慮するというものです。コンテンツをキャッシュし、あるいはコンピュートやストレージ、ネットワークを自給自足アプリケーションのために提供することは、限られた接続性という状況におけるエッジコンピュータの明らかな利用法です。
2. モバイル接続性: モバイル/無線ネットワークは、クラウドエッジコンピューティングの共通な環境要素になりそうです。モバイルネットワークは、少なくとも 5G が広く利用されるまでは、制限され予測不可能な帯域によって特徴付けられるでしょう。例えば遠隔修理や遠隔医療のための高いリアリティ、公共事業 (水道、ガス、電気、設備管理) データを監視する IoT 装置、商品目録、サプライチェーンや輸送ソリューション、スマートシティ、スマートロード、そして遠隔セキュリティといったアプリケーションは、多かれ少なかれ全てモバイルネットワークに頼っています。これらのアプリケーションは全て、エッジコンピューティングのワークロードをエンドユーザーに近づけるという機能に恩恵をうけることになるでしょう。
3. Network-as-a-Service (NaaS): 根本的に異なる環境における個別ネットワークサービスアプリケーションの提供ニーズから、NaaS のユースケースはエッジにおける分散プラットフォーム自身の小さなフットプリントと、エッジ外のサービスをサポートする信頼性に乏しく制限された WAN を管理する強力な集中管理ツールの両方が求められます。このシナリオの主要な特徴は、小さなハードウェア、移動 (これに伴いネットワーク接続が変化します) と恒常的なワークロードの変化、データとアプリケーションが混在することが挙げられます。マイクロノードをサポートするインフラへのニーズは、ケースの一つです。これは非伝統的な形でパッケージされた (冷房のあるデータセンター内にある19インチラックだけではありません) 少量のコンピュータです。NaaS はエッジにある数千から数万ノードをサポートすることが求められるでしょうし、メッシュや階層型アーキテクチャーのどちらか、あるいは双方を必ずサポートすることが求められるでしょう。さらに要求サイト上で必要なときに素早く起動し、終わればシャットダウンすることも求められます。API と GUI から同じデータセンター内でなく異なった場所に置かれている大規模なコンピュートノードの変更を反映する必要があるでしょう。
4. Universal Customer Premises Equipment (uCPE): このシナリオは、今日既に開発されていますが、アプライアンス程度の大きさをしたハードウェアのためにサポートが求められ、高可用性が求められる定常的に安定したワークロードが乗る制約付きのネットワーク接続によって性格づけられます。そして数百から数千のノードにまたがってデータとアプリケーションが混在することをサポートすることも必要ですし、既存の uCPE デプロイメントにスケールすることも新たに必要となるでしょう。
これは特に、サービス連携アプリケーションの異なる組合せが求められる異なったサイトや、協調動作するアプリケーションの異なる組合せが求められるサイト上で稼働する NFV アプリケーションに適用できます。メッシュや階層型アーキテクチャーは、断続的なネットワーク接続のためにローカライズされた機能と、データ処理の格納と転送を行う必要があります。自己修復と自己管理は、ノードの遠隔制御とともに必要となります。
5. Satellite enabled communication (SATCOM): このシナリオは、しばしばもっとも遠く厳しい条件に配布された多数の終端装置によって性格づけられます。そして同時に、とりわけ非常に高い遅延や、限られた帯域、そして衛星通信のコストを考慮する場合、ホスティングサービスのための分散プラットフォームを最適化する際に意味をなします。具体的なユースケースの例としては、船舶 (漁船からタンカーまで) や航空機、石油掘削装置、鉱山の運営や軍用基準のインフラが挙げられます。
たくさんのエッジ適用例が世界中で進められている一方で、新興や既存を問わずチャレンジや制限を解決する広範な適用のために、新しい考え方が必要とされています。
私たちは、ハードウェアとアプリケーションライフサイクルをサポートするプラットフォームサービスの両面から、伝統的なデータセンター集中型クラウドと比較し、より障害許容性を持ち強固である設計をすることにより、エッジコンピューティングプラットフォームのあるべき姿を確立しました。このため私たちは、エッジのユースケースが、標準的なデータセンターインフラが行ってきたのと同様な保守サポートを持つことは当然でない様に思います。ゼロタッチプロビジョニングや自動化、全インフラとプラットフォームスタックの自律オーケストレーションは、これらのシナリオにおいて極めて重要なものです。
しかし熟慮が必要なチャレンジが更にあります。
その一つとしてエッジのリソース管理システムは、ハイレベルなメカニズムセットを提供すべきであり、その結果 WAN により相互接続される地理的に分散された IaaS インフラの運用や利用を可能にするシステムになるでしょう。言い換えればこのチャレンジは、IaaS コアサービスを前述したエッジの特徴ーネットワーク切断や帯域、コンピュートとストレージの容量制約、無人デプロイメントなどなどを実現するために変化 (そして必要があれば拡張) させます。
いくつかの予測可能なニーズは次のようなものです。
これらのニーズは比較的明らかであり、既存のプロジェクトを活用し適応させることで満たされる可能性があります。しかしエッジコンピューティングの他のニーズは、よりチャレンジングです。これだけに限ったものではありませんが、次のようなものが含まれます。
Akihiro Motoki, <[email protected]>
Hajime Miyamoto, <[email protected]>
Shunichi Kuroyanagi, <[email protected]>
