개발자라면 앱이 로컬 테스트에서 잘 작동하는 것을 알고 있을 것입니다. 런던의 사용자들은 앱을 열어 모든 것이 빠르게 느껴집니다. 도쿄의 사용자들은 동일한 버전을 열어 시작 시간이 느려지고 업데이트가 너무 오래 걸리고 일부 콘텐츠가 지연되는 것을 알게 됩니다. 개발자는 한 지역과 다른 지역을 변경하지 않았습니다. 차이점은 거리입니다.
개발자가 종종 묻는 실제적인 이유입니다. 에지 네트워크는 무엇인가?. 이는 모든 요청, 자산 및 업데이트 를 한 곳으로부터 다시 보내야 한다는 것을 노출시키기 때문입니다.
모바일 팀에서 릴리스 시에 이는 매우 아프게 느껴집니다. 자바스크립트修정을 푸시하거나, 업데이트 된 복사본 또는 작은 자산 변경을 해야 할 때입니다. 사용자들은 빠르게 받거나, 기다리거나, 다시 시도하거나, 타임아웃을 맞출 수 있습니다. 사용자의 위치와 요청이 얼마나 먼지에 따라 다릅니다. 에지 네트워킹은 이러한 간격을 줄이기 위해 존재합니다.
목차
- 왜 런던에서 빠르지만 도쿄에서 느린 앱이 있는가?
- 에지 네트워크의 핵심 아키텍처
- 개발자들이 혼동하는 에지 네트워크, CDN, 에지 컴퓨팅
- 어플리케이션에 대한 주요 이점
- 실제 Edge 네트워크 사용 사례
- Edge 전략을 implement하는 방법
왜 런던에서 앱이 빠르지만 도쿄에서는 느리다
런던에서 사용자가 앱 아이콘을 탭합니다. 앱은 최신 설정을 확인하고 몇 가지 자산을 가져와 계속합니다. 도쿄에서 사용자가 같은 작업을 수행하지만 모든 요청이 인프라까지 더 먼 거리를 이동해야 합니다. 각 요청이 느려질 것처럼 느껴지더라도 모바일 앱은 종종 연속으로 여러 요청을 수행합니다. 그때 사용자가 앱이 '무작위로 느려진다'라고 설명하기 시작합니다.
이것은 누락된 개념입니다. 네트워크 지연. 만약 실용적인 리프레시를 원한다면, 이 가이드는 모바일 앱에서 네트워크 지연 앱 동작을 디버깅하는 개발자와 직접 연결합니다.
An 엣지 네트워크 이것을 해결하기 위해 네트워크와 처리를 사용자 위치에 가깝게 이동시킵니다. 대신 모든 장치를 한 곳에서만 통신하게 하는 대신, 시스템은 근처의 위치에서 요청을 처리할 수 있습니다. 인텔은 엣지 네트워크를 엣지 네트워크 아키텍처.
Intel의 설명에서처럼, 중앙 클라우드에서 중앙 클라우드에 있는 컴퓨팅, 스토리지 및 네트워킹 기능을 지리적으로 더 가까운 지점으로 이동하는 분산 아키텍처라고 설명합니다.
왜 이것이 더 중요한 이유 이것은 더 이상 특수한 인프라가 아닙니다. 2025년까지, 중앙 데이터 센터나 클라우드 밖에서 생성되고 처리되는 기업 데이터의 75%가 생성될 것이라고 예상됩니다.그리고 2023년 현재 에지 컴퓨팅 시장은 47.0억 달러에서 2023년 47.0억 달러에서 까지 2031년까지 171.0억 달러로 성장할 것으로 예상됩니다.에지 컴퓨팅 산업의 예측에 따르면 사용자는 '구조'를 경험하지 않습니다. 그들은 대기, 다시 시도, 지역에 따라 불일치하는 동작을 경험합니다..
모바일 개발자에게, 이것은 단순한 규칙으로 번역됩니다. 만약 앱이 전 세계 사용자를 대상으로 한다면, 릴리즈 시스템, 자산, 업데이트 경로도 전 세계적으로 동작해야 합니다. 그렇지 않으면, 앱은 사용자가 인프라 근처에 살고 있는 사람들만 빠르게 사용할 수 있습니다.
에지 네트워크의 핵심 구조
에지 네트워크를 이해하는 가장 쉬운 방법은 서버에 대해 생각하지 않고 로지스틱스에 대해 생각하는 것입니다.
기존 클라우드 설정은 중앙倉庫와 같이 작동합니다.
그것은 물류를 전달하고, 물류를 전달하고, 물류를 전달하는 것과 같습니다. 물류를 전달하는 것은 물류를 전달하는 것과 같습니다.모든 것이 하나의 주된 창고에 살고 있습니다. 고객이 어디에 있든지, 모든 주문은 그 위치에서 출발합니다. 그게 관리하기가 간단하지만, 고객이 대륙을 가로지르는 곳에 퍼져 있다면 ideal하지 않습니다.
에지 네트워크는 더 많은 지역 창고나 소매점과 같은 시스템과 같습니다. 주된 창고는 여전히 존재하지만, 일반적인 아이템과 일부 지역 운영은 고객 가까이에 위치합니다.중앙 클라우드와 근처의 접근점
에지 네트워크 아키텍처를 보여주는 다이어그램. 중앙 데이터 센터, 에지 노드, 그리고 사용자 장치가 있습니다.
접근점 또는 PoP 라고 불립니다. 그들은 지리적으로 분산된 곳입니다. 그곳에서 트래픽은 수신, 처리, 보안, 그리고 때때로 캐시되기 전에 코어 시스템에 도달하기 전에 처리됩니다.모바일 앱의 경우, 일본의 사용자는 항상 유럽이나 북미의 인프라를 기다릴 필요가 없습니다. 그들의 요청은 더 가까운 접근점에서 들어와서 인터넷에서 더 많은 긴 여행을 하지 않고 처리될 수 있습니다.
For a mobile app, that means a user in Japan doesn’t always need to wait on infrastructure sitting in Europe or North America. Their request can enter the network at a closer point and get handled with fewer long trips across the internet.
업데이트에도 중요합니다. 앱이 런칭 시 새로운 웹 번들, 구성 파일, 또는 자산 패키지를 확인하는 경우, 추가 라운드 트립은 시작 동작에 나타납니다. 이 문제를 모니터링하는 팀은 __CAPGO_KEEP_0__ 앱에 성능 모니터링을 설정하여 지역 테스트에만 의존하지 않고 대신 지역을 비교할 수 있습니다. 성능 모니터링을 설정하여 Capacitor 앱을 구성합니다. 캐싱, 라우팅, 및 지역 처리
개발자에게 모델을 이해하는 세 가지 요소가 있습니다:
캐싱은 자주 요청되는 콘텐츠를 근처에 저장합니다.
- 많은 사용자가 동일한 앱 자산 또는 업데이트 패키지를 요청할 경우, 에지 위치는 원본에서 매번 가져오지 않고 복사본을 준비할 수 있습니다. 라우팅은 사용자를 가장 근처의 진입점으로 보냅니다.
- 이것은 교통 제어와 같습니다. 네트워크는 사용자가 더 긴 또는 혼잡한 경로를 피하고 더 가까운 경로가 존재할 때 사용자를 보냅니다. 지역 처리는 간단한 작업을 처리하기 전에 핵심 클라우드가 관여하기 전에 처리합니다.
- 이것은 필터링, 인증 확인, 요청 처리, 또는 데이터를 업스트림으로 이동하기 전에 준비하는 작업을 포함할 수 있습니다. 실용적인 규칙:
Practical rule: 사용자가 많은 곳에서 반복적으로 동일한 것을 요청한다면, 그것을 한 곳에서 멀리 떨어진 원천에서 매번 요청할 필요가 없을 것이다.
‘에지 네트워크’라는 용어의 핵심 설명은 간단하게 ‘원격 네트워크 함수를 사용자들이 많이 사용하는 곳에 분산 배치하여 일반적인 요청이 빠르게 완료되고 실패할 가능성이 적게 되도록 하는 방식’이다.
클라우드는 사라지지 않는다. 클라우드는 주로 저장소가 되고, 에지 위치는 사용자 경험에서 거리를 제거하기 위해 근처의 매장으로 변한다.
에지 네트워크 vs CDN vs 에지 컴퓨팅
이 세 가지 용어는 끊임없이 혼동되며, 혼동의 이유는 실제 제품에서 겹치는 부분이 있기 때문이다.
개발자들은 종종 혼동하는 곳
A
CDN CDN의 주된 역할은 주로 캐시하고 콘텐츠를 전달하는 것 이미지, 자바스크립트 파일, 스타일 시트, 비디오 세그먼트, 다운로드 가능한 자산과 같은 콘텐츠를 사용자들이 많이 사용하는 곳에 위치한 곳에서 전달하는 것이다. CDN은 에지 네트워크와 에지 컴퓨팅과는 다른 개념이다.
에지 컴퓨팅 은 더 넓은 개념입니다. 그것은 사용자 또는 장치 근처에서 애플리케이션 로직 또는 데이터 처리를 실행하거나 에지 네트워크는 이러한 패턴이 가능하도록 하는 underlying 분산 연결성 layer입니다. Neos Networks는 메인 성능 효과를
의 종료까지의 지연 시간이 낮아진다 라고 설명하고, 에지 서버에서 데이터를 처리하기 전에 core cloud로 도달하기 전에 에지 네트워크가 지연 시간에 민감한 작업로드를 지원할 수 있음을 설명합니다. 에지 네트워킹 및 지연 시간 감소 의 설명에서. 이 차이는 앱 팀에 중요합니다:이미지 또는 번들 전송이 더 빠르기를 원한다면, CDN-style 캐싱만 필요할 수 있습니다. 에지 네트워크.
은 이러한 패턴이 가능하도록 하는 underlying 분산 연결성 layer입니다.
- Neos Networks는 메인 성능 효과를
- 만약 사용자와 가까운 곳에서 요청 처리나 결정을 원한다면, 에지 컴퓨팅 영역에 들어가고 있다.
- 만약 전반적인 경로가 사용자와 더 가까운 곳에 있고 지연 시간이 낮다면, 에지 네트워킹에 대해 이야기하고 있다.
만약 릴리스 동작, 시작 경로, 또는 요청 타이밍과 관련된 작업을 한다면, 이 앱 팀을 위한 네트워크 성능에 대한 이 기사 모음은 유용한 동반 주제이다. 네트워크 성능을 위한 앱 팀 에지 네트워크 vs. CDN vs. 에지 컴퓨팅 한눈에 보기
속성
| 에지 네트워크 | CDN (콘텐츠 전송 네트워크) | 에지 컴퓨팅 | 주요 작업 |
|---|---|---|---|
| 사용자와 장치에 가까운 곳에 네트워크 기능을 이동한다. | Primary job__CAPGO_KEEP_0__ | 속도와 효율성을 높여 콘텐츠를 캐시하고 전달하세요 | code 또는 사용자 또는 장치 근처에서 데이터를 처리하거나 실행하세요 |
| 일반적인 작업負荷 | 요청 라우팅, 트래픽 처리, 로컬 네트워크 서비스 | 정적 자산, 다운로드 가능한 파일, 미디어 전달 | API 논리, 필터링, 추론, 실시간 처리 |
| 작업이 발생하는 곳 | 사용자 근처의 분산된 지점 | 캐시 위치 근처의 분산된 지점 | 원본 근처의 에지 서버 또는 장치 |
| 최선의 정신 모델 | 도로 시스템과 근처의 진입점 | 지속적인 요청 경로 전체에서 낮은 지연 시간 | 빠른 자산 로드 및 다운로드 |
| 원본에 항상 호출하지 않고 빠른 결정 | CDN은 에지 전략의 일부일 수 있지만, 앱이 자동으로 에지 컴퓨팅을 수행하는 것은 아니다. | 아무리 많은 아키텍처 논쟁을 하더라도 대부분의 논쟁을 해결하는 단 한 문장이다. | 애플리케이션의 이점 |
아키텍처가 클릭되면 이점이 더 쉽게 판단된다. '에지'라는 레이블을 구매하는 것이 아니라, 거리를 줄이고 불필요한 라운드 트립을 제거하고 네트워크가 완벽하지 않아도 앱이 사용 가능한 상태를 유지하는 방법을 선택하는 것이다.
사용자가 느낄 수 있는 빠른 응답
IBM은 에지 네트워킹을 데이터 센터 처리에서 Edge 장치로 많은 컴퓨팅 작업을 재배치함으로써 속도, 대역폭 및 신뢰성을 향상시키고 지연 시간을 줄이는 것으로 설명한다. IBM의 한 예시에서는 다운로드 속도가
지속적인 요청 경로 전체에서 낮은 지연 시간
빠른 자산 로드 및 다운로드
원본에 항상 호출하지 않고 빠른 결정을 내릴 수 있다. 384 Kbps, or roughly 2에서 3배 빠른 정규 네트워크보다 그 시나리오에서 2에서 3배 빠른 IBM이 에지 네트워크가 속도 향상을 어떻게 설명하는지에 대해 설명한 것과 같습니다..
모바일 앱의 경우, 사용자는 Kbps를 생각하지 않습니다. 그들은 순간을 생각합니다:
- 스플래시 화면이 더 빨리 사라집니다.
- 업데이트 확인이 불편한 기다림 없이 완료됩니다.
- 약한 네트워크에서 앱이 더 강한 느낌을 받습니다.
- 작은 핫픽스가 지원 티켓이 쌓일 때까지 도착합니다.
팀이 빠른 속도로 풀 스택 앱을 배포하려고 한다면 ship full-stack apps quicklydelivery speed은 개발자 workflow 문제만이 아닙니다. 그것은 또한 infrastructure path 문제입니다.
더 많은 강건성은 네트워크가 복잡해질 때
분산 시스템은 하나의 경로 또는 위치가 문제가 될 때도 트래픽을 계속 제공할 수 있습니다. 실제로, 사용자는 항상 원격 오리진이 도달할 수 있고, 빠르고, 혼잡하지 않아야 하는 모든 순간에 의존하지 않습니다.
앱 팀에게는 릴리스 창과 인시던트 응답에서 나타납니다. 업데이트된 자산 또는 전역적으로 구성 파일을 분산할 필요가 있다면, 근처의 에지 위치가 사용자가 필요한 것을 얻을 수 있는 더 좋은 기회를 제공합니다. 이는 장거리로 돌아가야 하는 경우가 적습니다.
좋은 다음 단계는 자신의 앱 성능 최적화 체크리스트 and mark the parts that are really network-distance problems rather than code problems.
__CAPGO_KEEP_0__
문제를 표시하는 것입니다.
보안 제어가 더 가까운 곳에서 발생합니다.
에지 네트워크는 또한 보안 포지션을 개선할 수 있습니다. 필터링 및 강제가 트래픽이 중앙 시스템에 도달하기 전에 발생할 수 있습니다. 이는 일부 불쾌한 트래픽을 중단할 수 있습니다.
실세계 에지 네트워크 사용 사례
에지 네트워킹을 구체화하는 가장 쉬운 방법은 사람들이 매일 사용하는 제품을 살펴보는 것입니다.
스트리밍과 게임이 아이디어를 쉽게 이해할 수 있도록 해줍니다.
비디오 스트리밍 플랫폼은 사용자가 빠르게 시작할 수 있도록 근처의 전달을 의존합니다. 핵심 콘텐츠 라이브러리는 중앙화될 수 있지만 인기 콘텐츠는 사용자에게 더 가까운 곳에 분산됩니다.
온라인 게임도 유사한 문제를 가지고 있지만 다른 증상으로 나타납니다. 버퍼링 대신 플레이어는 지연, 반응 지연, 또는 불일치 멀티플레이어 동작을 경험합니다. 네트워크 경로가 더 멀면 지연이 더 심해질 수 있습니다.
이러한 예시들은 왜곡되지 않은 이점을 즉시 느낄 수 있기 때문에 도움이 됩니다. 비디오가 더 빠르게 시작되거나 게임이 더 반응이 좋게 느껴질 때.
왜 모바일 앱 업데이트는 에지 문제인가
모바일 앱 업데이트는 덜 명확하지만 동일한 아키텍처 문제가 있습니다.
앱이 라이브 업데이트를 확인하고, 다운로드한 웹 자산을 검증하고, 다음 런칭 시 적용할 때 업데이트 경로가 제품 품질에 포함됩니다. 사용자는 업데이트가 지연된 원인이 배포 크기, 네트워크 지리, 또는 원본 혼잡이었는지 신경 쓰지 않습니다. 그들은 단지 필요한 때에 고쳐지지 않았다는 것을 알게 됩니다.
이것이 라이브 업데이트에 에지 전달이 중요한 이유입니다. 글로벌로 분산된 업데이트 서비스는 변경된 배ंडल을 장치에 더 가까이 가져가서 요청 경로가 더 짧고 한 원본에 의존하지 않도록 할 수 있습니다.
A 실질적인 예는 CapgoCapacitorJS 및 Electron 앱에 대한 실시간 업데이트를 전달하고 전 세계 에지 네트워크를 통해 팀이 서명된 웹 번들을, 목표 채널, 및 오류를 수정할 수 있도록 앱 스토어 리뷰를 기다리지 않고 업데이트를 배포할 수 있습니다. 제어된 롤아웃을 진행하는 팀은 사용자 구성을 사용하여 실시간 업데이트를 사용하여 사용자에게 업데이트를 전송하지 않고 모든 사용자에게 업데이트를 전송하지 않도록 방지할 수 있습니다.
빠른_walkthrough를 통해 에지 전달이 릴리스 흐름에서 어디에 위치하는지 시각화하는 데 도움이 됩니다.
수정에 대한 작은 문제가 긴급할 때, 사용자에게 도달하는 네트워크 경로가修정 자체와 거의 같은 중요성을 가집니다.
개발자 중심의 답변은 대부분 일반적인 에지 기사에서 놓치고 있습니다. 에지 네트워크는 단순한 모바일 문제를 해결합니다: 사용자가 어디에 있든지 간에 올바른 업데이트를 올바른 사용자에게 빠르게 전달하는 것입니다.
에지 전략을 구현하는 방법
에지 전략을 선택하는 것은 앱의 병목 현상을 고려하는 데 시작됩니다. 벤더 마케팅에 따라서는 아닙니다. 주된 고통이 정적 자산 전달 속도라면 캐싱에 중점을 둔 접근법이 충분할 수 있습니다. 요청 지연, 지역 일관성, 또는 실시간 업데이트의 신뢰도와 같은 고통이 있다면 더 광범위한 에지 설정이 필요할 수 있습니다.
에지 네트워크 제공업체를 선택하기 전에 평가해야 하는 항목
__CAPGO_KEEP_0__
- 지리적 범위: 사용자들이 있는 곳에만 제공자가 있으면 안됩니다. 사용자들이 있는 곳에 제공자가 있으면야 합니다.
- traffic 처리: routing, caching, delivery controls를 찾으세요. 앱 자산, API 호출, 업데이트 패키지 모두 다르다는 것을 기억하세요.
- 보안 모델: access control, encryption, compliance needs, edge-side filtering를 확인하세요.
- 운영 관점: 로그, metrics, observability가 필요합니다. 한 지역이 다른 지역보다 느리게 작동하는 이유를 설명할 수 있어야 합니다.
- 개발자 워크플로: API, CI/CD 통합, 롤백 제어, 버전 목표가 네트워크 설계만큼 중요합니다.
좋은 선택 절차는 몇 가지 구체적인 질문으로 시작해야 합니다.
- 어떤 사용자가 가장 느린 속도로 사용하는 곳에 살고 있나요?
- 어플리케이션 시작 시 어떤 요청이 발생하는가요?
- 어떤 데이터를 안전하게 캐싱할 수 있나요?
- 어떤 부분은 여전히 원본으로 돌아가야 하나요?
- 지역적 배포 문제를 디버깅하는 방법은 무엇인가요?
에지가 올바른 해결책이 아닐 때
모든 앱이 분산된 에지 인프라를 필요로 하지 않습니다. Akamai는 "에지"라는 용어가 "fuzzy"하다고 주장하고, "silver bullet"이 아니라고 말합니다. 사업의 사례는 작업 부하, 운영 복잡성, 그리고 규제에 따라 다르며, 어떤 앱의 경우 지연 시간의 이익이 분산 아키텍처를 관리하는 오버헤드에 의해 정당화되지 않을 수 있습니다.Akamai의 "what an edge network is and isn’t"에 대한 설명서에서 논의된 것과 같이 what an edge network is and isn’twhat an edge network is and isn’t what an edge network is and isn’t.
그것은 유용한 현실 체크입니다.
앱이 좁은 지역의 사용자에게 제공되거나, 시작 네트워크 활동이 적거나, 빠른 자산 및 업데이트 전달에 의존하지 않는 경우, 에지 네트워크는 충분한 보상 없이 복잡성을 추가할 수 있습니다. 더 많은 위치가 더 많은 움직이는 부분을 의미합니다. 더 많은 움직이는 부분이 더 많은 캐시 동작, 배포 일관성, 보안 정책 및 모니터링에 대한 결정이 필요합니다.
올바른 질문은 '모던 앱이 에지 네트워크를 사용해야 하나?'가 아니라 '현재 사용자로부터 너무 멀리 떨어진 요청이 무엇이며, 거리를 줄이는 것이 운영 비용에 대한 가치가 있는지?'입니다.
CapacitorJS 또는 Electron 앱을 배포하는 팀이 JavaScript, CSS, config, copy 또는 자산 수정을 앱 스토어 검토를 기다리지 않고 배포해야 하는 경우 Capgo Edge 네트워크를 사용하는 것이 좋은 옵션입니다. Signed 웹 번들, 채널 기반 롤아웃, 롤백 보호 및 Edge 전달을 사용하여 팀이 다음 런칭 시 사용자에게 제어된 업데이트 push를 할 수 있도록 도와줍니다.
