당신의 모바일 앱은 로컬 테스트에서 잘 작동하고 있다. 런던의 사용자는 앱을 열면 모든 것이 빠르다. 도쿄의 사용자는 동일한 버전을 열면 시작 시간이 느려지고 업데이트가 너무 오래 걸리고 일부 콘텐츠가 지연되는 것 같다. 당신은 한 지역을 다른 지역과 다르게 변경하지 않았습니다. 차이점은 거리입니다.
개발자들은 왜 "에지 네트워크"라는 용어를 물어본다. 개발자들은 새로운 단어를 원하지 않기 때문에, 글로벌 앱은 요청, 자산 및 업데이트를 한 곳으로 보내야 한다는 제한을 드러내는 것을 원한다.모바일 팀에게는 릴리스 시점에 이러한 제한이 아플 수 있다. 자바스크립트修정, 업데이트 된 복사본 또는 작은 자산 변경이 필요하다. 일부 사용자는 빠르게 받는다. 다른 사용자는 기다리거나 다시 시도하거나 타임아웃을 맞출 수 있다. 사용자의 위치와 요청이 어디까지 가야 하는지에 따라.
Edge 네트워킹은 이러한 간격을 줄이는 것을 목표로 한다.
Table of Contents
- 런던에서 빠르지만 도쿄에서 느린 앱이 왜 느린가
- 에지 네트워크의 핵심 아키텍처
- 엣지 네트워크 vs CDN vs 엣지 컴퓨팅
- 어플리케이션에 대한 주요 이점
- 실제 엣지 네트워크 사용 사례
- 엣지 전략을 구현하는 방법
London과 Tokyo에서 앱 속도 차이가 있는 이유는 무엇인가요?
London의 앱 아이콘을 탭한 사용자가 있습니다. 앱은 최신 설정을 확인하고 몇 가지 자산을 불러오며 계속 진행합니다. Tokyo의 사용자가 동일한 작업을 수행하지만, 요청이 인프라까지 더 먼 거리를 이동해야 하므로 느려집니다. 각 요청이 느려질 것처럼 느껴질지라도, 모바일 앱은 종종 연속으로 여러 요청을 보내게 됩니다. 사용자는 앱이 “랜덤하게 느려지는 것”처럼 느끼기 시작합니다.
The missing concept is __CAPGO_KEEP_0__. 네트워크 지연. Capgo를 사용하는 실무자에게 실용적인 리프레시를 원한다면 이 안내서를 참조하세요. 모바일 앱에서 네트워크 지연 앱 동작 개발자들이 디버깅할 수 있도록 바로 앱 행동과 연결합니다.
An 에지 네트워크 네트워크와 처리를 사용자의 위치에 더 가까운 곳으로 이동하여 해결한다. 사용자 위치에서 가까운 곳에서 요청을 처리하는 대신, 모든 장치가 한 곳에서 멀리 떨어진 원본과 통신하도록 강요하는 대신, 시스템은 근처의 위치에서 요청을 처리할 수 있다. 인텔은 지엠넷을 지리적으로 더 가까운 출처로 컴퓨팅, 저장 및 네트워킹 기능을 중앙 클라우드에서 이동하는 분산 아키텍처로 설명한다. 이로 인해 각 요청당 데이터가 이동해야 하는 거리를 줄여준다. 엣지 네트워크 아키텍처.
왜 이것이 더 중요한 이유
이것은 더 이상 특정한 인프라 구조가 아니다. 2025년까지, 중앙화된 데이터 센터나 클라우드 이외의 곳에서 생성되고 처리되는 기업 데이터의 75%가 생성되고 처리될 것으로 예상된다. 엣지 컴퓨팅 시장은 2023년 47.0억 달러에서 2031년 171.0억 달러로 성장할 것으로 예상된다.엣지 컴퓨팅 산업의 예측에 따르면 사용자들은 "아키텍처"를 경험하지 않는다. 그들은 지역에 따라 기다리는 시간, 다시 시도, 불일치하는 동작을 경험한다. 모바일 개발자에게, 이것은 단순한 규칙이다. 글로벌 사용자를 가진 앱이 있다면, 릴리스 시스템, 자산, 업데이트 경로도 글로벌하게 동작해야 한다. 그렇지 않으면, 앱은 사용자가 특정한 인프라 근처에 살고 있는 사람들만 빠르게 사용할 수 있다. __CAPGO_KEEP_0____CAPGO_KEEP_0__ __CAPGO_KEEP_0__.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
Edge 네트워크의 핵심 아키텍처
Edge 네트워크를 이해하는 가장 쉬운 방법은 서버에 대해 생각하지 않고 로지스틱스를 생각하는 것입니다.
전통적인 클라우드 설정은 중앙倉庫와 같습니다. 모든 것이 중앙倉庫에 존재합니다. 고객의 위치에 관계없이 모든 주문은 중앙倉庫에서 출발합니다.이것은 관리하기가 간단하지만, 고객이 대륙을跨하는 경우에는 이상적이지 않습니다.
Edge 네트워크는 중앙倉庫가 있지만, 고객이 가까운 곳에 있는 지역倉庫 또는 소매점과 같은 시스템과 같습니다. 중앙 클라우드와 근처의 출하점Edge 네트워크 아키텍처를 나타내는 다이어그램입니다. 중앙 데이터 센터, 에지 노드, 그리고 고객 장치가 있습니다.
Edge 네트워킹에서 이러한 지역 위치는 종종 "출하점"이라고 불립니다.
Edge 네트워크 아키텍처 Edge 네트워크 아키텍처또는 PoPs. 그들은 지리적으로 분산된 장소입니다. 여기서 트래픽은 언제나 코어 시스템에 도달하기 전에 수신, 처리, 보안, 그리고 때로는 캐시 될 수 있습니다.
모바일 앱의 경우, 일본의 사용자는 항상 유럽이나 북미에 있는 인프라를 기다리지 않아도 됩니다. 그들의 요청은 더 가까운 지점에서 네트워크에 들어와서 인터넷에서 더 많은 긴 여행을 해야하는지 여부를 결정하기 전에 처리 될 수 있습니다.
업데이트에도 중요합니다. 앱이 런치 시 새로운 웹 번들, 구성 파일, 또는 자산 패키지를 확인할 때, 추가 라운드 트립은 시작 동작에 나타납니다. 이 팀은 지역 테스트만 의존하지 않고 지역을 비교하기 위해 __CAPGO_KEEP_0__ 앱에 성능 모니터링을 설정하는 것이 유익합니다. performance monitoring in Capacitor apps 개발자 대부분에게 모델을 클릭하는 세 가지 조각이 있습니다.
캐싱은 자주 사용되는 콘텐츠를 근처에 저장합니다.
많은 사용자가 동일한 앱 자산이나 업데이트 패키지를 요청할 때, 에지 위치는 원본에서 매번 가져오지 않고 복사본을 준비할 수 있습니다.
- 라우팅은 사용자를 가장 근처의 입구로 보냅니다. Caching stores frequent content nearby.
- Routing sends users to the best nearby entry point. 이것은 교통 통제와 같습니다. 네트워크는 사용자가 더 가까운 경로가 존재할 때 길거나 혼잡한 경로로 사용자를 보내지 않도록 시도합니다.
- 지역 처리는 간단한 작업을 처리하기 전에 핵심 클라우드가 관여되도록합니다. 그것은 필터링, 인증 확인, 요청 처리 또는 데이터를 업스트림으로 이동하기 전에 준비하는 것과 같은 작업을 포함할 수 있습니다.
실용적인 규칙: 사용자가 많은 곳에서 동일한 것을 요청하는 경우, 그것이 한 곳에서 멀리 떨어진 원천에서 매번 요청할 필요가 없다면, 그럴 것입니다.
그것이 평소 영어로 “what is edge network”의 핵심 대답입니다. 그것은 사용자에게 일반 요청이 더 빠르게 완료되고 실패할 가능성이 적은 방식으로 네트워크 기능을 분산하여 사용자 경험에서 거리를 제거하는 것입니다.
클라우드는 사라지지 않습니다. 클라우드는 주로 창고가 되며, 에지 위치는 사용자 경험에서 거리를 제거하기 위해 가까운 매장으로 변합니다.
에지 네트워크 vs CDN vs 에지 컴퓨팅
이 세 가지 용어는 실 제품에서 겹쳐서 혼동되며, 그것이 이해할 수 있는 이유입니다.
개발자는 “에지 전달,” “에지 컴퓨팅,” 및 “글로벌 CDN”이 같은 것을 의미한다고 듣고 혼동을 일으키는 것입니다.
개발자가 혼동하는 곳
A CDN __CAPGO_KEEP_0__ 캐시하고 콘텐츠를 전달하는 이미지, 자바스크립트 파일, 스타일 시트, 비디오 세그먼트, 다운로드 가능한 자산과 같은 콘텐츠를 사용자에게 가까운 위치에서 가져옵니다.
에지 컴퓨팅 __CAPGO_KEEP_0__ 애플리케이션 로직이나 데이터 처리를 사용자 또는 장치 근처에서 실행하거나캐시된 파일만 저장하는 것과는 다릅니다.
에지 네트워크 __CAPGO_KEEP_0__ 이러한 패턴이 가능하도록 하는 underlying 분산 연결성 층입니다. Neos Networks는 주요 성능 효과를 '끝-to-끝 지연 시간이 낮아진다'라고 설명합니다., 그리고 그것을 설명하는 것은 에지 서버에서 데이터를 처리하기 전에 핵심 클라우드로 도달하기 전에 에지 네트워크가 지연敏감적인 워크로드를 처리할 수 있도록 하는 것입니다. 예를 들어, 실시간 분석 및 AI 추론과 같은 것들입니다. 에지 네트워크와 지연 감소에 대한 설명.
그 distinction은 앱 팀에 중요합니다:
- 이미지 또는 번들 전달이 더 빠르기를 원한다면, CDN-style 캐싱만 필요할 수 있습니다.
- 사용자에게 요청 처리 또는 결정이 가까운 곳에 있다면, 에지 컴퓨팅 영역에 들어가고 있습니다.
- 전체 경로가 지리적으로 더 가까우며 지연 시간이 낮다면, 에지 네트워크에 대해 이야기하고 있습니다.
릴리스 동작, 시작 경로 또는 요청 타이밍과 관련된 작업을 하는 경우, 앱 팀의 네트워크 성능에 대한 이 컬렉션의 기사들은 유용한 동반 주제입니다. Edge Network vs. CDN vs. Edge Computing at a Glance 속성
Edge Network
| Attribute | Edge Network | CDN (컨텐츠 전송 네트워크) | 엣지 컴퓨팅 |
|---|---|---|---|
| 기본 작업 | 사용자 및 장치에 가깝게 네트워크 기능을 이동 | 내용을 효율적으로 캐시하고 전달 | code 또는 사용자 또는 장치 근처에서 데이터를 처리하거나 |
| 일반적인 작업 부하 | 요청 라우팅, 트래픽 처리, 로컬 네트워크 서비스 | 정적 자산, 다운로드 가능한 파일, 미디어 전달 | API 논리, 필터링, 추론, 실시간 처리 |
| 작업이 발생하는 곳 | 사용자 근처에 분산된 여러 지점 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
애플리케이션을 위한 주요 이점
아키텍처가 클릭되면 이점이 더 쉽게 판단됩니다. '에지'라는 레이블을 구매하는 것이 아니라, 거리를 줄이고 불필요한 라운드 트립을 제거하고 네트워크가 완벽하지 않아도 앱이 사용 가능하도록 하는 방법을 선택합니다.
사용자가 느낄 수 있는 빠른 응답
IBM은 에지 네트워킹을 데이터 센터 처리에서 데이터 센터를 재배치하여 속도, 대역폭 및 신뢰성을 향상하고 지연 시간을 줄이는 데 도움이 되는 여러 컴퓨팅 작업을 에지 장치로 옮기는 것으로 설명합니다. IBM의 설명에서 하나의 예시가 다운로드 속도가 384 Kbps로 달성되는 것을 언급합니다. 이는 약 2에서 3배 빠른 속도입니다. 정규 네트워크보다 2에서 3배 빠른 속도IBM의 에지 네트워크가 속도를 개선하는 방법에 대한 설명 모바일 앱에서 사용자는 Kbps를 생각하지 않습니다. 그들은 순간을 생각합니다. 스플래시 화면이 더 빨리 사라집니다. 업데이트 확인이 불편한 기다림 없이 완료됩니다..
__CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- 앱은 약한 네트워크에서 더 안정적입니다.
- 지원 티켓이 쌓일 때까지 작은 핫픽스가 도착합니다.
팀이 사용 중인 경우 전체 스택 앱을 빠르게 배포하세요., 배달 속도는 개발자 워크플로우 문제도 아니고, 인프라 경로 문제도 함께 있다.
네트워크가 혼란스럽게 될 때 더 많은 강건성
분산 시스템은 한 경로나 위치가 문제가 될 때도 계속해서 트래픽을 제공할 수 있습니다. 실제로, 이는 사용자가 한 번에 모든 순간에 원격 출처가 도달할 수 있고 빠르고 혼잡하지 않아야 하는 것을 의존하지 않도록 합니다.
애플리케이션 팀에게는 출시 기간 및 인시던트 대응 시에 표시됩니다. 업데이트된 자산 또는 전 세계적으로 구성 파일을 배포해야 하는 경우 근처의 에지 위치가 사용자에게 더 빠른 시간 내에 필요한 것을 받을 수 있는 기회를 제공할 수 있습니다.
A good next step is to review your own __CAPGO_KEEP_0__. 애플리케이션 성능 최적화 체크리스트 네트워크 거리 문제가 아닌 code 문제의 부분을 표시하세요.
traffic을 더 가까운 곳에서 제어하는 보안 제어
Edge 네트워크는 또한 보안 태세를 개선할 수 있습니다. 필터링 및 강제가 traffic이 core 시스템에 도달하기 전에 더 가까운 곳에서 발생할 수 있기 때문입니다. 그로 인해 일부 불쾌한 traffic을 중단할 수 있습니다.
간단한 작업은 사용자 근처에 유지하고 sensitive한 원본 시스템은 직접 모든 요청을 처리하지 않도록 하세요.
Edge 네트워크가 앱을 마법처럼 안전하게 만드는 것은 아닙니다. 중앙 시스템의 폭파 반경을 줄이고 보호를 더 가까운 곳에 위치시키는 것을 의미합니다.
실제 Edge 네트워크 사용 사례
Edge 네트워킹을 구체화하는 가장 쉬운 방법은 사용자가 매일 사용하는 제품을 살펴보는 것입니다.
스트리밍과 게임은 아이디어를 쉽게 이해할 수 있도록 합니다.
비디오 스트리밍 플랫폼은 사용자가 재생을 시작할 수 있도록 빠르게 전달하기 위해 근처의 전달을 의존합니다. core 콘텐츠 라이브러리는 중앙화되어 있지만 인기 있는 콘텐츠는 사용자에게 더 가까운 곳에 분산됩니다.
온라인 게임도 유사한 문제를 가지고 다른 증상으로 나타납니다. 대신 버퍼링 대신에 지연, 반응 지연, 또는 불일치 멀티플레이어 동작을 경험합니다. 네트워크 경로가 더 멀수록 이러한 지연이 더 심해질 수 있습니다.
이러한 예는 도움이 됩니다. 비디오가 더 빠르게 시작되거나 게임이 더 반응적인 느낌을 받을 때 바로 느낄 수 있기 때문입니다.
모바일 앱 업데이트가 Edge 문제라는 이유
모바일 앱 업데이트는 더 이상 명확하지 않지만, 동일한 아키텍처 문제가 여전히 존재합니다.
앱이 라이브 업데이트를 확인하고, 변경된 웹 자산을 다운로드하고, 검증하고, 다음 런칭 시 적용할 때 업데이트 경로가 제품 품질의 일부가 됩니다. 사용자는 배포 크기, 네트워크 지리, 또는 원본 혼잡에서 발생한 지연을 구별하지 않습니다. 그들은 단지 필요한 때에修정이 도착하지 않았음을 알게 됩니다.
그런 이유로 에지 전달이 라이브 업데이트에 중요합니다. 글로벌로 분산된 업데이트 서비스는 변경된 배ंडल을 장치에 가깝게 가져가서 요청 경로가 짧고, 한 원본에 의존하지 않도록 할 수 있습니다.
실제 예시는 Capgo입니다. 이 서비스는 글로벌 에지 네트워크를 통해 CapacitorJS 및 Electron 앱의 라이브 업데이트를 제공하고, 팀이 서명된 웹 배ंडल, 목표 채널, 및 수정을 출시할 수 있도록 해줍니다. 앱 스토어 검토를 기다리지 않고. 팀이 제어된 롤아웃을 수행하는 경우, 사용자 구성을 기반으로 하는 실시간 업데이트를 pair할 수 있습니다.
이를 통해 모든 사용자에게 업데이트를 전송하는 대신, 업데이트를 한 번에 전송할 수 있습니다.
빠른_walkthrough를 통해 에지 전달이 릴리스 흐름에 어디에 위치하는지 시각화할 수 있습니다.
작은修정은 긴급하지만, 사용자에게 도달하는 네트워크 경로가 거의 그 자체보다 중요합니다.
그것은 개발자 중심의 대답입니다. 대부분의 일반적인 에지 기사에서 놓친점입니다. 에지 네트워크는 미래 지향적인 IoT 시나리오에만 국한되지 않습니다. 그들은 일반적인 모바일 문제를 해결합니다: 사용자에게 필요한 업데이트를 빠르게 전달하는 것입니다. 사용자가 어디에 있든지.
Edge 전략을 선택하는 것은 앱의 병목 현상에서부터 시작해야 합니다. 벤더의 마케팅보다는 앱의 병목 현상에서부터 시작해야 합니다. 주된 고통이 정적 자산 전송 속도가 느리다면 캐싱에 집중하는 접근법이 충분할 수 있습니다. 요청 지연, 지역 일관성, 또는 실시간 업데이트 신뢰성의 고통이 있다면 더 광범위한 Edge 설정이 필요할 수 있습니다.
Edge 제공업체를 선택하기 전에 평가해야 할 사항
작업을 수행하는 앱의 동작에 직접 매핑된 짧은 목록을 사용하십시오.
- 지리적 범위: Edge 제공업체는 사용자의 위치에 대한 보장을 해야 합니다. 단지 팀이 있는 곳에만 보장을 해야 하는 것은 아닙니다.
- traffic 처리: routing, caching, 및 delivery controls가 작업 부하에 맞춰야 합니다. 앱 자산, API 호출, 및 업데이트 배ंडल은 모두 동일한 방식으로 동작하지 않습니다.
- 보안 모델: Edge 제공업체는 접근 제어, 암호화, 규정 준수 요구 사항, 및 Edge-side 필터링을 어떻게 처리하는지 확인하십시오.
- 운영 관점: 로그, 메트릭, 및 충분한 관찰 가능성을 필요로 합니다. 한 지역이 다른 지역보다 느리게 작동하는 이유를 설명할 수 있어야 합니다.
- 개발자 워크플로우: 네트워크 설계의 단순한 것만큼 중요하다는 것을 인식하고 있습니다. API, CI/CD 통합, 롤백 제어, 버전 목표.
좋은 선택 절차는 몇 가지 구체적인 질문으로 시작해야 합니다.
- 가장 느린 사용자가 어디에 살고 있는지?
- 어플리케이션 시작 시 어떤 요청이 발생하는지?
- 어떤 요청을 안전하게 캐싱할 수 있을까요?
- 어떤 부분은 원본으로 돌아가야 하는지?
- 지역 배포 문제를 디버깅하는 방법은?
에지가 잘못된 답일 때
모든 어플리케이션이 분산 에지 인프라를 필요로 하지 않는다는 것을 인식하고 있습니다. Akamai는 "에지"라는 용어가 모호하다는 점을 지적하고 있습니다.그것은 실버 뷸릿이 아니다. 사용자 위치, 운영 복잡도 및 관리에 따라 비즈니스 케이스는 워크로드에 따라 다르며, 일부 애플리케이션의 레이턴시 향상이 관리하는 분산 아키텍처의 오버헤드를 정당화하지 못할 수 있다. Akamai의 에지 네트워크의 정의와 차이점에 대한 설명에서 다룬다. 어떤 것이 에지 네트워크이고 어떤 것이 아닌지.
실용적인 현실 체크.
애플리케이션이 좁은 지역의 사용자에게 서비스를 제공하거나, 시작 네트워크 활동이 적거나, 빠른 자산 및 업데이트 전달에 의존하지 않는 경우, 에지 네트워크는 충분한 보상 없이 복잡성을 추가할 수 있다. 더 많은 위치가 더 많은 움직이는 부분을 의미한다. 더 많은 움직이는 부분이 더 많은 캐시 동작, 배포 일관성, 보안 정책 및 모니터링에 대한 결정이 필요하다.
올바른 질문은 “모던 앱이 에지 네트워크를 사용해야 하는가?”가 아니라 “현재 사용자로부터 너무 멀리 떨어진 요청은 무엇이고, 거리를 줄이면 운영 비용을 감당할 수 있는가?”이다.
CapacitorJS 또는 Electron 앱을 배포하는 팀이 JavaScript, CSS, config, copy 또는 자산 수정을 앱 스토어 리뷰를 기다리지 않고 배포해야 하는 경우 Capgo 은 그 워크플로우를 위해 설계된 옵션입니다. signed web bundles, channel-based rollouts, rollback protection 및 edge delivery를 사용하여 팀이 다음 런칭 시 사용자에게 제어된 업데이트를 푸시할 수 있도록 도와줍니다.
