당신의 모바일 앱은 로컬 테스트에서 잘 작동하고 있습니다. 런던의 사용자는 그것을 열고 모든 것이 빠르다고 느끼고 있습니다. 도쿄의 사용자는 동일한 버전을 열었을 때 시작 시간이 느리고 업데이트가 너무 오래 걸리고 일부 콘텐츠가 지연된 것처럼 느껴집니다. 당신은 한 지역과 다른 지역을 위해 앱을 변경하지 않았습니다. 차이점은 거리입니다.
개발자들은 그 이유로 Edge 네트워크가 무엇인가?를 물어보게 됩니다.
그것은 새로운 buzzword를 원하는 것이 아니라, 전 세계 앱이 요청, 자산 및 업데이트를 한 곳으로 보내야 한다는 제한을 드러내는 것입니다.
모바일 팀에게는 릴리스 시에 이것이 고통스럽게 드러납니다. 자바스크립트修正, 업데이트 된 복사본 또는 작은 자산 변경이 필요합니다. 일부 사용자는 빠르게 받습니다. 다른 사용자는 기다리거나 다시 시도하거나 타임아웃을 맞출 수 있습니다. 사용자의 위치와 요청이 여행해야 하는 거리에 따라.
- Edge 네트워킹은 그 간격을 줄이기 위해 존재합니다.
- 런던에서 빠르지만 도쿄에서 느린 앱이 왜 느린가요
- Edge 네트워크 vs CDN vs Edge 컴퓨팅
- 어플리케이션에 대한 주요 이점
- 실제 Edge 네트워크 사용 사례
- Edge 전략을 구현하는 방법
어플리케이션은 런던에서 빠르지만 도쿄에서 느린 이유는 무엇인가요?
사용자가 런던에서 앱 아이콘을 탭합니다. 앱은 최신 설정을 확인하고 몇 가지 자산을 다운받아 계속 진행합니다. 사용자가 도쿄에서 같은 일을 하더라도 요청이 인프라까지 더 먼 거리를 이동해야 하므로, 요청이 느려질 수 있습니다. 각 요청이 느려질 것처럼 느껴질지라도, 모바일 앱은 종종 연속으로 여러 요청을 보내게 됩니다. 사용자는 앱이 "랜덤하게 느려지는 것"처럼 느끼게 됩니다.
The missing concept is 네트워크 지연이 가이드는 Edge Network의 개념을 다시 한번 이해하는 데 도움이 될 것입니다. 모바일 앱에서 네트워크 지연 애플리케이션 동작을 개발자들이 디버그하는 데 직접적으로 연결합니다.
An 에지 네트워크 네트워크 에지로 해결한다. 이는 사용자가 있는 곳에 네트워킹과 처리를 더 가깝게 이동하여, 모든 장치가 한 곳의 원격 출처와 대화하는 대신, 가까운 위치에서 요청을 처리할 수 있도록 한다. 인텔은 에지 네트워크를 중앙 클라우드에서 지리적으로 더 가까운 출현 지점으로 컴퓨팅, 저장, 네트워킹 기능을 이동하는 분산 아키텍처로 설명한다. 이로써 각 요청에 대한 데이터가 이동해야 하는 거리를 줄여준다. 에지 네트워크 아키텍처.
이것은 더 중요한 이유입니다.
이것은 더 이상 특수한 인프라가 아닙니다. 하나의 예측은 2023년까지 이 숫자가 4조에 이를 것으로 예상합니다. 그리고 에지 컴퓨팅 시장은 2023년 47.0억 달러에서 2031년까지 171.0억 달러까지 성장할 것으로 예상됩니다.에지 컴퓨팅 산업의 예측에 따르면 사용자는 '아키텍처'를 경험하지 않습니다. 그들은 지역에 따라 기다리는, 다시 시도하는, 불일치하는 동작을 경험합니다. to 에지 네트워크의 핵심 아키텍처2025년까지 75%의 기업이 생성하고 처리하는 데이터가 중앙 데이터 센터나 클라우드 외부에서 생성되고 처리될 것이라고 예상됩니다. 에지 컴퓨팅 산업 예측.
에지 컴퓨팅 산업의 예측에 따르면
사용자는 '아키텍처'를 경험하지 않습니다. 그들은 지역에 따라 기다리는, 다시 시도하는, 불일치하는 동작을 경험합니다.
에지 네트워크의 핵심 아키텍처
Edge 네트워크를 이해하는 가장 쉬운 방법은 서버에 대해 생각하지 않고 로지스틱스에 대해 생각하는 것입니다.
클라우드 환경의 전통적인 설정은 중앙倉庫와 같습니다. 모든 것이 하나의 주된 창고에 존재합니다.고객이 어디에 있든지, 모든 주문은 그 위치에서 출발합니다.
관리하기가 간단하지만, 고객이 대륙을 가로지르는 경우에는 이상적이지 않습니다. 지점 창고 또는 소매점중앙 클라우드와 근처의 접근점
Edge 네트워크 아키텍처를 나타내는 다이어그램. 중앙 데이터 센터, 에지 노드, 그리고 사용자 장치가 있습니다.
Edge 네트워크의 이점 Edge 네트워크는 중앙 클라우드보다 빠른 속도와 더 나은 성능을 제공합니다., or PoPs그들은 지리적으로 분산된 장소입니다. 여기서 트래픽은 수신, 처리, 보안 및 때로는 캐시되기 전에 코어 시스템에 도달하기 전에 수신됩니다.
모바일 앱의 경우, 사용자는 일본에서 항상 유럽이나 북미의 인프라를 기다리지 않아도 됩니다. 요청은 더 가까운 지점에서 네트워크에 들어가고 길고 긴 인터넷 여행을 하는 횟수를 줄일 수 있습니다.
업데이트에도 중요합니다. 앱이 런칭 시 새로운 웹 번들, 구성 파일 또는 자산 패키지를 확인할 때, 추가 라운드 트립은 시작 동작에 나타납니다. 이 팀은 지역 테스트만 의존하지 않고 대신 지역을 비교할 수 있도록 __CAPGO_KEEP_0__ 앱에 성능 모니터링을 설정하는 것이 일반적입니다. Capacitor 앱의 성능 모니터링 개발자 대부분이 모델을 이해하는 세 가지 조각이 있습니다:
캐싱은 자주 요청되는 콘텐츠를 근처에 저장합니다.
많은 사용자가 동일한 앱 자산 또는 업데이트 패키지를 요청할 때, 에지 위치는 매번 원본에서 가져오지 않고 복사본을 준비할 수 있습니다.
- 라우팅은 사용자를 가장 가까운 입구로 보냅니다. 이것은 교통 제어와 같습니다. 네트워크는 사용자가 더 긴 또는 혼잡한 경로를 피할 수 있도록 더 가까운 경로가 존재할 때 사용자를 보냅니다.
- performance monitoring performance monitoring
- Local processing은 간단한 작업을 처리하기 전에 핵심 클라우드가 관여되기 전에 처리합니다. 그것은 필터링, 인증 확인, 요청 처리 또는 데이터를 업스트림으로 이동하기 전에 준비하는 것을 포함할 수 있습니다.
실용적인 규칙: 사용자가 많은 곳에서 동일한 것을 반복적으로 요청하는 경우, 그것이 한 곳에서 멀리 떨어진 원천에서 단일 요청마다 가져올 필요가 없을 가능성이 높습니다.
plain English에서 “what is edge network”의 핵심 대답입니다. 그것은 사용자 경험에서 일반적인 요청이 더 빠르게 완료되고 실패할 가능성이 적게 되도록 네트워크 기능을 분산된 방식으로 사용자에게 더 가까운 곳에 위치시키는 것입니다.
클라우드가 사라지지 않습니다. 클라우드는 주로 창고가 되며, 에지 위치는 사용자 경험에서 거리를 제거하는 근처의 매장으로 변합니다.
에지 네트워크 vs CDN vs 에지 컴퓨팅
이 세 가지 용어는 끊임없이 혼동되며, 혼동은 실제 제품에서 겹치는 부분이 있기 때문에 이해할 수 있습니다.
개발자는 “에지 전달”, “에지 컴퓨팅”, “글로벌 CDN”이라는 용어를 듣고 모든 것이 동일한 것처럼 들리지만, 그것은 아닙니다.
개발자가 혼동하는 곳
A CDN 일반적으로 가장 쉬운 개념입니다. 그 역할은 주로 사용자에게 가장 가까운 위치에 있는 곳에서 콘텐츠를 캐시하고 전달하는 것입니다. 캐시하고 콘텐츠를 전달하는 것입니다. 이미지, 자바스크립트 파일, 스타일 시트, 비디오 세그먼트 및 다운로드 가능한 자산과 같은 콘텐츠를 사용자에게 가장 가까운 위치에서 가져옵니다.
에지 컴퓨팅 보다 광범위합니다. 그것은 사용자 또는 장치 근처에서 애플리케이션 로직 또는 데이터 처리를 수행하는 것을 의미합니다.캐시된 파일만 저장하는 것이 아니라.
그것은 에지 네트워크 이 패턴을 가능하게 하는 underlying 분산 연결성 layer입니다. Neos Networks는 주요 성능 효과를 끝까지의 지연 시간이 낮아진다.라고 설명하고, 에지 서버에서 데이터를 처리하기 전에 핵심 클라우드로 데이터를 전달함으로써, 에지 네트워크는 지연 시간이 민감한 작업負荷을 지원할 수 있습니다. 예를 들어, 실시간 분석 및 AI 추론을 설명하는 Neos Networks의 설명에서. 에지 네트워킹 및 지연 감소.
그 distinction은 앱 팀에 중요합니다:
- 이미지 또는 번들 전달을 더 빠르게 원한다면, CDN-style 캐싱만 필요할 수 있습니다.
- 사용자 근처에서 요청 처리 또는 결정을 원한다면, 에지 컴퓨팅 영역에 들어가고 있습니다.
- 전체 경로가 지리적으로 더 가까운 저주파를 원한다면, 에지 네트워킹에 대해 이야기하고 있습니다.
릴리스 동작, 시작 경로 또는 요청 타이밍에 작업한다면, 이 앱 팀에 대한 네트워크 성능에 대한 이 컬렉션의 기사 네트워크 성능에 대한 앱 팀 에지 네트워크 vs. CDN vs. 에지 컴퓨팅 at a Glance
속성
| 에지 네트워크 | CDN (콘텐츠 전달 네트워크) | 속성 | 에지 컴퓨팅 |
|---|---|---|---|
| 기본 작업 | 사용자와 장치 근처에 네트워크 기능을 더 가까이 이동 | 내용을 효율적으로 캐시하고 전달 | code 또는 사용자 또는 장치 근처에서 데이터를 처리하거나 |
| 일반적인 작업 부하 | 요청 라우팅, 트래픽 처리, 지역 네트워크 서비스 | 정적 자산, 다운로드 가능한 파일, 미디어 전달 | API 논리, 필터링, 추론, 실시간 처리 |
| 작업이 발생하는 곳 | 사용자 근처의 분산된 지점 | 사용자 근처의 분산 캐시 위치 | Edge 서버나 장치 근처의 원천 |
| 최상의 인지 모델 | 도로 시스템과 근처의 입구 | 지구에 있는 인기 있는 항목이 이미 보관된 지역 매장 | 지구에 있는 현장에서 작업을 처리하는 지역 근로자 |
| 모바일 개발자가 주목하는 것 | 전체 요청 경로에서 낮은 지연 | 빠른 자산 로드 및 다운로드 | 원본을 항상 호출하지 않고도 빠른 결정을 내릴 수 있습니다. |
CDN은 에지 전략의 일부일 수 있지만, 자동으로 앱이 에지 컴퓨팅을 수행하는 것은 아님을 의미합니다.
이 한 문장은 대부분의 아키텍처 논쟁을 해결합니다.
애플리케이션에 대한 주요 이점
아키텍처가 클릭되면 이익이 더 쉽게 판단됩니다. '에지'를 '라벨'로 구매하는 것이 아니라, 거리를 줄이고 불필요한 라운드 트립을 제거하고 네트워크가 완벽하지 않아도 앱이 사용 가능하도록 하는 방법을 선택하는 것입니다.
사용자가 느끼는 빠른 응답
IBM은 에지 네트워킹을 데이터 센터 처리에서 Edge 장치로 많은 컴퓨팅 작업을 재배치함으로써 속도, 대역폭 및 신뢰성을 향상시키고 지연 시간을 줄이는 것으로 설명합니다. IBM의 설명에서 에지 네트워크가 속도를 향상시키는 방법에 대한 IBM 예시 중 하나는 다운로드 속도가 384 Kbps또는 약 2에서 3배 빠른 정규 네트워크와 비교하여 해당 시나리오에서 모바일 앱의 사용자는 Kbps를 생각하지 않습니다. 그들은 순간을 생각합니다:.
스플래시 화면이 더 빨리 사라집니다.
- 업데이트 확인이 불편한 기다림 없이 완료됩니다.
- 앱이 약한 네트워크에서 더 약하지 않습니다.
- 속도 향상에 대한 IBM의 설명
- 작업 티켓이 쌓일 때 작은 핫픽스가 먼저 도착합니다.
만약 팀이 빠르게 전체 스택 앱을 배포하려면 , 그것은 개발자 워크플로우 문제가 아니라 인프라 경로 문제이기도 합니다.
네트워크가 복잡해질 때 더 많은 내구성을 유지합니다.
분산 시스템은 하나의 경로나 위치가 문제가 될 때도 트래픽을 계속 제공할 수 있습니다. 실제로, 사용자는 한 순간에 원격 오리진이 항상 도달할 수 있고 빠르고 혼잡하지 않아야 하는 것은 아닙니다.
앱 팀에게는 이게 릴리스 창과 인시던트 리스폰스 중에 나타납니다. 만약 글로벌로 업데이트된 자산이나 구성 파일을 배포해야 한다면 근처의 에지 위치가 사용자가 원하는 것을 얻을 수 있는 기회를 더 많이 제공합니다. 에지 위치는 사용자가 원하는 것을 얻을 수 있는 기회를 더 많이 제공합니다.
좋은 다음 단계는 자신의 앱 성능 최적화 체크리스트 네트워크 거리 문제가 아닌 code 문제를 식별하고 표시하세요.
__CAPGO_KEEP_0__ 문제가 아닌 것을 표시하는 것입니다.
Edge 네트워크는 보안 태세를 향상시킬 수 있습니다. 필터링 및 강제가 트래픽이 시스템의 핵심에 도달하기 전에 발생할 수 있기 때문입니다. 따라서 일부 불필요한 트래픽을 중단할 수 있습니다.
사용자 근처의 단순한 작업을 유지하고 sensitive한 원본 시스템이 모든 요청을 직접 처리하지 않도록 유지하세요.
Edge 네트워킹이 앱을 마법처럼 안전하게 만드는 것은 아닙니다. 중앙 시스템의 폭파 반경을 줄이고 보호를 더 앞서서 보호할 수 있기 때문에 보호를 더 앞서서 할 수 있습니다.
실제 Edge 네트워크 사용 사례
Edge 네트워킹을 구체화하는 가장 쉬운 방법은 사용자가 매일 사용하는 제품을 살펴보는 것입니다.
스트리밍 및 게임은 이 아이디어를 쉽게 이해할 수 있도록 합니다.
비디오 스트리밍 플랫폼은 사용자가 빠르게 시작할 수 있도록 근처의 전달을 의존합니다. 사용자가 버퍼링을 피하고 싶하기 때문입니다. 콘텐츠 라이브러리는 중앙에 있지만 인기 있는 콘텐츠는 사용자 근처에 분산됩니다.
온라인 게임도 유사한 문제를 가지고 있습니다. 버퍼링 대신 지연, 반응 지연, 또는 불일치한 멀티플레이어 동작이 있습니다. 네트워크 경로가 더 멀면 이러한 지연이 더 심해질 수 있습니다.
이러한 예는 왜 이러한 예가 도움이 되는지 이해할 수 있도록 합니다. 비디오가 더 빠르게 시작되거나 게임이 더 반응적으로 느껴질 때 즉시 이점을 느낄 수 있기 때문입니다.
모바일 앱 업데이트는 더 명확하지 않지만 동일한 아키텍처 문제가 있습니다.
모바일 앱 업데이트는 더 명확하지 않지만 동일한 아키텍처 문제가 존재합니다.
앱이 live update을 확인하고 변경된 웹 자산을 다운로드하여 검증한 후 다음 런칭 시 적용할 때, 업데이트 경로가 제품 품질의 일부가 됩니다. 사용자는 배포 크기, 네트워크 지리, 또는 원본 혼잡으로 인한 지연이 무엇인지 신경 쓰지 않습니다. 그들은 단지 필요한 때에 수정이 도착하지 않았음을 알 뿐입니다.
그런 이유로 에지 전송이 라이브 업데이트에 중요합니다. 글로벌로 분산된 업데이트 서비스는 변경된 배포를 장치에 가깝게 가져가서 요청 경로가 짧아지고 하나의 원본에 의존하지 않도록 할 수 있습니다.
실제 예시로 Capgo은 Capgo로 PR을 제출하는 동안 사용하는 UI 문자열의 일부입니다. Capgo 마케팅 웹사이트의 페이지/영역: Capgo 마케팅 웹사이트. 역할: 웹사이트 복사본. 표시되는 곳: contributing.astro 페이지. Capgo 제품/브랜드 및 개발자 용어를 정확하게 유지합니다. 사용자 세그멘테이션을 기반으로 하는 실시간 업데이트 실시간 업데이트
를 pair할 수 있습니다. 이를 통해 모든 사용자에게 한 번에 모든 릴리스를 보내지 않고 릴리스를 피할 수 있습니다.
빠른_walkthrough를 통해 릴리스 흐름에서 에지 전송이 어디에 위치하는지 시각화할 수 있습니다:
수정 크기가 작지만 긴급한 경우, 사용자에게 도달하는 네트워크 경로가 수정 자체만큼 중요합니다.
에지 네트워크 전략 구현 방법
어떤 에지 전략을 선택할지 결정하는 것은 앱의 병목 현상에서부터 시작해야 합니다. 벤더 마케팅보다는 앱의 병목 현상에 따라 선택해야 합니다. 주된 고통이 정적 자산 전달 속도가 느리다면 캐싱에 집중하는 접근법이 충분할 수 있습니다. 그러나 요청 지연, 지역 일관성, 또는 라이브 업데이트 신뢰성의 문제가 있다면 더 광범위한 에지 설정이 필요할 수 있습니다.
어떤 제공자를 선택하기 전에 평가해야 할 사항
에지 네트워크 제공자를 선택하는 데 필요한 5가지 고려 사항을 나열한 인포그래픽입니다.
- 사용자 행동에 직접 매핑된 짧은 목록을 사용하십시오: 지리적 범위:
- 사용자들이 있는 곳에서 제공자가 커버리지가 있어야 합니다. 단지 팀이 있는 곳만 커버리지가 있어야 하는 것은 아닙니다. 네트워크 Edge의 특징을 찾으세요. 라우팅, 캐싱, 전달 제어를 찾으세요. 앱 자산, API 호출, 업데이트 패키지 모두 동일한 동작을 하지 않습니다.
- routing, caching, delivery controls가 앱의 작업 부하와 일치하는 것을 찾으십시오. 앱 자산, __CAPGO_KEEP_0__ 호출, 업데이트 번들 등은 모두 동일한 방식으로 작동하지 않습니다. 보안 모델:
- 액세스 제어, 암호화, 규정 준수 요구 사항, 에지 사이드 필터링이 어떻게 처리되는지 확인하십시오. 운영 관점:
- 개발자 워크플로우: API, CI/CD 통합, 롤백 제어 및 버전 목표는 네트워크 설계의 raw 것만큼 중요합니다.
좋은 선택 절차는 몇 가지 구체적인 질문으로 시작해야 합니다.
- 어떤 사용자가 느린 속도로 사용하는지 어디에 살고 있는지?
- 어플리케이션 시작 시 어떤 요청이 발생하는지?
- 어떤 것을 안전하게 캐시할 수 있는지?
- 어떤 부분이 원본으로 돌아가야 하는지?
- 지역적 배포 문제를 디버깅하는 방법은?
에지가 잘못된 답일 때
모든 앱이 분산된 에지 인프라를 필요로 하지 않는다는 점을 주의해야 합니다. 에지의 의미가 모호하다는 점을 주의해야 합니다. 실질적인 해결책이 아님. 비즈니스 케이스는 작업負荷, 운영 복잡성 및 관리에 따라 달라지며, 일부 애플리케이션의 경우 지연 시간의 이익이 관리하는 분산 아키텍처의 부하를 정당화하지 못할 수 있습니다. Akamai의 Edge Network에 대한 설명서에서 다루고 있습니다. Edge Network이 무엇이고 무엇이 아닌지.
그것은 유용한 현실 확인입니다.
앱이 좁은 지리적 대상 audience를 제공하거나 시작 네트워크 활동이 적거나 빠른 자산 및 업데이트 전달에 의존하지 않는 경우 Edge는 충분한 보상 없이 복잡성을 추가할 수 있습니다. 더 많은 위치가 더 많은 움직이는 부분을 의미합니다. 더 많은 움직이는 부분이 더 많은 캐시 동작, 배포 일관성, 보안 정책 및 모니터링에 대한 결정이 필요합니다.
올바른 질문은 'Edge를 사용해야 하나?'가 아니라 '현재 사용자로부터 너무 멀리 떨어진 요청이 몇 개이고, 거리를 줄이면 운영 비용이 가치 있는가?'입니다.
CapacitorJS 또는 Electron 앱을 배포하는 팀이 JavaScript, CSS, config, copy 또는 자산 수정을 앱 스토어 리뷰를 기다리지 않고 배포해야 하는 경우 Capgo 컨텍스트: Capgo UI의 더 긴 문자열에서 HTML 텍스트 프래그먼트 (부모 키 `submitting_a_pr_to_capgo`). 페이지/영역: Capgo 마케팅 웹사이트. 역할: 웹사이트 복사본. Seen in: contributing.astro. Capgo 제품/브랜드 및 개발자 용어를 정확하게 유지하십시오.
