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