소개
엣지의 정의는 항상 데이터 센터 아키텍처의 진화와 맞물려 왔습니다. 지난 10년 동안 엔터프라이즈 인프라 아키텍처는 온프레미스 데이터 센터에서 오늘날의 분산형 클라우드 아키텍처로 확장되며 급격한 혁신을 겪었습니다. 우리는 엣지 2.0을 어플리케이션이 분산형 클라우드 아키텍처를 활용할 수 있도록 하는 기술 변화라고 말합니다.
개인, 조직, 기업마다 엣지에 대한 해석이 다릅니다. 어떤 사람은 엣지를 기지국이라고 생각할 수도 있고, 어떤 사람은 엣지를 모바일 장치라고 말할 수도 있습니다. 클라우드 서비스 제공업체(CSP)에게 엣지는 백엔드에 원활하게 통합되는 관리형 인프라 공간이며, 군사 어플리케이션에서 엣지는 육상, 해상, 공중 등 전투의 장입니다. 엣지에 대한 해석은 일반적으로 인프라의 컴퓨팅, 네트워킹, 스토리지 기능 또는 그 위치로 요약될 수 있습니다.
하지만 엣지 2.0은 인프라 자산이나 그 위치뿐만 아니라 에코시스템의 모든 이해관계자에게 제공하는 경험으로 보고 있습니다.
이 문서는 물리적 또는 가상 인프라 또는 위치 또는 인스턴스화 위치에 관계없이 엣지 2.0의 기능에 대해 설명합니다. 더 나은 분산 어플리케이션을 구축하는 방법을 설명하는 것이 아니라 특정 요구 사항에 맞는 가장 최적의 분산 어플리케이션 생성을 지원하기 위해 엣지 2.0에 있어야 하는 기능을 조명하는 데 이 문서의 목적이 있습니다.
엣지 2.0이란?
이러한 분산 클라우드에 상주하는 엔티티의 관점에서 엣지는 엔티티가 현재 위치한 모든 곳이 엣지입니다. 따라서 인프라의 위치, 인프라 유형 또는 제어 엔티티에만 국한되지 않는 경험 중심적인 엣지 2.0의 정의를 제안합니다.
엣지 2.0의 초점은 어플리케이션 중심, 운영 중심, 개발자 중심의 경험을 향상하는 데 있습니다. 엣지 2.0은 어플리케이션의 변화하는 요구사항에 적응하여 SLA, SLO와 같은 어플리케이션의 메타 속성을 다루어야 합니다. 엣지 2.0은 운영이 간편해야 하며 모든 분산 어플리케이션에서 새로운 자동화를 만들어야 하는 운영 팀의 부담을 덜어주어야 합니다. 엣지 2.0은 개발자가 대규모로 분산 어플리케이션을 개발하고 배포할 때 직면하는 마찰을 줄이고 보안, 거버넌스 및 서비스 수준 목표를 원활하게 지원해야 합니다.
은행 어플리케이션을 예로 들어보겠습니다. 엣지 2.0의 목표는 거래의 비즈니스 로직을 개선하는 것이 아닙니다. 더 안전하고, 더 빠르고, 비공개적이며, 필요에 따라 모든 지역에서 사용할 수 있고, 비즈니스 목표를 지원하기 위해 필요에 따라 확장 또는 축소할 수 있도록 만드는 것입니다.
개념 및 주장
다음은 이 백서의 주요 개념과 주장입니다.
- 경험 중심 엣지: 자산이나 위치가 아닌 제공하는 경험을 중심으로 엣지 2.0의 기반을 구축합니다.
- 설계 고려 사항: 엣지 2.0 아키텍처의 성공적인 구현을 위한 주요 설계 고려 사항을 지정합니다.
- 이기종 인프라: 분산형 클라우드를 위한 설계는 인프라의 분산 제어를 고려해야 한다는 점을 강조합니다.
- 기반으로서의 텔레메트리: 인프라의 모든 계층에서 지원되어야 하는 기본 구성 요소로서 텔레메트리를 강조합니다. 텔레메트리가 없으면 데이터 우선 전략이 희석됩니다.
- 클러스터 간 과제: 엣지2.0의 근본적인 과제는 클러스터 내가 아닌 클러스터 간이라는 점을 강조합니다.
- 적응형 인터페이스: 선언적 인터페이스 및 명령형 인터페이스와 뚜렷한 비교가 되는 적응형 인터페이스를 소개합니다.
- 엣지 2.0 어플리케이션 플랫폼(EAP): 엣지 2.0이 어플리케이션의 요구 사항에 맞게 조정할 수 있도록 프레임워크로서 EAP를 소개합니다.
다루지 않은 주제
이 백서에서 아직 다루지 않은 몇 가지 주제가 있습니다.
- 어플리케이션 데이터 배포: 여기에는 콘텐츠 전송 네트워크(CDN), 스토리지 배포, 데이터 배포, 캐싱 등과 같은 많은 하위 주제가 있습니다. 충돌 없는 복제 데이터 유형(CRDT)과 같은 새로운 기술도 있습니다. 엣지 2.0 프레임워크는 어플리케이션 데이터 배포에 대한 지원을 그 범위에 포함시켜야 합니다.
- 기능 분산: 엣지 컴퓨팅의 발전은 핵심 클라우드 기능과 로직이 이벤트가 생성되는 위치 또는 데이터가 상주하는 위치에 더 가깝게 이동하는 것으로 생각할 수 있습니다. 엣지에서 상당한 양의 컴퓨팅을 사용할 수 있게 되면서 이제 이러한 컴퓨팅을 활용하려면 기존 클라우드 아키텍처에서 일반적으로 해결했던 문제와 유사한 문제를 해결해야 합니다. 예를 들어 오버레이 네트워킹, 미들웨어 워크로드 및 기타 유형의 워크로드는 초기 엣지에서 보았던 순진한 사용 사례(데이터 옆에서 실행되는 상태 저장 없는 단순 흐름인 스토릿)보다 더 복잡하고 서로 얽힌 상태입니다.
- 논의되지 않은 다른 영역이 있을 수 있습니다. 이 프레임워크의 목표는 필요에 따라 책임을 추가할 수 있도록 확장성을 확보하는 것입니다.
엣지 진화
그림 1은 엣지와 데이터 센터 아키텍처의 공동 진화를 가장 잘 보여줍니다. 엣지 1.0과 1.5는 오리진 사이트의 개념을 기반으로 데이터와 서비스를 오리진에서 소비자로 이동시켰습니다. 엣지 1.0은 분산 콘텐츠 캐싱, 즉 콘텐츠 배포 네트워크를 통해 대역폭 사용을 최적화하는 데 중점을 둔 인터넷 인프라 구축이었습니다. 전송할 콘텐츠의 총량이 항상 가용 대역폭을 초과하므로 CDN이 기본적인 설계 패턴입니다.
CPU와 메모리 비용이 하락하면서 CDN 노드와 함께 컴퓨팅 팜이 등장했고, 어플리케이션은 서비스 지향 아키텍처(SOA)를 통해 서비스로 소비되었습니다. 따라서 엣지 1.5를 서비스 배포 네트워크라고 부르게 되었습니다.
엣지 1.0과 엣지 1.5의 공통적인 특징은 오리진 사이트라는 개념입니다. 모바일이 성장하기 전에는 사람, 장치, 사물이 주로 콘텐츠를 다운로드하거나 서비스의 소비자 역할을 했습니다. 서비스를 제공하는 사이트와 서비스를 소비하는 사이트는 여전히 달랐던 것입니다.
그러나 엣지 2.0에서는 모든 엔티티가 오리진 사이트 또는 소비자 역할을 할 수 있습니다. 트래픽 흐름이 바뀌었습니다. 사람, 휴대폰, 장치는 콘텐츠를 업로드하거나 주기적으로, 그리고 적극적으로 데이터를 생산하고 있으며 앱은 다른 앱에 의존하면서 소비자가 되고 있습니다. API, 사람, IoT 장치, 웹, 백엔드, 헤드리스 어플리케이션 등 모든 엔티티는 서비스의 생산자 또는 소비자 역할을 할 수 있습니다. 자체 관점에서 보면 인프라의 모든 주체는 자신이 엣지에 있다고 생각하게 됩니다.
분산 클라우드는 데이터 센터 진화의 최신 단계입니다. 컴퓨팅은 모바일 장치에서 네트워크에 연결된 일상적인 사물에 내장되는 등 진정한 유비쿼터스가 되었습니다. 이와 함께 분산 및 확장 가능한 어플리케이션을 지원하는 소프트웨어 아키텍처도 함께 진화하고 있습니다.
엣지의 결과: 복잡성 증가
컴퓨팅과 스토리지가 어디에나 풍부하고 광범위하게 배포되면서 기업의 디지털 혁신이 빠르게 이루어질 수 있는 기회가 생겼습니다. 하지만 이러한 빠른 진화에는 그에 따른 대가도 따릅니다.
대부분의 기업은 일반적으로 균일하지 않은 환경의 이기종 인프라로 구성되어 있습니다. 이러한 환경을 효과적으로 확장하려면 배포된 시스템에 복잡한 조율과 자동화가 필요합니다. CPU 및 대역폭 요구 사항의 변경과 같이 어플리케이션의 요구 사항이 급격하게 변경되면 분산 클라우드 전반에서 운영의 복잡성이 증가합니다. 이는 어플리케이션 또는 최종 고객의 변화하는 요구 사항에 효율적으로 대응할 수 있는 장비가 부족한 운영 팀에 스트레스를 가중시킵니다.
이러한 문제의 결과는 운영 복잡성으로 이어져 디지털 혁신을 통해 기업이 얻을 수 있는 잠재적 이익을 저해합니다.
복잡성으로 인해 발생하는 몇 가지 얽히고설킨 문제와 유산에 대해서는 다음에 설명하겠습니다.
하이브리드 클라우드는 다양한 공격 벡터로 인해 침해될 수 있는 표면적이 증가합니다. 다양한 사용 사례는 여러 보안 문제를 야기하며, 인프라가 발전함에 따라 우리는 끊임없이 문제를 쫓고 있습니다. 따라서 우리가 예상하는 문제는 기술 권장 사항만 자주 변경될 것인가, 아니면 보안을 구현하는 설계 패턴도 변경될 것인가 하는 것입니다.
기존 접근 방식의 몇 가지 문제점은 다음과 같습니다.
- 소프트웨어 정의 경계(SDP)는 널리 사용되는 솔루션이 에이전트 기반이기 때문에 쉽게 확장할 수 없으며, 단순한 운영 배포에 적합하지 않습니다.
- 제로 트러스트 네트워크 액세스(ZTNA)를 구현하는 것은 트래픽 검사, 중앙 집중식 로그 관리, 글로벌 PKI 및 ID 관리 등과 같이 배포된 프로덕션 서비스의 집합을 필요로 하는 ZTNA 솔루션으로 인해 비현실적인 경우가 많습니다.
- 보안 액세스 서비스 엣지(SASE)는 서비스형 네트워크와 서비스형 보안을 결합한 것으로, 구현하기 쉽지 않은 여러 기술의 약어입니다. 또한 SASE의 초점은 소프트웨어 정의 광역 네트워크(SD-WAN) 중심이며 엔터프라이즈 네트워킹 엣지 사용 사례의 작은 부분을 다루는 경향이 있습니다.
- 여러 퍼블릭 클라우드 제공업체의 인프라, 그리고 ID 및 액세스 관리(IAM)와 같은 이미 복잡한 보안 모델의 불일치로 인해 팀에서는 제공업체는 덧붙이는 방식으로 강화되고 멀티클라우드 구성을 번거롭게 만드는 경우가 종종 있습니다.
엣지에서 사용 가능한 저전력 및 저비용 컴퓨팅의 초분산과 관련된 주요 과제 중 하나는 인프라를 일관된 방식으로 조율하고 예약하는 능력입니다. 운영팀은 분산 클라우드를 활용하는 어플리케이션을 확장하고 지원하는 데 어려움을 겪습니다. 이러한 어플리케이션에는 일반적으로 다양한 관리 요구 사항을 가진 이기종 기술이 포함되기 때문입니다.
Terraform과 같은 자동화 플랫폼은 자동화를 사용자 지정할 수 있는 정교한 수단을 제공하지만, 운영팀은 여전히 5가지 유형의 컴퓨팅, 4가지 유형의 방화벽, 3가지 유형의 로드 밸런서 등 다양한 조합을 위한 스크립트를 유지 관리해야 합니다. 자동화 스크립트를 관리하고 유지 관리해야 하는 인적 비용은 확장할 수 없습니다.
이로 인해 인프라 고객은 티켓 중심 시스템을 통해 운영 팀과 지속적으로 상호작용하게 되는데, 이는 기존 워크플로를 자동화하는 데 장애가 됩니다. 서비스 데스크는 티켓에 압도되어 민첩성보다 보안과 안정성에 우선순위를 두어야 합니다.
마이크로서비스 아키텍처는 이미 멀티 클라우드로 진화하면서 새로운 어플리케이션을 구축하는 사실상의 방법이 되었습니다. API가 게시되고 필요할 때 언제 어디서나 인스턴스화할 수 있어 API가 무질서하게 확장되고 있습니다. 이러한 API를 자율적으로 검색, 연결 및 관리하는 것이 큰 과제가 되고 있습니다.
API 확산 문제를 해결하기 위해서는 패러다임의 전환이 필요합니다. 내부 모델에 따르면 전 세계 API 개발자 수, 개발자당 연간 개발되는 API 수, API 유효 기간과 같은 매개변수를 적당히 가정해도 2030년까지 수십억 개는 아니더라도 수억 개의 API가 동시에 활성화되는 것으로 나타났습니다(그림 2). 2021 API 확산 보고서에서 이 새로운 주제에 대한 포괄적인 시각을 볼 수 있습니다.
복잡성이 증가함에 따라 기업은 포괄적 시스템에 대한 세분화되고 의미 있는 포괄적 가시성을 확보해야 합니다. 분산 클라우드 환경에서 어플리케이션은 별도의 엔티티에서 관리하는 여러 이기종 인프라 스택을 넘나들고 있습니다.
게다가 오늘날 어떤 통신사도 기업 고객에게 인프라의 기본 텔레메트리를 노출할 인센티브를 제공하지 않습니다. 기업은 분산 클라우드에 어플리케이션을 배포할 때 기본적으로 정보가 없는 상태로 실행하고 있으며 여러 가시성 도구에 의존해야 합니다. 이러한 관찰 가능성 격차를 메우기 위해 일반적으로 인프라 또는 어플리케이션 스택의 다른 지점에서 작동하는 여러 공급업체에서 제공하는 도구를 사용합니다.
비표준 인프라 지표는 기업 내 문제를 가중시킵니다. 일반적으로 운영 사일로 및 다양한 인프라 환경에 있는 균일하지 않은 인프라 등의 요인으로 인해 지표가 통합되지 않습니다. 예를 들어 퍼블릭 클라우드 제공업체 간의 지표는 서로 다르며 온프레미스 데이터 센터 기술도 표준 지표를 따르지 않습니다.
비즈니스 결과: 경험 악하
수익을 창출하는 워크로드와 미션 크리티컬 시스템이 일반적으로 기업에서 사용 가능한 운영 리소스와 예산의 대부분을 사용합니다. 반면, 소규모 프로젝트가 복잡성은 낮지만 기업 어플리케이션의 대부분을 차지하는 경향이 있습니다. 그림 3은 이를 기업의 운영 복잡성과 비교한 프로젝트 수의 긴꼬리 분포로 보여줍니다.
소규모 어플리케이션은 운영 복잡성이 낮을 수 있지만, 운영 프로세스와 워크플로는 여전히 수작업인 경우가 많으며 서비스 티켓이 여러 운영 팀을 성공적으로 통과하는 데 몇 주가 걸릴 수 있습니다. 예를 들어, 세분화된 보안 정책으로 전용 네트워크 리소스가 필요한 어플리케이션을 배포하려면 먼저 글로벌 보안 팀에서 보안 정책 승인을 처리해야 할 수 있습니다. 그런 다음 서비스 티켓은 네트워킹 팀에서 서브넷 및 경로 구성에 필요한 계획을 수립해야 할 수 있으며 마지막으로 방화벽 관리를 담당하는 다른 운영 팀의 방화벽 규칙 검증을 받아야 할 수도 있습니다.
이제 기업이 기본 인프라의 일부를 소유하지 않은 분산 클라우드에 배포된 각 어플리케이션에 대해 위의 복잡성을 해결해야 한다고 가정해 보겠습니다. 온보딩하고 지원해야 하는 소규모 프로젝트 또는 어플리케이션의 양이 너무 많기 때문에 운영 팀이 모든 프로젝트를 지원하는 것은 비현실적이며 우선순위 지정 문제와 셀프 서비스 기회가 생깁니다.
이러한 우선순위 지정 문제는 인프라 팀의 투자가 중요하고 수익을 창출하는 시스템을 지원하는 데 집중되어 생산 전 개발, 테스트, 스테이징의 자체 수명 주기를 포함하는 신규 프로젝트에 투자할 시간이나 예산이 거의 없기 때문에 특히 두드러집니다. 그 결과 기능 속도, 사용자 지정, 신제품을 지원하는 혁신에 대한 역량과 투자가 감소하여 비즈니스와 제품이 정체되는 정점에 이르게 됩니다.
엣지 솔루션 공간
엣지 에코시스템의 진화는 어플리케이션 플랫폼으로 이러한 과제를 해결할 수 있는 기회를 제공함으로써 솔루션 공간을 크게 확장합니다.
그림 4는 엣지 2.0 솔루션 공간을 보여줍니다. 여기서는 이를 분산 클라우드 아키텍처에 포함된 모든 것이 솔루션 공간의 총합이라고 설명합니다.
따라서 솔루션 공간의 맥락에서 엣지 2.0은 다음과 같은 모든 사용자가 원하는 경험을 제공해야 합니다.
- 이는 솔루션 범위 내에 있는 모든 엔티티(소비자 역할을 하는 앱, 사람, 장치 또는 서비스를 구성하는 웹 백엔드 및 헤드리스 어플리케이션)를 말합니다.
- 이러한 앱의 SRE 팀과 어플리케이션 소유자는 인프라에 기대되는 보안 및 규제 경계를 유지하면서 어플리케이션을 개발할 수 있습니다.
엣지 2.0은 운영이 간편하고 안전하며 규정을 준수하며, 참여하는 모든 에코시스템 엔티티에게 고품질의 경험을 제공할 것입니다.
엣지 2.0 설계 고려 사항
기본적으로 보호
분산 클라우드는 엔드포인트 수가 기하급수적으로 증가하기 때문에 대규모 보안 문제를 증폭시킵니다. 이러한 대규모로 인해 솔루션 구현의 복잡성도 증가합니다. 보안 태세는 어플리케이션이 현재 배포된 환경이 이미 손상된 것으로 가정해야 합니다. 마찬가지로 인프라는 그 안에서 실행되는 어플리케이션을 신뢰하지 않아야 합니다.
이러한 아이디어의 기본이 제로 트러스트라는 사고방식의 개념에 담겨 있으며, BeyondCorp1 예시는 어플리케이션 액세스 사용 사례에 대한 이러한 개념을 보여줍니다. 앞으로 엣지 2.0은 다음 5가지 핵심 원칙을 기반으로 이 모델을 확장합니다.
- ID는 기본: 엣지 2.0에서는 각 엔티티 인스턴스가 전 세계적으로 고유한 ID를 가질 뿐만 아니라 권한 수준과 함께 조직 계층 구조에서 차지하는 위치도 고유합니다. ID는 남북 트래픽뿐만 아니라 내부적으로 동서 액세스를 위한 핵심 고려 사항이어야 합니다.
- 최소 권한: 행위자가 허용하는 작업은 해당 행위자가 시스템에서 역할을 수행하는 데 필요한 작업으로만 제한되어야 합니다. 예를 들어 설계 사양에 따라 데이터베이스 서버와 통신할 수 있는 워크로드의 하위 집합을 제한하는 것입니다.
- 지속적인 인증: 시스템 행위자가 하는 모든 증명에는 검증 수단이 있어야 하며, 그러한 증명이 발생할 때마다 명시적으로 검증되어야 합니다. 인증은 공유된 비밀이나 신뢰 체인을 통해서만 명시적으로 이루어져야 하는 것이 아니라 암묵적인 행동 패턴과 상황에 맞는 메타 데이터도 고려해야 합니다.
- 지속적인 모니터링 및 평가: 시스템 내 모든 행위자의 행동을 모니터링해야 하므로 엣지 2.0 아키텍처에서 데이터 수집 및 웨어하우징 기술의 핵심 역할이 강화됩니다. 또한 이러한 활동을 지속적으로 평가하여 금지되거나 위험한 행동을 수행하려는 시도를 감지하고 완화해야 합니다. 평가는 거의 실시간으로 대규모로 이루어져야 하므로 자동화 및 머신 러닝 기술을 자유롭게 사용할 수 있어야 합니다.
- 침해 가정: 오늘날의 정교한 공격자가 사용할 수 있는 리소스를 고려할 때 모든 시스템이 어떤 방식으로든 침해되었다고 가정해야 합니다. 따라서 워크로드 및 사용자 ID에 뿌리를 둔 완전히 결정론적인 정책, 즉 A와 B로 대표되는 권한 기반 접속을 시행하는 정책만으로는 모든 공격을 방지하기에 충분하지 않습니다. 따라서 완전히 성숙한 엣지 2.0 시스템은 지속적인 모니터링과 평가를 기반으로 실시간 위험/보상 평가를 수행할 수 있어야 합니다.
네이티브 관찰 가능성 제공
엣지 2.0은 텔레메트리를 인프라 스택 깊숙한 곳에 일류 시민으로 통합하고, 인프라 내에서 계층 간 텔레메트리를 수집하고, 공통 플랫폼에 표시할 수 있는 간단하고 확장 가능한 수단을 제공해야 합니다. 이를 통해 관찰 가능성 팀은 필요에 따라 '인프라 상태'를 표면화할 수 있습니다. 어플리케이션 팀은 어플리케이션 스택을 명시적으로 계측하지 않고도 비즈니스 로직에 집중할 수 있습니다.
현재 관찰 가능성 기술의 상태는 대부분 공급업체별, 독점적으로 이루어져 왔습니다. 이로 인해 많은 공급업체별 에이전트가 유사한 신호를 수집하여 값비싼 메모리와 CPU를 차지하기 위해 경쟁하는 상황이 발생했습니다.
다음 논리적 단계는 인프라 및 트래픽 데이터를 중앙 집중식 데이터 플랫폼으로 스트리밍할 수 있는, 공급업체에 구애받지 않는 텔레메트리 수집기를 사용하는 것입니다.
많은 제품 팀이 계측에 대한 투자를 수익 기회로 연결해야 하기 때문에 계측에 대한 투자를 정당화하는 데 어려움을 겪습니다. 인프라는 다른 비즈니스 기능이나 프로세스와 마찬가지로 계측되어야 하며, 팀은 비즈니스 목표에 맞게 최적화하기 위해 인프라의 행동을 이해해야 하기 때문입니다. 따라서 계측의 필요성보다는 무엇을 우선적으로 계측해야 하는지에 대한 논의가 더 많이 이루어져야 합니다.
어플리케이션 동작을 보다 세분화되고 정확하게 측정하기 위해 계측을 코드 시점에 호출하여 "왼쪽으로 이동"할 것으로 예상됩니다(그림 5).
적응형 인터페이스 지원
분산 클라우드에 따라 범위(로컬 또는 글로벌) 내의 각 클라우드를 몇 가지 계층으로 분리하면 각 클라우드에는 자체 관리자, 관리자, 오케스트레이터 등이 있습니다. 각각은 독립적으로 동작하며 자체 결정을 내리지만 필요에 따라 다른 엔터티가 사용할 수 있는 인터페이스를 제공합니다.
따라서 분산 클라우드의 개념은 본질적으로 분산된 관리 및 제어입니다. 이 사실에서는 벗어날 수 없으며, 적응형 인터페이스와 선언적 및 명령형 인터페이스의 미묘한 차이를 더 잘 인식하는 것이 중요합니다.
엣지 2.0 인프라를 효과적으로 활용하려면 명령형 및 선언형 인터페이스만으로는 충분하지 않습니다. 이는 급변하는 조건에 충분히 빠르게 적응하지 못하는 본질적으로 정적인 구조인 수작업 아티팩트에 여전히 의존하고 있기 때문입니다.
결과 기반은 우리가 나아가야 할 방향이며, 시스템은 이러한 결과를 충족하기 위해 인프라 전반의 정책을 조정할 수 있을 만큼 스마트해야 합니다. 이를 적응형 인터페이스라고 부릅니다.
명확히 말하면, 명령형 인터페이스와 선언형 인터페이스, 적응형 인터페이스는 상호 배타적이지 않습니다:
명령형: 매우 규범적이며 원하는 상태에 도달하기 위한 일련의 작업을 자세히 정의합니다. 예를 들어 라우터 구성은 명령형 작업입니다. 위의 시나리오에서는 어떤 데이터 센터, CPU/메모리 양, 필요한 대역폭, 특정 경로 등 규범적 작업이 정확합니다. 데이터 모델의 입력 품질이 매우 높으므로 인프라에 대한 심층적인 지식과 전문성이 필요합니다. 인프라의 모델과 구조를 모두 알아야 할 것으로 예상됩니다.
선언적: 선언적의 뉘앙스는 원하는 상태를 달성하는 동작이 아니라 원하는 상태를 설명하는 데 중점을 둔다는 것입니다. 입력 품질은 낮지만 어플리케이션이 최소한 기본 인프라의 구조를 알고 있어야 합니다.
적응형: 명령형 또는 선언형과 구분됩니다. 적응형 인터페이스는 상태보다는 원하는 목적이나 목표에 중점을 둡니다. 적응형 인터페이스의 목표는 기본 시스템에 대한 사전 지식에 초점을 맞추기보다는 어플리케이션을 배포하려는 이해 관계자의 목표를 파악하는 것입니다. 적응형은 기본 인프라의 기능이 무엇인지에 대한 개념이 없다는 점에서 다릅니다. "작업을 완료"하는 방법에 대한 제약이 없으므로 독립적으로 존재합니다.
적응형에서는 입력의 품질이 낮고 자연어에 가깝습니다. 어플리케이션 소유자는 필요한 기능을 선언하거나 리소스를 구체적으로 구성할 필요 없이 인프라 컨트롤러에 예상 결과를 알려달라는 요청을 보낼 수 있습니다.
클러스터 간 문제 해결
분산 클라우드는 정의상 모놀리식, 마이크로서비스, 서버리스 등 모든 유형의 어플리케이션 아키텍처를 수용합니다. 아키텍처에 관계없이 어플리케이션은 API를 사용하여 서비스를 제공합니다.
API 검색, 연결, 네트워크 보안 문제는 주로 서비스 메시를 사용하여 해결할 수 있지만, 서비스 메시는 클러스터 내에서만(클러스터 간) 해결할 수 있습니다.
반면에 엣지 2.0 어플리케이션은 초분산 클라우드 인프라, 즉 본질적으로 다중 클러스터 환경에서 API를 활용합니다. 새로운 어플리케이션은 조직 및 지리적 경계를 넘나드는 API로 작성됩니다. 일부 API는 검색이 가능하더라도 여러 계층의 방화벽 뒤에 있는 비공개 또는 파트너 API일 수 있습니다. 이러한 이기종 클러스터(클러스터 간) 문제에는 우아하고 가볍고 확장 가능하며 안전한 솔루션이 실용적이지 않습니다.
| 시나리오/속성 | 명령형 | 선언형 | 적응형 |
|---|---|---|---|
| 정의 | 명령형 인터페이스는 기본 리소스의 특정 기능을 기반으로 세부 제어 흐름을 정의합니다. |
선언적 인터페이스는 로직은 정의하지만 제어 흐름은 정의하지 않습니다. 프로그래밍 용어로 의사 코드라고 할 수 있습니다. |
적응형 인터페이스는 기본 리소스의 기능을 가정하지 않고 원하는 상태를 요구 사항으로 표현합니다. 적응형 인터페이스는 인프라가 소유하며 인프라가 어플리케이션의 변화하는 요구사항에 동적으로 대응할 수 있도록 지원합니다. |
시나리오 1: 패키지가 SFO에서 뉴욕으로 이동해야 하는 경우 |
Jane은 Mark에게 (a) 배송 라벨 인쇄, (b) UPS 매장으로 이동, (c) 72시간 배송 선택, (d) 결제 및 배송을 지시합니다 Mark는 매우 구체적인 단계를 따라야 합니다. |
Jane은 Mark에게 (a)이 패키지를 이 주소로 택배로 보내주세요, (b)패키지는 72시간 이내에 도착해야 합니다. 라고 말합니다. Mark는 모든 택배사(UPS, FedEx, DHL 등)를 선택할 수 있습니다. |
Jane은 Mark에게 (a) 이 패키지는 토요일까지 뉴욕에 도착해야 합니다. 라고 말합니다. Mark는 원하는 것은 무엇이든 할 수 있습니다. 직접 택배를 들고 뉴욕으로 날아가서 직접 배달할 수도 있습니다. |
시나리오 2: 로드 밸런서 예제 |
로드 밸런서가 이미 존재할 경우 이 정책으로 구성해야 합니다. 여기서 작업은 로드 밸런서 제조사, 모델, 버전 등에 따라 다릅니다. |
로드 밸런서가 존재하지 않을 경우 지정된 개방형 정책으로 어플리케이션의 부하를 분산합니다. 작업은 오케스트레이션 |
기본 인프라에 대한 가정은 없습니다. 어플리케이션이 필요에 따라 확장되는지, 최대 지연 시간은 10ms인지 확인해야 합니다. |
소유권 |
공동 소유권: 어플리케이션 및 인프라 |
공동 소유권: 어플리케이션 및 인프라 |
인프라만 |
입력 품질 |
매우 높음. 기본 범위에 대한 깊은 지식이 필요합니다. 예를 들어, 어떤 F5 로드 밸런서, 어떤 소프트웨어 버전 등을 알아야 합니다. 필수 인터페이스의 예로 CLI 또는 NMS를 들 수 있습니다. |
높음: 인프라의 기능에 대한 지식이 필요합니다. 예를 들어, 위의 예에서는 로드 밸런서를 지원하는 인프라에 대한 사전 지식이 있습니다. |
낮음: 인프라의 기능에 대한 지식이 필요하지 않습니다. 입력 품질이 자연어에 준하는 수준입니다. |
기술 수준(페르소나) |
기능별 기술. 예를 들어 네트워크 관리자, 컴퓨팅 관리자, 스토리지 관리자 등 인프라의 모든 측면에서 사용자는 해당 분야의 전문가가 되어야 합니다. |
어플리케이션 배포 기술. 사용자는 어플리케이션 배포에 필요한 기능 유형을 알고 있습니다. 위의 사례에서와 같이 어플리케이션 관리자는 로드 밸런서가 필요하고 자동 확장을 지원하기 위해 LB를 구성해야 하는 상위 수준 정책을 알고 있습니다. |
어플리케이션 엔지니어: 어플리케이션의 비기능적 요구 사항이 무엇인지 인프라에 알릴 수 있습니다. 이 경우 어플리케이션이 고객 요청에 얼마나 빨리 응답해야 하는지입니다. 지리적 위치, 비용 등과 같은 다른 요소는 필요에 따라 추가할 수 있습니다. |
범위 |
필수 인터페이스는 |
선언적 범위가 더 넓습니다. 일반적으로 필요한 결과를 얻기 위해 여러 명령형 인터페이스와 통신하는 오케스트레이션 엔진과 관련이 있습니다. |
|
예 |
- name: 웹 서버 업데이트 hosts: webservers remote_user: root tasks: - name: 아파치가 최신 버전인지 확인 yum: name: httpd state: latest - name: 아파치 구성 파일 쓰기 template: src: /srv/httpd.j2 dest: /etc/httpd.conf |
apache-server: version: “latest” |
application-latency: - lt: 10ms infrastructure-cost: - lt: $200 - billing: monthly |
2021 API 확산 보고서2에서 API에 대해 광범위하게 다루었으며, 그 안에서 드러날 수 있는 많은 질문을 다루었습니다. 그림 6은 클러스터 간과 클러스터 내부의 차이점을 보여줍니다.
클러스터 내: 모놀리식 아키텍처에서는 다른 프로세스 간 통신 방법을 통해 모듈 간 내부 통신을 통해 노출되는 API가 거의 없을 수 있습니다. 반면 마이크로서비스 아키텍처는 수백 개는 아니더라도 수십 개의 API로 세분화됩니다.
어떤 경우든 각 어플리케이션 클러스터는 각자의 의견에 따라 개발 및 관리됩니다. 예를 들어, 마이크로서비스 아키텍처의 경우 팀에서 어떤 종류의 서비스 메시(Estio, Linkerd, Aspen Mesh 등)를 사용할 수 있습니다. 모든 접근 방식에는 클러스터 내, 즉 클러스터 내에서 API를 관리하고 제어하는 고유한 수단이 있습니다.
여기에는 많은 솔루션이 있으며, 엣지 2.0의 목표는 조직이나 개발 팀에 또 다른 신기술을 다시 발명하거나 도입하도록 강요하는 것이 아닙니다.
클러스터 간: API를 통해 제공되는 서비스의 수가 증가함에 따라, 기업 내 여러 어플리케이션 팀에서 이미 개발했거나 채택한 서비스를 사용해 새로운 어플리케이션을 구축할 수 있으므로 새로 발명할 필요가 없습니다.
새로운 어플리케이션은 퍼블릭 및 프라이빗 API의 다양한 조합을 통해 구축되고 있습니다. 아키텍처 관점에서 최신 어플리케이션은 다른 클러스터에서 제공하는 서비스를 활용합니다. 분산 클라우드에서는 이러한 클러스터가 전 세계에 배포되므로 어플리케이션을 호스팅할 수 있는 모든 부동산에 위치하거나 어플리케이션 클러스터의 일부가 될 수 있습니다.
다시 한 번 강조하지만, 어플리케이션 클러스터의 범위는 조직 내에만 국한되지 않습니다. 클러스터는 두 개의 네트워크, 어플리케이션, 조직 사일로 또는 두 기업 간에 존재할 수 있습니다.
이 범위는 모든 순열과 조합의 전체 영역에 걸쳐 있으므로 작업의 복잡성이 기하급수적으로 증가합니다. 그림 7은 어플리케이션 배포 범위 내의 트래픽 순열을 보여줍니다.
일반적인 기업에는 다양한 어플리케이션 아키텍처가 존재합니다. 개발 및 배포하는 팀에 따라 서비스 메시, 서비스 지향 아키텍처 기반의 웹 2.0 어플리케이션, 모놀리식 소프트웨어 배포 등 다양한 형태의 어플리케이션이 존재할 수 있습니다. 따라서 API는 비공개 API 또는 공용 API 사용 등 기업 전체에 흩어져 있습니다. 이 문제는 아직 해결되지 않았습니다. 여러 위치 간의 API 통신은 중요하며 규모에 관계없이 기업에서 해결이 어려운 문제입니다.
주입 컨트롤러, API 게이트웨이 등 클러스터 내에서 API를 관리하는 솔루션은 여러 가지가 있지만, 클러스터 간 API 통신은 실용적이고 확장 가능하며 안전한 방식으로 해결되지 않았습니다. 따라서 통합 API 제어 및 관리의 범위를 클러스터 간 문제만 해결하는 데 집중합니다.
자율성 제공
클라우드의 과소평가된 가치 중 하나는 클라우드가 '클라우드 소비자'에게 제공하는 자율성입니다. 기업과 기업가는 온디맨드 방식으로 자체 인프라를 인스턴스화하면서 완전한 제어권을 경험할 수 있습니다.
엣지 2.0 플랫폼이 따라야 하는 기본 설계 원칙은 올바른 방어막을 구현하면서 클라우드 고객에게 자율적인 경험을 제공하는 것입니다. 엔티티는 모든 인프라(신뢰할 수 있거나 신뢰할 수 없는)에 나타날 수 있으므로 어플리케이션 구축을 담당하는 BU 또는 DevOps 팀에 부담을 주지 않는 방식으로 방어막을 구현해야 합니다.
엣지 2.0의 새로운 과제는 다양한 서비스 간의 검색, ID, 신뢰, 관찰 가능성 문제입니다.
중견 기업의 경우에도 매년 생성되는 API의 수는 많을 것입니다. 팀은 기업 내에서 이러한 서비스를 어떻게 발견할 수 있을까요? 또한 해당 서비스가 여전히 유효한지, 누가 소유하고 있는지 어떻게 알 수 있을까요? 신뢰할 수 있는 검증된 서비스라고 확신할 수 있을까요? 기업 인프라 팀의 관리 통제를 완전히 벗어난 엣지 장치에서 실행되는 SaaS 공급업체 또는 앱처럼 팀이 기업 경계 외부에 있는 클러스터에서 만든 서비스를 사용하려는 경우 문제는 더 복잡해집니다.
엣지 2.0 어플리케이션 플랫폼
이전 섹션에서 제시된 과제를 고려할 때, 전체 분산 클라우드를 플랫폼으로 볼 필요가 있습니다. 높은 수준에서 솔루션의 목표는 분산 인프라 전반에서 분산 어플리케이션을 자율적으로(사람의 개입 없이) 발견하고, 확장하고, 안전하게 보호하는 것이라고 명시합니다.
본질적으로 엣지 2.0 어플리케이션 플랫폼(EAP)의 책임은 다음과 같이 설명할 수 있습니다.
- API 검색, ID 및 신뢰
- 인프라 스케줄링 및 조율
- 어플리케이션 연결 보호
EAP 범위
인프라는 인프라 요소가 지속적으로 나타났다 사라질 수 있는 솔루션 공간의 전체입니다. 인프라 및 해당 리소스의 소유권 대 해당 리소스의 관리 및 제어는 별개의 구성입니다. 인프라 소유자는 특정 인프라 또는 해당 인프라의 인스턴스를 관리 및 구성하는 다른 조직에 할당하거나, 인프라 소유자가 필요에 따라 제어 권한을 되찾을 수 있습니다. 요소를 관리하고 구성하는 조직은 요소를 개별 프로젝트 또는 어플리케이션에 추가로 할당할 수 있습니다. 이러한 개념은 새로운 것이 아닙니다. 예를 들어, 클라우드 서비스 공급업체는 기업의 IT 팀이 내부 사업부, 팀 등에 서비스형 인프라(IaaS)를 추가로 제공하기 위해 사용할 수 있는 계층적 관리 제어 기능을 제공합니다. 엣지 2.0의 주요 관심사는 지속적이고 미래의 엣지 인프라 상태인 초고도 분산 클라우드에서 이를 광범위하게 수행하는 방법입니다.
여기서 EAP의 범위가 드러납니다. 아래 그림 8은 다양한 유형의 인터페이스의 맥락에서 EAP의 범위를 보여줍니다. 각 EAP는 선언적 및 명령형 인터페이스를 사용하여 로컬 범위로 조율합니다. 이 예에서는 다음과 같습니다.
- 선언형/명령형은 AWS API, Azure API 등이 될 수 있습니다.
- 적응형 인터페이스는 사례별로 정의해야 하는 완전히 새로운 인터페이스입니다.
분산 클라우드를 활용하려면 EAP가 분산 클라우드를 통해 사용 가능한 모든 노드와 엔티티를 활용할 수 있어야 합니다. 비전은 개별 EAP가 IP 네트워크의 자율 시스템3 개념과 동등하게 되는 것이지만 어플리케이션 계층에 대해서는 그렇지 않습니다.
이를 종합하면(아래 그림 9) 이제 분산형 클라우드 인프라에서 여러 EAP가 자율적인 방식으로 서로 상호 작용하면서 배포되는 방법에 대한 높은 수준의 보기를 구축할 수 있습니다.
또한 적응형 인터페이스를 사용하면 CI/CD 및 기타 어플리케이션 수명 주기 앱을 분산 클라우드와 쉽게 통합할 수 있습니다. CI/CD 플랫폼은 원하는 결과만 명시하는 간단한 적응형 인터페이스를 통해 EAP와 직접 인터페이스할 수 있습니다.
적응형 인터페이스를 사용하여 EAP 간 통신을 수행할 수도 있다는 점에 유의해야 합니다.
EAP 프레임워크
그림 10에 표시된 것처럼 EAP 프레임워크는 각 EAP 인스턴스의 기능 측면에서 책임을 구성합니다. EAP의 역할은 서비스형 인프라(IaaS), 서비스형 플랫폼(PaaS), 서비스형 소프트웨어(SaaS) 등 기반 인프라 컨트롤러와 인터페이스하고 필요에 따라 적절한 리소스를 조율하고 예약하는 것입니다.
통합 API 제어 및 관리
미래는 API가 서비스 메시를 통해 단순화된 소프트웨어 아키텍처 접근 방식 그 이상의 의미를 갖는 API 중심 경제가 될 것입니다. API는 분산 클라우드에 참여하는 모든 주체가 서비스를 제공하는 주요 수단이 될 것입니다.
앞서 설명한 바와 같이, 10년 내에 전 세계적으로 사용 가능한 공공 및 민간 API의 수는 수십억 개는 아니더라도 수억 개에 달할 것입니다. API는 우리 경제를 재편할 것이며, 따라서 EAP는 이러한 경제를 지원하기 위해 무엇을 구현해야 하는지 면밀히 검토해야 할 것입니다.
API의 증가로 인해 각 API는 EAP 내부와 외부에서 검색 가능해야 합니다. 분산 클라우드를 사용하면 여러 클러스터의 어느 곳에나 API를 배치할 수 있습니다.
기본 가정은 API 검색 문제가 클러스터 간 문제라는 것입니다. EAP의 범위는 서로 다른 소프트웨어 접근 방식(마이크로서비스에서 모놀리식까지)을 사용하는 여러 어플리케이션 클러스터에 걸쳐 있을 수 있으며, 각각 고유한 API 게이트웨이 전략을 구현합니다. EAP는 클러스터 내뿐만 아니라 범위 내에서 등록 및 검색 가능한 모든 API를 위한 공통 저장소를 제공합니다. 이러한 구분은 서비스 메시에서처럼 기존 API 게이트웨이 전략의 한계를 도출하는 데 핵심적인 역할을 합니다.
EAP의 과제는 API를 검색할 수 있도록 하고, 사용법에 대한 올바른 문서를 제공하며, 일관성, 정확성 및 버전 관리를 위해 API의 수명 주기를 관리하는 것입니다. EAP는 API를 사용하는 엔터티에 사용 중인 특정 API의 현재 상태를 알리는 수단을 구현합니다. 이는 단순히 만료일을 설정하거나 일부 메시징 시스템을 통해 명시적으로 알리는 방식이 될 수 있습니다.
채택한 보안 태세는 어플리케이션이 현재 배포된 인프라가 이미 손상된 것으로 가정하는 경우입니다.
이러한 보안 태세를 구현하기 위한 핵심 요소는 ID 기반입니다. 모든 API 엔드포인트에는 전 세계적으로 고유한 ID가 있어야 합니다. 보안 정책과 제어는 중앙 저장소에서 별도로 유지 관리됩니다.
API를 공개 또는 비공개로 표시하여 기본 인프라 보안 구성 요소가 특정 API에 대해 자동으로 구성되도록 해야 합니다.
모든 앱과 앱 간의 대화는 거부 정책으로 시작됩니다. API가 표시된다고 해서 다른 어플리케이션이 이를 호출할 수 있는 것은 아닙니다. 이는 어플리케이션의 보안 정책 내에서 명시적으로 구성해야 합니다.
EAP는 범위 내의 모든 API를 신뢰할 수 있어야 하며, 동시에 범위 내의 서비스에서 사용하는 모든 외부 API도 신뢰할 수 있어야 합니다.
"신뢰를 증명할 수 없는 것, 그것이 바로 '신뢰'입니다." - 영화 반역자들 중에서, Netflix
신뢰는 본질적으로 '시간에 따른 평판'이며, 신뢰가 허용 가능한 수준 이하로 떨어지지 않도록 지속적으로 재검증해야 합니다. 이는 시스템에서 신뢰를 모델링하고 구현하는 데 있어 점점 더 일반적인 접근 방식이 되어가고 있으며, 초기 실행 시 정적으로 신뢰를 주장하는 대신 지속적으로 신뢰를 평가해야 합니다.
시간이 지남에 따라 신뢰가 유동적으로 변하는 것은 자사 시스템과 타사 시스템 간에 상호 평판을 구축할 여유가 없는 일부 기업에게는 어려운 문제일 수 있습니다. 평판을 면밀히 관찰하지 않으면 인프라와 API 모두 큰 혼란을 초래할 수 있습니다.
EAP 범위 내의 서비스가 외부 API에 액세스한다고 가정할 때, 플랫폼은 호출 서비스가 외부 API로부터 받은 응답의 정확성을 보장할 수 있는 메커니즘을 구현해야 합니다. API 응답이 유효해 보인다고 해서 신뢰할 수 있는 것은 아닙니다. 품질 문제로 인해 응답이 부정확하거나 비즈니스 경쟁력을 떨어뜨리기 위해 부정확한 내용이 명시적으로 삽입되었을 수 있습니다. 내부 또는 외부의 각 API에 신뢰 요소를 할당하는 이러한 기능은 EAP 구조에 고유한 기능입니다.
신뢰도를 구현하는 한 가지 전략은 서비스의 전체 기록 대신 가장 최근의 '기간'을 평균하는 것입니다. 이는 Amazon에서 제품에 대한 '최고 리뷰'와 '최근 리뷰'를 비교하는 것과 같습니다. 제품에 별 4개가 있을 수 있지만 부정적인 평가가 대부분 지난 6개월 동안 발생한 것이라면 최근 신뢰가 깨졌음을 의미하며, 지난 6개월 동안 긍정적인 댓글이 유입되면 문제가 해결되었거나 신뢰가 회복되고 있음을 의미합니다.
신뢰 요소는 API가 허위 또는 오해의 소지가 있는 데이터의 출처인지 여부에만 국한되지 않습니다. EAP의 평판은 해당 범위 내에서 API를 얼마나 잘 관리하고 업데이트하는지에 따라 달라집니다. 또한 '신뢰'는 상대적입니다. 서비스 A는 서비스 C를 신뢰할 수 있지만 서비스 B는 서비스 C에 대해 다른 경험을 가질 수 있습니다.
엣지 인프라 관리자
분산 클라우드가 엣지 2.0 인프라의 기반이 되면서 EAP 범위 내의 리소스를 쉽게 검색, 보호, 계측할 수 있어야 합니다. 다음은 엣지 인프라 관리자의 역량에 필요한 일련의 권장 사항으로 읽을 수 있습니다.
EAP 내에서 리소스는 필요에 따라 예약될 수 있습니다. 이동성으로 인해 새로운 리소스가 동적으로 도착하거나 떠날 수 있습니다. 또한 EAP는 다른 EAP로부터 요청을 보내거나 받아 대신 필요한 리소스를 검색하고 예약할 수 있습니다.
보안 태세를 다시 한 번 강조하자면, 어플리케이션이 배포된 인프라는 이미 손상된 상태입니다. 따라서 EAP는 해당 범위 내에서 배포된 어플리케이션의 보안을 보장해야 합니다.
관리 수준에 관계없이 EAP 프레임워크는 다음과 같은 보안의 여러 측면을 고려해야 합니다.
외부 위협: 예를 들어 분산 서비스 거부(DDoS) 공격 및 지능형 지속 위협(APT)이 있습니다. 이러한 위협은 DDoS 방지, 방화벽 등과 같은 기존 보안 모범 사례를 사용하여 완화할 수 있습니다. 모든 트래픽에 필수로 적용하는 것을 권장합니다.
중간자: 모든 트래픽은 암호화되어야 하며 어플리케이션 계층이 올바른 작업을 수행할 것이라고 가정할 수 없습니다. 이를 통해 트래픽 스누핑 장치로부터 기본적인 데이터 기밀성을 보장하고 전송 중 조작으로부터 데이터의 무결성을 보호합니다.
내부 위협: 인프라 계층의 범위는 제한되어야 하며 주로 자체 보호를 위해 사용되어야 합니다. 인프라 내의 리소스가 인프라 관리자에 대한 내부 공격을 시작하지 못하도록 하는 것이 권장 사항입니다.
엣지 2.0이 자산이나 위치가 아니라 제공하는 경험에 관한 것이라면, 텔레메트리도 경험 중심이어야 한다는 것은 당연한 이치입니다.
문제는 누구의 경험을 말하는가 하는 것입니다. 경험이란 앱, 장치, 사람, 백엔드 어플리케이션, 데이터베이스 등 인프라에 상주하거나 인프라를 사용하여 서비스를 생산하거나 소비하는 모든 엔티티의 경험을 말합니다. 따라서 경험의 관점은 엔티티의 경험입니다. 엔티티가 생산하거나 소비하는 서비스는 해당 엔티티에 할당된 컴퓨팅, 스토리지 및 네트워킹 리소스와 직접적으로 관련이 있습니다.
그러나 경험을 측정하는 데 그쳐서는 안 되며, 이를 개선할 수 있는 수단도 있어야 합니다.
서비스를 소비하거나 제공하는 모든 주체는 요청한 경험을 얻고 있는지 여부를 확인할 수 있습니다. 그러나 분산된 클라우드 환경에서는 인프라 계층에서 어떤 일이 발생하여 열악한 경험을 초래했는지 설명하는 것이 거의 불가능할 수 있습니다.
CPU 사용률, 메모리, 대역폭, 지연 시간 측정과 같은 높은 수준의 지표만으로는 어플리케이션이 요청된3 경험을 제공하지 못하는 이유를 파악하기에 충분하지 않습니다. 지표는 시간 단위로 세분화되어야 하며 어플리케이션 스택 내부에서 인프라 스택의 여러 계층에서 가능한 경우 언제든지 수집할 수 있어야 합니다.
강력하고 확장 가능하며 확장 가능한 텔레메트리 및 데이터 전략은 EAP의 핵심입니다. 머신 러닝(ML) 및 인공 지능(AI) 전략을 활용하여 새로운 리소스를 예약하거나 기존 리소스의 사용을 최적화하는 데 있어 최선의 결정을 내릴 수 있습니다.
소프트웨어 정의 어플리케이션 연결 기능
연결성과 도달성은 해결된 문제라고 가정하지만, 많은 네트워크 팀은 여전히 어플리케이션 계층의 동적 요구사항에 따라 네트워크 패브릭을 합리화하는 데 어려움을 겪고 있습니다. 플랫폼은 이러한 문제도 해결해야 합니다.
기존 접근 방식의 문제점은 특히 분산 클라우드에서 어플리케이션 연결 요구 사항을 엔터프라이즈 WAN 연결로 변환한다는 것입니다. 분산 클라우드 네트워크를 해결하기 위한 접근 방식은 다양한 SDN 전략 또는 순수한 라우팅 기반 방법을 사용할 수 있습니다. 그러나 이러한 솔루션은 인프라의 동질성에 크게 의존하기 때문에 일관된 동작을 제공하는 데 부족합니다.
어플리케이션을 위해 전 세계적으로 확장 가능하고 안전하며 안정적인 네트워크를 구축할 수 있는 유일한 방법은 다음에 설명하는 것처럼 어플리케이션 연결 플레인을 기본 네트워크에서 분리하는 것입니다.
분산 클라우드 아키텍처로 진화하는 과정에서 새롭게 부상하는 SDN 패턴은 언더레이 네트워크와 오버레이 네트워크를 공동으로 조율하고 어플리케이션 경로의 포괄적인 프로그래밍을 가능하게 하는 것입니다.
엣지 2.0에서는 엔터프라이즈 네트워크 연결 시에도 이러한 안정성을 제공해야 합니다. 어플리케이션 연결 플레인을 엔터프라이즈 네트워크 연결과 분리할 것을 제안합니다. 어플리케이션 연결 패턴은 VXLAN, NVGRE 등 데이터 센터 오버레이에서 볼 수 있는 것과 동일한 SDN 연결 또는 BGP 기반 SDN 패턴을 따를 수도 있고 따르지 않을 수도 있습니다.
모든 네트워크가 오버레이와 언더레이로 분리되어 있는 것은 아닙니다. 네트워크 팀은 이제 언더레이와 오버레이 네트워크의 분리가 중요한 포괄적 자동화를 구현하기 위한 중요한 요구 사항으로 이러한 공동 프로그래밍 기능의 필요성을 인식하고 있습니다.
어플리케이션 플레인을 언더레이 네트워크 및 전송과 분리하면 네트워크 팀이 모든 어플리케이션 요청에 적극적으로 대응할 필요가 없어집니다. 그 범위는 가장 낮은 지연 시간으로 총 대역폭 사용을 최적화하는 데 중점을 두고 강력하고 안정적이며 잘 정의된 경로를 제공하는 것으로 제한됩니다.
적응형 인터페이스 모델
EAP의 핵심 원칙은 독립적이고 자율적이며 전체 솔루션 공간의 하위 세트를 관리한다는 것입니다. 하지만 EAP는 커뮤니케이션을 통해 리소스를 제공하거나 다른 EAP에 리소스를 요청할 수 있는 수단이 필요합니다. 이 접근 방식에는 몇 가지 장점이 있습니다.
결과에 기반한 인터페이스는 EAP가 다른 인프라에 대한 세부 정보를 알 필요가 없습니다. A와 B라는 두 개의 EAP가 있다고 가정합니다. 각 EAP는 리소스를 예약하고 예약할 수 있는 인프라의 로컬 범위를 가지고 있습니다. EAP-A는 EAP-B가 제공하는 리소스를 알 필요가 없습니다. 예를 들어 EAP-A가 어플리케이션의 요구 사항을 충족할 수 없고 EAP-B의 범위 내에 있는 인프라의 리소스가 필요한 경우 원하는 목표를 EAP-B에 간단히 표현하면 됩니다. 그러면 선언적 또는 명령적 인터페이스를 호출하여 여유 리소스 풀에서 예약, 할당 및 구성하는 것은 EAP-B의 책임입니다. 또한 EAP-B는 인프라 내에서 해당 서비스의 SLO가 충족되도록 하는 책임이 있습니다.
일반적인 구문은 초기 적응형 API 세트를 부트스트랩하는 데 도움이 되지만, 자연어 처리와 AI를 사용하여 필요한 입력 품질을 줄임으로써 시간이 지남에 따라 구현이 더욱 정교해지고 성숙해집니다.
EAP 기능
- 멀티 테넌트: 그림 9에 표시된 EAP 메시가 단일 배포를 위한 것이지만 클라우드당 여러 개의 EAP를 사용할 수 있습니다. 다른 어플리케이션이 다른 EAP 또는 메시와 통신할 수 있습니다.
- 확장하도록 설계: 각 메시가 P2P(피어 투 피어) 메시이며 수평적으로 확장할 수 있습니다. 피어 EAP는 어떤 EAP에 어떤 리소스 유형이 있는지, 리소스에 연결하는 방법을 독립적으로 추적할 수 있습니다. AI/ML은 각 EAP가 자체 범위 내에서 리소스를 예약하거나 필요에 따라 다른 EAP에 연락하는 방법을 더욱 개선합니다.
- 기본 제공 네트워킹: 어플리케이션이 분산된 클라우드에 연결하려면 EAP가 기본 인프라에 관계없이 기본 제공 네트워킹을 지원해야 합니다.
종합
그림 12는 분산 클라우드에 어플리케이션을 배포할 때 다양한 계층의 역할을 시각화한 것입니다.
이 표현의 하이라이트는 다음과 같습니다.
- 각 EAP에는 국지적인 범위가 있으며 모든 기능이 그림 10에 표시되어 있지 않습니다. EAP는 리소스 검색 및 스케줄러 기능을 지원해야 합니다. EAP는 적응형 API를 통해 적절한 인프라 컨트롤러와 인터페이스하여 리소스를 예약합니다.
- 어플리케이션 연결은 서비스 메시 사이드카 모델과 같이 네트워크 연결과 동일하지 않으며, 멀티 클라우드에서 어플리케이션을 연결하는 리소스는 어플리케이션 인프라의 일부여야 합니다. 인프라 플레인이 어플리케이션 네트워크 연결도 제공하므로 네트워크 계층 아래에 있어야 한다고 주장할 수도 있습니다. 기술적으로는 맞지만, 주로 네트워크 기능이므로 '어플리케이션 연결' 플레인 안에 포함하기로 결정했습니다.
- 인프라 플레인은 어플리케이션 플레인과 분리된 것으로 간주해야 합니다.
- 네트워크 연결은 본질적으로 어플리케이션 연결과는 별개의 라우팅 가능한 특정 네트워크에 대해 이야기하는 것이므로 전송과는 다릅니다.
- 전송 플레인은 통신 제공업체가 위의 네트워크 계층을 연결하는 프로세스 및 API를 활성화하는 경우 프로비저닝할 수 있는 종합 백본 네트워크라고 생각할 수 있습니다.
요약
이 백서는 기존 엣지 2.0 선언문에서 몇 가지 계층을 더 세분화합니다. 조직 내부의 다양한 이해관계자와 외부의 업계에 정보를 제공하기 위해 몇 가지 새로운 주제를 추가했습니다.
엣지 2.0은 모든 엔터티가 서비스의 소스이자 대상으로 참여할 수 있는 분산 클라우드라는 개념을 기반으로 합니다. 엣지 2.0의 주요 주제는 자산이나 위치가 아닌 경험에 관한 것입니다.
엣지 어플리케이션 플랫폼(EAP)은 분산 클라우드에서 엣지 2.0을 실현할 수 있도록 지원하는 기능 스택으로 도입되었습니다.
공급업체에 구애받지 않는 시각을 제시하기 위해 구현 세부 사항은 일부러 생략했습니다.
리소스
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3위키백과 - 자율 시스템(AS)은 인터넷에 명확하게 정의된 공통 라우팅 정책을 제공하는 단일 관리 엔티티 또는 도메인을 대신하여 하나 이상의 네트워크 운영자가 제어하는 연결된 인터넷 프로토콜(IP) 라우팅 접두사의 모음입니다.