Edge 2.0 핵심 원칙

Rajesh Narayanan, Michael Wiley 작성

소개

엣지의 정의는 언제나 데이터 센터 아키텍처의 발전과 밀접하게 연관되어 왔습니다. 지난 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은 애플리케이션 중심, 운영 중심, 개발자 중심의 경험을 향상하는 데 중점을 둡니다. Edge 2.0은 애플리케이션의 변화하는 요구 사항에 적응하여 SLA 및 SLO와 같은 애플리케이션의 메타 속성을 충족해야 합니다. Edge 2.0은 운영이 간편해야 하며, 운영 팀이 분산 애플리케이션마다 새로운 자동화를 구축해야 하는 부담을 덜어 주어야 합니다. 또한 보안, 거버넌스 및 서비스 수준 목표를 원활하게 지원함으로써 개발자가 분산 애플리케이션을 대규모로 개발하고 배포할 때 겪는 어려움을 줄여야 합니다.

예를 들어 은행 애플리케이션을 살펴보겠습니다. Edge 2.0의 목표는 거래의 비즈니스 로직을 개선하는 것이 아닙니다. 비즈니스 목표를 지원할 수 있도록 보안과 속도, 개인정보 보호를 강화하고, 필요에 따라 모든 지역에서 사용할 수 있게 하며, 규모를 확장하거나 축소할 수 있게 하는 것입니다.

개념 및 주장

다음은 이 논문의 핵심 개념과 주장입니다:

• 경험 중심 엣지: 자산이나 자산의 위치가 아닌, 제공하는 경험을 중심으로 엣지 2.0의 기반을 구축합니다.
• 설계 고려 사항: Edge 2.0 아키텍처를 성공적으로 구현하기 위한 주요 설계 고려 사항을 명시합니다.
• 이기종 인프라: 분산 클라우드를 설계할 때는 인프라에 대한 분산형 제어를 고려해야 한다는 점을 강조합니다.
• 기반으로서의 텔레메트리: 텔레메트리는 인프라의 모든 계층에서 지원되어야 하는 핵심 구성 요소임을 강조합니다. 텔레메트리가 없으면 데이터 우선 전략의 효과가 약화됩니다.
• 클러스터 간 과제: Edge2.0의 근본적인 과제는 클러스터 내부가 아닌 클러스터 간 환경에 있다는 점을 강조합니다.
• 적응형 인터페이스: 적응형 인터페이스를 소개하고, 선언형 및 명령형 인터페이스와의 차이점을 명확하게 비교합니다.
• Edge 2.0 애플리케이션 플랫폼(EAP): Edge 2.0이 애플리케이션의 요구 사항에 맞게 적응할 수 있도록 지원하는 프레임워크로 EAP를 소개합니다.

다루지 않은 주제

이 논문에서 아직 다루지 않은 몇 가지 주제가 있습니다:

• 애플리케이션 데이터 분산: 여기에는 콘텐츠 전송 네트워크(CDN), 스토리지 분산, 데이터 분산, 캐싱 등 다양한 하위 주제가 있습니다. 또한 충돌 없는 복제 데이터 유형(CRDT)과 같은 새로운 기술도 등장하고 있습니다. Edge 2.0 프레임워크는 애플리케이션 데이터 분산 지원을 범위에 포함해야 합니다.
• 기능 분산: 엣지 컴퓨팅의 발전은 핵심 클라우드 기능과 로직이 이벤트가 생성되거나 데이터가 위치한 곳에 더 가까이 이동하는 것으로 볼 수 있습니다. 엣지에서 상당한 규모의 컴퓨팅 자원을 사용할 수 있게 됨에 따라, 이 자원을 활용하려면 기존 클라우드 아키텍처에서 일반적으로 해결하던 것과 유사한 문제를 이제 해결해야 합니다. 예를 들어 오버레이 네트워킹, 미들웨어 워크로드를 비롯해 서로 긴밀하게 얽혀 있으며, 데이터 가까이에서 실행되는 단순한 무상태 흐름인 스토어릿(storlet)과 같은 초기 엣지의 단순한 사용 사례보다 더 복잡한 여러 유형의 워크로드가 이에 해당합니다.
• 논의되지 않은 다른 영역도 있을 수 있습니다. 이 프레임워크의 목표는 필요에 따라 책임 범위를 추가할 수 있도록 확장 가능하게 만드는 것입니다.

엣지의 진화

그림 1은 엣지와 데이터센터 아키텍처가 함께 발전해 온 과정을 가장 잘 보여줍니다. 엣지 1.0과 1.5는 오리진 사이트라는 개념을 기반으로, 데이터와 서비스를 오리진에서 소비자에게 전달하는 방식이었습니다. 엣지 1.0은 분산 콘텐츠 캐싱, 즉 콘텐츠 전송 네트워크를 통해 대역폭 사용을 최적화하는 데 주로 초점을 맞춘 인터넷 인프라 구축 단계였습니다. 전송해야 할 전체 콘텐츠의 양은 항상 가용 대역폭보다 많기 때문에 CDN은 기본적인 설계 패턴입니다.

CPU와 메모리 비용이 급격히 하락하면서 CDN 노드와 함께 컴퓨팅 팜이 등장했습니다. 애플리케이션은 서비스 지향 아키텍처(SOA)를 통해 서비스 형태로 이용되었습니다. 이러한 이유로 Edge 1.5를 서비스 분산 네트워크(Service Distribution Network)라고 부릅니다.

Edge 1.0과 Edge 1.5의 공통적인 특징은 오리진 사이트라는 개념입니다. 모바일이 성장하기 전에는 사람, 기기, 사물이 주로 콘텐츠를 다운로드하거나 서비스의 소비자 역할을 했습니다. 서비스를 제공하는 사이트는 여전히 소비자 측 사이트와 구분되어 있었습니다.

그림 1: 엣지와 인프라의 공동 진화

하지만 Edge 2.0에서는 모든 엔터티가 오리진 사이트 또는 소비자 역할을 할 수 있습니다. 트래픽 흐름도 달라졌습니다. 사람, 휴대폰, 디바이스는 콘텐츠를 업로드하거나 주기적으로 데이터를 생성하면서 능동적으로 데이터를 생산합니다. 애플리케이션은 다른 애플리케이션에 의존하게 되면서 소비자가 되고 있습니다. API, 사람, IoT 디바이스, 웹·백엔드·헤드리스 애플리케이션 등 모든 엔터티가 서비스의 생산자 또는 소비자 역할을 할 수 있습니다. 각자의 관점에서 보면 인프라의 모든 엔터티는 자신이 엣지에 있다고 생각합니다.

분산 클라우드는 데이터 센터 진화의 최신 단계입니다. 컴퓨팅은 모바일 기기에서부터 네트워크에 연결된 일상용품에 내장되는 형태에 이르기까지 진정으로 어디에나 존재하게 되었습니다. 이와 함께 분산형 확장 가능 애플리케이션을 지원하는 소프트웨어 아키텍처도 발전해 왔습니다.

엣지의 영향: 복잡성 증가

어디서나 컴퓨팅 및 스토리지 리소스를 풍부하게 활용하고 초분산할 수 있게 되면서 기업은 빠르게 디지털 혁신을 추진할 기회를 얻게 되었습니다. 하지만 이러한 급속한 발전에는 그에 따른 결과가 있습니다.

대부분의 기업은 일반적으로 서로 다른 환경을 갖춘 이기종 인프라로 구성되어 있습니다. 이러한 환경을 효과적으로 확장하려면 배포된 시스템의 복잡한 오케스트레이션과 자동화가 필요합니다. CPU 및 대역폭 요구 사항의 변화와 같이 애플리케이션 요구 사항이 빠르게 바뀌면 분산 클라우드 전반의 운영 복잡성이 증가합니다. 이로 인해 애플리케이션이나 최종 고객의 변화하는 요구에 효율적으로 대응할 준비가 충분하지 않을 수 있는 운영 팀의 부담이 가중됩니다.

이러한 문제는 운영 복잡성을 초래하며, 이는 디지털 전환을 추진하는 기업이 얻을 수 있는 잠재적 이점을 상쇄합니다.

복잡성으로 인해 발생하는 서로 얽힌 문제와 부작용 중 일부를 다음에서 살펴보겠습니다.

보안 모델은 끊임없이 변화에 발맞춰야 합니다

하이브리드 클라우드는 다양한 공격 벡터로 인해 침해될 수 있는 공격 표면을 확대합니다. 서로 다른 사용 사례는 여러 보안 과제를 야기하며, 인프라가 발전함에 따라 우리는 끊임없이 변화에 뒤처지지 않으려 애쓰고 있습니다. 따라서 우리가 예상하는 문제는 기술 권장 사항만 자주 바뀔 것인지, 아니면 보안을 구현하기 위한 설계 패턴도 함께 바뀔 것인지입니다.

기존 접근 방식에는 다음과 같은 몇 가지 문제가 있습니다:

• 소프트웨어 정의 경계(SDP)는 널리 사용되는 솔루션이 에이전트 기반이어서 운영 환경에 간편하게 배포하기 어렵기 때문에 확장성이 떨어집니다.
• 제로 트러스트 네트워크 액세스(ZTNA)를 구현하려면 트래픽 검사, 중앙 집중식 로그 관리, 글로벌 PKI 및 ID 관리 등 다양한 프로덕션 서비스를 배포해야 하므로 현실적으로 적용하기 어려운 경우가 많습니다.
• 보안 액세스 서비스 엣지(SASE)는 서비스형 네트워크와 서비스형 보안을 결합한 것으로, 구현이 쉽지 않은 여러 기술이 복잡하게 얽혀 있습니다. 또한 SASE는 소프트웨어 정의 광역 네트워크(SD-WAN)에 초점을 맞추는 경향이 있어, 엔터프라이즈 네트워크 엣지 사용 사례 중 일부만 다룹니다.
• 서로 다른 퍼블릭 클라우드 제공업체의 인프라와 이미 복잡한 보안 모델(예: ID 및 액세스 관리(IAM)) 간의 차이로 인해, 팀은 제공업체별 보안을 임시방편으로 강화하고 번거로운 멀티클라우드 구성을 관리해야 하는 경우가 많습니다.

자동화의 과제

엣지에서 사용할 수 있는 저전력·저비용 컴퓨팅이 초분산됨에 따라 발생하는 주요 과제 중 하나는 인프라를 일관된 방식으로 오케스트레이션하고 스케줄링하는 것입니다. 이러한 애플리케이션에는 일반적으로 관리 요구 사항이 서로 다른 이기종 기술이 포함되므로, 운영 팀은 분산 클라우드를 활용하는 애플리케이션을 확장하고 지원하는 데 어려움을 겪습니다.

Terraform와 같은 자동화 플랫폼은 자동화를 정교하게 맞춤 구성할 수 있는 수단을 제공하지만, 운영 팀은 여전히 여러 조합에 맞는 스크립트를 유지 관리해야 합니다. 예를 들어 컴퓨팅 유형 5가지, 방화벽 유형 4가지, 로드 밸런서 유형 3가지에 각각 대응해야 합니다. 자동화 스크립트를 관리하고 유지하는 데 드는 인적 비용은 규모가 커질수록 감당하기 어렵습니다.

이로 인해 인프라 고객은 기존 워크플로의 자동화를 가로막는 티켓 기반 시스템을 통해 운영팀과 계속 소통하게 됩니다. 서비스 데스크에는 티켓이 과도하게 몰려 민첩성보다 보안과 안정성을 우선시할 수밖에 없습니다.

API 난립

멀티 클라우드로의 진화와 함께 마이크로서비스 아키텍처는 이미 새로운 애플리케이션을 구축하는 사실상의 표준 방식으로 자리 잡았습니다. API는 게시된 후 필요할 때 언제 어디서나 인스턴스화할 수 있어 API가 무분별하게 확산됩니다. 이러한 API를 자율적으로 검색하고 연결하며 관리하는 일은 큰 과제가 됩니다.

API 스프롤 문제를 해결하려면 패러다임의 전환이 필요합니다. 당사의 내부 모델에 따르면 전 세계 API 개발자 수, 개발자 1인당 연간 개발 API 수, API 수명과 같은 매개변수를 보수적으로 가정하더라도 2030년에는 수억 개(수십억 개에 이를 수도 있음)의 API가 동시에 활성화될 것으로 예상됩니다(그림 2). 2021 API 스프롤 보고서에서는 새롭게 부상하는 이 주제를 종합적으로 다룹니다.

엔드투엔드 시스템 가시성 부족

복잡성이 증가함에 따라 기업은 전체 시스템을 세부적이고 유의미하게 파악할 수 있는 엔드투엔드 가시성을 확보해야 합니다. 분산형 클라우드 환경에서 애플리케이션은 서로 다른 주체가 관리하는 여러 이기종 인프라 스택에 걸쳐 운영됩니다.

그림 2: 향후 10년간 예상 API 증가량

또한 현재 어떤 운영 사업자도 자사 인프라의 네이티브 텔레메트리 데이터를 기업 고객에게 공개할 유인이 없습니다. 기업은 분산 클라우드에 애플리케이션을 배포할 때 사실상 아무런 가시성 없이 운영하고 있으며, 여러 관측성 도구에 의존해야 합니다. 이러한 가시성의 공백을 메우기 위해 일반적으로 인프라 또는 애플리케이션 스택의 서로 다른 지점에서 작동하는 여러 공급업체의 도구를 사용합니다.

표준화되지 않은 인프라 메트릭은 기업의 어려움을 가중합니다. 일반적으로 운영 사일로와 인프라 환경별로 서로 다른 인프라 등의 요인으로 인해 메트릭이 통합되어 있지 않습니다. 예를 들어 퍼블릭 클라우드 제공업체마다 메트릭이 다르며, 온프레미스 데이터 센터 기술 역시 어떠한 표준 메트릭도 따르지 않습니다.

비즈니스 결과: 저하된 경험

수익을 창출하는 워크로드와 미션 크리티컬 시스템에는 일반적으로 기업에서 사용할 수 있는 운영 리소스와 예산의 대부분이 투입됩니다. 반면, 소규모 프로젝트는 복잡성이 낮지만 기업 애플리케이션의 대다수를 차지하는 경향이 있습니다. 그림 3은 기업이 보유할 것으로 예상되는 프로젝트 수를 운영 복잡성과 비교하여 롱테일 분포로 나타낸 것입니다.

소규모 애플리케이션은 운영 복잡성이 낮을 수 있지만, 운영화 프로세스와 워크플로는 여전히 수작업으로 진행되는 경우가 많으며 서비스 티켓이 여러 운영 팀을 성공적으로 거치는 데 몇 주가 걸릴 수 있습니다. 예를 들어, 세분화된 보안 정책이 적용된 전용 네트워크 리소스가 필요한 애플리케이션을 배포하려면 먼저 글로벌 보안 팀이 보안 정책 승인을 처리해야 할 수 있습니다. 그런 다음 필요한 서브넷 및 경로 구성을 계획하기 위해 서비스 티켓이 네트워킹 팀으로 전달될 수 있습니다. 마지막으로 방화벽 관리를 담당하는 또 다른 운영 팀에서 방화벽 규칙을 검증해야 할 수도 있습니다.

이제 기업이 기반 인프라를 전혀 소유하지 않는 분산 클라우드에 배포된 각 애플리케이션마다 앞서 설명한 복잡성을 해결해야 한다고 가정해 보겠습니다. 온보딩하고 지원해야 할 소규모 프로젝트나 애플리케이션이 워낙 많기 때문에 운영 팀이 모든 프로젝트를 지원하는 것은 현실적으로 불가능하며, 이에 따라 우선순위 지정 문제가 발생하는 동시에 셀프서비스를 도입할 기회가 생깁니다.

그림 3: 프로젝트 규모와 배포 복잡성의 분포

이러한 우선순위 문제는 인프라 팀의 투자가 핵심 시스템과 수익 창출 시스템을 지원하는 데 집중되면서 특히 두드러집니다. 그 결과, 개발과 테스트, 스테이징을 거쳐 프로덕션에 배포되는 자체 수명 주기를 수반하는 완전히 새로운 프로젝트에는 투입할 시간이나 예산이 거의 남지 않습니다. 이는 기능 개발 속도와 맞춤화, 신제품을 뒷받침하는 혁신을 위한 역량과 투자의 감소로 이어지며, 결국 비즈니스와 제품 및 서비스의 정체를 초래합니다.

엣지 솔루션 영역

엣지 생태계의 발전은 애플리케이션 플랫폼을 통해 이러한 과제를 해결할 기회를 제공함으로써 솔루션의 범위를 크게 확장합니다.

그림 4는 Edge 2.0의 솔루션 영역을 보여줍니다. 여기서는 분산 클라우드 아키텍처에 포함되는 모든 것이 전체 솔루션 영역을 구성한다고 정의합니다.

따라서 솔루션 영역의 맥락에서 Edge 2.0은 다음 모든 대상이 원하는 경험을 제공해야 합니다:

• 솔루션 범위 내에 존재하는 모든 엔터티—소비자 역할을 하는 앱, 사람 및 디바이스와 서비스를 구성하는 웹 백엔드 및 헤드리스 애플리케이션.
• 인프라에 요구되는 보안 및 규제 가드레일을 유지하면서 이러한 앱을 담당하는 SRE 팀과 애플리케이션 소유자.

그림 4: Edge 2.0 솔루션 영역

Edge 2.0은 운영이 간편하고 안전하며 규정을 준수하는 동시에, 이에 참여하는 모든 생태계 구성원에게 고품질의 경험을 제공할 것입니다.

Edge 2.0 설계 고려 사항

기본적으로 안전

분산 클라우드에서는 엔드포인트 수가 기하급수적으로 증가함에 따라 대규모 환경의 보안 문제가 더욱 심화됩니다. 이처럼 규모가 방대해지면 솔루션 구현의 복잡성도 함께 증가합니다. 보안 관점에서 애플리케이션은 현재 배포된 환경이 이미 침해되었다고 가정해야 합니다. 마찬가지로 인프라도 그 안에서 실행되는 어떠한 애플리케이션도 신뢰해서는 안 됩니다.

이러한 아이디어의 토대는 제로 트러스트 사고방식의 개념에 담겨 있으며, BeyondCorp1 사례는 애플리케이션 액세스 사용 사례에서 이러한 개념을 잘 보여줍니다. 앞으로 Edge 2.0은 다음의 다섯 가지 핵심 원칙을 바탕으로 이 모델을 확장합니다:

1. ID는 기본 토대입니다. Edge 2.0에서는 ID가 시스템 전반에 깊이 적용되어 각 엔터티 인스턴스가 전 세계적으로 고유한 자체 ID를 가질 뿐만 아니라, 조직 계층 구조 내 위치와 권한 수준도 갖습니다. ID는 남북 방향 트래픽뿐만 아니라 내부의 동서 방향 액세스에서도 핵심 고려 사항이어야 합니다.
2. 최소 권한: 행위자에게 허용되는 작업은 시스템에서 자신의 역할을 수행하는 데 필요한 작업으로만 제한되어야 합니다. 예를 들어 설계 사양에 따라 데이터베이스 서버와 통신할 수 있는 워크로드의 범위를 제한할 수 있습니다.
3. 지속적 인증: 시스템 행위자가 제시하는 모든 증명은 검증할 수 있는 수단을 갖추어야 하며, 그러한 증명이 이루어질 때마다 명시적으로 검증되어야 합니다. 인증은 공유 비밀이나 신뢰 체인을 통한 명시적 방식에만 의존해서는 안 되며, 암묵적인 행동 패턴과 상황별 메타데이터도 고려해야 합니다.
4. 지속적인 모니터링 및 평가: 시스템 내 모든 행위자의 활동을 모니터링해야 하며, 이는 Edge 2.0 아키텍처에서 데이터 수집 및 웨어하우징 기술이 수행하는 핵심 역할을 더욱 강조합니다. 또한 금지되거나 위험한 작업을 수행하려는 시도를 탐지하고 완화하기 위해 이러한 활동을 지속적으로 평가해야 합니다. 평가는 대규모 환경에서 거의 실시간으로 이루어져야 하므로 자동화 및 머신 러닝 기술을 폭넓게 활용해야 합니다.
5. 침해를 전제로 하기: 오늘날의 지능형 공격자가 활용할 수 있는 자원을 고려하면, 모든 시스템이 어떤 식으로든 침해되었다고 가정해야 합니다. 따라서 워크로드와 사용자 ID를 기반으로 하며 a와 b로 표시된 권한 기반 액세스를 적용하는 완전히 결정론적인 정책만으로는 모든 공격을 방지하기에 부족한 경우가 많습니다. 그러므로 완전히 성숙한 Edge 2.0 시스템은 지속적인 모니터링과 평가를 바탕으로 위험과 보상을 실시간으로 평가할 수 있어야 합니다.

네이티브 관측 가능성 제공

Edge 2.0은 텔레메트리를 인프라 스택 전반에 핵심 요소로 깊이 통합하고, 인프라 내 여러 계층의 텔레메트리를 수집할 수 있는 간단하고 확장 가능한 수단을 제공하며, 이를 공통 플랫폼에 표시해야 합니다. 이를 통해 관측성 팀은 필요에 따라 ‘인프라 상태’를 조회할 수 있습니다. 또한 애플리케이션 팀은 애플리케이션 스택을 명시적으로 계측하지 않고도 비즈니스 로직에 집중할 수 있습니다.

그림 5: 텔레메트리 수집기의 발전

현재의 관측 가능성 기술은 대부분 특정 공급업체에 종속된 독점 기술입니다. 이로 인해 여러 공급업체별 에이전트가 유사한 신호를 수집하면서 값비싼 메모리와 CPU 리소스를 두고 경쟁하게 되었습니다.

다음으로 자연스럽게 고려할 단계는 공급업체에 종속되지 않는 텔레메트리 수집기를 사용하여 인프라 및 트래픽 데이터를 중앙 집중식 데이터 플랫폼으로 스트리밍하는 것입니다.

많은 제품 팀이 계측에 드는 노력을 수익 창출 기회와 연결해야 하므로 관련 투자의 타당성을 입증하는 데 어려움을 겪습니다. 팀이 비즈니스 목표에 맞게 인프라를 최적화하려면 그 동작을 이해해야 하므로, 다른 비즈니스 기능이나 프로세스와 마찬가지로 인프라도 계측해야 합니다. 따라서 계측의 필요성 자체보다는 무엇을 우선적으로 계측해야 하는지를 논의해야 합니다.

애플리케이션 동작을 더 세분화하고 정확하게 측정하기 위해, 계측은 코드를 작성하는 시점에 적용하는 방식으로 ‘시프트 레프트’될 것으로 예상합니다(그림 5).

적응형 인터페이스 지원

분산 클라우드의 개념에 따라 몇 계층을 더 들여다보면, 각 클라우드는 로컬이든 글로벌이든 해당 범위 내에서 자체 관리자, 운영자, 오케스트레이터 등을 갖추고 있습니다. 각각은 독립적으로 동작하고 자체적으로 의사 결정을 내리면서도, 필요에 따라 다른 엔터티가 사용할 수 있는 인터페이스를 제공합니다.

따라서 분산 클라우드의 개념은 본질적으로 관리와 제어의 분산화를 의미합니다. 이 사실은 피할 수 없으며, 적응형 인터페이스와 선언형 및 명령형 인터페이스 간의 미묘한 차이를 더 잘 이해하려면 이를 인식하는 것이 중요합니다.

Edge 2.0 인프라를 효과적으로 활용하려면 명령형 및 선언형 인터페이스만으로는 충분하지 않습니다. 이러한 인터페이스는 여전히 수작업으로 만든 산출물에 의존하며, 이는 본질적으로 정적인 구조이기 때문에 급변하는 상황에 충분히 빠르게 적응하지 못합니다.

우리가 나아가야 할 방향은 성과 중심이며, 시스템은 이러한 성과를 달성할 수 있도록 전체 인프라(엔드 투 엔드)의 정책을 조정할 만큼 충분히 지능적이어야 합니다. 이를 적응형 인터페이스라고 합니다.

분명히 말하자면, 명령형, 선언형, 적응형 인터페이스는 상호 배타적이지 않습니다.

명령형: 매우 구체적인 지침을 제시하며 원하는 상태에 도달하기 위한 일련의 작업을 상세히 정의합니다. 예를 들어 라우터 구성은 명령형 작업입니다. 위 시나리오에서는 사용할 데이터 센터, CPU/메모리 용량, 필요한 대역폭, 특정 경로 등 수행할 작업이 정확하게 지정됩니다. 데이터 모델에 입력되는 정보의 품질이 매우 높아야 하므로 인프라에 대한 깊이 있는 지식과 전문성이 필요합니다. 또한 인프라의 모델과 구조를 모두 알고 있어야 합니다.

선언형: 선언형의 특징은 원하는 상태를 달성하기 위한 작업이 아니라 원하는 상태 자체를 기술하는 데 중점을 둔다는 것입니다. 입력에 요구되는 품질 수준은 더 낮지만, 애플리케이션이 최소한 기반 인프라의 구조는 알고 있어야 합니다.

적응형: 명령형이나 선언형과는 별개의 방식입니다. 적응형 인터페이스는 상태가 아니라 원하는 목적이나 목표에 중점을 둡니다. 적응형 인터페이스의 목표는 기반 시스템에 대한 사전 지식에 초점을 맞추기보다 애플리케이션을 배포하려는 이해관계자의 목적을 파악하는 것입니다. 적응형은 기반 인프라의 기능이 무엇인지 전제하지 않는다는 점에서 다릅니다. ‘작업을 완수하는’ 방식에 제약이 없으므로 독립적인 방식으로 구분됩니다.

적응형 방식에서는 입력의 정형화 수준이 낮고 자연어에 가깝습니다. 애플리케이션 소유자는 필요한 기능을 명시하거나 리소스를 구체적으로 구성하는 대신, 인프라 컨트롤러에 요청을 보내 기대하는 결과를 전달할 수 있습니다.

클러스터 간 문제 해결

분산 클라우드는 그 정의상 모놀리식, 마이크로서비스, 서버리스 등 모든 유형의 애플리케이션 아키텍처를 지원합니다. 아키텍처와 관계없이 애플리케이션은 API를 사용하여 서비스를 제공합니다.

API 검색, 연결 및 네트워크 보안 문제는 서비스 메시를 사용하면 대부분 해결할 수 있지만, 서비스 메시는 클러스터 내부(클러스터 내)에서만 이러한 문제를 해결합니다.

반면 Edge 2.0 애플리케이션은 초분산 클라우드 인프라, 즉 본질적으로 멀티 클러스터 환경 전반에서 API를 활용합니다. 새로운 애플리케이션은 조직 및 지리적 경계를 넘나드는 API를 사용해 작성됩니다. 일부 API는 검색할 수 있더라도 여러 계층의 방화벽 뒤에 있어 서로 간에 명시적인 경로가 없는 비공개 API 또는 파트너 API일 수 있습니다. 이러한 이기종 클러스터(클러스터 간) 문제에는 실용적이면서도 세련되고 가벼우며 확장 가능하고 안전한 해결책이 아직 없습니다.

2021 API 스프롤 보고서2에서는 API를 폭넓게 다루고, 제기될 수 있는 여러 질문에 답했습니다. 그림 6은 클러스터 간 통신과 클러스터 내 통신의 차이를 보여줍니다.

그림 6: 클러스터 내부와 클러스터 간 비교

클러스터 내부: 모놀리식 아키텍처에서는 외부에 노출되는 API가 매우 적고, 모듈 간 내부 통신에는 다른 프로세스 간 통신 방식이 사용될 수 있습니다. 반면 마이크로서비스 아키텍처는 수십 개, 많게는 수백 개의 API로 세분화됩니다.

어떤 경우든 각 애플리케이션 클러스터는 정해진 방식에 따라 개발되고 관리됩니다. 예를 들어 마이크로서비스 아키텍처의 경우, 팀은 Istio, Linkerd, Aspen Mesh 등 다양한 서비스 메시 중 하나를 사용할 수 있습니다. 각 접근 방식에는 클러스터 내부, 즉 인트라 클러스터의 API를 관리하고 제어하는 고유한 수단이 있습니다.

여기에는 이미 다양한 솔루션이 있으며, Edge 2.0의 목표는 기존 기술을 새로 만들거나 조직 또는 개발팀에 또 다른 신기술 도입을 강요하는 것이 아닙니다.

클러스터 간: API를 통해 제공되는 서비스가 늘어남에 따라, 이미 있는 것을 새로 만들 필요 없이 기업 내 여러 애플리케이션 팀이 기존에 개발하거나 도입한 서비스를 활용해 새로운 애플리케이션을 구축합니다.

새로운 애플리케이션은 퍼블릭 API와 프라이빗 API를 다양하게 조합하여 구축되기도 합니다. 아키텍처 관점에서 최신 애플리케이션은 다른 클러스터에서 제공하는 서비스를 활용합니다. 분산 클라우드에서는 이러한 클러스터가 전 세계에 배포되므로, 애플리케이션을 호스팅하거나 애플리케이션 클러스터의 일부가 될 수 있는 모든 인프라 환경에 위치할 수 있습니다.

애플리케이션 클러스터의 범위

다시 말해, 애플리케이션 클러스터의 범위는 단일 조직 내부로만 제한되지 않습니다. 클러스터는 서로 다른 두 네트워크, 애플리케이션, 조직 사일로는 물론 두 기업 간에도 구성될 수 있습니다.

이 범위는 가능한 모든 순열과 조합을 아우르므로 운영 복잡성이 기하급수적으로 증가합니다. 그림 7은 애플리케이션 배포 범위 내의 트래픽 조합을 보여 줍니다.

그림 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는 선언형 및 명령형 인터페이스를 사용하여 로컬 범위 내에서 오케스트레이션을 수행합니다. 이 경우에는 다음과 같습니다:

• 선언형/명령형 인터페이스에는 AWS API, Azure API 등이 해당합니다.
• 적응형 인터페이스는 완전히 새로운 것으로, 사례별로 정의해야 합니다.

그림 8: 인터페이스 유형별 EAP 범위 매핑

분산 클라우드의 이점을 활용하려면 EAP가 분산 클라우드를 통해 제공되는 모든 노드와 엔터티를 활용할 수 있어야 합니다. 궁극적으로는 개별 EAP가 애플리케이션 계층에서 IP 네트워크의 자율 시스템3 개념에 상응하는 역할을 하도록 하는 것이 목표입니다.

이러한 내용을 종합하면(아래 그림 9), 여러 EAP가 분산형 클라우드 인프라 전반에 배포되어 자율적으로 상호 작용하는 방식을 개괄적으로 파악할 수 있습니다.

적응형 인터페이스를 사용하면 CI/CD 및 기타 애플리케이션 수명 주기 앱을 분산형 클라우드와 손쉽게 통합할 수도 있습니다. CI/CD 플랫폼은 원하는 결과만 명시하는 간단한 적응형 인터페이스를 통해 EAP와 직접 연동할 수 있습니다.

적응형 인터페이스를 사용하면 EAP 간 통신도 구현할 수 있다는 점에 유의해야 합니다.

그림 9: 로컬 범위를 갖는 EAP의 상위 수준 토폴로지

EAP 프레임워크

그림 10에 나와 있는 것처럼 EAP 프레임워크는 각 EAP 인스턴스의 기능을 기준으로 책임을 구성합니다. EAP의 역할은 서비스형 인프라(IaaS), 서비스형 플랫폼(PaaS), 서비스형 소프트웨어(SaaS) 등 기반 인프라 컨트롤러와 연동하고, 필요에 따라 적절한 리소스를 오케스트레이션하고 스케줄링하는 것입니다.

그림 10: Edge 2.0 애플리케이션 플랫폼(EAP) 프레임워크

통합 API 제어 및 관리

미래에는 API가 주도하는 경제가 펼쳐질 것이며, API는 서비스 메시를 통해 간소화된 소프트웨어 아키텍처 접근 방식을 넘어서는 의미를 갖게 될 것입니다. API는 분산 클라우드에 참여하는 모든 주체가 서비스를 제공하는 핵심 수단이 될 것입니다.

앞서 살펴본 바와 같이, 전 세계에서 이용 가능한 퍼블릭 및 프라이빗 API의 수는 향후 10년 이내에 수억 개, 많게는 수십억 개에 이를 것입니다. API는 우리 경제를 재편할 것이므로, 이러한 경제를 지원하기 위해 EAP가 무엇을 구현해야 하는지 면밀히 살펴볼 필요가 있습니다.

API 검색

임박한 API 확산에 대응하려면 각 API를 EAP 내부와 외부에서 모두 검색할 수 있어야 합니다. 분산 클라우드 환경에서는 API가 여러 클러스터에 걸쳐 어디에나 존재할 수 있습니다.

기본 전제는 API 검색 문제가 실제로 클러스터 간 문제라는 것입니다. EAP의 범위에는 서로 다른 소프트웨어 접근 방식(마이크로서비스부터 모놀리식까지)을 사용하고 각기 자체적인 API 게이트웨이 전략을 구현하는 여러 애플리케이션 클러스터가 포함될 수 있습니다. EAP는 클러스터 내부에 국한되지 않고, 범위 내의 모든 API를 등록하고 검색할 수 있는 공통 저장소를 제공합니다. 이러한 차이는 서비스 메시의 사례처럼 기존 API 게이트웨이 전략의 한계를 도출하는 데 핵심적인 요소입니다.

EAP의 과제는 API를 검색할 수 있도록 하고, 사용 방법에 관한 적절한 문서를 제공하며, 일관성, 정확성 및 버전 관리를 위해 API의 수명 주기를 관리하는 것입니다. EAP는 API를 사용하는 주체에게 현재 사용 중인 특정 API의 상태를 알리는 수단을 구현합니다. 이는 만료일을 설정하는 간단한 방식일 수도 있고, 특정 메시징 시스템을 통해 명시적으로 알리는 방식일 수도 있습니다.

ID 기반 보안

채택된 보안 태세는 애플리케이션이 현재 배포된 인프라가 이미 침해되었다고 가정하는 것입니다.

이러한 보안 태세를 구현하는 핵심 요소는 ID 중심 접근 방식입니다. 모든 API 엔드포인트에는 전역적으로 고유한 ID가 있어야 합니다. 보안 정책과 제어는 중앙 리포지토리에서 별도로 관리됩니다.

API는 공개 또는 비공개로 표시해야 하며, 이에 따라 기본 인프라 보안 구성 요소가 해당 API에 맞게 자동으로 구성됩니다.

모든 앱 간 통신에는 기본적으로 전체 거부 정책이 적용됩니다. API가 노출되어 있다고 해서 다른 애플리케이션이 해당 API를 호출할 수 있는 것은 아닙니다. 이는 애플리케이션의 보안 정책에서 명시적으로 구성해야 합니다.

신뢰: 시간이 쌓아 올린 평판

EAP는 해당 범위 내의 모든 API를 신뢰할 수 있도록 보장해야 하며, 동시에 해당 범위 내의 서비스에서 사용하는 모든 외부 API 역시 신뢰할 수 있도록 보장해야 합니다.

“신뢰는 증명할 수 없어. 그렇기 때문에 ‘신뢰’인 거야.” – 넷플릭스 <트레이터스> 중에서

신뢰란 본질적으로 ‘시간이 흐르며 쌓이는 평판’이며, 그 신뢰가 허용 가능한 수준 아래로 떨어지지 않았는지 지속적으로 재검증해야 합니다. 이는 시스템에서 신뢰를 모델링하고 구현할 때 점점 더 보편적인 접근 방식으로 자리 잡고 있으며, 최초 실행 시 신뢰를 정적으로 단정하는 대신 지속적으로 평가해야 합니다.

시간이 지남에 따라 신뢰가 유동적으로 변한다는 점은 자사 시스템과 타사 시스템 간에 상호 평판을 구축할 시간적 여유가 없는 일부 기업에 어려움이 될 수 있습니다. 평판을 면밀히 모니터링하지 않으면 인프라와 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는 자체 범위 내에 배포된 애플리케이션의 보안을 보장해야 합니다.

관리 수준과 관계없이 EAP 프레임워크는 다음을 포함하되 이에 국한되지 않는 다양한 보안 측면을 고려해야 합니다:

외부 위협: 예를 들어 분산 서비스 거부(DDoS) 공격과 지능형 지속 위협(APT)이 있습니다. 이러한 위협은 DDoS 방어, 방화벽 등의 기존 보안 모범 사례를 활용하여 완화할 수 있습니다. 모든 트래픽에 이러한 보안 조치를 적용할 것을 권장합니다.

중간자 공격: 모든 트래픽은 암호화되어야 하며, 애플리케이션 계층이 적절히 처리할 것이라고 가정해서는 안 됩니다. 이를 통해 트래픽을 감시하는 장치로부터 기본적인 데이터 기밀성을 보장하고, 전송 중 조작으로부터 데이터 무결성을 보호할 수 있습니다.

내부 위협: 인프라 계층의 범위는 제한되어야 하며, 주로 자체 보호에 초점을 맞춰야 합니다. 인프라 내의 리소스가 인프라 관리자를 대상으로 내부 공격을 감행하지 못하도록 방지하는 것이 좋습니다.

경험 중심 텔레메트리

Edge 2.0이 자산이나 자산의 위치가 아니라 제공하는 경험에 초점을 맞춘다면, 텔레메트리 역시 경험 중심이어야 하는 것은 당연합니다.

문제는 우리가 누구의 경험을 말하는가입니다. 여기서 경험이란 인프라에 상주하거나 인프라를 사용하여 서비스를 제공 또는 이용하는 모든 엔터티, 즉 앱, 디바이스, 사람, 백엔드 애플리케이션, 데이터베이스 등의 경험을 의미합니다. 따라서 경험의 관점은 해당 엔터티의 관점입니다. 엔터티가 제공하거나 이용하는 서비스는 해당 엔터티에 할당된 컴퓨팅, 스토리지 및 네트워킹 리소스와 직접적으로 연관됩니다.

하지만 경험을 측정하는 데 그쳐서는 안 되며, 이를 개선할 수 있는 수단도 마련되어야 합니다.

서비스를 이용하거나 제공하는 모든 주체는 자신이 요청한 경험을 얻고 있는지 판단할 수 있습니다. 그러나 분산형 클라우드 환경에서는 인프라 계층에서 어떤 일이 발생해 만족스럽지 못한 경험으로 이어졌는지 설명하기가 거의 불가능할 수 있습니다.

CPU 사용률, 메모리, 대역폭, 지연 시간 측정값과 같은 상위 수준의 메트릭만으로는 애플리케이션이 요청한 경험을 제공받지 못하는 이유를 파악하기에 충분하지 않습니다. 메트릭은 세밀한 시간 단위로 측정되어야 하며, 애플리케이션 스택의 심층부와 가능한 경우 인프라 스택의 여러 계층에서 수집되어야 합니다.

견고하고 확장 가능하며 유연하게 확대할 수 있는 텔레메트리 및 데이터 전략은 EAP의 핵심입니다. 이를 바탕으로 머신 러닝(ML)과 인공 지능(AI) 전략을 활용하여 새로운 리소스를 확보하거나 기존 리소스의 활용을 최적화하기 위한 최선의 결정을 내릴 수 있습니다.

소프트웨어 정의 애플리케이션 연결

연결성과 도달 가능성은 이미 해결된 문제로 여겨지지만, 많은 네트워크 팀은 여전히 네트워크 패브릭을 애플리케이션 계층의 역동적인 요구 사항에 맞게 조정하는 데 어려움을 겪고 있습니다. 플랫폼은 이러한 과제도 해결해야 합니다.

애플리케이션 연결 계층을 분리해야 하는 이유

기존 접근 방식의 문제점은 특히 분산 클라우드 환경에서 애플리케이션의 연결 요구 사항을 엔터프라이즈 WAN 연결 요구 사항으로 변환한다는 데 있습니다. 분산 클라우드 네트워크를 구현하기 위해 다양한 SDN 전략이나 순수 라우팅 기반 방식을 사용할 수 있습니다. 하지만 이러한 솔루션은 인프라의 동질성에 크게 의존하므로 일관된 동작을 제공하는 데 한계가 있습니다.

애플리케이션을 위한 전 세계적으로 확장 가능하고 안전하며 안정적인 네트워크를 구현할 수 있는 유일한 방법은 다음에서 설명하듯이 애플리케이션 연결 계층을 기반 네트워크와 분리하는 것입니다.

제안된 연결성 스택

분산 클라우드 아키텍처로 발전해 나가는 과정에서 새롭게 부상하는 SDN 패턴은 언더레이 네트워크와 오버레이 네트워크를 통합 오케스트레이션하고, 애플리케이션 경로 전 구간의 프로그래밍 기능을 지원하는 것입니다.

그림 11: 애플리케이션 연결 계층이 언더레이(엔터프라이즈 및 백본 네트워크)와 다름을 보여줍니다.

Edge 2.0에서는 엔터프라이즈 네트워크를 연결할 때도 이와 유사한 안정성을 확보해야 합니다. 이를 위해 애플리케이션 연결 플레인을 엔터프라이즈 네트워크 연결과 분리할 것을 제안합니다. 애플리케이션 연결 패턴은 데이터 센터 오버레이에서 볼 수 있는 것과 동일한 SDN 연결 방식(예: VXLAN, NVGRE 등)이나 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 메시(mesh)는 단일 배포를 위한 것이지만, 클라우드당 여러 EAP를 구성할 수도 있습니다. 다른 애플리케이션은 별도의 EAP 또는 EAP 메시와 통신할 수 있습니다.
• 확장성을 고려한 설계: 각 메시는 P2P(피어 투 피어) 메시로 구성되며 수평적으로 확장할 수 있습니다. 피어 EAP는 어떤 EAP가 어떤 리소스 유형을 보유하고 있는지, 그리고 해당 리소스에 어떻게 연결하는지를 독립적으로 추적할 수 있습니다. AI/ML을 통해 각 EAP가 자체 범위 내에서 리소스를 스케줄링하거나 필요에 따라 다른 EAP에 요청하는 방식이 더욱 향상될 것입니다.
• 내장형 네트워킹: 애플리케이션이 분산 클라우드 전반에서 연결되려면 EAP가 기반 인프라에 구애받지 않는 내장형 네트워킹을 지원해야 합니다.

종합하기

그림 12는 분산 클라우드에 애플리케이션을 배포할 때 각 계층이 수행하는 역할을 시각적으로 보여줍니다.

이 표현의 주요 특징은 다음과 같습니다:

• 각 EAP는 지역화된 범위를 가지며, 그림 10에는 모든 기능이 표시되어 있지 않습니다. EAP는 리소스 검색 및 스케줄러 기능을 지원해야 합니다. EAP는 적응형 API를 통해 적절한 인프라 컨트롤러와 연동하여 리소스를 스케줄링합니다.

그림 12: 다양한 엔터티와 계층의 역할을 보여주는 참조도.

• 애플리케이션 연결은 네트워크 연결과 동일하지 않습니다. 서비스 메시 사이드카 모델과 마찬가지로 멀티클라우드 전반에서 애플리케이션을 연결하는 리소스는 애플리케이션 인프라의 일부여야 합니다. 인프라 플레인도 애플리케이션 네트워크 연결을 제공하므로 네트워크 계층 아래에 있어야 한다고 주장할 수도 있습니다. 기술적으로는 이 역시 맞지만, 이러한 기능은 주로 네트워크 기능이므로 여기서는 이를 ‘애플리케이션 연결’ 플레인에 포함했습니다.
• 인프라 계층은 애플리케이션 계층과 별개로 간주해야 합니다.
• 네트워크 연결은 전송 계층과는 다릅니다. 여기서 말하는 것은 본질적으로 애플리케이션 연결과 분리된, 라우팅 가능한 특정 네트워크이기 때문입니다.
• 전송 플레인은 통신 사업자가 상위 네트워크 계층을 연결하기 위한 프로세스와 API를 지원한다는 전제하에 프로비저닝할 수 있는 통합 백본 네트워크로 볼 수 있습니다.

요약

이 백서는 기존 Edge 2.0 선언문의 내용을 몇 단계 더 깊이 있게 살펴보고자 합니다. 또한 조직 내부의 다양한 이해관계자와 외부 업계 관계자에게 정보를 제공하기 위해 몇 가지 새로운 주제를 소개합니다.

Edge 2.0은 모든 개체가 서비스의 제공자이자 이용자로 참여할 수 있는 분산형 클라우드라는 개념을 기반으로 합니다. 핵심 주제는 Edge 2.0이 자산이나 위치가 아닌 경험에 초점을 맞춘다는 것입니다.

에지 애플리케이션 플랫폼(EAP)은 분산 클라우드에서 Edge 2.0을 구현할 수 있도록 지원하는 기능 스택으로 소개됩니다.

벤더에 구애받지 않는 관점을 제시하기 위해 구현 세부 사항은 의도적으로 생략했습니다.