.png)
소개: 쿠팡은 한국을 대표하는 대형 전자상거래 기업으로, 수백만 사용자의 주문을 실시간 처리하고 빠른 로켓배송을 제공해야 합니다.
이렇게 대규모 트래픽과 데이터를 처리하기 위해서는 확장성과 안정성을 갖춘 견고한 엔터프라이즈 시스템 아키텍처가 필수적입니다.
본 글에서는 쿠팡의 시스템을 C#과 Microsoft Azure 클라우드를 활용해 구축한다고 가정하고, 그 아키텍처 설계 방안을 분석합니다.
마이크로서비스 도입부터 이벤트 기반 처리, 데이터베이스 구성, 보안 전략, 성능 최적화까지 현업에서 적용할 수 있는 기술적 고려사항과 모범사례를 중점적으로 살펴보겠습니다.
1. 아키텍처 설계
확장 가능한 시스템 구조
쿠팡과 같은 대규모 서비스는 수평 확장(horizontal scaling)을 통해 폭증하는 트래픽을 감당할 수 있어야 합니다.
모놀리틱 구조로는 한계가 있으므로 서비스 기능을 쪼개어 배포하는 마이크로서비스 아키텍처를 채택합니다.
마이크로서비스는 각각 작고 자율적인 서비스들로 구성되어 탄력적이고 높은 확장성을 갖습니다
즉, 개별 서비스별로 필요한 만큼 인스턴스를 증설하여 트래픽을 분산 처리할 수 있으므로, 특정 기능에 부하가 몰릴 때 전체 시스템이 아니라 해당 서비스만 확장하면 됩니다.
이러한 구조는 독립적 배포와 장애 격리가 가능해 시스템의 신뢰성을 높입니다
실제로 서비스 오케스트레이션을 통해 자동으로 컨테이너를 추가 배치하여 부하를 분산시킬 수 있으며(Kubernetes 등의 기술 활용), 이를 통해 서비스 밀도를 높여 하드웨어 자원도 효율적으로 활용합니다.
(Microservices architecture design - Azure Architecture Center | Microsoft Learn).
마이크로서비스 아키텍처 개념 및 장점
마이크로서비스 아키텍처에서는 애플리케이션을 비즈니스 기능별 작은 서비스로 분리합니다.
각 서비스는 해당 도메인의 한 가지 책임만 담당하는 자급자족형(self-contained) 컴포넌트로, 다른 서비스와 느슨하게 결합되어 있습니다
이러한 구조의 주요 장점은 다음과 같습니다:
- 독립 배포: 각 서비스는 별도의 코드베이스와 배포 단위를 가지므로, 전체 시스템을 재배포하지 않고도 개별 서비스의 업데이트나 롤백이 가능합니다.
이를 통해 장애 발생 시 신속한 롤백과 부분적인 기능 릴리스가 수월해집니다.
- 독립 확장: 서비스마다 개별적으로 확장(스케일 아웃) 할 수 있어, 일부 서비스에 트래픽이 집중될 때 해당 부분만 확장하면 됩니다.
예를 들어, 주문 처리 서비스에 요청이 몰리면 그 서비스만 인스턴스를 늘려 처리하고, 다른 서비스에는 영향을 주지 않습니다. - 폴리글롯 아키텍처: 각 마이크로서비스는 자신에게 맞는 기술 스택과 데이터베이스를 선택하여 구현할 수 있습니다
한 서비스는 C# + .NET으로, 다른 서비스는 Python으로 개발하는 등의 기술 이질성 허용으로 최적의 도구를 활용합니다. - 장애 격리: 한 서비스의 장애가 전체 시스템 중단으로 이어지지 않도록 격리됩니다.
예를 들어 결제 서비스에 오류가 발생해도 상품 검색 서비스는 독립적으로 동작하므로 전체 쇼핑 서비스는 지속됩니다.
이러한 이점 덕분에 쿠팡과 같은 대규모 플랫폼은 마이크로서비스를 통해 **민첩한 개발(Agility)**과 **확장성(Scalability)**을 확보하고 있습니다
(Microservices architecture design - Azure Architecture Center | Microsoft Learn)
(Microservices architecture design - Azure Architecture Center | Microsoft Learn).
이벤트 드리븐 아키텍처 적용 사례
대용량 트래픽 환경에서는 이벤트 드리븐(event-driven) 아키텍처를 적용하여 서비스 간 연계를 비동기로 처리하는 것이 효과적입니다.
이벤트 드리븐 아키텍처란 **이벤트 생산자(Producer)**가 발생시킨 이벤트를 **이벤트 소비자(Consumer)**들이 비동기적으로 수신하여 처리하는 구조를 말합니다
(Event-driven architecture style - Azure Architecture Center | Microsoft Learn).
이때 이벤트는 중앙 메시지 브로커나 이벤트 버스를 통해 전달되며, 생산자와 소비자는 직접적으로 서로를 알지 못한 채 느슨하게 연결됩니다
(Event-driven architecture style - Azure Architecture Center | Microsoft Learn).
쿠팡 시스템에서도 주문, 결제, 배송 등 주요 비즈니스 사건을 이벤트로 게시하여 비동기 처리를 수행할 수 있습니다.
예를 들어 주문 생성 이벤트가 발생하면 주문 서비스는 이를 이벤트 버스에 게시하고 바로 응답을 반환합니다.
이후 재고 서비스, 결제 서비스, 배송 서비스 등 관련된 마이크로서비스들이 해당 이벤트를 구독하여 자기 할 일을 수행합니다.
이러한 발행-구독(pub/sub) 패턴을 활용하면 서비스 간 강결합을 피하고, 이벤트 큐를 통한 **완충(Buffering)**으로 피크 트래픽을 흡수할 수 있습니다
(Microservices Architecture on Azure Kubernetes Service - Azure Architecture Center | Microsoft Learn).
Microsoft Azure에서는 Azure Service Bus나 Event Grid를 이벤트 스트림 채널로 활용할 수 있는데, Producer는 Consumer의 존재를 몰라도 되므로 시스템 확장이나 변경이 쉬워집니다
(Event-driven architecture style - Azure Architecture Center | Microsoft Learn).
실제 Azure 참조 아키텍처에서도, 전방의 Ingestion 서비스가 요청을 바로 큐에 넣고 처리 작업은 백엔드 워커가 나눠서 수행하도록 설계하여 확장성과 비동기 처리를 구현합니다
(Microservices Architecture on Azure Kubernetes Service - Azure Architecture Center | Microsoft Learn).
예시: 쿠팡에서 새 주문이 들어오면 주문 서비스는 Service Bus 큐에 “주문 생성” 메시지를 넣고 즉시 응답합니다.
이후 재고 서비스는 큐에서 메시지를 소비해 재고를 차감하고, 배송 서비스는 출고를 준비하며, 알림 서비스는 사용자에게 주문 확인 알림을 보냅니다.
이러한 이벤트 기반 비동기 흐름을 통해 **최종 일관성(eventual consistency)**을 유지하면서도 시스템이 느슨하게 연동되어 확장성과 성능을 확보합니다.
2. 마이크로서비스 구현
C#을 활용한 마이크로서비스 개발
C# 및 .NET 플랫폼은 엔터프라이즈급 애플리케이션 개발에 성숙한 환경을 제공합니다.
.NET 6/7 이상의 ASP.NET Core로 경량 웹 API 서비스를 구현하면, 마이크로서비스 개발에 필요한 고성능 REST API 엔진을 구축할 수 있습니다.
각 서비스는 **컨테이너 이미지(Docker)**로 패키징되어 Azure에 배포되며, .NET의 비동기 프로그래밍(async/await) 지원과 높은 처리 성능 덕분에 마이크로서비스의 응답 속도와 안정성이 향상됩니다.
또한 .NET의 풍부한 에코시스템으로 Entity Framework Core 같은 ORM을 활용한 데이터 접근, Polly 라이브러리를 통한 재시도/폴백 패턴 구현, Serilog/Application Insights를 통한 로깅 등이 가능하여 서비스 개발 생산성을 높여줍니다.
C# 마이크로서비스를 구현할 때는 각각이 독립 프로세스로 동작하도록 설계합니다.
예를 들어 상품 카탈로그 서비스, 주문 서비스, 결제 서비스를 별도의 ASP.NET Core 웹 API로 구현하고, Swagger와 API 문서를 통해 인터페이스를 명확히 정의합니다.
각 서비스는 **도메인 주도 설계(DDD)**의 Bounded Context를 따른 자체 비즈니스 로직을 가지며, 다른 서비스와 통신은 HTTP REST 또는 경량 메시징을 이용합니다.
이러한 구조에서는 공통 라이브러리나 패키지를 통해 로깅, 인증, 예외 처리 등의 단면적인 기능을 공유하되 비즈니스 로직은 격리합니다.
.NET의 **의존성 주입(DI)**과 모듈성을 활용해 서비스 간 중복 코드를 최소화하면서도 결합도를 낮춘 구현을 지향합니다.
Azure Kubernetes Service(AKS)를 이용한 컨테이너 오케스트레이션
마이크로서비스 컨테이너를 효율적으로 배포/운영하기 위해 Azure의 **AKS(Azure Kubernetes Service)**를 사용합니다.
AKS는 관리형 Kubernetes 서비스로, 컨테이너화된 애플리케이션의 스케줄링, 자동 복구, 롤링 업데이트, 자가치유 등을 담당합니다
(Microservices architecture design - Azure Architecture Center | Microsoft Learn).
쿠팡과 같은 대규모 서비스에서는 수백 개 이상의 컨테이너 인스턴스가 동작할 수 있으므로, AKS의 오토스케일러를 활용해 부하에 따른 Pod 증설 및 축소를 자동화합니다.
AKS 클러스터 상에서는 **Azure Container Registry(ACR)**에 저장된 C# 서비스들의 Docker 이미지를 배포합니다.
CI/CD 파이프라인(Azure Pipelines 등)을 통해 새로운 버전 이미지를 빌드/푸시하고, Kubernetes 배포(manifest 또는 Helm 차트)를 적용하여 업데이트를 진행합니다.
Kubernetes는 각 서비스에 대한 Deployments와 ReplicaSet을 관리하여 설정된 복제본 수만큼 컨테이너를 유지시키고, 장애 발생 시 자동으로 재시작합니다.
또한 서비스 디스커버리와 로드 밸런싱을 내부적으로 제공하여, 쿠팡의 수많은 서비스 인스턴스들이 서로를 찾고 통신할 수 있게 합니다.
예를 들어 Kubernetes의 클러스터 DNS를 통해 order-service.default.svc.cluster.local 같은 도메인으로 주문 서비스에 접근 가능하며, 이를 통해 별도 서비스 레지스트리 없이도 마이크로서비스 간 호출이 원활히 이루어집니다.
AKS 환경에서는 Azure의 여러 매니지드 서비스를 함께 활용할 수 있습니다.
예를 들어 Azure Monitor와 Container Insights를 통해 컨테이너들의 상태, 리소스 사용량, 응답 속도를 모니터링하고 장애를 감지합니다
또한 비공개 컨테이너 이미지를 다룰 경우 Azure Key Vault와 AKS 연계를 통해 민감한 설정이나 시크릿(예: DB 연결 문자열)을 안전하게 주입합니다
(Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn) (Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn). AKS와 Azure 서비스들의 원활한 통합으로 운영 편의성과 보안성이 강화된 컨테이너 오케스트레이션 환경을 구축할 수 있습니다.
API 게이트웨이 및 서비스 디스커버리
쿠팡의 수많은 마이크로서비스를 외부에서 효율적으로 이용하려면 API 게이트웨이(API Gateway) 패턴이 필요합니다.
API 게이트웨이는 클라이언트의 모든 API 호출을 단일 진입점에서 받아 해당 내부 서비스로 라우팅하는 역프록시 역할을 합니다
(Microservices architecture design - Azure Architecture Center | Microsoft Learn).
이를 통해 클라이언트는 일일이 여러 서비스의 URL을 알 필요 없이 게이트웨이에만 요청을 보내면 되고, 게이트웨이가 내부 라우팅 규칙에 따라 요청을 전달해 줍니다.
Azure 환경에서는 Azure API Management나 Azure Application Gateway + Ingress Controller 조합을 API 게이트웨이로 활용할 수 있습니다
예컨대 Azure Application Gateway에 WAF(Web Application Firewall)를 활성화하여 AKS로 들어오는 모든 트래픽을 검사하고, Kubernetes용 **AGIC(Azure Gateway Ingress Controller)**를 사용해 쿠버네티스 Ingress 리소스와 연동함으로써 서비스별 경로 라우팅을 구현합니다
API 게이트웨이는 다음과 같은 이점을 제공합니다:
- 인증/인가 중앙화: 게이트웨이에서 OAuth2 액세스 토큰 검증이나 API 키 검사를 수행하여, 내부 서비스들은 신원 검증된 요청만 처리하도록 합니다 (Microservices architecture design - Azure Architecture Center | Microsoft Learn). 이로써 각 서비스에 중복 구현을 하지 않고 보안을 강화할 수 있습니다.
- 로드 밸런싱 및 리트라이: 게이트웨이가 각 서비스의 여러 인스턴스로 트래픽을 분산하고 장애 시 재시도 로직을 가짐으로써 고가용성을 높입니다.
- 요청 조작 및 통합: 필요에 따라 게이트웨이에서 응답 캐싱, 본문 변환(예: REST to gRPC), 병합 요청(fan-out/fan-in) 등의 기능을 수행해 클라이언트 통신을 최적화합니다.
- 서비스 디스커버리: 외부에서 보면 오직 게이트웨이만 보이므로, 내부 서비스들의 위치나 개수 변화는 게이트웨이가 추상화하여 관리합니다.
새로운 마이크로서비스가 추가되어도 게이트웨이에 라우팅 규칙만 추가하면 클라이언트에서 사용 가능하므로, 시스템의 유연한 확장이 가능합니다.
한편, 서비스 디스커버리는 마이크로서비스가 동적으로 늘어나거나 변경되는 상황에서 서로를 찾는 메커니즘입니다.
AKS 상에서는 Kubernetes의 내부 DNS와 서비스 오브젝트가 기본적인 디스커버리를 제공하지만, 복잡한 시나리오에서는 Istio 등의 서비스 메쉬를 도입하기도 합니다.
서비스 메쉬를 사용하면 사이드카 프록시를 통해 트래픽을 제어하고 관찰성을 높이며, 서비스 호출 시 로드 밸런싱, 서킷 브레이커, 모니터링 등을 일관된 방식으로 적용할 수 있습니다.
쿠팡 규모의 시스템에서는 이러한 서비스 디스커버리/메쉬 기법도 고려하여, **유레카(Eureka)**나 Consul 같은 별도 서비스 레지스트리를 쓸 필요 없이 Kubernetes와 메쉬가 서비스 위치를 해결하도록 합니다.
결과적으로 API 게이트웨이 + 서비스 디스커버리 조합을 통해 클라이언트-서비스 분리와 동적 확장 대응을 실현할 수 있습니다
(Microservices architecture design - Azure Architecture Center | Microsoft Learn)
(Microservices architecture design - Azure Architecture Center | Microsoft Learn).
Azure 기반 마이크로서비스 아키텍처 예시: 위 다이어그램은 Azure Kubernetes Service 상에서 동작하는 마이크로서비스들이 Azure Service Bus를 통해 서로 통신하는 구조를 보여줍니다.
프론트엔드 웹 클라이언트 요청은 NGINX 기반 인그레스 컨트롤러를 통해 AKS 내의 개별 서비스(Election, Candidate, Voter 서비스)로 전달됩니다.
각 서비스는 자신만의 Azure Cosmos DB 데이터베이스를 보유하여 폴리글롯 영속성을 가지며, 서비스 간에는 Azure Service Bus의 큐를 통해 이벤트를 주고받음으로써 느슨한 결합과 비동기 처리를 구현합니다
이러한 아키텍처를 통해 지역적으로 분산된 데이터 저장과 이벤트 중심의 마이크로서비스 통신이 가능해집니다.
3. 데이터베이스 설계
Azure Cosmos DB, SQL Database, NoSQL 활용 사례
마이크로서비스 아키텍처에서는 폴리글롯 퍼시스턴스(polyglot persistence) 원칙에 따라 각 서비스별로 적합한 데이터베이스를 선택하여 사용할 수 있습니다
(Microservices architecture design - Azure Architecture Center | Microsoft Learn).
쿠팡의 시스템에서도 업무 특성에 따라 Azure Cosmos DB, Azure SQL Database, 기타 NoSQL 등을 혼용하여 사용합니다.
- Azure Cosmos DB: Cosmos DB는 전 세계에 분산된 데이터베이스로, 지리적으로 분산된 사용자들에게 짧은 지연시간으로 데이터를 제공하기 적합합니다.
Cosmos DB는 다중 지역 복제를 지원해 데이터가 자동으로 글로벌 동기화되며, **5가지 일관성 수준(강력, 제한적 부실, 세션, 일관적 접미사, 최종)**을 제공하여 성능과 정합성 사이의 균형을 조절할 수 있습니다.
예를 들어 상품 카탈로그나 사용자 프로필처럼 글로벌 서비스가 필요한 데이터는 Cosmos DB에 저장하고 여러 Azure 리전으로 복제하여, 사용자들이 가장 가까운 리전에서 데이터를 읽도록 하면 지연을 최소화할 수 있습니다 (Distribute data globally with Azure Cosmos DB | Microsoft Learn). Cosmos DB는 NoSQL(MongoDB API, Cassandra API 등) 모델을 지원하여 스키마 유연성과 확장성을 제공합니다
(Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn). 쿠팡은 이를 통해 글로벌 진출 시 지역별 데이터베이스를 통합 관리하고, Azure의 SLA로 지원되는 고가용성을 확보할 수 있습니다
(Distribute data globally with Azure Cosmos DB | Microsoft Learn). - Azure SQL Database: 트랜잭션 일관성이 매우 중요한 주문 결제나 재무 회계 영역의 데이터는 Azure SQL Database와 같은 관계형 DBMS를 사용합니다.
Azure SQL은 완전 관리형 PaaS 관계형 DB로, ACID 트랜잭션과 강력한 스키마를 제공하여 금융 수준의 정합성을 요구하는 워크로드에 적합합니다.
예를 들어 주문 서비스는 주문 테이블, 결제 테이블 등을 Azure SQL에 저장하여 조인 및 복잡한 쿼리를 활용하고, 트랜잭션으로 주문-결제-재고 감소를 동시에 처리할 수 있습니다.
Azure SQL은 Auto-Failover 그룹을 통해 지역 장애 시 자동으로 보조 리전으로 장애 조치(failover)할 수 있어 재해 복구에도 유용합니다. 또한 인텔리전트 성능 기능(인덱스 튜닝, 성능 추천)으로 쿠팡의 방대한 관계형 데이터를 최적화해주므로, 관계형 데이터는 Azure SQL로 처리합니다. - NoSQL (Cosmos DB 외): 쿠팡 서비스의 일부 도메인은 특화된 NoSQL 저장소를 활용하기도 합니다.
예를 들어 캐시형 데이터나 세션 데이터는 Azure Cache for Redis를 통해 메모리 내 저장하고(자세한 내용은 성능 최적화 섹션의 캐싱 전략 참고), 대용량 로그나 이벤트 트레이싱 데이터는 Azure Table Storage 또는 Azure Blob Storage에 반정형 형태로 저장할 수 있습니다.
또한 검색 기능을 위해 Elasticsearch(OpenSearch)나 Azure Cognitive Search를 도입해 전문 검색 인덱스를 운영하고, 그래프 데이터는 Neo4j나 Cosmos DB의 Gremlin API를 활용하는 등, 요구에 맞는 NoSQL 기술 스택을 적용합니다.
이러한 다양성 덕분에 각 마이크로서비스는 자신의 데이터 접근 패턴에 최적화된 저장소를 선택하여 성능과 비용 효율을 모두 높일 수 있습니다 (CQRS Pattern - Azure Architecture Center | Microsoft Learn).
이처럼 하나의 거대한 DB 대신 서비스별 DB 분리 전략을 쓰면 성능 향상과 스케일 아웃에 유리하지만, 동시에 데이터 정합성을 유지하는 도전도 따릅니다.
아래에서 이러한 정합성 유지 전략을 살펴봅니다.
데이터 정합성 유지 전략 (CQRS, 이벤트 소싱 등)
마이크로서비스 간에 데이터베이스가 분리되어 있을 때, 한 서비스에서 발생한 데이터 변경을 다른 서비스가 어떻게 일관되게 반영할지 고민이 필요합니다. 이
를 위해 CQRS와 Event Sourcing 같은 패턴을 적용합니다.
(CQRS Pattern - Azure Architecture Center | Microsoft Learn)
- CQRS (Command Query Responsibility Segregation): CQRS 패턴은 쓰기 모델과 읽기 모델을 분리하여 각각 별도의 경로와 저장소를 사용하는 설계입니다.
쓰기 모델은 데이터 갱신에 집중하고, 읽기 모델은 조회에 최적화된 별도 뷰(view)를 유지합니다. 예를 들어 주문 서비스는 주문 접수를 처리하는 쓰기 DB(관계형)와, 사용자 주문 이력을 빠르게 보여주기 위한 읽기 DB(캐시 또는 도큐먼트 DB)를 분리할 수 있습니다. 쓰기 모델에서 주문이 생성되면 이벤트를 발행하여 읽기 모델이 이를 수신하고 자신의 DB에 주문 이력 데이터를 갱신하는 식입니다.
이렇게 하면 읽기 부하와 쓰기 부하를 개별적으로 확장할 수 있고, 조회 쿼리는 사전에 준비된 단순 뷰를 읽으므로 성능과 응답속도가 크게 향상됩니다.
다만 CQRS 적용 시 이벤트 발생 후 데이터 전파까지 약간의 지연이 있어 최종적 일관성(Eventual Consistency) 모델을 이해하고 운영해야 합니다. Azure에서는 Cosmos DB Change Feed나 Azure Functions 트리거 등을 활용해 쓰기-읽기 모델 간 데이터 동기화를 구현할 수 있습니다. - 이벤트 소싱 (Event Sourcing): 이벤트 소싱은 상태 변경을 데이터베이스에 이벤트의 형태로 기록하고, 현재 상태는 이러한 이벤트의 누적 결과로 구성하는 패턴입니다.
전통적으로는 테이블에 최종 상태만 저장하지만, 이벤트 소싱에서는 “주문 생성”, “주문 취소” 등의 이벤트를 모두 순차 로그로 저장하고, 필요하면 이 이벤트들을 재생(replay) 하여 상태를 구합니다.
이 방법의 장점은 모든 변경 내역이 남기 때문에 **감사 추적(audit trail)**이 자연스럽게 되고, 복잡한 분산 트랜잭션 대신 이벤트 로그에 기록함으로써 서비스 간 일관성을 유지할 수 있다는 점입니다.
예를 들어 주문 서비스가 주문 생성 이벤트를 발생시키면, 결제 서비스와 배송 서비스는 이를 자신의 이벤트 스트림에 기록하고 자신의 상태(결제 상태, 배송 상태)를 변화시킵니다.
Azure Cosmos DB는 Change Feed 기능으로 이벤트 소싱을 지원하는데, 특정 Container에 이벤트를 Append Only로 넣으면 Change Feed를 통해 다른 서비스가 이를 실시간 구독하여 자신의 데이터베이스에 반영할 수 있습니다
(Azure Cosmos DB design patterns - Part 6: Event Sourcing) (Event Sourcing Pattern in Microservices Architectures - Medium). 또한 Azure Event Hubs나 Apache Kafka를 이벤트 스토어로 사용해 스트림 처리를 구현할 수도 있습니다. 이벤트 소싱은 CQRS와 궁합이 좋아 함께 적용되곤 합니다.
이벤트 소싱으로 모든 변경 이벤트를 저장하고, CQRS로 이벤트를 가공해 읽기 모델을 생성하면, 시스템이 분산되어 있어도 강력한 일관성 대신 최종 일관성 하에서 데이터 정합성을 유지할 수 있습니다 (CQRS Pattern - Azure Architecture Center | Microsoft Learn). - 거래 보상 패턴(Saga): 분산 환경에서 한 트랜잭션이 여러 서비스에 걸칠 때는 두 단계 커밋(2PC)이 현실적으로 어려우므로 Saga 패턴을 사용합니다.
Saga는 로컬 트랜잭션들의 연쇄로 전체 비즈니스 트랜잭션을 구성하고, 중간에 실패 시 보상 작업을 실행하여 취소하는 방식입니다.
예를 들어 주문-결제-재고 감소가 순차적으로 다른 서비스에서 이뤄질 때, 결제 단계에서 실패하면 앞서 성공한 주문을 취소하는 보상 이벤트를 발행합니다. 이는 일종의 수동 롤백으로, 모든 서비스가 분산 트랜잭션 없이도 데이터 정합성을 맞추도록 합니다.
Azure Service Bus의 일괄 메시지 처리나 Event Grid를 통해 Saga 오케스트레이터/코레오그래피를 구현할 수 있습니다. 이처럼 이벤트 기반의 보상 트랜잭션으로 데이터 불일치를 해결합니다.
요약하면, 쿠팡의 마이크로서비스 데이터 레이어는 서비스별 전용 DB로 분리되어 있고, 이벤트/메시지를 통해 데이터 변화를 서로 전달하여 전체 시스템의 데이터 정합성을 유지합니다.
개발자는 멱등성(Idempotency), 중복 처리, 오류 복구 시나리오를 면밀히 고려해 구현해야 하며, Azure의 풍부한 메시징 인프라와 기능을 활용하여 이를 지원합니다
(CQRS Pattern - Azure Architecture Center | Microsoft Learn) (CQRS Pattern - Azure Architecture Center | Microsoft Learn).
글로벌 확장을 위한 분산 데이터 설계
쿠팡처럼 글로벌 서비스를 지향하는 시스템에서는 멀티 리전(Multi-Region) 분산 데이터 설계가 중요합니다.
Azure를 활용하면 비교적 손쉽게 지리적으로 분산된 데이터베이스와 캐시 인프라를 구축할 수 있습니다.
- 앞서 언급한 Azure Cosmos DB는 대표적인 글로벌 분산 DB로, Azure의 모든 리전에 레플리카를 가질 수 있습니다.
Cosmos DB를 사용하면 애플리케이션에서 별도 복제 로직 없이 한 곳에 쓰면 자동으로 전세계에 복제되므로 매우 편리합니다
(Distribute data globally with Azure Cosmos DB | Microsoft Learn).
예를 들어 미국 동부 리전과 한국 리전에 Cosmos DB를 복제해두면, 한국 사용자의 데이터 요청은 한국 리전 복제본에서 처리되고 미국 사용자의 요청은 미국 리전에서 처리되어 서로 지연 없이 서비스를 이용하게 해줄 수 있습니다.
Azure Cosmos DB는 멀티마스터 쓰기를 지원하여 각 지역에서 동시 쓰기도 가능하며, 충돌 해결 로직을 제공해 최종 일관성을 확보합니다 (multi-master in cosmosdb/documentdb - azure - Stack Overflow). - Azure SQL DB의 경우 지역 읽기 복제(Read Replica)나 Azure SQL Hyperscale을 이용해 다수 지역에서 읽기 성능을 높일 수 있습니다.
또한 Azure SQL Managed Instance나 SQL Server on VM으로 구성하고 이중화 복제를 설정해도 됩니다. 중요한 것은 모든 데이터가 한 곳에 몰리지 않도록 **데이터 지리적 분할(Geo-Partitioning)**을 하는 것입니다.
이를 위해 흔히 테넌트 기반 파티셔닝(예: 미주 고객은 미주 DB, 아시아 고객은 아시아 DB) 혹은 기능 서비스별 데이터 지역화(예: 결제 데이터는 본사 리전 집중, 제품 데이터는 글로벌 분산) 전략을 사용합니다. - 캐시 및 CDN: 전세계 사용자에게 빠른 콘텐츠 전송을 위해 Azure CDN을 통해 정적 콘텐츠(이미지, CSS 등)를 엣지 서버에 캐싱하고 제공하고, 동적 데이터는 Azure Cache for Redis를 각 주요 리전에 분산 배치하여 지연을 줄입니다.
예를 들어 사용자 세션 정보를 글로벌 Redis 캐시로 저장해 사용자 근접 리전에서 세션 검증이 가능하도록 합니다. - 멀티-마스터 아키텍처 고려: 멀티 리전에서 활성-활성으로 서비스를 운영하려면 데이터 레이어도 멀티-마스터 쓰기가 가능해야 합니다.
Azure Cosmos DB는 이를 기본 제공하지만, 관계형 DB의 경우 멀티-마스터는 어렵기에 보통 마스터-슬레이브로 한 지역을 쓰기 마스터로 두고 다른 지역은 읽기전용으로 두는 전략을 취합니다.
쿠팡의 경우 국내 서비스가 주를 이룬다면 한국 리전을 주 데이터 센터로, 해외는 캐싱 및 복제본 위주로 운영하고, 만약 해외에서 주문 작성이 발생하면 그 건만 한국 본사 DB로 쓰게 하는 식입니다.
분산 데이터 설계의 핵심은 데이터 중복과 동기화를 잘 관리하는 것입니다.
Azure의 Traffic Manager/Front Door를 통해 지역별 트래픽을 분배하고, 각 지역의 데이터 변경은 중앙 이벤트 버스로 모아서 필요시 글로벌 동기화를 처리합니다.
예컨대, 미국과 한국의 재고 수량이 분리 관리되더라도 중앙 이벤트를 통해 최종 합산이나 일관성을 맞추는 방식입니다.
이런 아키텍처를 통해 쿠팡은 글로벌 사용자에게도 지역에 구애받지 않는 일관된 서비스를 제공할 수 있습니다.
4. 보안
Zero Trust 보안 모델
클라우드 시대의 현대적인 보안 접근법으로 Zero Trust(제로 트러스트) 모델이 채택되고 있습니다.
Zero Trust 보안 모델은 **“항상 침해당한 것으로 가정하고 매 요청마다 검증한다”**는 철학에 기반합니다
(Zero Trust security in Azure | Microsoft Learn).
전통적인 경계 보안(내부망은 신뢰, 외부망은 불신)과 달리, Zero Trust에서는 네트워크 내부/외부를 불문하고 모든 접근을 의심하며 사용자의 신원, 디바이스 상태, 권한 등을 **항상 확인(verify explicitly)**합니다
(Zero Trust security in Azure | Microsoft Learn).
쿠팡의 시스템에도 Zero Trust 원칙을 적용하여, 사내 시스템이든 클라우드 서비스든 모든 연결에 다중 인증과 최소 권한 원칙을 적용합니다.
Zero Trust 구현을 위해 Azure AD(Microsoft Entra ID)를 중심으로 강력한 인증과 조건부 접근 정책을 활용합니다.
예를 들어 관리형 백오피스 시스템에 접근할 때 Azure AD의 MFA(다단계 인증)를 통과해야 하고, 디바이스가 Intune으로 준수성 검증을 받은 상태여야 하며, 특정 IP나 지리적 위치에서는 추가 승인이 필요하도록 설정할 수 있습니다.
원격 근무자나 모바일 사용이 많아지는 환경에서도 Zero Trust 전략으로 각 요청마다 토큰을 검증하고 세션을 모니터링하여, 내부자가 아니면 어떤 리소스에도 바로 접근할 수 없도록 합니다.
Zero Trust의 세 가지 기본 원칙은 명시적 확인, 최소 권한, 침해 가정이며, 쿠팡 시스템에서는 이를 다음과 같이 적용합니다 (Zero Trust security in Azure | Microsoft Learn):
- 항상 인증 및 인가: 사용자의 모든 요청에 대해 OAuth2 액세스 토큰이나 API 키 등의 유효성을 검사하고, 토큰에 포함된 권한(스코프, 역할)이 해당 작업을 수행하기에 적절한지 서비스 단에서 재확인합니다.
예를 들어, 주문 API를 호출하는 토큰에 Order.Write 권한이 없다면 즉시 거부합니다.
이러한 검증은 API Gateway나 각 서비스의 미들웨어 레벨에서 수행됩니다. - 최소 권한 부여: 각 마이크로서비스와 데이터베이스, 자원에 부여되는 접근 권한을 작업에 필요한 최소로 제한합니다.
Azure RBAC(Role-Based Access Control)을 활용하여 운영자별, 서비스별로 최소한의 리소스만 조작할 수 있도록 하고, 필요 시에만 권한을 상승시키는 JIT(Just-In-Time) 방식을 씁니다.
예를 들어 배포 파이프라인이 사용하는 서비스 프린시플에게 특정 리소스 그룹 배포 권한만 주고 다른 리소스 접근은 막는 식입니다. - 네트워크 마이크로 세그멘테이션: 쿠팡의 클라우드 네트워크를 여러 보안 영역으로 쪼개서 각 세그먼트 간 통신을 엄격히 통제합니다.
Azure Virtual Network와 Subnet NSG를 활용해 서비스 종류별로 서브넷을 분리하고 불필요한 East-West 트래픽을 차단합니다.
또한 Azure의 Privatelink나 Service Endpoint를 사용해 주요 PaaS (예: Cosmos DB, Storage) 접근을 사설 네트워크로 제한하고 인터넷을 통하지 않도록 합니다 (Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn). 이로써 내부 침입자가 있더라도 추가적인 중요 자원 접근이 어렵게 설계합니다.
Zero Trust 모델을 구현함으로써 쿠팡은 내부 망이라고 방심하지 않고 모든 계층에서 지속적인 검증과 모니터링을 수행해 보안 공격 표면을 최소화합니다.
Azure 보안 서비스와 결합해 위험 기반 접근 제어, 이상 탐지 등을 실현함으로써 신뢰할 수 있는 서비스 환경을 조성합니다.
OAuth2, OpenID Connect 인증/인가 적용
쿠팡의 플랫폼은 수많은 고객과 파트너가 이용하는 API 및 웹 서비스를 제공하므로, 인증(Authentication)과 인가(Authorization)를 표준 프로토콜로 구현하는 것이 중요합니다.
OAuth2.0와 **OpenID Connect(OIDC)**는 이를 위한 업계 표준이며, Azure AD (Entra ID)를 통해 쉽게 적용할 수 있습니다
(OAuth 2.0 and OpenID Connect protocols - Microsoft identity platform | Microsoft Learn).
OAuth2.0는 주로 인가에 초점을 둔 프로토콜로, 액세스 토큰(access token)을 활용해 클라이언트 애플리케이션이 사용자를 대신하여 자원에 접근할 수 있게 합니다.
OpenID Connect는 OAuth2 위에 사용자 인증 정보를 포함한 ID 토큰을 추가한 확장으로, 사용자가 누군지를 증명하는 기능을 제공합니다.
Azure AD는 OAuth2/OIDC 표준을 완벽 준수하는 권한 서버(Authorization Server) 역할을 하여, 애플리케이션들에 대한 중앙 인증 서비스를 제공합니다
(OAuth 2.0 and OpenID Connect protocols - Microsoft identity platform | Microsoft Learn).
쿠팡 시스템에서 OAuth2/OIDC 활용 시나리오 몇 가지는 다음과 같습니다:
- 사용자 로그인 및 SSO: 고객이나 판매자 포털 웹사이트 로그인은 OpenID Connect의 Authorization Code Flow로 구현합니다.
사용자가 ID/PW로 Azure AD B2C 등에서 인증하면 ID 토큰과 액세스 토큰이 발급되고, 웹앱은 이를 받아 세션 없이도 JWT 토큰 검증만으로 사용자 인증 상태를 유지합니다.
이렇게 하면 **싱글 사인온(SSO)**이 가능해 쿠팡의 여러 도메인 서비스 간에도 한 번 로그인으로 이용할 수 있습니다. - 서비스 간 인증: 마이크로서비스 간 통신이나 서드파티 API 호출에는 OAuth2의 Client Credentials Flow를 사용합니다.
예를 들어 결제 서비스가 주문 서비스의 API를 호출할 때 Azure AD에 미리 등록된 애플리케이션 신임을 통해 머신간 토큰을 발급받고, 이를 Authorization 헤더에 실어 보냅니다.
수신 서비스는 토큰의 **앱 역할(App Role)**이나 스코프를 검사하여 요청을 신뢰할지 결정합니다.
이 과정에서 토큰은 Azure AD가 서명한 JWT이므로 위변조를 막을 수 있습니다. - 권한 부여(Authorization): OAuth2 토큰에 포함된 **스코프(scope)**나 사용자/애플리케이션 역할을 통해 세부 권한 인가를 제어합니다.
예를 들어 사용자가 주문 조회 권한만 가진 경우 GET /orders API는 허용되지만 POST /orders는 거절됩니다. 이 같은 권한 모델은 Azure AD의 App Registration과 Role Assignment로 중앙 관리할 수 있어, 코드단 복잡도를 낮춥니다.
Azure AD의 Microsoft Identity Platform은 위와 같은 OAuth2/OIDC 흐름을 지원하며, 표준 규격에 맞는 OAuth2/OIDC 구현을 제공하므로 상호운용성과 보안성이 높습니다
(OAuth 2.0 and OpenID Connect protocols - Microsoft identity platform | Microsoft Learn).
또한 Azure AD는 Conditional Access 정책과 연계되어 토큰 발급 시 추가 MFA나 기기 준수 여부를 조건으로 걸 수 있어, 보안 통제가 수월합니다.
결과적으로 쿠팡 시스템은 OAuth2, OIDC를 통해 통합 인증/인가 체계를 구축함으로써, 사용자 경험을 해치지 않으면서도 서비스와 API 전반에 걸쳐 보안 통일성을 갖출 수 있습니다.
개발자는 OAuth2 라이브러리(Microsoft.Identity.Web 등)를 통해 토큰 검증과 권한 체크를 편리하게 구현하고, Azure Portal에서 애플리케이션과 사용자 권한을 한 곳에서 관리할 수 있습니다.
Azure Security Center 및 DDoS 방어
Azure 상에 구축되는 쿠팡의 인프라는 클라우드 네이티브 보안 서비스들을 활용해 지속적인 취약점 감지와 공격 방어를 받습니다.
그 중심에는 **Azure Security Center(현 Microsoft Defender for Cloud)**가 있습니다.
Azure Security Center는 구독 내 자원들의 보안 구성을 모니터링하고, 모범사례 대비 부족한 부분을 **보안 점수(Security Score)**로 나타내며 개선 조치를 권고합니다
(14 Azure Security Best Practices You Can't Ignore - intercept.cloud).
예를 들어 개방된 네트워크 포트, 암호화 설정 미적용, 취약한 VM 확장 등을 발견하면 경고를 주고 수정 가이드라인을 제공합니다.
또한 Security Center는 실시간 위협 탐지 기능이 있어, 쿠팡 인프라에 대한 의심스러운 활동(예: 비정상 프로세스 실행, 알려진 악성 IP 접근)을 감지하면 즉시 경고를 띄우고 필요 시 자동 대응(예: 해당 VM 격리)도 수행합니다
(Top Azure Security Best Practices & Checklists 2025 - SentinelOne).
쿠팡 운영팀은 Security Center 대시보드를 통해 전체 클라우드 자산의 보안 상태를 한눈에 파악하고 신속히 취약점을 해결할 수 있습니다.
또한 Azure는 DDoS(Distributed Denial of Service) 공격에 대한 기본 방어력을 제공하며, 추가적으로 DDoS Protection Standard를 통해 엔터프라이즈급 보호를 제공합니다.
쿠팡과 같이 트래픽이 많은 서비스는 악의적인 대량 트래픽 공격의 표적이 될 수 있으므로, Azure DDoS Protection을 설정합니다.
이 서비스는 Azure의 전역 네트워크 엣지에서 유입되는 트래픽 패턴을 모니터링하다가 평소 대비 비정상적으로 높은 트래픽이 감지되면 자동으로 대응 정책을 적용합니다
(Azure DDoS Protection Pricing).
공격 유형에 따라 유입 속도를 제한하거나, 특정 IP 블록을 무시하거나, Azure 프런트도어 레벨에서 차단합니다.
DDoS Protection Standard는 L3/L4 레벨에서의 볼륨 공격을 완화하고, 앱 레벨 공격은 WAF가 방어하도록 이중 보호를 구축합니다.
실제 Azure의 DDoS 완화 시스템은 초당 수 테라비트 규모의 공격도 막아낸 사례가 있고, 쿠팡은 이러한 인프라 위에서 안심하고 서비스를 운영할 수 있습니다.
예를 들어 2021년 Azure가 초당 2.4Tb에 달하는 거대한 DDoS 공격을 성공적으로 완화한 바 있으며, 쿠팡도 비슷한 보호를 자동으로 받습니다.
그 외에도 Azure Firewall, Web Application Firewall(WAF), Microsoft Sentinel(SIEM) 등을 활용하여 네트워크 경계 보안과 로그 기반 침해 탐지를 강화합니다.
Azure Firewall은 아웃바운드 트래픽에 대한 FQDN 필터링과 위협 인텔리전스 차단을 적용해 내부에서 외부로 나가는 연결도 통제합니다
(Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn). WAF는 SQL 인젝션, XSS 등 웹 공격 패턴을 실시간 차단하여 애플리케이션 레벨 보안을 제공하며, Azure Sentinel은 모든 보안 로그를 종합 분석해 공격 징후를 머신러닝으로 찾아냅니다.
이러한 다계층 보안 대책을 통해 쿠팡의 클라우드 인프라는 **방어 심층화(Defense-in-depth)**를 구현하고, 잠재적 공격으로부터 고객 데이터를 지킵니다
(Top Azure Security Best Practices & Checklists 2025 - SentinelOne) (14 Azure Security Best Practices You Can't Ignore - intercept.cloud).
5. 성능 최적화
대규모 시스템에서 성능 최적화는 곧 비용 최적화와 사용자 만족으로 직결됩니다.
쿠팡 아키텍처는 캐싱, 비동기 처리, 서버리스 활용 등의 기법을 통해 높은 성능과 응답성을 유지합니다.
캐싱 전략 (Redis, Azure Cache for Redis 등)
**캐싱(Caching)**은 반복되는 데이터 조회 부담을 줄여주는 핵심 기법입니다.
쿠팡의 서비스에서는 제품 목록, 사용자 세션, 인기 검색어, 재고 정보 등 변경 빈도가 낮고 조회가 빈번한 데이터를 캐시에 저장해 DB 부하를 낮춥니다.
Azure에서는 완전 관리형 캐시 서비스인 Azure Cache for Redis를 활용하여 캐시 레이어를 구축합니다
(Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn). Redis는 인메모리 데이터 저장소로, 마이크로초 단위의 읽기/쓰기 지연을 제공하므로 대규모 트래픽에도 응답 속도를 높여줍니다.
구체적인 캐싱 전략으로는 읽기 캐시와 쓰기 캐시를 나눠볼 수 있습니다:
- 읽기 캐시: 데이터베이스 조회 결과를 캐시에 저장해 두고 이후 동일 요청 시 DB가 아닌 캐시에서 바로 반환합니다.
예를 들어 상품 상세정보 API 호출 시 먼저 Redis 캐시를 조회해서 데이터가 있으면 즉시 반환하고(DB 쿼리 생략), 없으면 DB에서 가져와 응답하면서 그 결과를 캐시에 저장하는 패턴입니다.
이렇게 하면 Cache Hit일 경우 DB 부하 없이 신속히 응답할 수 있습니다.
쿠팡은 수천만 상품 데이터를 다루므로, 인기 상품은 캐시에 올려두고 반복 조회에 효율적으로 대응합니다.
Azure Cache for Redis는 고가용성 및 자동 스케일링 옵션도 있어 트래픽 증가에 따라 캐시 용량을 늘릴 수 있습니다.
실제 Azure 솔루션 예시에서도 웹 페이지 출력을 Redis에 캐시하여 페이지 로드 성능을 향상시킵니다 (Architect scalable e-commerce web app - Azure Architecture Center | Microsoft Learn). - 쓰기 캐시/세션 캐시: 사용자 세션이나 쇼핑 카트처럼 짧은 기간 유지되는 데이터는 DB 대신 캐시에 저장하여 메모리 기반 처리로 속도를 높입니다.
예를 들어 사용자가 상품을 장바구니에 담으면 그 정보를 즉시 Redis에 세션별로 기록하고, 주문 확정 시에만 한 번 DB에 영구 저장하는 식입니다.
이렇게 하면 장바구니 조회/수정은 모두 메모리에서 처리되어 빠르고, DB에는 최종 확정된 데이터만 반영하므로 부하가 적습니다. 또한 분산 세션 저장소로 Redis를 쓰면, 사용자가 여러 웹 서버로 라운드로빈되더라도 세션 일관성을 유지할 수 있습니다. - 멀티 레벨 캐싱 및 CDN: 정적 컨텐츠(제품 이미지, CSS, JavaScript)는 Azure CDN을 사용해 Edge 노드에 캐시하고 사용자와 가장 가까운 노드에서 서빙합니다
(Architect scalable e-commerce web app - Azure Architecture Center | Microsoft Learn).
또한 브라우저 레벨 캐시(Cache-Control 헤더)도 적극 활용하여, 동일한 자원에 대한 불필요한 재요청을 막습니다.
캐싱은 만능열쇠는 아니므로 만료 정책을 신중히 관리해야 합니다.
Redis 캐시 항목에 **TTL(Time-to-Live)**을 설정해 일정 시간 후 자동으로 폐기하거나, DB 업데이트 시 관련 캐시를 수동으로 무효화하는 Cache Invalidation 로직이 필요합니다.
쿠팡에서는 상품 가격이 변경되면 해당 상품ID의 캐시를 지우도록 이벤트를 발생시키거나, 주문 후 재고 수량이 변경되면 재고 캐시를 갱신하는 식으로 데이터 정합성을 유지합니다.
또한 캐시 용량이 부족해지면 LRU(Least Recently Used) 등 알고리즘으로 오래 사용 안 한 항목부터 제거하여 메모리를 확보합니다.
이러한 캐싱 전략을 통해 읽기 응답 속도 개선, DB 부하 감소, 네트워크 트래픽 절감 효과를 얻을 수 있습니다.
실제 Azure 아키텍처 가이드도 Redis 캐시를 추가하면 고객 응답시간을 개선하고 고부하 트래픽을 흡수할 수 있다고 명시하고 있습니다
쿠팡은 전방위에 걸쳐 캐싱을 활용함으로써, 대형 이벤트 기간(예: 블랙프라이데이)에도 서비스가 원활히 동작하도록 합니다.
비동기 메시징 (Azure Service Bus, Event Grid 등을 활용)
비동기 메시징은 앞서 언급한 이벤트 드리븐 아키텍처의 구체적인 구현 수단으로, 시스템의 성능과 확장성을 높이는 데 기여합니다.
동기식 REST 호출은 호출자와 피호출자가 모두 완결될 때까지 대기해야 하지만, 비동기 메시징을 사용하면 호출자는 메시지를 보내놓고 즉시 반환하고 후속 작업은 수신자가 별도로 처리합니다.
이 덕분에 사용자 요청에 대한 **응답 지연(latency)**을 줄이고, 백엔드 작업은 병렬로 처리하거나 큐잉하여 스파이크 트래픽을 평활화할 수 있습니다.
Azure에서는 Service Bus, Event Grid, Storage Queue 등 다양한 메시징 서비스를 제공하며, 쿠팡 아키텍처에서는 주로 Azure Service Bus와 Event Grid를 활용합니다:
- Azure Service Bus: Service Bus는 Azure의 엔터프라이즈 메시징 서비스로, 고신뢰 큐와 토픽(topic) 기능을 제공합니다.
큐를 사용하면 1:N 구조에서 한 번에 한 소비자가 메시지를 처리하고, 토픽/구독을 사용하면 1:다 구조로 한 이벤트를 여러 소비자가 받을 수 있습니다.
Service Bus는 FIFO 순서 보장, 트랜잭션, 복수 구독자, Dead-letter 큐 등 강력한 기능이 있어 금융 거래나 주문 처리 등 **정확하고 한 번만 처리(at-least-once)**가 중요한 시나리오에 적합합니다.
쿠팡에서는 주문, 결제, 배송 간 연계에 Service Bus 큐/토픽을 사용해 프로세스 디커플링을 달성합니다. 예를 들어 주문 생성 메시지를 큐에 넣으면 여러 백엔드 프로세서가 Competing Consumers 패턴으로 병렬 처리하여 throughput을 높이고, 처리 실패 시 메시지를 죽은 편지로 넘겨 별도 처리함으로써 내구성을 확보합니다. Microsoft 문서에서도 Service Bus가 마이크로서비스 간 일반적인 비동기 메시징 패턴을 지원한다고 명시되어 있습니다
(Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn). - Azure Event Grid: Event Grid는 Azure의 서버리스 이벤트 라우팅 서비스로, 이벤트 생산자와 소비자를 느슨하게 연결해주는 퍼블리시/구독(pub/sub) 플랫폼입니다.
Service Bus보다 더 경량화된 구조로, Azure 리소스에서 발생하는 이벤트(Azure Blob에 파일 업로드 등)나 커스텀 이벤트를 손쉽게 전달할 수 있습니다.
Event Grid는 푸시(push) 방식으로 구독자에게 HTTP 요청을 보내 이벤트를 알리며, 서버를 직접 운영하지 않아도 돼 확장성 면에서 뛰어납니다.
또한 Azure Functions, Logic Apps 등과 자연스럽게 연계되어 서버리스 아키텍처의 허브 역할을 합니다.
예를 들어 신규 주문이 발생하면 Event Grid를 통해 서버리스 함수들에게 이벤트를 뿌리고, 각 함수가 문자메시지 발송, 이메일 발송, 추천 시스템 트리거 등 다양한 후속작업을 수행하도록 구성할 수 있습니다.
Event Grid는 자동 확장되며 최대 수백만 TPS를 처리할 수 있어, 쿠팡의 이벤트 처리 요구사항 (예: 실시간 로그 스트림, 가격 변동 이벤트 전파 등)에 효과적입니다.
Event Grid 자체는 요금이 이벤트 수에 비례하므로 높은 QPS 상황에서도 비용 효율적으로 운용할 수 있습니다. 참고로, Event Grid는 완전 관리형, 고가용성, 유연한 라우팅을 제공하여 클라우드 상 이벤트 처리의 복잡함을 줄여줍니다
(Azure - Event-Driven Architecture in the Cloud with Azure Event Grid | Microsoft Learn). - Azure Event Hubs (필요 시): Event Hubs는 대용량 텔레메트리 스트림에 특화된 이벤트 인제스트 서비스로, 초당 수백만건의 이벤트를 순차 로그에 수집하는 데 쓰입니다.
쿠팡에서 사용자 클릭스트림, 앱 로그, IoT 데이터 등을 실시간 분석하려면 Event Hubs를 통해 데이터를 모으고 Spark/Stream Analytics로 처리할 수 있습니다.
이는 성능 최적화보다는 빅데이터 파이프라인 측면이지만, 시스템 전반 성능에 영향을 미치는 부분이기에 필요한 경우 포함됩니다.
비동기 메시징을 도입하면 **백프레셔(backpressure)**를 자연스럽게 처리할 수 있습니다.
급격한 주문량 폭증 시 큐의 길이가 일시적으로 늘어나더라도 시스템은 다운되지 않고, 소비자가 따라잡을 때까지 순차 처리하면 됩니다.
반면 동기 처리였다면 타임아웃이나 장애로 이어질 상황을 메시징으로 탄력적으로 흡수하는 것입니다.
다만 메시징 도입 시 멱등 처리, 중복 메시지 제거, 메시지 순서 등에 유의해야 합니다.
Service Bus의 세션이나 동일 파티션 키를 활용하면 순서를 보장할 수 있고, 메시지 ID 기반으로 중복 수신을 체크해 무해하게 무시하는 로직이 필요합니다.
Azure Functions의 Trigger 기능을 사용하면 Service Bus나 Event Grid의 메시지를 편리하게 콜백 처리할 수 있어 개발 생산성도 높습니다
(Architect scalable e-commerce web app - Azure Architecture Center | Microsoft Learn).
정리하면, 쿠팡의 마이크로서비스들은 Service Bus와 Event Grid로 구성된 메시징 백본(backbone) 위에서 느슨하게 연결되어 높은 성능과 확장성을 발휘합니다
(Advanced Azure Kubernetes Service (AKS) microservices architecture - Azure Architecture Center | Microsoft Learn) (Azure - Event-Driven Architecture in the Cloud with Azure Event Grid | Microsoft Learn).
사용자 요청에 대한 응답은 빨라지고, 내부 작업은 이벤트 드리븐으로 처리되어 시스템 자원을 효율적으로 사용하게 됩니다.
서버리스 컴퓨팅 (Azure Functions) 활용
**서버리스(Serverless)**는 필요한 시점에 필요한 만큼만 리소스를 소비하는 실행 모델로, 쿠팡의 일부 워크로드에 적용하여 비용과 운영 부담을 줄이고 있습니다.
Azure의 대표적인 서버리스 서비스인 Azure Functions는 이벤트 기반으로 코드를 실행하며, 자동으로 인스턴스를 할당/해제하여 부하에 대응합니다
(Azure Functions scale and hosting | Microsoft Learn).
쿠팡 아키텍처에서 Azure Functions를 활용하는 몇 가지 예:
- 백그라운드 작업 처리: 주문 완료 후 영수증 메일 발송, 배송 추적 업데이트, 추천 상품 계산 등 즉각적인 응답은 필요 없지만 후속으로 반드시 처리해야 하는 작업들을 Azure Function으로 구현합니다. 이 함수들은 Event Grid나 Service Bus의 트리거를 받아 실행되고, 작업 완료 후 자동 종료됩니다
(Architect scalable e-commerce web app - Azure Architecture Center | Microsoft Learn). 서버를 상시 띄워둘 필요 없이 이벤트 발생 시에만 실행되므로 리소스 효율성이 높습니다. - 스케줄러 작업(Cron): 매일 심야에 재고 정산을 한다든지, 매 시간마다 로그를 집계한다든지 하는 정기 작업에 Azure Functions의 Timer 트리거를 사용합니다.
별도 스케줄러 서버 없이 클라우드에서 지정된 크론식에 따라 함수를 실행하므로 관리포인트가 줄어듭니다. - API 처리 및 BFF(Backend for Frontend): 간단한 API 엔드포인트나 모바일 BFF 역할을 함수로 구현할 수도 있습니다.
Azure Functions는 HTTP 트리거도 제공하여, 소규모 서비스라면 굳이 AKS에 배포하지 않고 함수로 바로 API를 만들면 필요 시 자동 확장되고, 사용 안 하면 비용이 발생하지 않습니다.
다만 응답시간이 아주 중요한 서비스(예: 사용자-facing API)는 콜드스타트 이슈 때문에 앱 서비스나 AKS에 두는 것이 일반적입니다.
Azure Functions의 큰 장점은 자동 확장성입니다.
쿠팡의 특정 이벤트가 일시에 폭증해 함수 호출이 갑자기 늘어나면, Azure가 알아서 함수 인스턴스를 수십 수백 개까지 늘려 병렬 실행합니다
(Azure Functions scale and hosting | Microsoft Learn).
개발자는 함수의 단일 실행 논리만 신경 쓰면 되며, 인프라는 Azure가 관리합니다.
이 덕분에 짧은 시간에 대량의 작업을 처리해야 하는 시나리오에 적합합니다.
가령 한꺼번에 1만 건의 주문 배송완료 이벤트가 들어와도, 이를 처리하는 함수를 Azure가 병렬 실행해 수분 내 모든 후처리를 끝낼 수 있습니다.
또한 서버리스는 비용 절감 효과가 있습니다.
함수는 실행 시간과 실행 횟수에 기반해 과금되므로, 트래픽이 적을 때는 거의 비용이 들지 않습니다.
반면 상시 VM이나 컨테이너는 유휴 시간에도 비용이 계속 발생하죠.
쿠팡처럼 트래픽 패턴이 일간 주기나 요일별 차이가 큰 서비스는, 일부 기능을 서버리스로 구현하여 피크 때만 비용 지불하고 평상시에는 절약하는 구조를 취할 수 있습니다.
Azure Functions 외에도 Azure Logic Apps(시각적 워크플로 자동화)나 Azure Durable Functions(상태를 가진 장기 실행 서버리스) 등을 사용해 복잡한 백엔드 프로세스를 구성합니다.
예를 들어 주문 취소 후 환불 프로세스를 Durable Function으로 구현하여, 중간에 외부 승인 대기 같은 상태를 관리하면서 멱등성있게 흐름을 끝까지 실행할 수도 있습니다.
서버리스를 도입할 때 고려할 점은 모니터링 및 디버깅과 콜드 스타트입니다.
Azure Application Insights를 사용해 함수의 로그와 성능을 모니터링하고, 분산 트레이싱으로 어디서 병목이 있는지 파악합니다.
콜드 스타트는 소비 플랜에서 발생할 수 있으나, 프리미엄 플랜이나 Always On 설정으로 완화할 수 있습니다.
쿠팡 시스템에서는 사용자 영향이 적은 비동기 처리에 주로 함수앱을 활용해 이러한 콜드 스타트 이슈를 회피합니다.
종합하면, Azure Functions 등 서버리스 기술은 쿠팡 아키텍처의 보조적 요소로 활용되어 아키텍처를 더욱 유연하고 탄력적으로 만들어줍니다
(Architect scalable e-commerce web app - Azure Architecture Center | Microsoft Learn) (Azure Functions scale and hosting | Microsoft Learn).
개발팀은 인프라 관리 부담을 덜고 오로지 코드 구현에 집중할 수 있으며, 시스템은 필요한 순간에만 자원을 소비하여 전체적인 효율성이 향상됩니다.
마무리
지금까지 쿠팡의 엔터프라이즈 시스템을 C#과 Microsoft Azure를 기반으로 설계하는 방안을 살펴보았습니다.
마이크로서비스 아키텍처로 서비스를 분리하고, AKS로 컨테이너를 운영하며, 이벤트 드리븐 설계로 유연성과 확장성을 확보했습니다.
또한 폴리글롯 데이터베이스 전략과 CQRS/이벤트 소싱으로 데이터 일관성을 유지하면서 성능을 높이고, Zero Trust 보안 모델 및 Azure 보안 서비스를 통해 안전한 운영을 도모하였습니다.
끝으로 캐싱, 비동기 메시징, 서버리스 최적화를 적용하여 대규모 트래픽에 대한 높은 성능과 비용 효율성을 얻을 수 있었습니다.
쿠팡 사례를 통해 본 이러한 아키텍처 원칙과 구현 방법들은 대규모 클라우드 애플리케이션을 설계하려는 개발자와 아키텍트에게 유용한 참고가 될 것입니다.
핵심은 요구사항에 맞는 Azure의 매니지드 서비스와 .NET 기술 스택을 적재적소에 활용하여, 변화에 빠르게 대응하고 탄력적으로 확장되는 시스템을 만드는 것입니다.
C# 및 Azure 조합은 엔터프라이즈 수준의 개발 생산성과 운영 편의성을 제공하므로, 올바른 아키텍처적 판단과 결합하면 쿠팡처럼 대규모 트래픽에도 끄떡없는 견고한 클라우드 네이티브 시스템을 구현할 수 있을 것입니다.
앞으로도 이러한 모범 사례를 발전시켜 나감으로써 더 나은 확장성과 신뢰성을 갖춘 서비스 아키텍처를 구축해 나가길 기대합니다.
댓글
댓글 쓰기