네이버 페이 배송 모듈 아키텍처 및 사용기술 분석

많은 양의 트래픽을 감당하고 어떻게 고가용성의 시스템을 구축하는지 알아보기 위해서 네이버 기술 블로그 및 세미나를 보면서 사용하는 기술을 분석하고 어떤 고민을 하고 있는지 살펴보았다.

네이버 페이가 고민했던 문제점

위에 있는 기술 세미나 영상을 보면서, 기존에 네이버 페이에서 발생했던 문제점들과 이를 해결하기 위한 기술들을 살펴볼 수 있었다.

네이버 페이에서 유저와 상호 작용하는 서비스

• 스마트 스토어에 보이는 주문형 페이
• 배달의 민족에 연동되어 있는 결제형 페이
• 송금
• 네이버 통장

배송 모듈은 주문형 페이에 속하고, 주문형 페이에는 이커머스 삼대장인 주문, 배송, 클레임 을 관리하는 부서이다.

배송 모듈의 특징 및 문제점

• 배송 모듈은 트래픽이 높았고, 다른 모듈과는 다른 특성이 있었다.
• 다른 모듈들은, 온라인에서 데이터가 생성되며 액션의 주체가 사용자 및 내부시스템이다.
• 배송은 오프라인에 의해서 데이터가 생성되며 액션의 주체가 유저가 아닌 외부 시스템이다.
• 다른 모듈은 자체적으로 데이터를 생산하기에 데이터 보정 및 생성 규칙에 대해서 지정을 할 수 있지만, 배송 모듈은 외부에 의해서 생성되는 데이터이기 때문에 데이터에 대한 필터링 및 검증이 어렵다.

• 또한 점점 더 비즈니스 로직이 복잡해지고, 따라서 배송 모듈에 대한 트래픽도 증가했다.

기존 배송 시스템

• 택배사와 다이렉터로 연결하는 것이 아니라, 배송 모듈을 엔드포인트로 하여, 택배사의 정보를 제공해주는 업체와 연동을 하였다.

• 배송 데이터가 생성되면 연동 업체에 전달하고, 변경 사항이 발생했을 때, 연동 업체에서 변경분에 대해서 FTP 통신으로 정보를 주고 받았다.

• 최소 설계시에는 빠른 배송에 대한 관심이 없었던 시절이라서 FTP 통신으로도 문제가 없었지만, 빠른 배송에 대한 니즈 및 실시간성을 사용자들이 요구하면서 위의 구조는 한계점을 드러내었다.

배송 데이터 생성 패턴

• 배송의 경우 특정 시간대에 트래픽이 몰리게 된다.

한계점

• HPA(Horizontal Pod Autoscaler) 구성이 되어있지 않음
• 배송 처리로 인해서 상품 주문 및 클래임으로 다른 모듈에 부하가 전파된다.
• 장애 인지의 어려움 (지연, 누락, 장애)
• 내부 시스템에서 장애가 발생한 경우에는 비교적 빠른 대응이 가능했지만, 외부 업체에서 생성된 장애를 인지하기에는 어려웠다.
• 모니터링 시스템이 미비하여 쉽게 장애를 캐치하기 어려웠다.
• 택배사가 코드에 적용되어 있어, 심심하면 나타나는 택배사를 추가해주어야하는 업무가 있었다.
• 이전에는 국내 택배사만 있었지만 최근에는 (일반, 해외, 물류, 장보기) 등 다양한 종류의 택배사가 등장했다.

개선 시도

• 과거 FTP를 통해서 통신하던 배치에서 Kafka로 변경하여 적용하였다.

• 결제 모듈과 다르게, 배송은 특정 시간대에 몰리게 되며, 배송은 N개 단위의 벌크로 진행하게 된다. 이 통신 사이에는 데이터 밸리데이션을 수행하고 데이터가 유실될 경우 데이터를 재보정 처리할 수 있어야하는 구조여야 한다.

• 또한 데이터가 외부 업체와 연동이 되어야하므로, 누구 귀책으로 데이터가 처리되지 않았는지를 알아야한다.

• 또한 한 요청당 약 1000건의 데이터 통신이 이루어 지므로, 통신이 길어지는 문제가 발생하였다.

• API로 수신한 내용들을 파일로 저장하고, 그 파일을 배치로 처리하는 구조로 변경하였다.
• 하지만 여전히 대량의 데이터를 처리하는데에는 많은 한계를 가지고 있었다.

• 따라서 카프카를 이용하여, 이러한 작업을 처리해주었다.
• 배치가 주는 모니터링의 장점을 버리게 되었다.
• 배치가 카프카로 변경되는 건 기술을 적용했을 뿐 큰 변화는 없었다.
• 데이터 누수 및 보정에 대한 새로운 FLOW 생성이 필요했다.
• 메시지 스펙 정의 시 확장이 아닌 기능 기반 설계를 진행하였다.

배송 분리 프로젝트 Plasma

• 네이버 페이 서비스의 Scalability 확보
• 모놀리틱 구조의 네이버 페이 주문 서비스를 분리
• 기존 네이버 페이 서비스 개발자와 사내 플랫폼 개발자가 협업

문제 해결 접근 방법

• 기술적인 부분과 비즈니스 적인 부분을 나누어서 생각을 했다.

이 부분에는 나도 공감하는데, 기술적으로 풀려고 시도했을 경우 많은 생각을 해야하지만 사실 비즈니스적으로 변경하여 문제가 쉽게 풀리는 경우가 많았다.

• 렉 모니터링에 대한 세분화된 알람이 필요할 것으로 보임
• 앞 모듈에 컨트롤 할 수 있는 부분을 두어서 랙이 기준치 이상 도달 할 경우, 우선순위가 중요한 메시지는 특정 큐에 집어 넣고 특정 큐에 대한 오퍼레이션을 별도로 수행하는 구조를

배송 서비스를 분리한 후에 구조

• 복잡한 쿼리가 필요한 데이터들은 분산 RDBMS에 저장을 한다.
• 로직이 간단한 데이터들은 Redis에 저장을 한다.
• 간단한 조회의 경우에는 API 서버를 통해서 분산 저장소에서 데이터를 읽어와 처리한다.
• 추가 처리가 필요한 경우에는 Kafka에 추가 처리나 이벤트를 발송시키게 된다.
• Kafka에서 처리하는 모든 이벤트는 Logstash를 통해서 Elasticseach에 저장이 된다.

이벤트 기반 모니터링

• 데이터베이스에는 최종 데이터만 저장하고 갱신하기 때문에, 이벤트 기반 모니터링 시스템을 구축하였다. 따라서 특정 시간에 대한 데이터를 배송 이벤트를 분석해서 데이터를 처리하기 때문에 상태를 추적하거나, 상태를 복원할 수 있었다.

요약

• 확장성에 대해서는 분산 저장소를 사용하여, 스토리지 확장성을 높혔고, 쿠버네티스를 활용하여 컴퓨팅 확장성을 높혔다.

• 모니터링을 강화함으로써, 운영 비용을 절감시켰다.

• 인스턴스 분리 및 의존성 분리를 통해서 장애적으로 독립적인 상태가 되었다.

네이버 페이 아키텍처 및 인프라 구성

나도 현재는 웹 개발자로 일하고 있지만 언젠가는 플랫폼 개발을 경험하고 싶은 마음이 있는데, 멋있다는 생각이 들었다. 내가 만든 기능을 통해서 개발자들이 어떤 서비스를 만들었다고 생각하면 자부심과 동시에, 책임감을 느낄 수 있을 것 같다. 물론 이는 모든 개발자가 마찬가지지만 특히 플랫폼 개발을 하면 더욱 와닿을 것 같은 생각이 들었다. 내가 오픈 소스 활동을 하는 이유도 이와 비슷하다. 다른 사람들에게 선한 영향력을 주고 싶다.

• 네이버페이는 비즈니스 성장과 트래픽 급증에 대응할 수 있도록 마이크로 서비스 아키텍처와 이벤트 드리븐 아키텍처를 적용해서 개발하고 있다.

• 이러한 구조를 사용하면 각각의 마이크로서비스가 독자적으로 유연하게 개발되고 데이터가 더 다양한 곳에 다양한 형태로 존재하게 된다.

• 따라서 기존에 고려되었지 않았던 새로운 문제가 발하고 이러한 문제를 플랫폼에서 지원해서 시스템적으로 해결하면 서비스와 완성도를 높일 수 있다.

• 따라서 기존 서비스 개발자와 플랫폼 개발자가 협력하여 일을 하고 있다.

마이크로서비스 아키텍처 및 이벤트 드리븐 아키텍처에 대해서 대략적으로만 알고 있어서 이 기회에 정리를 해보았다.

마이크로 서비스 아키텍처

• 마이크로 서비스 아키텍처는 애플리케이션을 느슨하게 결합된 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.

• 마이크로서비스 아키텍처에서 서비스들은 섬세하고, 프로토콜은 가벼운 편이다.

• 마이크로 서비스 아키텍처의 서비스들은 독립적인 배포가 가능하다.

• 서비스의 교체가 쉽다.

이벤트 드리븐 아키텍처

• 이벤트 드리븐 아키텍처(EDA)는 이벤트의 생산, 감지, 소비 및 반응을 제고하는 소프트웨어 아키텍처 패턴이다.

• 이벤트는 “상태의 변화"로 정의할 수 있다.

• 시스템 내부 및 외부에 발생한 주목할 만한 상태의 변환에 기반하여 동작한다.

• 예를 들어, 소비자가 자동차를 구매할 때, 자동차의 상태는 “판매 중"에서 “판매 완료"로 바뀐다.

• 특정 행동이 자동으로, 순서에 따라서 발생하는 것이 아닌 어떤 일에 대한 반응으로 동작하는 패턴이다.

이벤트 주도 마이크로서비스(EDM)

이벤트 주도 마이크로 서비스(EDM)은 MSA가 적용된 시스템에서 이벤트 발생시 해당 이벤트 로그를 보관하고 이를 기반으로 동작하며, 비동기 통신을 통해 시스템 내 통합(integeration)을 수행하는 아키텍처이다.

• 이벤트 : 이벤트 주도에서 언급하는 이벤트는 상태의 변경, 즉 데이터의 변경, 생성, 삭제 (CUD)를 통해서 발생하는 서비스의 의미있는 변화를 뜻한다.

• 이벤트 로그 보관: 현재의 데이터는 상태 변경의 누적이라는 생각에서 시작한다. 이 때의 상태 변경은 이벤트를 뜻하고 이를 누적하는 행위는 이벤트 로그를 보관하는 것이다.

• EDM에서 생성한 이벤트는 반드시 보관되어야 한다. 보관된 이벤트는 데이터의 현재 상태를 구성하는 근간이 된다.

• 또한 보관된 이벤트를 바탕으로 장애 발생 또는 특정 요구사항에 따라 지정된 시점으로 복원을 수행한다. 이벤트 로그를 보관하는 장소를 이벤트 스토어라고 한다.

• 비동기 통신 : AMQP, MQTT, JMS등 메세지 프로토콜을 통한 메시지 큐 방식이 자주 사용된다. 서비스에서 데이터의 생성, 변경, 삭제(CUD)를 통해 이벤트가 발생하면, 발생 서비스는 메시지의 형태로 이벤트를 발생하고, 해당 이벤트에 관심이 있는 서비스에서 구독을 수행한다.

네이버 페이를 뒷 받침하는 플랫폼

• 빠르고 유연한 확장을 위해서, 쿠버네티스 클러스터에서 서비스 이미지를 배포해서 사용하고 있다.

• 메인 데이터베이스 저장소로는 자체 분산 데이터베이스 클러스터(nBase-T)와 분산 레디스 클러스터를 사용하고 있다.

• 이벤트 전달 및 저장을 위해서 Kafka, ElasticSearch 클러스터와 LogStash를 사용하고 있다.

• 모니터링과 분석을 위해서 사용하는 플랫폼은 Grafana를 사용하고 있고, Elasticsearch 상태와 데이터 확인을 위해서 Kibana와 Cerebro를 사용하고 있다.

• 로그 수집과 매트릭 수집은 자체 플랫폼을 사용하고 있고 APM(application performance management)로는 사내에서 오픈 소스로 발표한 Pinpoint를 사용하고 있다.

이러한 플랫폼을 활용해서 서비스를 개발하고 있고, 공통화가 필요한 부분은 플랫폼에 적용하거나 라이브러리화 하고 있다.

인상 깊었던 부분은 Spring Data JDBC에서 제공하지 않는 추가 기능들은 직접 개발해서 사용한다는 것이다. 기술에 이해도가 높지 않으면 절대로 쉽지 않다는 것을 알기 때문이다.

인프라 운영

• CI/CD 시스템으로 젠킨스를 적극적으로 활용하고 있다.
• 서비스가 메모리나 CPU를 과도하게 사용하고 있으면 Grafana가 알려주고, 오류 로그가 있으면 로깅 시스템이 알려주고, Kafka에 LAG이 생기면 매트릭 시스템이 알려주고, 에러 응답이 늘어나면 Pinpoint가 알려주는 식으로 동작한다.
• 서비스가 복잡해지고 문제 상황에서 확인해봐야 하는 곳이 늘어나도 이러한 알람을 통해서 빠르게 파악할 수 있다.
• 이러한 플랫폼들을 활용하여 시간을 아낄 수 있었고, 아낀 시간을 서비스 개발에 투자할 수 있었다.
• 새로운 플랫폼을 접했을 때는 대부분 개념 증명부터 해보면서 필요한 부분만 빨리 익혀서 사용하는 편이라고 했다.

일하는 방식

• 길거나 짧은 목표를 설정한 후 거기까지 각자의 역량을 발휘해서 자유롭게 도달하는 방식으로 일한다.

• 목표에 어떤 방법으로도 도달해도 좋지만, 그 방식에 타당한 이유가 있어야하고, 방식에 확신이 없을 때는 주위 사람과 활발하게 논의해서 진행한다.

• 서비스의 목표 내지는 문제를 해결하는 과정에서 플랫폼이 지원하면 효율적인 일도 도출되었던 것 같다.

• 기록과 공유가 권장되는 분위기이다. 그렇기에 팀에서는 사내/외 세미나나 기고를 통해서 경험을 활발하게 공유하고 있다.

참고 문헌

• 네피셜 플랫폼 개발자의 커머스 서비스 개발기
• Wiki - Microservices
• Event Driven Architecture란?
• 페이왕국 주문가문 배송용사 독립기