마이크로소프트 래디어스와 클라우드 네이티브 개발의 미래

클라우드 네이티브 애플리케이션의 복잡성은 끝이 없다. 익숙한 쿠버네티스 외에도 퍼블릭 클라우드 플랫폼에 기본 탑재된 서비스 생태계를 구축된 서비스 생태계를 기반으로 구축되는 경우도 증가하고 있다. 이런 애플리케이션을 개발하고 관리하려면 코딩을 넘어 플랫폼 및 인프라 엔지니어링에 이르기까지 훨씬 더 많은 것이 필요하다. 안정적인 애플리케이션을 원한다면 필요할 때 배치할 수 있는 재현 가능한 코드 및 환경 설정을 제공하겠다는 목표로 모든 팀이 협력해야 한다.

이를 위해서는 이미 사용 중인 다양한 툴을 기반으로 최신 클라우드 네이티브 애플리케이션의 다양한 동작 부분을 모두 통합할 수 있는 방안이 필요하다. 모든 툴을 새로 개발할 수는 없다. 실제로 이들 각각의 툴은 잘 동작한다. 다만, 함께 조화를 이루며 동작하지 않을 뿐이다.
 

이 영역에서는 상당한 진전이 이루어졌다. 테라폼이나 애저 리소스 매니저 같은 IaC(Infrastructure as Code) 툴은 인프라 서비스 및 플랫폼의 관리를 자동화할 수 있는데, 코드가 필요로 하는 네트워크와 서버, 서비스를 정의한 후 구축할 수 있다. 이들 툴은 점점 더 성숙해져 클라우드 서비스 관리 API에 대해 직접 작업할 수 있으며, 인프라 정의에 대한 선언적 및 프로그래밍 방식 모두에 익숙한 구문을 제공한다.

코드 측면에서는 애플리케이션 구축, API 관리를 간소화하고 일반적인 클라우드 네이티브 애플리케이션을 구성하는 마이크로서비스를 정의하는 데 도움이 되는 프레임워크가 있다. 최신 애플리케이션 프레임워크를 사용하면 몇 가지 CLI 명령어만으로 사용자에게 필요한 것을 제공할 수 있는 기본 애플리케이션 골격을 구축할 수 있다.

그렇다면 이 두 가지 뚜렷하게 다른 작업 방식을 어떻게 통합하여 클라우드 네이티브 애플리케이션을 구축하고 관리하는 데 사용할 수 있을까? 마이크로소프트가 최근 이를 위한 새로운 플랫폼 엔지니어링 툴을 공개했다.
 

플랫폼 엔지니어링을 위한 새로운 툴

애저 인큐베이션팀에서 개발한 래디어스(Radius)는 기존의 분산 애플리케이션 프레임워크와 익숙한 IaC 툴, 클라우드 서비스에 대한 자동화된 연결을 통합한다. 기존 툴을 계속 사용하면서 이런 다양한 모델을 관리할 수 있는 한 곳을 제공하는 것이 핵심이다. 래디어스는 어렵게 익힌 기술력을 버리지 않고 애플리케이션 리소스를 관리하는 데 필요한 정보를 자동으로 캡처한다.

필자는 이메일을 통해 애저 CTO인 마크 루시노비치와 래디어스의 개발 방향과 클라우드 네이티브 개발에서 래디어스의 역할에 대한 이야기를 나누었다.

“개발자가 비용, 운영 및 보안 베스트 프랙티스를 따를 수 있기를 바라지만, 개발자에게 쿠버네티스의 작동 방식이나 레디스(Redis)의 환경 구성 옵션의 미묘한 차이를 가르치려고 하는 것은 효과가 없다는 것을 알게 됐다. 개발자가 "성공의 구렁텅이에 빠지지 않도록" 더 나은 방법이 필요했다.”

루시노비치는 또 다른 동인, 즉 플랫폼 엔지니어링의 등장에 주목했다.

"플랫폼 엔지니어링이 하나의 영역으로 부상하는 것을 지켜봤다. 래디어스는 개발자가 레시피를 사용해 기업의 베스트 프랙티스를 따를 수 있는 일종의 셀프서비스 플랫폼을 제공할 수 있다고 생각한다. 레시피는 기업이 이미 보유하고 있는 테라폼 모듈을 둘러싸는 래퍼일 뿐이다. 이를 제대로 활용하면 IT 및 개발팀이 플랫폼 엔지니어링 베스트 프랙티스를 구현하는 동시에 개발자는 코딩이라는 좋아하는 일에 집중할 수 있다."

래디어스는 새로운 세대의 플랫폼 운영 툴 중 초기 툴이라고 생각하는 것이 좋다. 이미 앱 관리를 위한 Dapr과 인프라 관리를 위한 Bicep과 같은 툴이 있지만, 래디어스는 클라우드 네이티브 애플리케이션 개발의 맥락에서 애플리케이션과 인프라를 하나로 통합하는 역할을 한다. 연결 문자열, 역할, 권한과 같은 주요 플랫폼 정보를 관리할 수 있는 곳으로, 코드를 쿠버네티스 및 클라우드 서비스 형태의 기본 플랫폼에 연결하는 데 필요한 모든 것을 관리할 수 있도록 만들어졌다.
 

래디어스 시작하기

래디어스를 실행하려면, 쿠버네티스 클러스터가 필요한데, 래디어스는 쿠버네티스 애플리케이션으로 실행된다. 그러나 래디어스 운영은 대부분 명령줄을 통해 수행되며, 리눅스용 윈도우 서브시스템 및 파워셸과 맥OS를 모두 지원한다. 설치가 완료되면 rad version을 실행해 설치 여부를 확인할 수 있다. 이제 처음으로 래디어스가 관리하는 애플리케이션을 구축할 준비가 완료됐다.

rad init 명령을 사용해 개발 클러스터의 현재 컨텍스트에서 래디어스를 시작하고, 네임스페이스를 추가하고, 작업을 시작할 환경을 설정한다. 이와 함께 rad init은 기본 래디어스 애플리케이션을 설정해 애저 래디어스 리포지토리에서 데모 컨테이너를 로드할 Bicep 앱을 만든다. 데모 컨테이너를 실행하려면 rad run 명령을 사용해 Bicep 인프라 애플리케이션을 실행한다. 이렇게 하면 쿠버네티스 서버가 구성되고 간단한 웹 애플리케이션을 실행하는 기본 웹 서버가 포함된 데모 컨테이너가 시작된다.

래디어스는 비주얼 스튜디오 코드(Visual Studio Code) 확장 프로그램과도 함께 작동하므로 반드시 명령줄을 사용해야 하는 것은 아니다. 가장 확실한 첫 번째 단계는 애저 클라우드나 AWS 리소스를 지원하는 래디어스 Bicep 확장 프로그램을 추가하는 것이다. 이 확장 프로그램은 전체 Bicep 확장 프로그램과 동일하지 않으며 호환되지도 않는다는 점에 유의하기 바란다. 마이크로소프트는 래디어스 지원을 공식 Bicep 확장 프로그램과 통합할 계획이지만, 시간이 좀 걸릴 것이다. 대신 공식 하시코프 테라폼 확장 프로그램을 사용해 레시피를 만들고 편집할 수 있다.

내부에는 애플리케이션 정의에서 래디어스가 빌드하는 쿠버네티스 서버로의 배치를 관리하는 헬름(Helm) 차트가 있다. 이 접근 방식을 사용하면 애플리케이션 개발을 관리하기 위해 래디어스를 사용하더라도 기존 헬름 프로세스를 사용해 애플리케이션을 쿠버네티스에 배치할 수 있습니다. 래디어스를 사용해 애플리케이션과 인프라를 구축하고, 출력을 OCI 호환 레지스트리에 저장하고, 기존 배치 툴을 사용해 글로벌 인프라 전체에 코드를 제공할 수 있다. 래디어스는 Bicep 정의에 따라 헬름 YAML을 생성한다.

이는 컨테이너와 컨테이너의 콘텐츠를 구축하기 위해 선택한 툴을 사용할 수 있는 기본적인 클라우드 네이티브 애플리케이션에서는 매우 일반적인 작업이다. 하지만 래디어스에서 흥미로운 점은 마이크로소프트가 "레시피"라고 부르는 것을 Bicep 코드에 추가할 때이다. 레시피는 컨테이너를 일반적인 플랫폼 서비스 또는 데이터베이스와 같은 외부 리소스에 연결하는 방법을 정의한다.
 

래디어스 레시피로 플랫폼 서비스 관리하기

레시피의 가장 유용한 점은 데이터베이스 연결 문자열을 추가하는 등 적절한 환경 변수를 컨테이너에 자동으로 추가하도록 설계되어 코드가 Bicep에 있는 것 외에 추가 구성 없이 리소스를 사용할 수 있다는 점이다. 이를 통해 플랫폼팀은 예를 들어 연결 보안을 유지하기 위한 방지책이 마련되어 있는지 확인하는 등의 작업을 할 수 있다.

레시피는 Bicep 또는 테라폼에서 작성할 수 있는데, 크로스 클라우드 개발에는 테라폼이 더 확실한 선택이다. 이미 IaC 기술을 사용하고 있다면, 다른 곳에서 사용하는 것과 동일한 Bicep 매개변수 또는 테라폼 변수를 사용해 레시피를 인프라 템플릿으로 취급하는 이 접근 방식에 익숙할 것이다.

레시피는 대상 리소스로 작업하는 데 사용되는 매개변수를 정의해 코드에서 사용하는 서비스에 대한 연결을 관리한다. 이들 연결은 이후 애플리케이션 정의에 정의된다. 이런 방식으로 래디어스 레시피는 플랫폼 엔지니어링과 애플리케이션 개발 간의 책임 분리를 표시한다. 애플리케이션에 레디스 캐시가 필요한 경우, 래디어스 애플리케이션에 적절한 레시피를 추가한다. 해당 레시피는 플랫폼팀에서 구축하고 관리하며, 해당 기능이 배치되는 방식과 애플리케이션에서 해당 기능을 사용하기 위해 제공해야 하는 정보를 결정한다.

래디어스는 공통 서비스에 대한 기본 레시피를 로컬로 제공한다. 이들 레시피를 자체 레시피를 빌드하기 위한 템플릿으로 사용할 수 있다. 예를 들어, 애플리케이션을 애저 OpenAI에 연결하거나 객체 저장소를 정의하거나 결제 서비스에 연결하는 등에 이용할 수 있다.

한 가지 흥미로운 옵션은 래디어스를 사용해 Dapr 애플리케이션의 스캐폴딩을 구축하는 것이다. 여기서는 애플리케이션을 Dapr 리소스로 정의하는데, 래디어스 레시피를 사용해 원하는 데이터베이스를 사용하는 상태 저장소를 연결한다. 래디어스 리포지토리에서 여러 샘플 Dapr 컨테이너를 찾을 수 있다.

사용자는 상태 저장소 레시피에 연결을 추가하고 Dapr 사이드카에 대한 확장자를 추가하기만 하면 된다. 실제로는 일반적인 마이크로서비스 개발 툴을 사용해 Dapr 기반의 자체 컨테이너를 구축한 다음 로컬 리포지토리에 추가하고 래디어스에서 해당 애플리케이션을 관리한다.
 

클라우드 네이티브 개발 길들이기

래디어스가 해결하고자 하는 가장 큰 과제는 방대한 클라우드 네이티브 애플리케이션을 구성하는 수많은 리소스와 종속성에 대한 가시성이 부족하다는 점이다. 래디어스는 안정적이고 안전한 엔터프라이즈 애플리케이션을 구축하고 제공하기 위해 애플리케이션의 지도를 확보하고 아키텍처 거버넌스를 제공할 수 있는 구조를 제공한다.

래디어스 같은 툴의 가장 큰 장점은 애플리케이션 아키텍처를 빠르게 시각화해 컨테이너와 서비스 간의 연결을 그래프로 매핑할 수 있다는 점이다. 현재 래디어스 애플리케이션 그래프는 텍스트만 표시되지만, 대규모 애플리케이션을 이해하고 디버깅하는 데 훨씬 더 도움이 되는 사용자 친화적인 시각화를 추가할 수 있는 여지가 있다. 

“래디어스는 쉽게 쿼리하고 전체 애플리케이션 그래프를 검색할 수 있다. 서드파티 애플리케이션 그래프를 원격 측정 데이터나 네트워킹 데이터와 같은 다른 데이터 소스와 통합할 수도 있다. 이런 그래프를 서로 연관시켜 볼 수 있다면 정말 강력할 것이다.”

애플리케이션 그래프는 애플리케이션 구축에 포함되는 구성 요소를 이해하는 데 도움이 될 뿐만 아니라 팀이 개발에서 프로덕션으로 전환하는 데 도움이 되는 역할을 할 것이다.

“예를 들어, 개발자가 애플리케이션을 정의하는 방식과 애플리케이션이 프로덕션 환경에 배치되는 방식을 살펴볼 수 있다. 애플리케이션 그래프가 있으면 팀은 애플리케이션이 정의되는 방식과 배치되는 방식에 대해 함께 작업할 수 있다. 비용도 한 부분이고 인프라도 한 부분이지만, 성능, 모니터링, 추적 분석과 같은 다른 추가 계층도 상상할 수 있다.”

클라우드 네이티브 개발은 수작업으로 작성된 코드의 세계에서 벗어나 신뢰할 수 있고 안정적인 엔지니어링 원칙을 일상적인 작업의 일부로 적용할 수 있는 세계로 나아가야 한다. 그렇기 때문에 래디어스 같은 플랫폼의 역할이 중요하다. 이 플랫폼은 마이크로소프트가 출시했지만, 컴캐스트, 블랙록 포르투갈 은행 밀레니엄 BCP에서도 개발 및 사용 중이며, 깃허브에서 에서 오픈소스 프로젝트로 제공되고 있다.

이메일 대화 말미에 마크 루시노비치는 클라우드 네이티브 컴퓨팅 재단(CNCF)을 통한 커뮤니티 참여와 함께 래디어스 플랫폼이 어떻게 발전할 수 있을지 가능성을 제시했다.

“래디어스에는 여러 확장 지점이 있다. 컨플루언트(Confluent)나 몽고DB 같은 협력업체가 래디어스와 자사 서비스를 통합하는 래디어스 레시피를 제공하면 좋을 것이다. 또한 AWS나 GCP와 같은 클라우드 서비스 업체가 래디어스가 자사 클라우드와 함께 작동하는 방식을 확장하면, 래디어스의 멀티클라우드 지원도 개선할 수 있을 것이다. 마지막으로, AWS 파게이트(Fargate) 및 애저 컨테이너 인스턴스와 같은 서버리스 컴퓨팅을 지원하기 위한 확장을 구상하고 있다.”
editor@itworld.co.kr