ローカル テストでは、モバイル アプリは問題なく動作しています。ロンドンでユーザーがアプリを開くと、すべてがスナップし、東京で同じバージョンを開くと、起動が遅く、更新が長く、コンテンツが遅延していることがユーザーから報告されます。アプリを 1 つの地域と他の地域で変更していません。違いは距離です。
その実際の理由は、開発者が次のように尋ねることです。 エッジ ネットワークとは何かエッジ ネットワークとは何か
グローバル アプリは、リクエスト、資産、更新を 1 つの遠い場所に送信することの限界を明らかにします。
モバイル チームにとって、このことはリリース時に痛感されます。JavaScript の修正、更新されたコピー、または小さなアセットの変更が必要です。ユーザーは早く受け取るか、遅延、リトライ、タイムアウトに遭遇します。エッジ ネットワークは、このギャップを減らすために存在します。
- 目次
- これが今より重要な理由
- エッジ ネットワーク vs CDN vs エッジ コンピューティング
- アプリケーションにとっての主な利点
- 現実世界のエッジ ネットワークの使用例
- エッジ ストラテジーを実装する方法
LondonとTokyoの間でアプリの速度が違う理由
Londonでアプリのアイコンをタップしたユーザーは、最新の設定を確認し、必要なアセットを取得し、続行します。東京で同じことを行うユーザーも同じことを行いますが、すべてのリクエストはユーザーのインフラストラクチャまでの距離が遠いので、さらに遅くなります。各リクエストが僅かに遅く感じられる場合でも、モバイルアプリは通常、連続して複数のリクエストを送信します。その時点でユーザーはアプリが「ランダムに遅い」と説明します。
欠けている概念は ネットワーク遅延。実用的なリフレッシュを求めている場合は、このガイド「モバイルアプリにおけるネットワーク遅延」を参照してください。 ネットワーク遅延 を直接アプリの動作と関連付けることができます。
エッジネットワーク はこの問題を解決するために、ユーザーがいる場所に近い位置にネットワーキングと処理を移動します。すべてのデバイスが遠くの起点に接続するのではなく、システムは近くの場所からリクエストを提供できます。インテルはエッジネットワークを、データが各リクエストごとに移動する距離を減らすように、コンピュート、ストレージ、ネットワーキング機能を中心のクラウドから地理的に近いポイントオブプレゼンスに移動する分布型アーキテクチャとして説明しています。 インテルのエッジネットワークアーキテクチャの概要 エッジネットワークアーキテクチャ.
これは今より大切な理由です
インフラはもうニッチなものではありません。この予測によると、2025年までに、 2025年、75%の企業生成データは、集中データセンターまたはクラウド外で作成および処理される、そしてエッジコンピューティング市場は2023年 $47.0億ドルから2031年まで to 、エッジコンピューティング産業のプロジェクションによるとユーザーは「アーキテクチャ」を経験しません。彼らは、待ち、リトライ、地域によって不一致な動作を経験します。 エッジコンピューティング産業の予測.
エッジネットワークの基本アーキテクチャ
to
2025年
エッジ ネットワークを理解する最も簡単な方法は、サーバーについて考えずに、物流について考え始めることです。
クラウドの伝統的なセットアップは、 中央倉庫のようになっています。
エッジ ネットワークはシステムのような エッジ ネットワークは、ローカルな倉庫や小売店
のシステムに似ています。
クラウドの中心と近くのポイント オブ プレゼンス エッジ ネットワークのアーキテクチャを示す図。中央データセンター、エッジ ノード、エンド ユーザ デバイスが含まれます。, or PoPs地理的に分散された場所です。 ここでは、トラフィックを受信、処理、セキュリティ、キャッシュすることができます。 これは、コアシステムに到達する前に発生する可能性があります。
モバイルアプリの場合、ユーザーは日本でいる必要はなく、ユーザーのリクエストは近い場所で受け取ることができます。 これにより、ユーザーはインターネット上で長い距離を移動する必要がなくなるため、待ち時間が短縮されます。
アップデートも同様です。 アプリが起動時に新しいWebバンドル、設定ファイル、またはアセットパッケージをチェックする場合、各ラウンドトリップが起動時の動作に影響を与えるため、チームはアップデートのパフォーマンスを監視することが推奨されます。 performance monitoring in Capacitor apps キャッシュ、ルーティング、ローカル処理
キャッシュは頻繁にアクセスされるコンテンツを近くの場所に保存します。
Three pieces make the model click for most developers:
- ルーティングはユーザーを最も近いエントリポイントに送信します。 ルーティングは、ユーザーが長い距離を移動するのではなく、近い距離を移動するようにします。 これは、トラフィックを制御するのと同じです。 ここでは、ユーザーが近い距離を移動するようにします。
- 処理は、ユーザーのリクエストを処理します。 これは、ユーザーのリクエストを処理するのと同じです。 __CAPGO_KEEP_0__アプリのパフォーマンスを監視することで、地域間の比較を行うのではなく、ローカルテストのみに頼るのではなく、地域間の比較を行うことができます。
- ローカル処理は、クラウドのコアが関与する前に、単純な作業を処理します。 そうした作業には、フィルタリング、認証チェック、リクエストの処理、またはデータをアップストリームに送る前にデータを準備することが含まれます。
実用的なルール: 同じものが、多くの場所からユーザーによって繰り返しリクエストされていれば、それを1つの遠いオリジンから毎回のリクエストごとに取得するべきではないでしょう。
「エッジ ネットワークとは何か」という質問の核心的な答えは、簡単に言えば、ユーザーに近い場所にネットワーク機能を分散して配置することで、共通のリクエストが速く完了し、失敗の可能性が少なくなることです。
クラウドは消えません。クラウドは主な倉庫になり、エッジの場所はユーザー体験から距離を取り除く近くの店舗になります。
エッジ ネットワーク vs CDN vs エッジ コンピューティング
これらの3つの用語は常に混同され、混乱は理解できることです。実際の製品では、オーバーラップが発生します。
開発者は、ベンダーが「エッジ デリバリー」、「エッジ コンピュート」、「グローバル CDN」といった用語を使用していることを聞きます。すべて同じもののように聞こえますが、実際には違います。
開発者が混同する場所
A CDN は通常、最も簡単な概念です。 その役割は主に、 コンテンツのキャッシュと配信 画像、JavaScriptファイル、スタイルシート、ビデオセグメント、ダウンロード可能なアセットなどの
エッジコンピューティング はより広い意味で、 ユーザーやデバイスの近くでアプリケーションロジックまたはデータ処理を実行することを意味します。ただし、キャッシュされたファイルをそこにのみ保存するのではなく、
エッジネットワーク は、これらのパターンを可能にする下位互換性のある分散接続性レイヤーです。 Neos Networksは、主なパフォーマンス効果を エンドツーエンドの遅延の低下 と説明し、エッジサーバーでデータを処理することで、エッジネットワークは、実時間分析やAI推論などのレイテンシーセンシティブワークロードを有効にすることを説明しています。エッジネットワーク エッジ ネットワークと遅延の削減.
その区別はアプリチームにとって重要です:
- 画像やバンドルの配信を高速化したい場合は、CDNスタイルのキャッシュが必要かもしれません。
- リクエストの処理やユーザーの近くで決定を下したい場合は、エッジコンピューティングの領域に入っています。
- 全体のパスが地理的に近く、低遅延である場合、エッジ ネットワークの話題です。
リリースの挙動、起動パス、リクエストのタイミングに関わる場合は、このアプリチーム向けの ネットワークパフォーマンスの記事のコレクション は有用な補足トピックです。
エッジ ネットワークとCDNとエッジコンピューティングの概要
| 属性 | エッジ ネットワーク | CDN (コンテンツ デリバリーネットワーク) | エッジコンピューティング |
|---|---|---|---|
| 主なタスク | ユーザーとデバイスに近い位置にネットワーク機能を移動する | コンテンツを効率的にキャッシュして配信する | code またはユーザーまたはデバイス近くのデータ処理を実行する |
| 典型的なワークロード | リクエストルーティング、トラフィックハンドリング、ローカルネットワークサービス | 静的アセット、ダウンロード可能なファイル、メディア配信 | API ロジック、フィルタリング、推論、リアルタイム処理 |
| 作業が行われる場所 | ユーザーに近い分散ポイント | キャッシュの分散位置 | エッジサーバーまたはソースの近くにあるデバイス |
| 最良の認識モデル | 近隣のエントリポイントと道路システム | 近くの棚にすでに人気のアイテムが並んでいる | 現地の労働者が現場でタスクを処理している |
| モバイル開発者が気づくこと | 全リクエストパスの全体的な遅延が低下 | アセットの読み込みとダウンロードが速くなる | 常にオリジンにアクセスすることなく、迅速な決定が可能になる |
CDNはエッジ戦略の一部になることができるが、自動的にアプリケーションがエッジコンピューティングを実行していることを意味するわけではない。
これでほとんどのアーキテクチャの議論が解決する。
アプリケーションにとっての主な利点
アーキテクチャが理解されると、メリットを判断するのが簡単になります。 "エッジ" というラベルを購入するのではなく、距離を短縮し、不要なループ回避、ネットワークが不完全な場合でもアプリの利用性を維持する方法を選択することです。
ユーザーは高速なレスポンスを感じる
IBMはエッジネットワーキングを、データセンターの処理からエッジデバイスに多くの計算タスクを移行することで、速度、帯域幅、信頼性を向上させ、遅延を削減することで説明しています。IBMの説明にあるように、1つのIBMの例ではダウンロード速度が384Kbpsに達し、 約2から3倍の速さ 通常のネットワークと比較して、IBMのエッジネットワーキングの説明にあるように、 エッジネットワークが速度を向上させる方法 モバイルアプリのユーザーはKbpsで考えません。彼らは次のようになります:.
スプラッシュスクリーンが早く消える
- アップデートチェックが不快な待ち時間なしで完了する
- 弱いネットワークでもアプリがより強固な感覚になる
- __CAPGO_KEEP_0__
- サポートチケットが大量に寄せられる前に、緊急修正が到着します。
チームが速くフルスタックアプリをリリースする場合 、速いリリースのために開発者ワークフローだけを考慮するのではなく、インフラストラクチャのパスも考慮する必要があります。ネットワークが混雑したときに、システムがより頑丈になる
ネットワークが混乱してもより強い耐性
リリースウィンドウやインシデント対応のときに、アプリチームにとっては、更新されたアセットや構成をグローバルに配布する必要がある場合、近くのエッジロケーションがユーザーに必要なものを取得するのに役立ちます。
エッジネットワークの利点を比較する表。パフォーマンスとセキュリティの3つの利点をリストしています。
パフォーマンス最適化チェックリスト を確認し、実際にネットワーク距離の問題である部分をマークする必要があります。 and mark the parts that are really network-distance problems rather than code problems.
トラフィックに近いセキュリティ制御
エッジ ネットワークは、フィルタリングと強制がトラフィックがコア システムに到達する前に行われるため、セキュリティ ポジションを向上させることもできます。 それが、不必要なトラフィックを停止するのに役立ちます。
シンプルな作業はユーザーに近く、敏感なソース システムはすべてのリクエストを直接処理しないようにしてください。
エッジ ネットワークは、単にアプリケーションをセキュアにするという魔法のようなものではありません。 それが、保護をパスに早く配置し、中央システムの爆発半径を減らすことを意味します。
実用的なエッジ ネットワークの使用例
エッジ ネットワークを具体化する最も簡単な方法は、人々が毎日使用している製品を調べることです。
ストリーミングとゲームは、この概念を簡単に理解できるようにします。
動画配信プラットフォームは、ユーザーがプレイバックを開始できるように近くの配信を依存しています。ユーザーが待つ時間を減らすため、ユーザーが待つ時間を減らすため、人気のコンテンツは視聴者に近いところに配信されます。
オンライン ゲームは、異なる症状を持つ類似の問題を持っています。バッファリングの代わりに、プレイヤーは遅延、遅延した反応、または不均等なマルチプレイヤー動作を感じます。ネットワーク パスが遠いと、遅延が感じられることがさらに悪化します。
その例は役立ちます。動画が早く開始したり、ゲームがより反応的な感じになったりすると、すぐにその利点を感じることができます。
モバイル アプリケーション アップデートは、より明確ではありませんが、同じアーキテクチャの問題が存在します。
モバイルアプリの更新は明らかではありませんが、同じアーキテクチャの問題は存在します。
アプリが live update をチェックし、変更されたウェブアセットをダウンロードし、検証し、次の起動時に適用すると、更新パスは製品の品質の一部になります。ユーザーは、バンドルサイズ、ネットワークの地理、または起源の混雑からどの遅延が生じたかを気にしません。彼らはただ、修正が必要な時には到着しなかったことを知っています。
エッジ配信はライブ更新のために重要です。グローバルに配布された更新サービスは、変更されたバンドルをデバイスに近づけることができ、リクエストパスは短くなり、起源に依存することが減ります。
実際の例は CapgoCapacitorJS と Electron アプリ向けのライブ更新をグローバル エッジ ネットワークを通じて提供し、チームが署名済みのウェブ バンドル、ターゲット チャネル、修正をアプリ ストアのレビューを待たずに公開できるようにします。制御されたロールアウトを実行するチームは、ユーザー セグメントを使用したリアルタイム更新と組み合わせて、すべてのユーザーに一度にリリースを送信するのを避けることができます。 リアルタイムの更新機能を使用したユーザー セグメント化 リリースフローでエッジ配信がどのように機能するかを視覚化するための簡単なウォークスルーがあります。
修正が小さくて緊急の場合、ユーザーに到達するまでのネットワークパスは、修正自体とほぼ同じくらい重要です。
エッジネットワークは、IoT の将来的なシナリオだけを解決するものではありません。エッジネットワークは、モバイルの日常的な問題を解決するために使用されます: どこにいても、正しい更新を正しいユーザーに迅速に送信することです。
エッジ戦略を実装する方法
context
エッジ戦略の選択は、まずアプリのボトルネックから始まります。 その主な痛みは静的アセットの配信が遅れている場合、キャッシュに焦点を当てたアプローチが十分かもしれません。 ただし、リクエストの遅延、地域間の不一致、またはライブアップデートの信頼性が主な痛みの場合、より広いエッジ設定が必要かもしれません。
エッジプロバイダを選択する前に評価すること
短縮リストを作成し、直接アプリの動作にマップします。
- 地理的範囲: ユーザーがいる地域でカバーしていることを確認してください。 ただし、チームがいる地域だけではありません。
- トラフィックハンドリング: ルーティング、キャッシュ、配信制御を検討し、ワークロードに合致するものを探します。 アプリアセット、API呼び出し、更新パッケージはすべて同じ動作をしないからです。
- セキュリティモデル: アクセス制御、暗号化、法的要件、エッジ側フィルタリングの取り扱いを確認してください。
- 運用可視性: ログ、メトリック、観察性が十分で、1つの地域が他の地域よりも遅い理由を説明できるようにする必要があります。
- 開発者ワークフロー: API、CI/CD統合、ロールバック制御、バージョン対象設定は、ネットワーク設計のrawさよりも重要です。
良い選択のプロセスは、以下の具体的な質問から始まります。
- 最も遅いユーザーがどの地域に住んでいますか?
- アプリ起動時に発生するリクエストはどれですか?
- どのリソースを安全にキャッシュできますか?
- どの部分は元の場所に戻る必要がありますか?
- 地域配信の問題をデバッグするにはどのようにしますか?
エッジが間違った答えである場合
すべてのアプリには、分散型エッジインフラが必要ではない場合があります。 アカマイは、「エッジ」という言葉が曖昧であると指摘しています。エッジは、 エッジ ネットワークは必ずしも銀の弾丸ではない. 企業のビジネスケースは、ワークロード、運用の複雑さ、ガバナンスに依存し、Akamaiのエッジ ネットワークとは何かというガイドエントリで説明されているように、管理する必要がある分散アーキテクチャのオーバーヘッドが、レイテンシーの低減の利点を上回る場合もある エッジ ネットワークとは何か、そしてそれではない.
実際のところ、それは役に立つチェックポイントである
あなたのアプリが狭い地理的範囲のユーザーにサービスを提供し、起動時のネットワークアクティビティが少ない、または高速なアセットと更新の配信に依存していない場合、エッジは複雑さを追加するだけで十分な報酬をもたらさない可能性がある。 さらに多くの場所が存在する場合、さらに多くの動作が必要になる。 さらに多くの動作が必要になる場合、キャッシュの動作、展開の一貫性、セキュリティ ポリシー、監視の決定が必要になる
正しい質問は、「ユーザーが現在どのリクエストが距離が遠いのか、それを減らすことで、運用コストを増やさないか」ということである
あなたのチームがCapacitorJSまたはElectronアプリを配信し、JavaScript、CSS、config、コピー、またはアセットの修正を待たずにユーザーに配信する必要がある場合、 Capgo コンテキスト: HTMLテキストのフラグメント (親キー `submitting_a_pr_to_capgo` の中の Capgo UI の長い文字列)。ページ/エリア: Capgo マーケティング ウェブサイト。役割: ウェブサイト コピー文。見られる場所: contributing.astro
