당신의 모바일 앱은 로컬 테스트에서 잘 작동합니다. 런던의 사용자들은 앱을 열어 모든 것이 빠르다고 느낍니다. 도쿄의 사용자들이 같은 버전을 열어 느린 시작, 업데이트가 너무 오래 걸리고 일부 콘텐츠가 늦게 나타나는 것을 느낍니다. 당신은 한 지역과 다른 지역을 위해 앱을 변경하지 않았습니다. 차이점은 거리입니다.
개발자들은 실제로 이러한 이유로 Edge 네트워크를 사용하도록 요청합니다. 에지 네트워크는 무엇인가요__CAPGO_KEEP_0__
글로벌 앱은 요청, 자산 및 업데이트 모두를 한 곳에서 멀리 떨어진 곳으로 보내는 것을 노출시켜서, 그들은 새로운 트렌드가 아니라는 것을 알고 있습니다.
모바일 팀은 릴리스 시에 이러한 제한을 아는 것이 고통스럽습니다. JavaScript 수정, 업데이트 된 텍스트, 또는 작은 자산 변경이 필요합니다. 사용자는 빠르게 받거나, 다른 곳에서 받을 때까지 기다리거나, 타임아웃을 맞출 수 있습니다.
- 이러한 문제를 해결하기 위해 에지 네트워크가 존재합니다.
- 왜 런던에서 빠르지만 도쿄에서 느린가요
- 중앙 클라우드와 근처의 포인트 오브 프레젠스
- 애플리케이션에 대한 주요 이점
- 실제 Edge 네트워크 사용 사례
- Edge 전략을 구현하는 방법
앱이 런던에서 빠르지만 도쿄에서 느린 이유
런던의 사용자가 앱 아이콘을 탭합니다. 앱은 최신 설정을 확인하고 몇 가지 자산을拉고 계속합니다. 도쿄의 사용자가 같은 일을 하지만 요청이 더 먼 거리를 이동하여 인프라에 도달해야 합니다. 각 요청이 느려질 것처럼 느껴지지만, 사용자가 앱을 "랜덤하게 느려지기 시작한다"고 설명하기 시작할 때, 모바일 앱은 여러 요청을 연속적으로 수행합니다.
실현되지 않은 개념은 네트워크 지연. 만약 실용적인 리프레시를 원한다면, 이 가이드는 모바일 앱에서 네트워크 지연 이dea를 앱 동작 개발자들이 디버그하는 것과 직접 연결합니다.
An 엣지 네트워크 이것을 해결하기 위해 네트워킹과 처리를 사용자 위치 근처로 옮깁니다. 사용자 기기를 한 곳의 원격 위치로 강제하는 대신, 시스템은 근처의 위치에서 요청을 처리할 수 있습니다. 인텔은 엣지 네트워크를 중앙 클라우드에서 지리적으로 더 가까운 존재로 컴퓨팅, 스토리지 및 네트워킹 기능을 이동하는 분산 아키텍처로 설명합니다. 이로 인해 각 요청에 대한 데이터가 이동해야 하는 거리를 줄여줍니다. 인텔의 엣지 네트워크 아키텍처 개요에서 설명한 바와 같습니다. 왜 이것이 더 중요한지.
이것은 더 이상 특수한 인프라가 아닙니다. 한 프로젝션에 따르면,
2025년까지 75%의 기업 데이터 생성 및 처리는 중앙 데이터 센터나 클라우드 외부에서 발생할 것입니다. __CAPGO_KEEP_0__과거의 예측에 따르면, 에지 컴퓨팅 시장은 2023년 47.0억 달러에서 2031년 171.0억 달러로 성장할 것으로 예상됩니다. 사용자는 '구조'를 경험하지 않습니다. 그들은 대기, 다시 시도, 지역에 따라 불일치하는 동작을 경험합니다. 모바일 개발자에게는 간단한 규칙이 있습니다. 만약 앱이 전 세계 사용자를 대상으로 한다면, 릴리즈 시스템, 자산, 업데이트 경로도 전 세계적으로 동작해야 합니다. 그렇지 않다면, 앱은 사용자가 개발자 인프라 근처에 살고 있는 사람들만 빠르게 동작합니다. 에지 네트워크의 핵심 구조에지 네트워크를 이해하는 가장 쉬운 방법은 서버에 대해 생각하지 않고 로지스틱스에 대해 생각하는 것입니다. 기존 클라우드 설정은 중앙倉庫와 같이 작동합니다..
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__. 모든 물류는 하나의 주된 창고에 모여있다. 고객이 어디에 있든지, 모든 주문은 그 위치에서 출발한다. 그게 관리하기가 간단하지만, 고객이 대륙을 가로지르는 곳에 퍼져 있다면 ideal하지 않다.
Edge 네트워크는 지역 창고나 소매점과 같은 시스템에 더 가깝다. 주된 창고는 여전히 존재하지만, 일반적인 물품과 일부 지역 운영은 고객이 가까운 곳에 있다.
중앙 클라우드와 근처의 접근점
Edge 네트워크에서, 그 지역 위치는 종종 접근점, 또는 PoP라고 불린다. 그들은 지리적으로 분산된 곳으로, 트래픽이 코어 시스템에 도달하기 전에 받을 수 있고, 처리할 수 있고, 보안할 수 있고, 때로는 캐시할 수 있다.
모바일 앱의 경우, 그 의미는 일본의 사용자가 항상 유럽이나 북미의 인프라를 기다리지 않아도 된다는 것이다. 그들의 요청은 더 가까운 곳에서 네트워크에 들어와, 인터넷에서 더 먼 여행을 해야 하는 횟수를 줄일 수 있다.
이것은 업데이트에도 중요합니다. 앱이 런치 시 새로운 웹 번들, 구성 파일, 또는 자산 패키지를 확인하는 경우, 추가 라운드 트립은 시작 동작에 나타납니다. 이 문제를 모니터링하는 팀은 __CAPGO_KEEP_0__ 앱에 성능 모니터링을 설정하여 지역 테스트에만 의존하지 않고 대신 지역을 비교할 수 있습니다. performance monitoring in Capacitor apps 개발자에게 모델을 이해하는 세 가지 조각입니다.
캐싱은 자주 사용되는 콘텐츠를 근처에 저장합니다.
많은 사용자가 동일한 앱 자산 또는 업데이트 패키지를 요청할 경우, 에지 위치는 원본에서 매번 가져오지 않고 대신 복사본을 준비할 수 있습니다.
- 라우팅은 사용자를 가장 근처의 진입점으로 보냅니다. 이것은 교통 제어와 같습니다. 네트워크는 사용자가 더 가까운 경로가 존재할 경우, 더 긴 또는 혼잡한 경로를 피하기 위해 노력합니다.
- 지역 처리는 간단한 작업을 처리하기 전에 핵심 클라우드가 관여하기 전에 처리합니다. 이것은 필터링, 인증 확인, 요청 처리, 또는 데이터를 업스트림으로 이동하기 전에 준비하는 것 등이 포함될 수 있습니다.
- 실용적인 규칙: __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ 만약 사용자가 많은 곳에서 동일한 것을 반복적으로 요청한다면, 그것은 한 곳에서 멀리 떨어진 원천에서 매 요청마다 가져와야 하는 것이 아닐 것이다.
Edge 네트워크의 핵심은 영어로 설명할 수 있는 단순한 대답이다. 사용자에게 가까운 곳에 네트워크 함수를 분산 배치하여 일반적인 요청이 더 빠르게 완료되고 실패할 가능성이 적게 되도록 하는 것이다.
cloud는 사라지지 않는다. cloud는 주로 저장소가 되고, edge 위치는 사용자 경험에서 거리를 제거하는 근처의 매장으로 변한다.
Edge Network vs CDN vs Edge Computing
이 세 가지 용어는 실질적으로 제품에서 겹쳐서 혼동되는 것이 이해할 수 있다.
개발자는 'edge delivery', 'edge compute', 'global CDN'과 같은 용어를 듣게 되는데, 모두 같은 것처럼 들린다. 그러나 그것은 아니다.
개발자가 혼동하는 곳
A CDN 는 일반적으로 가장 쉬운 개념이다. 주로 캐시하고 콘텐츠를 전달한다 이미지, 자바스크립트 파일, 스타일 시트, 비디오 세그먼트, 다운로드 가능한 자산과 같은 콘텐츠를 사용자들이 가까운 곳에 있는 위치에서 가져온다.
엣지 컴퓨팅 더 넓은 개념입니다. 사용자 또는 장치 근처에서 애플리케이션 로직 또는 데이터 처리를 수행하는 것을 의미합니다.파일 캐싱만 저장하는 것이 아니라.
엣지 네트워크 엣지 네트워크는 이러한 패턴을 가능하게 하는 underlying 분산 연결성 층입니다. Neos Networks는 주요 성능 효과를 끝-to-end 지연 시간이 낮아진다.라고 설명합니다. 엣지 서버에서 데이터를 처리하기 전에 핵심 클라우드로 도달하기 전에 엣지 네트워크는.
실시간 분석 및 AI 추론과 같은 지연 시간에 민감한 워크로드를 가능하게합니다.
- 엣지 네트워크와 지연 시간 감소에 대한 설명에서 설명합니다. 이 차이는 앱 팀에 중요합니다:
- If you want request handling or decision-making close to users, you’re entering edge computing territory.
- If you want the whole path to be geographically closer and lower-latency, you’re talking about edge networking.
If you work on release behavior, startup paths, or request timing, this collection of articles on 네트워크 성능을 위한 앱 팀의 유용한 동반 주제입니다. Edge Network vs. CDN vs. Edge Computing at a Glance
속성
| Edge Network | CDN (Content Delivery Network) | Edge Computing | Primary job |
|---|---|---|---|
| 사용자와 장치에 가깝게 네트워크 기능을 이동하세요. | __CAPGO_KEEP_0__ | 효율적으로 콘텐츠를 캐시하고 전달하세요 | code 또는 사용자 또는 장치 근처에서 데이터를 처리하세요 |
| 일반적인 작업 부하 | 요청 라우팅, 트래픽 처리, 로컬 네트워크 서비스 | 정적 자산, 다운로드 가능한 파일, 미디어 전달 | API 논리, 필터링, 추론, 실시간 처리 |
| 작업이 발생하는 곳 | 사용자 근처의 분산된 지점 | 캐시 위치 | 원본 근처의 에지 서버 또는 장치 |
| 최선의 정신 모델 | 도로 시스템과 근처의 입구 | 인기 아이템이 이미 보관된 지역 셸프 | 사이트에서 작업을 처리하는 지역 작업자 |
| 모바일 개발자가 주목하는 사항 | 전체 요청 경로에서 지연 시간을 낮추다 | 빠른 자산 로드 및 다운로드 | 원본을 항상 호출하지 않고 빠른 결정 |
CDN은 에지 전략의 일부일 수 있지만, 자동으로 앱이 에지 컴퓨팅을 수행하는 것은 아니다.
그 한 문장으로 대부분의 아키텍처 논쟁이 해결된다.
애플리케이션의 주요 이점
아키텍처가 클릭되면 이점이 더 쉽게 판단된다. '에지'라는 레이블을 구매하는 것이 아니라, 거리를 줄이고 불필요한 반복을 제거하고 네트워크가 완벽하지 않아도 앱이 사용 가능하도록 하는 방법을 선택한다.
사용자가 느낄 수 있는 빠른 응답
IBM은 에지 네트워킹을 데이터 센터 처리에서 데이터 센터를 재배치하여 속도, 대역폭 및 신뢰성을 향상시키고 지연 시간을 줄이는 방식으로 Edge 장치에서 많은 컴퓨팅 작업을 이동하는 것으로 설명한다. IBM의 한 예시에서는 다운로드 속도가 384 Kbps, 또는 약 2에서 3배 빠른 __CAPGO_KEEP_0__의 경우 일반 네트워크보다 그 시나리오에 대해 더 안전하다고 설명된 IBM의 설명과 같습니다. edge 네트워크는 속도 향상을 위해 어떻게 개선되나요?.
모바일 앱 사용자들은 Kbps로 생각하지 않습니다. 그들은 순간에 생각합니다:
- 스플래시 화면이 더 빨리 사라집니다.
- 업데이트 확인이 완료되며 불편한 기다림 없이 끝납니다.
- 앱은 약한 네트워크에서 더 안정적입니다.
- 지원 티켓이 쌓일 때까지 작은 핫픽스가 도착합니다.
팀이 사용 중인 경우 전체 스택 앱을 빠르게 배포하세요.delivery speed는 개발자 workflow 문제만이 아닙니다. 그것은 또한 infrastructure path 문제입니다.
네트워크가 복잡해질 때 더 많은 강건성
분산 시스템은 하나의 경로 또는 위치가 문제가 될 때도 트래픽을 계속 제공할 수 있습니다. 실제로, 사용자는 항상 원격 오리진이 모든 순간에 빠르고 혼잡하지 않으면서 접근할 수 있는 경우에만 의존하지 않습니다.
앱 팀에게는 릴리스 창과 인시던트 리스폰스에서 나타납니다. 업데이트된 자산 또는 전 세계적으로 구성 파일을 분산할 필요가 있다면, 근처의 에지 위치가 사용자가 필요로 하는 것을 얻을 수 있는 기회를 제공할 수 있습니다. 그러나 긴 여행을 다시 코어로 가야합니다.
다음 단계는 자신의 앱 성능 최적화 체크리스트 를 검토하는 것입니다. 정말 네트워크 거리 문제인지 code 문제인지 표시해야합니다.
traffic에 가까운 보안 제어
에지 네트워크는 보안 포지션을 향상시킬 수 있습니다. 필터링 및 강제가 traffic이 코어 시스템에 도달하기 전에 발생할 수 있습니다. 그로 인해 일부 불쾌한 traffic을 중단할 수 있습니다.
사용자에게 가까운 단순 작업을 유지하고 sensitive source 시스템이 모든 요청을 직접 처리하지 않도록 하세요.
그것은 앱이 magically 안전해지는 것을 의미하지 않습니다. 그것은 중앙 시스템의 폭발 반경을 줄이고 protections을 path의 earlier 위치에 위치시키는 것을 의미합니다.
Real-World Edge Network Use Cases
일상생활에서 사용하는 제품을 통해 에지 네트워킹을 구체화하는 가장 쉬운 방법입니다.
스트리밍과 게임은 아이디어를 쉽게 이해할 수 있게 해줍니다.
비디오 스트리밍 플랫폼은 사용자가 빠르게 재생을 시작하고 버퍼링을 피하기 위해 근처의 배송을 의존합니다.核心 콘텐츠 라이브러리는 중앙화될 수 있지만 인기 콘텐츠는 사용자에게 더 가까운 곳에 분산됩니다.
온라인 게임도 유사한 문제를 가지고 있지만 다른 증상으로 나타납니다. 버퍼링 대신 플레이어는 지연, 반응 지연, 또는 불일치 멀티플레이어 동작을 경험합니다. 네트워크 경로가 더 멀면 지연감이 더 심해질 수 있습니다.
이 예시들은 왜인지 알 수 있습니다. 비디오가 더 빠르게 시작되거나 게임이 더 반응이 좋게 느껴질 때 바로 그 이점을 느낄 수 있기 때문입니다.
为什么移动应用程序更新是一个边缘问题
移动应用程序更新은 명확하지 않지만 동일한 아키텍처 문제가 있습니다.
앱이 라이브 업데이트 확인, 다운로드된 웹 자산을 다운로드, 검증, 다음 시작 시 적용할 때 업데이트 경로는 제품 품질에 포함됩니다. 사용자는 배포 크기, 네트워크 지리, 또는 원본 혼잡으로 인한 지연을 구별하지 않습니다. 그들은 단지 필요한 때에 수정이 도착하지 않았음을 알게 됩니다.
이것이 라이브 업데이트에서 에지 전달의 중요성입니다. 글로벌로 분산된 업데이트 서비스는 변경된 번들을 장치에 더 가까이 가져가서 요청 경로가 더 짧고 원본에 의존하지 않도록 할 수 있습니다.
실제 예시로는 Capgo, CapacitorJS 및 Electron 앱에 대한 실시간 업데이트를 전 세계 에지 네트워크를 통해 제공하고, 팀은 서명된 웹 번들을, 대상 채널, 및 수정 사항을 앱 스토어 리뷰를 기다리지 않고 배포할 수 있습니다. 제어된 롤아웃을 진행하는 팀은 사용자 구성을 사용한 실시간 업데이트와 pair할 수 있습니다. 이러한 업데이트를 모든 사용자에게 전송하는 대신, 한 번에 모든 사용자에게 업데이트를 보내지 않도록 합니다.
빠른 워크숍을 통해 에지 전달이 릴리스 흐름에서 어디에 위치하는지 시각화할 수 있습니다.
작은修정은 긴급하지만, 사용자에게 도달하는 네트워크 경로가修정 자체만큼 중요합니다.
이것이 개발자 중심의 대답입니다. 일반적인 에지 기사들은 이점을 놓치고 있습니다. 에지 네트워크는 미래의 IoT 시나리오만을 위한 것이 아닙니다. 에지 네트워크는 매우 평범한 모바일 문제를 해결합니다: 사용자가 어디에 있든지, 올바른 업데이트를 올바른 사용자에게 빠르게 전달하는 것입니다.
에지 전략을 구현하는 방법
에지 전략을 선택하는 것은 앱의 병목 현상을 고려하는 것부터 시작합니다. 벤더 마케팅보다는.
정적 자산 전달 속도가 느려서 문제가 되는 경우, 캐싱에 집중하는 접근법만이 필요할 수 있습니다. 요청 지연, 지역 일관성, 또는 실시간 업데이트의 신뢰도 문제가 있는 경우, 더 광범위한 에지 설정이 필요할 수 있습니다.
사용자 행동에 직접 매핑되는 짧은 목록을 사용하십시오:
- 지리적 범위: 사용자들이 있는 곳에만 서비스가 제공되는 것이 아니라, 팀이 있는 곳에만 서비스가 제공되는 것을 피하십시오.
- traffic 처리: 라우팅, 캐싱 및 배달 제어 기능이 작업 부하에 맞춰져 있는지 확인하십시오. 앱 자산, API 호출 및 업데이트 패키지는 모두 동일한 방식으로 동작하지 않습니다.
- 보안 모델: 서비스 제공자가 접근 제어, 암호화, 규정 준수 요구 사항 및 에지 사이드 필터링을 어떻게 처리하는지 확인하십시오.
- 운영 관찰성: 로그, 메트릭 및 한 지역이 다른 지역보다 느린 이유를 설명할 수 있는 관찰성 수준이 충분한지 확인하십시오.
- 개발자 워크플로: API, CI/CD 통합, 롤백 제어 및 버전 대상이 네트워크 설계만큼 중요합니다.
좋은 선택 절차는 몇 가지 구체적인 질문으로 시작해야 합니다.
- 어느 지역의 사용자가 가장 느린가?
- 어플리케이션 시작 시 어떤 요청이 발생하는가?
- 어떤 데이터를 안전하게 캐싱할 수 있는가?
- 어떤 부분은 원본으로 다시 돌아가야 하는가?
- 지역 배포 문제를 디버깅하는 방법은?
에지가 올바른 해결책이 아닐 때
모든 앱이 분산 에지 인프라스트럭처가 필요하지는 않다. Akamai는 "에지"라는 용어가 "fuzzy"하다고 주장하며, "silver bullet"이 아니라고 말한다.사업의 사례는 작업 부하, 운영 복잡성, 관리, 그리고 일부 애플리케이션의 경우 지연 시간의 이익이 분산 아키텍처의 관리 오버헤드를 정당화하지 못할 수 있다. Akamai의 "what an edge network is and isn’t" 글에서 discussed하는 것과 같이어떤 앱은 지연 시간의 이익이 분산 아키텍처의 관리 오버헤드를 정당화하지 못할 수 있다. 어떤 앱은 지연 시간의 이익이 분산 아키텍처의 관리 오버헤드를 정당화하지 못할 수 있다..
그것은 유용한 현실 검증입니다.
앱이 좁은 지리적 청중을 대상으로 하거나, 시작 네트워크 활동이 적거나, 빠른 자산 및 업데이트 전달에 의존하지 않는 경우, 에지로 인한 복잡성이 충분한 보상과 함께 추가되지 않을 수 있습니다. 더 많은 위치는 더 많은 움직이는 부분을 의미합니다. 더 많은 움직이는 부분은 캐시 동작, 배포 일관성, 보안 정책 및 모니터링에 대한 결정이 필요합니다.
어떤 요청이 현재 사용자로부터 너무 멀리 떨어져 있는지, 거리를 줄이는 것이 운영 비용에 대한 가치가 있는지 여부를 결정하는 것이 올바른 질문입니다.
CapacitorJS 또는 Electron 앱을 배포하는 팀이 JavaScript, CSS, config, copy 또는 자산 수정을 앱 스토어 검토를 기다리지 않고 사용자에게 배포해야 하는 경우 Capgo 는 이러한 워크플로에 최적화된 옵션입니다. signed web bundles, channel-based rollouts, rollback protection 및 edge delivery를 사용하여 팀이 다음 런칭 시 사용자에게 제어된 업데이트를 푸시할 수 있도록 도와줍니다.
