brunch

You can make anything
by writing

C.S.Lewis

by 김영욱 Dec 14. 2023

멀티 클라우드를 위한 오픈소스 개발 플랫폼 Radius

이 글은 제가 NIA [한국지능정보사회진흥원]의 < 디지털서비스 이슈리포트 > 2023년 11월호에 기고한 글입니다. 원본 글 '멀티 클라우드 컴퓨팅을 위한 오픈 소스 개발 플랫폼 Radius'을 이곳 브런치에서도 공유합니다.

멀티 클라우드

시장 조사 및 데이터 회사 스태티스타(Statista)가 발표한 자료[1]에 따르면 현재 대다수의 기업이 두 개 이상의 IaaS 퍼블릭 클라우드 회사를 이용하고 있다. 2021년까지 대기업의 90%가 멀티 클라우드 접근 방식을 채택했으며 2023년에는 이 수치가 94%까지 증가했다. 중소기업의 60%도 현재 두 개 이상의 IaaS 클라우드 플랫폼을 사용하고 있지만 2023년에는 그 비율이 79%로 약 20% 증가했다. 중견 기업의 4분의 3 이상이 멀티 클라우드 전략을 사용하고 있으며, 2023년에는 84%까지 증가했다.

그림 1. 전 세계 멀티 클라우드 도입률, 조직 규모별 (출처: Statista)

멀티 클라우드 전략이 현재 IaaS 시장을 지배하고 있는 것은 분명하지만, 모든 시장 조사에서 같은 수준의 답이 나타나는 것은 아니다. 예를 들어, 베인 앤 컴퍼니의 설문조사[2] 에 따르면 응답 기업의 2/3가 종속을 피하기 위해 여러 IaaS 공급업체의 클라우드 서비스를 사용하는 것을 선호한다고 답했음에도 불구하고 71%가 여전히 하나의 클라우드 공급업체에만 의존하고 있는 것으로 나타났다. 대기업은 모두 공식적으로 멀티 클라우드 혹은 하이브리드 전략을 가지고 있다. 하지만 실제로는 사용자 애플리케이션의 부하를 여러 퍼블릭 클라우드 제공업체에 분산하는 경우는 드물다. 멀티 클라우드 전략의 가장 일반적인 사례는 보다 민감한 데이터와 관련된 업무 부하를 보다 안전한 클라우드 환경으로 분산하는 데 사용되는 전략이다.

분명 기업이 멀티 클라우드 전략을 선택하는 데는 여러 이점이 있다. 프로바이더에 종속되는 위험을 방지할 수 있고, 클라우드 컴퓨팅 비용을 최적화할 수 있으며, 서비스 보안이나 데이터 주권 요구사항에 탄력적으로 대응할 수 있고, 다양한 워크로드를 제공업체 간에 원활하게 이동할 수 있는 자유를 누릴 수 있으며, 각 제공업체의 강점을 최대한 활용하면서 약점은 최소화할 수 있다. 그런데 이 많은 장점에도 불구하고 하나의 너무나 큰 약점이 이 멀티 클라우드 전략을 선뜻 선택하지 못하게 한다. 바로 개발과 운영 비용이 비싸다는 데 있다. 클라우드 개발 및 DevOps 전문가는 AWS 또는 마이크로소프트 애저와 같은 하나의 주요 클라우드 플랫폼에 특화된 경향이 있다. 크로스 플랫폼 경험이 있는 전문가를 고용하거나 지식 격차를 메우기 위해 추가 전문가를 고용하려면 비용이 크게 증가한다.

오픈소스 네이티브 애플리케이션 플랫폼Radius

지난 10월 말에 열린 리눅스 재단 멤버 서밋에서 마이크로소프트는 획기적인 오픈 소스 프로젝트인 레이디어스(Radius)를 공개했다.[3] 이 클라우드 네이티브 애플리케이션 플랫폼은 개발자와 운영자가 퍼블릭 클라우드와 프라이빗 인프라 전반에서 클라우드 네이티브 애플리케이션을 정의, 배포 및 협업할 수 있도록 지원한다.

혹시 Radius라는 단어에 익숙한 엔터프라이즈 사용자에게는 혼란을 피하기 위해 이 설명을 필요하다. 마이크로소프트 기술 스택에서 원격 및 클라우드 액티브 디렉토리(Active Directory) 서비스를 제공할때 사용하는 모두 영문 대문자로 표기된 RADIUS(Remote Authentication Dial-In User Service- 원격 인증 전화 접속 사용자 서비스) 프로토콜과 이 글의 주제인 클라우드 네이티브 애플리케이션 플랫폼 Radius는 서로 아무 관련이 없는 서로 다른 것이다.

클라우드 컴퓨팅의 발전은 많은 기업의 혁신 속도를 높였다. 그중 쿠버네티스와 같은 클라우드 네이티브 기술 덕분에 어디서나 실행할 수 있는 애플리케이션을 더 쉽게 구축할 수 있게 되었다. 동시에 기업들의 클라우드 네이티브 애플리케이션은 상호 연결된 마이크로 서비스로 구성되고 여러 퍼블릭 클라우드와 프라이빗 인프라에 배포함에 따라 더욱 복잡해지게 되었다. 클라우드에서 이를 관리하는 것이 점점 더 어려워지는 것이 사실이다.

이번에 발표한 Radius는 클라우드 네이티브 컴퓨팅의 복잡한 환경에서 개발, 관리 및 운영상의 여러 어려움을 간소화하는 것을 목표로 한다. 쿠버네티스와 같은 클라우드 네이티브 기술을 통해 어디서나 실행할 수 있는 애플리케이션을 더 쉽게 구축할 수 있다는 것은 사실 실제 실행해 본다면 생각보다 훨씬 더 어렵다는 것을 안다. 애저와 AWS에서 동일하게 실행되는 애플리케이션을 작성하는 것은 사실 매우 어려운 일이다.

쿠버네티스가 멀티 클라우드 컴퓨팅을 위한 핵심적인 기술을 제공하는 게 맞지만, 많은 고객 경험 사례에서는 일반적으로 하나의 추상화층을 쿠버네티스 위에 구축한다. 애플리케이션에 대한 공식적인 정의가 없고, 인프라와 애플리케이션 개념이 뒤섞여 있기에 사실 쿠버네티스는 복잡하다. 따라서 개발자는 이것을 해결하기 위해 API 프런트 엔드, 키-값 저장소, 캐시 및 가시성 시스템과 같은 종속성 지원과 같은 훨씬 더 많은 일이 필요하다. 개발자가 이러한 과제를 안고 있는 가운데, 기업 IT 담당자는 계속해서 증가하는 기업 표준, 규정 준수 및 보안 요구사항을 적용하는 동시에 신속한 애플리케이션 혁신을 지원해야 한다. 즉 많은 기술 기업은 클라우드 서비스 제공업체에서 호스팅 하거나 통합할 수 있는 휴대용 또는 호스트 프리 플랫폼에 높은 관심이 있다. 마이크로소프트는 개발자들이 쿠버네티스를 넘어서는 사고를 할 수 있도록 하고, 기존의 여러 쿠버네티스의 불편함을 해소하기 위한 추가 도구 관리기능을 제공하는 Radius를 도입했다.

Radius는 기업이 클라우드로의 여정을 계속 진행하면서 개발 및 운영 전반에서 발생하는 이러한 서로 다르지만 관련된 문제를 해결하기 위해 설계되었다. 쿠버네티스뿐만 아니라 테라폼(Terraform), 바이셉(Bicep) 등 널리 사용되는 다른 인프라 도구도 지원하고 깃헙 액션과 같은 지속적 통합/배포(CI/CD) 시스템과 통합하여 이런 전체 애플리케이션의 베스트 프랙티스를 찾는 팀에게는 매우 유용하다. Radius는 멀티티어 웹-플러스-데이터부터 인기 있는 클라우드 참조 애플리케이션인 eShop과 같은 복잡한 마이크로서비스 애플리케이션까지 지원한다.

Radius는 여러 장점이 있다. 하지만 진짜 중요한 점은, Radius는 애저 전용 프로그램이 아니라는 점이다. 쿠버네티스가 동작하는 모든 클라우드에서 동작하도록 설계되었다는 점이다. 즉 이론적으론 모든 클라우드에서 똑같이 동작한다는 뜻이다.

그림 2. Radius 전체 구성도 (출처: 마이크로소프트)

Radius는 두 가지 유형의 멀티 클라우드 사용 사례를 만족하도록 설계되었다.

멀티 클라우드 엔터프라이즈

일부 기업은 개별 엔지니어링 팀이 구축 중인 애플리케이션 유형에 가장 적합한 클라우드를 결정한다. 이런 팀은 클라우드 제공업체에 대한 이전 경험, 클라우드 제공업체의 고유한 기능, 특정 클라우드 제공업체가 팀에서 사용하는 도구와 통합되는 방식 등 다양한 이유로 클라우드 제공업체를 선택했다. 일부 다른 기업은 인수를 통해 멀티 클라우드를 사용하게 되었을 수도 있다. 새로운 모기업이 선택한 클라우드 제공업체와 다른 특정 클라우드 제공업체를 선택했을 수도 있다. 많은 고객들은 기존 애플리케이션을 한 클라우드 제공업체에서 다른 클라우드 제공업체로 마이그레이션 할 필요가 거의 없었다. 또 다른 일부 기업은 관성 때문에 멀티 클라우드를 사용한다고 설명했습니다. 처음에는 한 클라우드 공급업체에서 시작했지만, 나중에 새로운 애플리케이션을 위해 다른 공급업체를 기본 선택으로 전환했을 수 있다. 위의 인수 사례처럼 기존 애플리케이션을 새로운 클라우드 제공업체로 이전할 필요가 없었다.

Radius는 이러한 시나리오를 생각하고 설계되었다. 기업은 클라우드 공급업체에 관계없이 애플리케이션을 '방사화(radify)'할 수 있으므로 애플리케이션이 특정 퍼블릭 클라우드 공급업체를 사용하든 기업이 자체적으로 운영하는 프라이빗 클라우드를 사용하든 관계없이 Radius를 사용할 수 있다. Radius 애플리케이션은 아마존의 DynamoDB 또는 애저의 Cosmos DB와 같은 클라우드 공급업체별 기술을 사용할 수도 있고, Redis와 같은 오픈 소스 기술을 사용할 수도 있다.

클라우드에 구애받지 않는 애플리케이션

동일한 애플리케이션을 여러 클라우드에서 실행하는 기업이 있다. 이러한 기업에는 여러 클라우드 제공업체를 사용해야 하는 비즈니스 요구 사항이 있는 경우가 많다. 예를 들어, 일부 금융 서비스 기업은 애플리케이션과 애플리케이션과 관련된 모든 데이터를 특정 국가 또는 지역에서 호스팅해야 한다. 이 기업은 특정 국가 또는 지역에서 사용할 수 있는 클라우드 제공업체에 애플리케이션을 배포할 수 있어야 한다.

Radius는 처음부터 이러한 특정 사용 사례를 지원하도록 설계되었다. IT 팀, 플랫폼 엔지니어링 팀 또는 클라우드 전문 센터 팀이 애플리케이션을 사용할 클라우드 제공업체를 결정할 수 있도록 하고 개발자와 개발자가 작성하는 애플리케이션 로직에 영향을 주지 않으면서 이러한 결정을 내릴 수 있기를 바랐다. Radius는 두 가지 방식으로 클라우드에 구애받지 않는 애플리케이션을 지원한다.

첫째, 기업은 애플리케이션에 오픈 소스 기술을 사용할 수 있다. 예를 들어 캐시가 필요한 개발자는 애플리케이션에서 Redis 캐시를 사용할 수 있고 플랫폼 엔지니어링 팀은 클라우드 제공업체에 따라 다른 기본 Redis 호환 서비스를 사용하는 Radius 레시피를 구축할 수 있다. 예를 들어, 애저에 배포할 때 Azure Cache for Redis를 사용하거나 AWS의 Redis를 위해 Amazon ElastiCache를 사용할 수 있다.

두 번째 방법은 분산 애플리케이션 런타임인 Dapr이다. Dapr은 개발자가 클라우드 네이티브 애플리케이션을 빌드할 때 정기적으로 직면하는 일반적인 과제의 복잡성을 추상화하는 API를 개발자에게 제공한다. 이러한 API 빌딩 블록은 상태 관리, 비밀 관리 또는 게시 및 구독 시스템을 제공하는 서비스를 추상화해준다.

플랫폼 전략

Radius는 하이퍼스케일 클라우드부터 에지에서 자체 호스팅되는 쿠버네티스, IoT 및 에지 디바이스에 이르기까지 모든 호스팅 플랫폼 유형을 지원하는 것을 목표로 한다. 즉 쿠버네티스가 설치된 모든 환경에서 동작하지만, 마이크로소프트 애저에서는 모든 주변 앱, 보안, 거버넌스까지 하나의 관리되는 서비스로 제공된다.

· 애플리케이션 이식성 : Radius 앱 모델은 모든 Radius 지원 플랫폼에서 이식할 수 있도록 설계되었다. 이식 가능한 리소스 및 Dapr과 같은 기타 프레임워크와 결합하여 팀은 앱을 한 번만 작성하면 몇 분내에 모든 Radius 지원 플랫폼에 배포할 수 있다.

· 일관된 툴링(Tooling): Radius를 사용하고 여러 플랫폼에 배포를 시작하면 도구와 환경이 모든 곳에서 일관되게 유지된다. Radius CLI는 모든 플랫폼과 환경에서 동작하므로 플랫폼 간에 쉽게 확장하고 어디서나 생산성을 높일 수 있다.

그림 3. Radius 동작 플랫폼 (출처: radapp.io)

마무리

끊임없이 진화하는 클라우드의 복잡성 속에서 애플리케이션 개발 수명주기를 간소화해야 할 필요성이 절실히 요구되고 있는 시기이다. 기업 내 개발자가 한 번의 개발작업으로 여러 클라우드 플랫폼에서 동작하는 애플리케이션을 제공, 관리할 수 있고 규정 준수 표준과 요구사항을 준수하면서 필요한 인프라에 빠르게 액세스 할 수 있다면 기업의 경쟁력은 크게 증가한다. 개발자는 구현 문제에 신경 쓸 필요 없이 올바른 레시피를 활용하여 애플리케이션과 관련된 사항을 파악하는 데 집중할 수 있고, 인프라 팀은 애플리케이션 종속성을 명확하게 이해하여 인프라를 관리할 수 있다. 이러한 관점에서 Radius는 유망한 솔루션이라고 생각한다. 멀티클라우드나 하이브리드 클라우드를 사용하고 있는 조직이나 기업에서는 Radius의 사용을 적극적으로 검토해 보길 바란다.