[AWS] LG Uplus의 BSS 현대화를 위한 클라우드 마이그레이션 여정, DevOps 포인트

 

ㅁ 들어가며

AWS Summit Seoul 2024에서 공개된 LG Uplus의 BSS 현대화 사례를 보게 되었다.

예전에 LGUplus에서 일했을 때에 알고 있었던 UCube 시스템의 고도화 사례를 소개하고 있다.

복잡한 레거시 시스템을 DevOps관점에서 어떻게 바꾸었는지 기술적으로 배울점이 많아 정리해 보았다.

ㅁ BSS(Ucube)는 무엇?

https://www.youtube.com/watch?v=ZEJRN-p9QYw

BSS는 통신사의 고객, 계약, 과금, 청구를 담당하는 핵심 시스템이다. 

LG Uplus의 BSS는 홈·기업·모바일 전 영역의 정보를 다루는 대형 기관계 시스템이고, 운영 규모도 상당하다.

매달 청구되는 휴대폰요금부터 시작해서 기업메시징 비용까지, 모든 계약과 요금들이 이 시스템을 통해 정산 청구된다.

 

통신사가 오래된 만큼 시 오래 운영된 시스템도 문제가 많았다. 
오래된 UI 구조, 복잡한 분기 로직, 백엔드 중복 코드, DB 종속성 때문에 유지보수가 점점 어려워졌다고 한다.

하루 수천만 건 규모의 트랜잭션과 배치가 오가는 대형 시스템이다.

ㅁ 레거시에서 클라우드로 가는 문제점

대부분의 레거시 시스템은 대규모 DB의존적인 경우가 많다. 트래픽이 많지면서 컨넥션 갯수도 용량도 부족하게 된다.

문제는 과도한 트랜젝션은 감당하기 어려워 진다. 

이처럼 느린 시스템보다 더 어려운 점은 바꾸기 어려운 시스템이라는 점이다.

메뉴가 약 2,500개, 화면이 4,000개... 

기능 추가도 어려워지고, 변경 영향 범위가 크다. 점점 감당하기 어려운 파스타소스가 되어가는 것이다.

ㅁ 현대화의 방향

LG Uplus가 세운 현대화 전략은 크게 세 가지였다.

- 분리된 서비스는 비동기 방식으로 연결한다. => 소스를 쪼개고

- 서비스를 독립적으로 분리하고 CI/CD를 구축한다. => 민첩하게 배포하고

- 클라우드와 오픈 소스를 활용해 유연하고 효율적인 인프라를 만든다. => 확장가능한 인프라를 구축

 

MSA로 쪼개고, 비동기로 만들고, k8s로 배포의 용이성과 장애 대응을 이루는 목표이다.

 

ㅁ 적용 기술

적용기술을 보면서 사용하지 못한 기술들이 있어서 매우 흥미로웠다.

사실 내가 해보지 못한 고난이도의 트랜젝션 처리를 위한 SAGA와 이를 지원해주기 윈한 Eventuate가 그것이었다.

Agility 강화	Framework	Spring Boot Eventuate
	데이터베이스	Mysql(Aurora, MariaDB), Oracle
	CI/CD	Gitlab, Jenkins, Helm, ECR, Harbor, ArgoCD
서비스 안정성	Event Driven	Message Broker (kafka), Eventuate CDC
	Observability	WhaTap, Dynatrace, EFK
	컨테이너관리	Public: AWS EKS, Private: Openshift
	Service Mesh	Istio
자원사용 최적화	Virtual Machine	Public: AWS EC2, Private: VMware

ㅁ 서비스 분리 방식

모든 기능을 무조건 마이크로서비스로 나눈지는 않는다.

변경이 잦은 기능은 마이크로서비스로, 안정성과 일관성이 주용한 기능은 비교적 큰 단위로 분리 전략을 가졌다.

무조건 작은 서비스로 쪼개는 방식이 아니라,

변경 빈도와 중요도에 따라 마이크로/매크로로 나눴다는 점이 인상적이었다.

 

분산된 서비스에 대한 처리는 비동기 설계를 원칙으로 한다. 

처리 영역에서 Message Broker를 적용하여 개별 Micro서비스의 장애 시에도 처리를 보장하고자 한다.

ㅁ 정합성은 어떻게 해결했나?

MSA의 경우 도메인별, 혹은 서비스별로 모듈화하여 빠르게 신규 서비스를 적용하고

서비스장애로부터 전체 시스템에게 영향력을 최소화한다.

하지만, 데이터의 분리로 인해 데이터 정합성을 위한 트렌젝션 처리는 난감해진다.

 

사실 이 부분은 예전부터 내가 가장 궁금했던 주제이기도 했다.

마이크로서비스는 서비스를 독립적으로 분리하지만, 그만큼 데이터도 분산된다.

서비스 간 결합도는 낮아지지만, 반대로 하나의 트랜잭션으로 처리하던 작업은

여러 서비스에 걸쳐 수행되어야 한다. 그러면 서로 다른 서비스에 저장된 데이터를 어떻게 일관성 있게 유지할 것인가?

이 고민 때문에 예전에도 MSA를 공부하면서
'12가지 마이크로서비스 패턴', '배민 마이크로서비스 여행기', 'CQRS 패턴' 등을 정리한 적이 있다.

 

특히 배민 사례에서는 변경이 잦은 영역과 안정성이 중요한 영역을 다르게 분리하는 전략을 소개했고,

CQRS는 읽기와 쓰기를 분리하여 서비스의 확장성과 성능을 확보하는 대신,

결국 데이터 정합성을 어떻게 유지할 것인지가 핵심 과제가 된다는 점을 설명하고 있었다.

 

결국 MSA의 핵심은 서비스를 잘게 나누는 것이 아니라,

분산된 데이터의 정합성과 장애를 어떻게 설계할 것인지에 있다는 점을 계속 고민해 왔다.

 

이번 LG U+ 사례는 그 고민에 대한 실제 운영 사례를 보여주었다.

단순히 CQRS를 적용하거나 이벤트를 사용하는 수준이 아니라,

Transactional Outbox, Saga, 시멘틱 락, Dead Letter Queue를 함께 활용하여

최종 일관성(Eventual Consistency)을 확보하는 방식을 선택한 것이다.

결국 MSA의 핵심은 서비스를 잘 나누는 것이 아니라,

분산된 데이터의 정합성과 장애를 어떻게 설계할 것인가에 있다는 점을 계속 고민해 왔다.

 

분산 환경에서 가장 어려운 건 결국 데이터 정합성이다.  

이를 위해 Transactional Outbox, Saga 패턴, 락 전략, 재처리용 별도 서비스 등을 조합해 운영했다고 설명한다.

방식	설명
Transactional Outbox	데이터베이스 변경과 메시지 발행을 하나의 트랜잭션으로 묶어 원자성을 보장하는 설계 방식
Saga 패턴	마이크로서비스 아키텍처(MSA)에서 분산된 여러 서비스의 데이터 일관성을 유지하기 위해 사용하는 로컬 트랜잭션 연속 실행 및 보상 트랜잭션 관리 방식 단일 거대 트랜잭션 대신 각 서비스별로 DB를 업데이트하고 이벤트를 통해 다음 단계를 진행하며, 중간에 실패하면 보상 트랜잭션으로 이전 작업을 되돌려 최종 일관성(Eventual Consistency)을 보장
시멘틱 락	데이터베이스 수준의 락이 아니라 애플리케이션 수준에서 데이터에 플래그(표식)를 두어 아직 처리 중이거나 변경될 수 있는 상태임을 나타내는 동시성 제어 기법
Dead Letter Queue	메시지 큐 시스템에서 오류나 기타 이유로 정상 처리되지 못한 메시지들을 별도로 모아두는 특수한 대기열(토픽)

 

이 부분이 특히 인상적이었다.  
MSA 전환은 “서비스를 쪼개는 일”처럼 보이지만, 실제로는 정합성을 어떻게 유지할지 결정하는 일에 더 중요하다.
기술적으로 멋진 구조보다, 장애 상황에서도 데이터가 틀어지지 않게 만드는 설계가 더 중요하다는 메시지가 분명했다.

특히 돈과 계약에 관련된 사안들은 더욱 그러하다. 

ㅁ 데이터 마이그레이션과 검증

돈은 그래도 맞지 않는 경우가 발생한다. 이를 찾기 위해서 일일 대사를 비교하곤 하는데 그 작업이 쉬운게 아니다.

예전 전자결제팀에서 정산데이터를 다루는 SQL문을 함부로 돌릴 수도 없었다. 부하가 발생하기 때문이다. 

AWS를 사용한다면, Read쪽에서 돌리던가, DB 인스턴스를 복제하여 부하로 인한 운영 영향력을 줄일 수 있다.

 

여기서 소개하는 것은 조금 다른 방법이었다.

방해한 로그를 S3에 적제하고 있었든데, 이를 Athena를 통해 특정 유입을 분석한 경험은 있었다.

하지만, 이를 정산 데이터에 적용한 부분은 AWS의 새로운 가능성을 제시해 준다고 생각한다. 

 

방대한 데이터를 AWS DMS, Glue, S3, Athena, Lambda, EventBridge를 활용해 데이터 비교와 검증을 하였다.

요소	역할
AWS DMS	데이터베이스와 분석 시스템을 안전하고 빠르게 다른 곳으로 옮겨주는 ⁠AWS Database Migration Service 클라우드 서비스 원본 데이터베이스의 데이터를 손실 없이 대상 데이터베이스로 복제하며, 서비스 중단 시간을 최소화함.
AWS Glue	여러 소스의 데이터를 쉽게 검색, 준비, 이동, 통합할 수 있도록 돕는 서버리스 데이터 통합 서비스이자 완전 관리형 ETL(추출, 변환, 적재) 서비스
AWS Athena	표준 SQL을 사용해 ⁠Amazon S3에 저장된 데이터를 직접 분석할 수 있는 서버리스 대화형 쿼리 서비스
EventBridge	다양한 소스에서 발생한 이벤트를 받아 원하는 곳으로 전달해 주는 서버리스 이벤트 라우팅 서비스

 

구성은 다음과 같다. 

 - AWS DMS와 Glue로 검증 대상 데이터를 S3로 추출.
 - Athena로 비교 검증.
 - Lambda와 EventBridge로 전체 과정을 자동화.

이렇게 해서 사용자가 쉽게 활용할 수 있는 자동 데이터 검증 플랫폼을 만들었고, 

이후에는 분산 서비스 간 대용량 데이터 추출과 배치 작업에도 활용하고 있다.

 

ㅁ 클라우드 전략과 마이그레이션

우선 AWS를 선정하고 인프라의 가용성과 효율성을 정하고 민감정보는 Private, 민첩성이 중요한 서비스는 퍼블릭에 둔 하이브리드 클라우드를 택하였다.

중요한 점은 기존 기능과 신규 기능을 BFF 레이어로 라우팅해서 점진적으로 페이드아웃시켰다.

신규 기능은 차세대 쪽으로, 기존 기능은 레거시 쪽으로 보내면서 사용자가 자연스럽게 전환되도록 한 구조이다.

기술	대상
BFF	Frontend를 위한 API
API Gateway	외부 요청의 입구 모든 API 요청이 먼저 Gateway를 통과 인증,권한 Routing, Load Balancing 처리 대표: Envoy
GraphQL	필요한 데이터만 조회는 API 조회 방식 REST라면 3번 호출할 것을 다음처럼 한번에 호출하는 API 형태이다. {   user {     name     orders {       product     } }
Istio	서비스 간 통신 관리이다.

 

DAX 관점에서는

Client
  ↓
 BFF
  ↓
API Gateway
  ↓
Kubernetes
  ↓
Istio(Service Mesh)
  ↓
Microservices

 

ㅁ 기존 데이터와 신규 데이터를 어떻게 공존시켰나

레거시 모놀리스에서 신규 도메인을 분리할 때는 참조 관계가 가장 어렵다.

DB 스키마를 광범위하게 바꿔야 하므로,

이 팀은 전환 기간 동안 원본 스키마를 유지하면서 신규 스키마와 데이터를 동기화하는 방식을 사용했다.

구체적으로는 신규 도메인 서비스 영역을 읽기 전용처럼 두고, 갱신이 발생하면 그 변경을 모놀리스에 복제해 최신 상태를 유지하여,

기존 서비스와 신규 서비스 간 데이터 동화를 유지했다. 결국 이 영역은 전환이 끝나면 모놀리스와 함께 페이드아웃된다.

 

ㅁ 차세대 이후의 최적화

네트워크 개선

기존에는 중앙 집중식 네트워크에서 Direct Connect(전용선)를 타고 IDC의 시 서버를 경유해 인터넷으로 나가는 구조였는데,

이 방식은 EKS와 애플리케이션 각각에 별도 설정이 필요해 관리가 어려웠다.

이를 개선하기 위해 쉐어드 어카운트에 AWS Network Firewall을 두고 인터넷 통신 구조를 재설계했다.

이렇게 하면 각 계정마다 NAT Gateway나 IGW를 따로 만들지 않아도 되어,

공인 IP 사용을 줄이고 보안 정책에 맞는 도메인만 통신하도록 통제할 수 있다.

 

또한 기존 172 대역 24비트 CIDR의 IP 고갈 문제를 해결하려고, 10점대 16비트 CIDR을 적용한 새 VPC를 설계했다.

EKS 서비스가 기존 DB와 통신할 때는 VPC Peering을 쓰고,

IDC/온프레미스와는 Private NAT Gateway로 IP 변환 통신하게 개선했다.

 

나도 IP고갈문제로 인해 작성한 글이 있어서 공감되었다.

[AWS VPN] Amazon VPC의 CIDR 블록 IP 확장방법, AWS IP증설

 

코드 기반 인프라

기존에는 AWS 콘솔 작업이 많아서 생성·변경·삭제 이력이 추적하기 어려웠다.

이를 Terraform과 Atlantis로 가져가고 GitHub에서 관리해 히스토리 추적이 가능하게 만들었다.

배포도 Helm 명령에서 GitOps 방식으로 바꿔 Argo CD 멀티클러스터 구조로 관리한다.

 

CI/CD와 배포 가시성

예전에는 테스트와 CI/CD가 한 파이프라인에 있어 불필요한 테스트 코드 때문에 빌드와 배포가 느려졌다.

이를 분리해 테스트가 통과한 후 머지되면 빌드와 배포가 진행되도록 바꿨고,

배포된 앱의 상태는 Argo CD와 Git으로 관리한다.

 

접근제어

이전에는 VDI 환경에서 Bastion을 거쳐 EC2/EKS에 접근해야 했는데,

이제는 사내 SSO와 GitHub SSO, 그리고 Teleport를 활용해 접근 제어를 개선했다.

누가 어떤 세션으로 어떤 행위를 했는지 세션 레코딩도 가능해 보안성과 추적성이 좋아졌다.

 

배치 서버리스화

기존에는 EC2를 24시간 켜두고 에이전트가 배치를 실행하는 구조였는데,

이를 Jenkins와 CodeBuild 기반으로 바꿔 배치 잡이 실행될 때만 서버가 뜨고 끝나면 죽는 서버리스 형태로 개선했다.

여기에 Datadog, Sumo Logic으로 가시성도 확보했다.

 

ㅁ 마지막 메시지

• Agility: 내부 개발자가 빠르게 비즈니스 로직을 바꿀 수 있어야 한다.
• Continuity: 큰 변화 없이 지속적으로 개발·배포·모니터링·성능 개선을 이어가야 한다.
• Optimization: 성능과 비용을 계속 최적화해야 한다.

이 팀이 원하는 방향은 단발성 대규모 전환이 아니라 지속적으로 진화하는 플랫폼화된 DevOps의 완전체이다.

 

발표의 마지막 인용문 “완벽함은 더할 것이 없을 때가 아니라 뺄 것이 남지 않을 때 완성된다”는,

복잡한 레거시를 계속 덧붙이는 게 아니라 불필요한 걸 줄이고 단순하게 만드는 현대화의 철학을 강조하면서도,

DevOps 가치를 강조하고 있다.

 

ㅁ 마무리 

[DevOps] DevOps란 무엇입니까?에게 DevOps의 의미를 정리한 적이 있다. 

DevOps는 기술적 스팩만을 말하는 것이 아니라 기술을 어떻게 고객의 요구상황에 맞게 빠르고 안전하게 실현하는데 있다. DevOps는 일종의  문화와 철학이며, 이를 이루기 위해 기술적이고 인프라차원의 환경이 필요한 것이다. 실질적인 공유와 협업의 정신을 무시하고 우선적으로 자신의 처지에만 취중할 때에 전체 조직의 퍼포먼스를 줄어들 수 밖에 없다. - 블로그 글 중 -

DevOps는 협업과 통합을 강조하는 개발 문화이자 운영 방식이다. 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다. 

 이 동영상에서는 BSS 현대화 과정에서 DevOps의 핵심 원칙과 조직 문화가 실제 업무에 어떻게 적용되는지 잘 보여준 발표였다.

서비스 요구사항을 빠르고 안정적으로 전달하기 위해 DevOps가 어떻게 활용되는지 확인할 수 있었다.