이 글은 Tech-Verse 2025에서 발표된 Central Dogma Control Plane으로 LY Corporation의 수천 개 서비스를 연결하기 세션을 글로 옮긴 것입니다.

안녕하세요. LINE Plus Developer eXperience 팀의 송민우, 이한남입니다. 저희 DX 팀은 개발자 경험을 향상시키기 위해 여러 프로덕트를 개발하고 있는데요. 이번 글에서는 그중 LY Corporation에서 수천 개의 서비스를 연결하기 위해 사용하고 있는 Central Dogma의 컨트롤 플레인(control plane)을 소개하겠습니다.

먼저 배경 지식과 컨텍스트를 설명한 뒤 저희가 어떤 문제를 겪었는지 소개하겠습니다. 이어서 이 문제를 해결하기 위해 Central Dogma 컨트롤 플레인을 이용해 서비스 메시를 구성한 방법과 더 나아가 사이드카 없이 서비스 메시를 이용할 수 있는 환경을 제공해서 개발자들에게 큰 이점을 드린 내용을 말씀드리겠습니다.

컨트롤 플레인은 서비스 간 커뮤니케이션 트래픽 정책을 관리하면서 이를 실제 트래픽을 처리하는 데이터 플레인으로 전달하는 역할을 담당하는 컴포넌트입니다. 정책 설정을 중앙화된 저장소 한 곳에서 관리하기 때문에 관리 효율을 높일 수 있고, 하드코딩 방식이 아니라 컨트롤 플레인에서 데이터 플레인으로 전달하는 방식이기 때문에 동적으로 변경할 수 있다는 장점이 있습니다. LY Corporation에서도 이러한 장점을 살리기 위해 컨트롤 플레인이 필요했는데요. 이를 Central Dogma에 구현했습니다.

여기서 Central Dogma가 무엇인지 설명하고 넘어가겠습니다. Central Dogma는 저희가 오픈소스로 공개한, 텍스트 설정을 저장할 수 있는 리포지터리 서비스입니다. Central Dogma 서버에 여러분의 설정 정보를 저장하면 UI를 통해서 설정 정보를 확인하고 수정할 수 있습니다. 또한 애플리케이션에서 Central Dogma 서버를 지켜보고 있다가 설정 정보가 변경되면 해당 내용을 가져와 적용할 수 있습니다. 이와 같이 구성하면 애플리케이션의 설정을 변경할 때마다 재부팅하지 않아도 되겠죠.

Central Dogma 내부에서는 모든 데이터를 Git에 저장합니다. 설정은 UI를 통해서 직접 수정할 수도 있고, 외부 GitHub의 리포지터리를 셋업한 뒤 미러링을 통해 변경 사항을 Central Dogma로 가져올 수도 있습니다. 이런 방식은 설정을 변경할 때 PR(pull request)을 생성해 동료들의 리뷰를 받고 안전하게 설정 정보를 변경할 수 있다는 큰 장점이 있습니다.

Central Dogma 컨트롤 플레인 개발 배경

이제 저희가 어떤 문제에 직면했는지 설명하겠습니다. 아래는 저희가 만든 컨트롤 플레인의 초기 버전입니다. 오픈소스로 공개하지는 않았고 내부에서만 사용하던 컴포넌트라고 보시면 될 것 같습니다.

위 그림에서 PMC(Project Management Tool)는 회사 내부에서 사용하는 배포 툴로 물리/가상 머신에서 구동되는 모든 서비스의 주소 정보가 저장돼 있습니다. 이 정보를 Central Dogma로 가져와서 서비스 레지스트리를 구성했고, 각 서비스의 가중치나 카나리 배포 같은 것들을 설정할 수 있도록 만들어 기본적인 트래픽 정책을 구성할 수 있도록 제공했습니다. 정보는 저희가 정의한 커스텀 메시지 스키마로 표현돼 애플리케이션으로 전달되며, 애플리케이션 내에 위치한 저희가 제공한 커스텀 클라이언트가 이 커스텀 메시지 스키마를 읽어와서 트래픽을 조절하고 클라이언트 측 로드 밸런싱(client-side load balancing)을 수행하도록 구성돼 있었습니다.

이 레거시 시스템에는 몇 가지 문제가 있었습니다. 먼저 PMC와 결합돼 있었다는 점입니다. PMC는 정보를 1분 간격으로 가져오고 있기 때문에 설정을 실시간으로 변경하기 어려웠습니다. 또한 PMC는 쿠버네티스 서비스에 접근할 수 없어서 쿠버네티스 지원이 불가합니다. 두 번째로 자체 정의한 커스텀 메시지 스키마를 사용하기 때문에 저희가 제공하는 클라이언트만 메시지를 이해할 수 있었습니다. 서비스 메시에서 업계 표준처럼 사용되는 xDS 프로토콜과는 전혀 호환되지 않았습니다. 세 번째로는 제공하는 기능이 많지 않았습니다. 컨트롤 플레인이라고 부르기도 민망한 수준으로 단순히 서비스 레지스트리 역할만 수행했습니다.

결국 쿠버네티스로 구성된 서비스가 계속 추가되며 변화하는 환경에서 레거시 컨트롤 플레인을 계속 사용하는 것은 어렵겠다는 결론과 함께 새로운 시스템이 필요해졌는데요. 저희는 새로운 시스템에 필요한 요소가 무엇인지 아래와 같이 정리했습니다.

현재 사용하고 있는 다양한 환경 지원
기존과 같이 PMC 정보를 가져올 수 있으면서 물리/가상 머신 정보 변경 시 실시간 반영이 가능, 또한 쿠버네티스로 구성된 서비스의 정보를 가져오는 게 가능
업계 표준에 가까운 xDS 프로토콜을 사용하는 Envoy와 호환
설정 정보를 안전하게 변경할 수 있는 GitOps(Git을 이용해 PR을 보낸 후 리뷰를 받고 머지하는 형태) 지원
높은 신뢰성 보장
아무나 설정 정보를 변경할 수 없는 인증 시스템 지원

이와 같이 요구 사항이 매우 많았고 이 모든 요구 사항을 만족하는 시스템을 찾기가 어려웠는데요. 문득 생각해 보니 Central Dogma에서 이미 이 중 많은 것을 지원하고 있었습니다.

PMC 정보 가져와서 변경
미러링 통해서 GitOps 지원
멀티 데이터 센터 복제(multi-datacenter replication)이라는 기능으로 고신뢰성(high reliablity) 확보
강건한 인증 시스템

이에 따라 저희는 ‘Central Dogma에 나머지 기능을 구현하면 되지 않을까?’라는 결론에 도달했습니다.

Central Dogma 컨트롤 플레인 소개

저희가 개발해 Central Dogma 컨트롤 플레인의 전체 작동 흐름을 먼저 살펴보겠습니다.

기존 시스템처럼 PMC의 정보를 가져오고 있고, 쿠버네티스 엔드포인트 플러그인을 이용해 쿠버네티스 노드의 정보도 가져오고 있습니다. 또한 물리/가상 머신 머신 안에 있는 애플리케이션이 자기 자신의 정보를 실시간으로 등록하고 변경할 수 있도록 Central Dogma의 동적 등록(dynamic resgitration) API를 추가했습니다.

이 모든 정보는 커스텀 메시지 스키마가 아니라 xDS 리소스 형태로 저장되며, 이에 따라 xDS에서 제공하는 접근 제어, 로드 밸런싱, 존 인식(zone-aware) 라우팅, 재시도와 같은 기능을 사용할 수 있게 됐습니다. 중앙에서 관리하는 이 정보들은 xDS 프로토콜을 통해서 각 사이드카로 전달됩니다. 사이드카에서는 해당 정보를 이용해서 접근 제어, 동시성 제어, 트래픽 제어와 같은 작업을 수행해 우리가 흔히 아는 횡단 관심사(cross-cutting concern) 문제를 해결해 줍니다. 덕분에 애플리케이션에서는 비즈니스 로직에만 집중할 수 있게 되는 것이죠.

먼저 아래 슬라이드와 함께 PMC 정보를 어떻게 처리했는지 간단하게 보여드리겠습니다. 왼쪽이 레거시에서 사용했던 데이터 스키마, 오른쪽이 xDS 리소스로 변형한 내용입니다.

오른쪽을 보시면 메타데이터에 jp.co.lycorp로 시작하는 필드가 있습니다. 기존 레거시에서 사용하는 프로퍼티들도 xDS에서 사용할 수 있도록 변경한 것인데요. 이 부분은 Central Dogma가 플러그인을 가져와 Central Dogma에서 구동시키는 방식으로 플러그인 시스템을 지원하는 것을 이용했습니다. 회사에서 저희의 PMC와 같이 주소 정보를 갖고 있는 툴이 있다면 플러그인을 구현해 쉽게 xDS 형태로 변환할 수 있습니다.

또한 쿠버네티스 노드의 접속 정보도 xDS 리소스로 변환합니다. Central Dogma뿐 아니라 쿠버네티스도 아래 오른쪽 그림과 같이 컨트롤 플레인이 있습니다. 쿠버네티스 컨트롤 플레인은 각 노드의 주소 정보를 갖고 있습니다.

위 왼쪽 JSON 파일의 controlPlaneUrl과 같이 쿠버네티스 컨트롤 플레인의 URL을 등록하고 관심 있는 쿠버네티스 서비스의 정보를 가져올 수 있는 기능을 구현했고, 아래 슬라이드와 같이 물리/가상 머신 내 애플리케이션이 자기 자신의 정보를 실시간으로 등록하고 변경할 수 있는 기능도 구현했습니다.

이와 같이 저희는 Central Dogma를 이용해 서비스 메시 컨트롤 플레인을 구현했습니다. 업계 표준으로 간주되는 xDS 프로토콜을 지원하도록 구현했고, 이종(heterogeneous) 환경에서 잘 작동하도록 구현했습니다. 더불어 기존 Central Dogma에서 제공하고 있던 모든 이점들(GitOps, 고 신뢰성, 인증 시스템)도 함께 지원할 수 있게 됐습니다.

사이드카 없는 서비스 메시로 개선

이와 같이 많은 것을 개선했지만 저희는 여기서 한 걸음 더 나아가기로 결정했습니다. 앞서 소개한 구조에서는 사이드카를 사용했는데요. 사이드카 없이 서비스 메시를 구성하는 것입니다.

사이드카 없는 구조를 설명하기 전에 사이드카가 있는 환경, 즉 일반적인 쿠버네티스 애플리케이션 구성이 어떠한지 먼저 살펴보겠습니다.

우선 쿠버네티스를 한마디로 정의하면 '애플리케이션을 자동으로 배포하고 라이프사이클을 관리해 주는 오케스트레이션 시스템'이라고 할 수 있습니다. 일반적인 쿠버네티스는 쿠버네티스 컨트롤 플레인 내부에 있는 API 서버를 이용해서 각 파드의 라이프사이클을 관리하는 형태로 운영합니다.

이때 쿠버네티스만으로도 서비스를 운영할 수 있지만 Istio를 함께 사용하는 경우도 있습니다. Istio는 인프라스트럭쳐 레이어로서 코드 수정 없이 mTLS를 이용한 보안이나 더 고도화된 로드 밸런싱, 재시도 등의 기능을 제공하며, 이때 코드 수정 없이 이런 것들을 가능하게 만들기 위해서 Envoy 사이드카 프락시를 사용합니다.

Envoy 사이드카 프락시는 Istio나 쿠버네티스에 의해 각 파드마다 파드의 라이프사이클에 따라 함께 배포됩니다. Istio 컨트롤 플레인에서는 쿠버네티스 API 서버로부터 쿠버네티스 클러스터에 대한 정보를 받아와 이를 서비스 메시에 적합한 설정 환경으로 변경해서 Envoy 사이드카 프락시로 전달하는 역할도 수행합니다.

여기서 Istio 컨트롤 플레인은 아래와 같이 Central Dogma 컨트롤 플레인으로 변경해서 서비스할 수 있습니다. Central Dogma 컨트롤 플레인은 Istio와 동일하게 쿠버네티스 API 서버에서 쿠버네티스 클러스터에 대한 정보를 받아와 Envoy 사이드카 프락시로 설정을 전달하는 역할을 수행할 수 있습니다.

쿠버네티스 내부 애플리케이션끼리 통신할 때에는 앞서 살펴본 Istio와 Envoy 사이드카 프락시를 사용해도 문제는 없습니다. 하지만 쿠버네티스 환경 밖에서 쿠버네티스로 운영하는 서비스에 요청을 보내고 싶은 경우에는 문제가 발생합니다. 만약 기존에 운영하던 모든 서비스를 쿠버네티스로 한 번에 마이그레이션할 수 있다면 괜찮겠지만, 그렇게 하기 쉽지 않은 상황에서는 외부에서 쿠버네티스로 운영하는 서비스로 요청을 보낼 수 있어야 하는데요. 이 부분이 조금 어려울 수 있습니다.

이를 해결하기 위해 한 가지 방법으로 아래와 같이 쿠버네티스 환경 밖에 Envoy 사이드카 프락시를 두고 운영하는 방법이 있긴 하지만, 이 방법은 별도로 또 하나의 프로세스를 운영해야 하고 구조가 복잡해진다는 단점이 있습니다. 또한 Envoy 사이드카 프락시를 통해야 하기 때문에 네트워크에 홉(hop)과 실패할 수 있는 지점이 하나 더 추가된다는 단점도 있습니다.

저희는 '만약 Envoy 사이드카 프락시 없이 애플리케이션이 직접 컨트롤 플레인으로부터 서비스 메시 관련 설정을 받아올 수 있으면 어떨까?'라고 생각했습니다. 기존 Istio에서 제공하던 보안이나 고도화된 로드밸런싱 등의 장점을 유지할 수 있으면서 동시에 Envoy 사이드카 프락시가 없어지기 때문에 배포가 보다 단순해지고 지연 시간이 줄어들며 트러블슈팅도 편해질 것입니다.

저희 내부에서는 Armeria라는 마이크로 서비스 프레임워크를 사용하고 있는데요. 이미 저희 회사 내부에서 많이 사용하고 있는 이 Armeria를 아래와 같이 데이터 플레인으로 사용하면 어떨까 한번 상상해 봤습니다.

Armeria에 대해서 짧게 설명하자면, 저희가 개발해 오픈소스로 공개한 마이크로 서비스 프레임워크로 마이크로 서비스를 쉽게 만들 수 있도록 여러 가지 기능과 자체 클라이언트 구현체를 제공하고 있습니다.

위 슬라이드 오른쪽의 클라이언트를 만드는 예시 코드를 보겠습니다. 클라이언트를 만들 때 손쉽게 엔드포인트 주소(myendpoint.com)를 주입할 수 있고, 마이크로 서비스에서 자주 사용되는 서킷 브레이커 관련 설정이나 재시도 관련 설정도 간단하게 추가할 수 있습니다.

저희는 Armeria 클라이언트가 데이터 플레인으로서의 역할을 수행할 수 있도록 새로운 클라이언트를 제공하기로 결정했습니다. 아래 코드는 데이터 플레인으로서의 Armeria를 만드는 예시입니다.

위 코드의 1번 부분을 보겠습니다. Bootstrap에는 컨트롤 플레인에 어떻게 연결할 건지에 대한 정보를 입력하는데요. 이것이 잘 정의돼 있습니다. 일반적인 bootstrapStr 설정으로 만약 Envoy Bootstrap을 사용해 보셨다면 익숙한 코드일 것 같습니다. 다음으로 2번을 보면 위 bootstrapStr을 Armeria에서 이해할 수 있는 xdsBootstrap이라는 객체로 감싸고 있습니다.

이것으로 웹 클라이언트를 만들 준비는 끝났습니다. 다음으로 이 클라이언트에 앞서 설명드렸던 xdsBootstrap을 주입하고 my-listener라는 리소스 이름을 주입합니다. 여기서 리소스란 간단히 말해 라우팅 정책의 집합체라고 할 수 있습니다. 컨트롤 플레인에 어떻게 접근할 것인지, 컨트롤 플레인에서 가져온 리소스 중 어떤 리소스를 사용할 것인지, 이 두 가지만 주입하면 클라이언트를 만들 수 있습니다.

클라이언트를 만든 후에는 위 코드의 2번처럼 클라이언트를 이용해서 요청을 보낼 수가 있는데요. 요청을 보낼 때에는 컨트롤 플레인으로부터 가져온 리소스 정보 중 앞서 주입한 my-listener에 해당하는 리소스에 정의돼 있는 라우팅 정책을 따라서 자동으로 클라이언트가 라우팅할 수 있도록 구현했습니다.

데이터 플레인으로서의 Armeria(아래 오른쪽)와 기존의 Armeria 클라이언트(아래 왼쪽), 이 두 가지를 비교해 보겠습니다.

오른쪽 데이터 플레인으로서의 Armeria 클라이언트를 보면 어느 엔드포인트로 연결할지에 대한 정보나 서킷 브레이킹에 대한 정보, 재시도에 대한 정보 모두 주입하지 않았습니다. 주입할 필요가 없기 때문입니다. 이 모든 것은 컨트롤 플레인에 정의돼 있고 사용자가 동적으로 변경할 수 있습니다.

지금까지 Armeria의 클라이언트를 이용해 쿠버네티스 환경 밖에서 쿠버네티스 내부에 있는 서비스에 요청을 보내는 방법을 말씀드렸는데요. 이제 한 번 상상해 볼 수 있을 것 같습니다. '쿠버네티스 내부에 있는 서비스들도 Envoy 사이드카 프락시 없이 운영할 수 있을까?' 만약 이것이 가능하다면 Envoy 사이드카 프락시가 없어지면서 추가로 사이드카 프락시를 운영해야 부담이 줄어들 것이고, 지연 시간이나 실패 지점, 복잡도도 줄어들 것이고, 컴포넌트가 하나 사라지면서 디버깅도 훨씬 쉬워질 것입니다.

실제로 저희는 아래와 같이 Armeria 데이터 플레인 클라이언트를 사용하고 있습니다. LINE 앱에서 메시지를 보낼 때 메시징 서버에서 앞서 살펴본 Armeria 클라이언트를 이용해서 쿠버네티스에서 운영하는 푸시 서버 컨테이너로 요청을 보냅니다. 푸시 서버 컨테이너에서는 APNs나 Firebase 등 퍼블릭 클라우드로 푸시 요청을 보냅니다(이와 관련해서는 먼저 발행된 Pushsphere: LINE 메신저의 빠르고 신뢰할 수 있는 대량 푸시 알림 비법을 참고해 주세요!).

마치며

이번 글에서는 저희가 사이드카 없는 서비스 메시를 어떻게 구성하고 개선했는지 소개했습니다. 정리해 보자면, Central Dogma 컨트롤 플레인을 이용하면 쿠버네티스뿐만 아니라 PMC나 물리/가상 머신 등 다양한 환경의 인프라스트럭쳐에 대한 서비스 메시를 이용할 수 있습니다. 또한 Central Dogma에서 장점으로 뽑혔던 여러 가지 기능들(고가용성, 강력한 GitOps 기능, 고도화된 인증 시스템, 이력을 확인할 수 있는 히스토리 기능 등)을 사용할 수 있습니다. 또한 사이드카 없는 서비스 메시를 사용하면 쿠버네티스 환경 내부에서 운영하는 서비스에 손쉽게 요청을 보낼 수 있으며, 사이드카 프락시를 추가 운영하지 않아도 되기 때문에 복잡도와 비용, 실패 지점을 모두 줄일 수 있습니다. 이미 테스트가 완료된 Armeria라는 프레임워크를 사용할 수 있다는 장점도 있습니다.

이번 글에서 소개한 Central Dogma 컨트롤 플레인과 사이드카 없는 서비스 메시가 현재 완벽하게 구현돼 있는 것은 아닙니다. 여러분들의 도움과 관심이 많이 필요합니다.

우선 현재 Central Dogma 컨트롤 플레인 쪽에서는 컨트롤 플레인에 조금 더 특화된 UI를 개발하는 작업에 집중하고 있으며, 인증 시스템 고도화에도 관심을 기울이고 있습니다. 사이드카 없는 서비스 메시 쪽에서는 현재 방대한 xDS 프로토콜의 모든 기능을 제공하고 있지 않기 때문에 커버리지를 높이는 작업을 진행하고 있으며, 디버그 메뉴나 커스텀 필터 기능(Armeria 클라이언트가 Java로 개발돼 있기 때문에 사용자가 손쉽게 커스텀 필터 등록 가능) 제공 등의 여러 가지를 계획하고 있습니다.

이번 글에서 소개한 모든 것은 오픈소스로 공개돼 있으니 관심 있으신 분들은 한 번 찾아오셔서 편하게 의견 주시면 감사하겠습니다. 마지막으로 저희 리포지터리 주소 알려드리며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.

Central Dogma: https://github.com/line/centraldogma
Armeria: https://github.com/line/armeria

Central Dogma 컨트롤 플레인으로 LY Corporation의 수천 개 서비스를 연결하기

댓글