翻訳: Edge Native Application Principles Whitepaper

はじめに

　本稿は、CNCFのIoT Edge Working Groupが2023年1月に公開した「Edge Native Application Principles Whitepaper」の翻訳記事です。

目的

　「エッジネイティブ」という言葉は、GartnerやMacrometa、FutureCIOなどの業界ブログを含む多くの場所で言及されています。State of the EdgeやLinux Foundation（LF）などの組織も、エッジネイティブアプリケーションについて議論していますが、エッジネイティブの原則に焦点が当てられているわけではありません。
　本ホワイトペーパーは、エッジネイティブアプリケーションに焦点を当て、その原則がどのように定義されているかを解説します。

エッジとは？

　エッジコンピューティングとは、例えば工場のロボット制御のように、データ処理をよりソースに近づけるパラダイムです。
　エッジコンピューティングは、2022年から2030年にかけて38.9%成長すると推定されており、よりユビキタスになっていくでしょう。企業は、エッジにコンピューティングパワーを持つことで、以下のようなメリットを得ることが期待されます。

• レイテンシの削減
• 帯域の管理
• センシティブデータへのプライバシー保護
• 信頼性の低いネットワークでもオペレーションを中断させない

　エッジコンピューティングには様々な定義が存在しますが、本稿で注目するのは、データ処理を行うリソースの、地理的な位置を基準としたものです。地理に基づくエッジの定義は、ユーザーからの距離によって複数のカテゴリーに分類されます。
　下図は、Linux Foundation Edge Whitepaperで定義されたカテゴリを示したものです。

エッジネイティブの原則は、クラウドネイティブの原則と多くの共通点がありますが、いくつかの重要な相違点もあります。

クラウドネイティブ VS エッジネイティブ

　Cloud Native Computing Foundation (CNCF)が定義するクラウドネイティブテクノロジーとは、以下の通りです：

クラウドネイティブテクノロジーは、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど、モダナイズされた動的でスケーラブルなアプリケーションを構築し、実行できるようにするテクノロジーです。コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIはクラウドネイティブなアプローチの例です。
　これらの技術により、耐障害性、管理性、観測性に優れた疎結合システムを実現することができます。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力（minimum toil）で、インパクトのある変更を頻繁に、かつ予測可能に行うことができます。

The Open Glossary of Edge Computingは、「エッジネイティブアプリケーションはクラウドネイティブの原則を活用する」としており、この幅広いミッションはエッジアプリケーションにも適用可能です。

• エッジネイティブアプリケーションとは、集中型データセンターでの運用が現実的でない、あるいは望ましくない、エッジコンピューティング機能を活用するために、ネイティブに構築されたアプリケーションのことです。
• エッジネイティブアプリケーションは、リソースの制約、セキュリティ、遅延、自律性といったエッジ特有の特性を考慮しながら、クラウドネイティブの原則を活用します。
• エッジネイティブアプリケーションは、クラウドを活用し、上流のリソースと協調して動作する方法で開発されます。集中型のクラウドコンピューティングのリソース、リモート管理、オーケストレーションを理解せず、CI/CDを活用しないエッジアプリケーションは、真の「エッジネイティブ」ではなく、むしろ従来のオンプレミスアプリケーションに近いと言えます。
  　>- クラウドネイティブのユースケースが従来のクラウドからエッジロケーションのデータやイベントを取り込むようになるにつれ、新しいツールや技術が、エッジのユニークな特性を管理しながら、回復力、管理性、観測性を備えた疎結合システムを提供するという目標に沿って進化しています。

エッジネイティブアプリケーションの特性の類似性

求められる属性	概要
アプリケーションやサービスの可搬性	アプリケーションやサービスとインフラとの結合を抽象化します。よくできたアプリケーションは、それがどこで動いているのかを知る必要がなく、プラットフォーム間でポータブルであることが期待されます。
可観測性	プラットフォームには、問題の検出やメトリクスの収集を可能にする、十分に文書化された一連のインターフェースとツールオプションが提供されています。これにより、開発者は、弾力性があり、効率的に管理されたシステムを構築することができます。
管理性	アプリケーションとリソースをスケールアップして管理するためのインターフェースとツールオプションが提供されています。また、プラットフォームには、ベースラインのネットワーク接続、サービス、管理機能を提供するプラグインがあります。
言語やフレームワークにとらわれないサポート	アプリやサービスは、一般的なさまざまな言語やフレームワークを使用して実装し、ホスティングすることができます。

クラウドネイティブとエッジネイティブの違い

求められる属性	クラウドネイティブ	エッジネイティブ
アプリモデル	ロードバランスによる水平スケーリングのために、ステートレス実装のマイクロサービスがほとんど	サービスプロバイダのエッジアプリはクラウドネイティブと類似する可能性があるが、ユーザーのエッジアプリはシングルトンの「モノリシック」かもしれない。どちらの場合も、ステートはアプリにコロケーションされている(ステートフル)可能性がある。
データモデル	ステートレスコンポーネントをバックアップする集中型モデルが一般的です。	キャッシング、ストリーミング、リアルタイム、分散モデルなどがよく利用されます。
弾力性	高速なスピンアップとダウン。一般に、基礎となるリソースは無制限として扱われる。	エッジのハードウェアリソースに制約があるため、伸縮性に乏しい。利用可能であれば、接続されたクラウドまで「垂直」に拡張できるかもしれない。
レジリエンススケール	failure domainに分散した冗長ノードを用いて、クラウド事業者に耐障害性を委託している。	多くの場合、ハード化されたインフラに依存し、ステートフルなコンポーネントのリカバリーアーキテクチャを備える。多くの場合、回復力はクラウドよりも低い可能性がある。
スケール	通常、いくつかの場所、インスタンスに限定	多数の外部機器（最大10万台）に対応し、多数の拠点（最大1万台）にまたがる可能性がある
オーケストレーション	大規模なパブリッククラウドやオンプレミスクラウドにおけるオーケストレーションは、集中的にプールされたホスト上でワークロードを実行し、水平方向にスケジュールすることで効率性と可用性を実現するように設計されている。	エッジは、ワークロードが分散して配置され、多くの場合、場所に応じた方法でスケジューリングされる分散型となる。
マネジメント	クラウドネイティブもエッジネイティブも管理は可能ですが、その仕組みは様々で、クラウドネイティブは中央管理と自動化に頼っています。	エッジネイティブでは、リモート管理、集中管理、ハードウェアとソフトウェアのゼロタッチプロビジョニングを組み合わせて行う必要がある。エッジに配置されたスタッフは、訓練されていない、信頼されていない、最小限の人員、あるいは存在しない場合もあり得る。復旧の課題があるため、Atomicアップグレードが望まれるようになる。
レジリエンススケール	failure domainに分散した冗長ノードを用いて、クラウド事業者に耐障害性を委託している。	多くの場合、ハード化されたインフラに依存し、ステートフルなコンポーネントのリカバリーアーキテクチャを備える。多くの場合、回復力はクラウドよりも低い可能性がある。
ネットワーキング	アプリケーションが豊富な機能を持つ高速ネットワークに依存可能	アプリケーションは、さまざまな速度（断続的で貧弱なものから優れたものまで）と機能を考慮する必要がある。また、モバイル、無線ベース、非IPプロトコルネットワークからのデータおよびイベントの統合を含む。
セキュリティ	セキュアな施設内の信頼できるファブリック	非セキュアな環境でのゼロトラスト
HWアウェアネス	ほとんどのアプリケーションに対応できるように、コンピューティングリソースが事実上統一されている。そのため、アプリケーションがハードウェアの配置を気にする必要がほとんどない。	アプリケーションには、ハードウェアプラットフォーム、位置情報、セキュリティなどに関するリアルタイム性能の要件が存在する場合がある。また、開発者は、より多様なハードウェアとインターフェイスを認識する必要がある。
外部リソースとの連携	アプリケーションは滅多にローカルのハードウェアリソースと連携しない。	エッジに配置されたサービスは、カメラ、センサー、アクチュエーター、ユーザーなど、ローカル環境と相互作用する必要があることが多い。

エッジネイティブの原則

大項目	中項目	概要
リソース＆デバイスの考慮	HWの考慮	ハードウェアプラットフォームが均質ではなく、開発者はより多様なハードウェアとインターフェースを意識する必要がある。
	外部デバイスとの接続	アプリケーションは、環境内のデバイスに接続する方法を知っていなければならず、実行時に機能の変更を認識する必要がある。例えば、初期設定後にエッジサーバーへのセンサーの接続が解除されたり、新しいデバイスがネットワークに侵入した場合に対応する必要がある。そのケイパビリティは静的なものではなく、むしろ環境を含むものであるため、オーケストレーターはケイパビリティの変化とアプリケーションの状態を調整できる必要がある。
	コネクティブティが不定	アプリケーションは、非同期通信、キューイング、キャッシュなどのメカニズムを使用して、ネットワークの信頼性の低い、あるいはネットワークを利用できない（エアギャップ）環境に適応する必要があります。規模、ネットワーク接続性、セキュリティの問題を克服するために、エッジが中央のサイトから設定を引き出す「プル」型のメカニズムが必要となる場合がある。
At Scale管理	中央の可観測性	エッジネイティブアプリケーションとクラウドネイティブアプリケーションは、どちらも中央で観測できる必要があるが、エッジネイティブアプリケーションには独自の考慮事項がある。エッジネイティブアプリケーションのインスタンスは、大規模なインスタンスで展開される可能性があり、スタッフや現場でのサポートに制約が伴う。そのため、分散型データ収集や集中型集計、オープンループ（人による観察・実行）とクローズドループの自動化（機械が実行可能）の組み合わせなどの技術が必要とされる。なお、観測可能とは、メトリクス、ログ、デジタルツイン、アラート（イベントやアラーム）、ヘルスモニタリングなどを指す。
	インフラやプラットフォームの管理	エッジアプリケーションは、規模に応じたインフラとプラットフォームの管理が重要であり、宣言的なインテントベースのメカニズムが求められる。さらに、デバイスのオンボーディング、水平スケーリングの制限、ベアメタル環境の管理など、独自の要件が存在する場合もある。プラットフォームレベルでは、Kubernetesや仮想化、さまざまなプラグインの導入や管理も重要な課題。
	アプリケーションの管理	エッジではアプリケーションの数やインスタンスの数が非常に多く、宣言的な配置や構成意図、クローズドループによるサービス保証の自動化、複数のアプリケーションインスタンスにまたがる管理ビューの集約など、さまざまな自動化が求められる。また、アプリケーションにはリアルタイム性が求められることもあり、アプリケーションとインフラ／プラットフォーム（GPU、DPU、FPGA、CPUアーキテクチャ、カーネル最適化、Kubernetesプラグインの使用など）の連携は、クラウドアプリケーションよりも密になる可能性がある。言い換えれば、アプリケーションのオーケストレーションが、その下のインフラ／プラットフォームのオーケストレーションを誘発する可能性がある。
Spanning		アプリケーションは1つの場所に存在するのではなく、地理的、レイテンシー、障害ドメインの境界をまたぐことができる。実際、エッジアプリケーションは、パブリッククラウドや集中型のプライベートクラウドにもまたがることがある。
リソース使用効率の最適化		エッジコンピューティングのリソースは制約があるため、アプリケーションは継続的にリソースの使用量を最適化する必要がある。例えば、オンデマンドでアプリケーションをロールアウトしたり、停止させたりするケース、配置と可用性を考慮して、アプリケーションの移行と複製を行うケース、また、1日のうちで異なる時間帯に異なるワークロードを実行するケースがあり得る。
アプリケーションはポータブルで再利用可能（制限あり）		抽象化レイヤーの目的は、ベンダーニュートラルなPaaSを通じて、インフラやプラットフォームにとらわれないポータビリティを提供することにある。しかし、エッジネイティブでは、ローカルリソースやハードウェアプラットフォーム、セキュリティ、モバイルネットワーク、その他を考慮する必要があるため、アプリケーションがローカルの構成の違いに適応するための設定オプションが必要となる。