메뉴

문서정보

목차

PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기

위 동영상을 분석해서 정리한다. 영상에서 PAYCON 쇼핑 플랫폼은 NHN TOAST 클라우드를 기반으로 하고 있다. 나는 AWS를 사용하고 있기 때문에 AWS 클라우드를 기반으로 새로운 아키텍처를 제안하려 한다. TOAST에 비해서 AWS에서 제공하는 서비스가 훨씬 다양하기 때문에 더 많은 부분이 클라우드 서비스로 대체되는 그림이 나올 것이다.

당연하지만 나는 PAYCO 쇼핑 개발과는 1도 상관이 없기 때문에 많은 부분을 일반화해서 설명할 것이다.

PAYCO

페이코(PAYCO)는 미리 결제수단을 등록해두고 등록한 결제수단을 통해서 결제를 하는 간편결제 서비스다. 결재외에 송금, 금융정보 조회, 비대면 채널링 등 서비스를 확장하고 있다. 결재는 온라인과 오프라인 모두 지원하며, 모바일(안드로이드, 아이폰)에서 앱을 다운로드받아서 간편하게 사용 할 수 있다. 삼성 페이, 네이버 페이, 카카오페이와 함께 4대 간편결제 서비스로 꼽히고 있으며, 토스, 뱅크셀러드와 함께 주요 금융 플랫폼 기업으로 꼽히고 있다.

PAYCO 서비스의 핵심 키워드는 4개로 정리된다.
  1. 결제
  2. 송금
  3. 금융
  4. 생활

PAYCO 쇼핑

상품 검색부터, 쇼핑 결제까지 모두 페이코로 가능한 쇼핑 채널링 서비스다. 참고로 채널링 서비스란 방문자를 다른 서비스로 연결해주는 서비스를 말한다. 영상자료를 보면 채널링 서비스로서의 PAYCO 쇼핑의 특징을 정확히 확인 할 수 있다.

 PAYCO 쇼핑

다나와가 대표적인 채널링 서비스다.

PAYCO 쇼핑 기본 구조

 PAYCO 쇼핑 기본 구조

PAYCO는 쇼핑 채널링 서비스다. 채널링 서비스를 제공하기 위해서는 파트너사로 부터 상품 정보를 주기적으로 수집을 해야 한다. 아마도 배치 서버를 이용해서 주기적으로 상품 정보를 수집 할 것이다. 수집한 정보는 검색엔진을 이용해서 색인한다. 쉽게 생각 할 수 있는 검색엔진으로 ElasticSearch 와 Solr가 있다.

고객은 "홈쇼핑 웹 서버"에서 상품 정보를 요청하면, 검색서버에 질의를 보내고 이 결과를 고객에게 출력한다.

구매의사가 있는 고객이 상품 구매하기 버턴을 누르면, 고객/상품 정보와 함께 PAYCO 결재를 수행 할 수 있는 PAYCO ID가 파트너 쇼핑몰로 전달된다. 다나와 같은 서비스는 상품 페이지로의 링크만 제공 할 수 있는 반면 PAYCO는 결제 서비스까지 통합 할 수 있다. 괜찮은 서비스 아닌가? 하는 생각이 드는데, 달리 생각해보면 이건 그냥 더 잘 할 수 있는 전문 파트너사에게 맡기는게 낫겠다는 생각도 든다.

이렇게 해서 고객은 쇼핑몰에서 PAYCO ID로 물건을 구매하고 결제를 끝낸다. 파트너 쇼핑믈은 PAYCO 결제 API를 호출 할테고, 자연스럽게 주문 정보가 주문서버에 수집된다. 주문서버에 수집된 정보는 분석을 거쳐서 고객 데이터에 반영한다. 반영된 데이터는 상품 추천, 상품판매 분석 등에 다양하게 활용 할 수 있을 것이다.

채널링 서비스의 일반적인 구조라고 볼 수 있겠다.

AWS GLUE

PAYCO 쇼핑 구조는 두 개 부분으로 나눌 수 있다.
  1. 데이터를 수집해서 서비스 할 수 있도록 색인하고 서비스하는 과정 : 전형적인 ETL이다.
  2. 컴퓨팅 파워로 비지니스 로직을 수행하는 부분
이중 ETL 부분은 AWS GLUE로 재 구성할 수 있을 것이다. AWS GLUE는 관리형 ETL(추출, 변환, 로드) 서비스다. 데이터 소스를 읽어서 미리 만들어둔 형식으로(혹은 자동으로) 데이터를 변환하고 변환된 데이터를 다른 타겟에(RDBMS, DW, S3...) 적재하는 일을한다. PAYCO의 쇼핑 기본 구조에서 "상품 수집 -> 검색서버" 까지의 과정을 처리 할 수 있다.

PAYCO 쇼핑 기본 구조는 수집에서 검색서버 까지의 과정을 개요를 묘사하고 있지만 실제로는 많은 복잡한 작업들이 들어간다. AWS GLUE를 이용해서 ETL 전 과정을 자동화 할 수 있다.

 GLUE를 이용한 ETL

파트너 쇼핑몰의 데이터는 배치작업으로 S3에 저장한다. 데이터가 저장되면 람다(Lambda)코드가 실행되고, 데이터 카탈로그를 참조하여 ETL 작업을 수행한다. 최종적으로는 ElasticSearch, Redshift 등으로 로딩된다.

NCP(NHN Commerce Platform)

최근의 인터넷 서비스들이 그러하듯이 SaaS 형태의 전자상거래 솔류션을 개발하고 있었던 것으로 보인다. NHN 솔류션인 만큼 클라우드 서비스는 토스트(TOAST)이다. 클라우드에서 SaaS 형태로 개발하는 이유는 아래와 같이 정리 할 수 있다.
  1. 고객 입장에서는 인터넷 서비스 형태로 솔류션을 사용할 수 있기 때문에 비용 부담을 덜 수 있다. 이 경우 PAYCO 쇼핑는 NCP의 서비스가 된다.
  2. 즉시 사용 가능하다.
  3. 소프트웨어를 설치할 물리적 자원이 필요하지 않다. 어디에서든 접근 할 수 있다.
SaaS는 서비스 형태로 애플리케이션을 전달하는 형태로 설치형 애플리케이션처럼 작업환경에 맞게 커스터마이징을 자유롭게 할 수는 없다. 따라서 SaaS 제공자는 "소스코드에 대한 직접적인 코드 수정 없이도 다양한 워크플로를 지원 할 수 있도록"유연하게 개발해야 한다. 워드프레스(WordPress)를 생각해보면 된다.

NCP의 도메인은 아래와 같다(고) 한다.

 NCP 비지니스 도메인

NCP는 쇼핑몰을 위한 7개 카테고리의 기능들을 제공한다. 하지만 PAYCO 쇼핑 서비스 전통적인 쇼핑몰이 아닌 채널링 서비스 였으므로 필요한 기능들을 선택해서 서비스를 개발한다.

프로젝트 구성과 아키텍처

 모노리딕 구조

다양한 모듈들로 구성이 되는데 핵심은 모노리딕 구조를 따랐다는 점이다. 모든 핵심 비지니스 로직은 "COMMON" 모듈에 집중된다. 아래 그램은 Payco 쇼핑 아키텍처다.

 Payco 쇼핑 아키텍처

로드밸런서 -> WAS -> 캐시 -> 데이터베이스로 이어지는 구조다. PS.FE.API는 유저(쇼핑몰 서비스 사용자)를 위한 API를 제공한다. 파트너 서버에게는 백앤드 API인 PS.BE.API를 제공하는데, 아마도 PAYCO 쇼핑 결재 API로 생각된다. 기타 쇼핑 상품정보 업데이트를 위한 API를 제공 할 수도 있을 것이다. PS.WEB.ADMIN은 서비스 운영자를 위한 API를 제공한다.

이렇게 개발을 하고 운영을 하다보면 여러가지 요구사항이 발생 한다. 이러한 기능들의 많은 부분들을 Common 모듈에서 담당하다 보니, 시간이 지날수록 Common 모듈이 비대해진다. 그래서 아래와 같은 모습이 된다.

 거대해진 Common 모듈

이렇게 Common 모듈이 비대해지면서 아래와 같은 문제들이 발생한다.
  1. Common 모듈의 빌드시간이 늘어난다.
  2. 단위 테스트 시간이 늘어난다.
  3. 기능이 거대해지지면서 배포 리스크도 함께 늘어난다. 리스크를 줄이기 위해서 정기 배포의 간격이 늘어난다. 배포 담당자가 할당이 되며, 백업&롤백 플랜도 세워야 한다. 배포 자체가 하나의 커다란 업무가 된다. Common 모듈이 거대한 레거시가 된거다.
 Legacy system

이는 전반적인 생산성 감소로 이루어진다.
  1. 변경으로 인한 Side Effect : Common 모듈에 많은 기능들이 모여있기 때문에 한 기능의 작은 수정이 다른 영역에 영향을 줄 수 있다. 기능이 많아질 수록 수정한 내용이 미치는 영향을 예상하기 힘들어진다.
  2. 변경에 보수적으로 접근 함 : 소프트웨어에서 가장 큰 리스크는 높은 복잡도로 인한 예측 불가능 성이다. 애초에 코드가 간단하면 문제가 생기더라도 빠르게 복구 할 수 있지만, 코드가 복잡해지고 밀접하게 연결될 수록 이게 힘들어 진다. 결국 가능하면 코드를 변경지 않으려 한다. 레거시의 기능 하나 변경하려면 네트워크 담당자, 데이터베이스 담당자, 보안 담당자, 소프트웨어 개발자, 기획자가 모두 모여서 격론을 벌이는 장면을 본 개발자라면 이게 어떤 상황인지 감이 올것이다. 새로운 기술 도입대신에 Ctrl+C, Ctrl+V를 선호하게 된다.
  3. 라이브러리 버전을 올리는게 힘들다.
  4. Scale out이 쉽지 않다.
장애를 두려워하고 회피하려 하기 때문에 혁신적인 시도가 쉽지 않다. 시장이 빠르게 변하는 인터넷 환경에서는 치명적일 수 있다.

MSA

변화에 대한 두려움으로 코드를 내버려두면(혹은 깨작 깨작 문제가 터지지 않을만한 수준에서 손을 보다보면) 현대적인 요구사항을 따라갈 수 없는 시점이 된다. 쌓였던 기술부채를 감당할 수 없는 시점이 온다. 금융 시스템의 경우 차세대 프로젝트라는 이름으로 기술부채를 덜어내는 작업을 한다.

하여 모노리딕 아키텍처를 마이크로 서비스 아키텍처(MSA)로 변경하기 위한 작업을 한다.
  1. 서비스가 단순하던 시절이 있었음. 고객의 요구사항이 명확하고 다양하지 않았고 변화를 예측하기가 쉬웠기 때문에 하나의 완전한(그리고 거대한) 서비스를 만들어서 제공했다. : 포드사의 대량생산 대량판매 시스템이 먹히던 그런 시절을 생각하면 되겠다.
  2. 진정한 인터넷 시대가 도래. 모든 사업들이 인터넷위로 올라가고 모든 고객이 인터넷으로 모임. 시장의 요구사항이 시시각각 바뀌고 새로운 경쟁자가 계속 생겨난다. 예전 처럼 느리게 움직여서는 살아남을 수가 없다.
  3. "적응과 진화"가 중요한 시대. 이런 시대에 맞는 프레임워크를 만들자.
  4. 그래 애자일이 나온다.
  5. 어 클라우드가 나왔네 ? 컴퓨팅 파워를 소프트웨어화 할 수 있게 됐다!. 운영을 소프트웨어화 하자.
그래서 DevOps가 나온다. DevOps아주 아주 핫한 키워드다. 혹자는 그냥 기술 마케팅 용어라고 폄하하기도 하지만 나는 그렇게 보지 않는다. 일련의 흐름에서 나온 현상이다.

OK 그렇게 클라우드와 DevOps가 나왔는데, 클라우드를 살펴보자.
  1. 클라우드는 바깥에서 보면 하나의 컴퓨팅 자원으로 보인다. 여기에서 필요한만큼 가져다 쓰는게 기본 개념이다.
  2. 클라우드 컴퓨팅은 가상화 기술을 기반으로 한다.
  3. 컨테이너로 컴퓨팅을 경량으로 가상화 할 수 있게 된다. + 네트워크도 가상화 + 스토리지 가상화
  4. 정말로 하나의 컴퓨터처럼 보이네 ?
  5. 그래 그러면 예전 리눅스에서 사용하던 파이프 기술을 사용 할 수 있지 않을까 ?
해서 나온게 MSA다. 파이프 기술은 아래와 같다.
# ls -l | find ./ -type f -name "*.txt" -exec grep "program" {} \;
전문적인 일을 하는 작은 프로그램들을 연결해서 큰 일을 하는 프로그램을 만드는 기술이다. 리눅스의 파이프 기술을 이용하면 유연하게 시스템을 제어 할 수 있다. 이러한 파이프 기술의 개념을 클라우드 상에 구현한게 MSA다. 별거 없다. MSA라는 것도 결국은 는 개념이다. 파이프 대신 HTTP, GRPC, REST API를 사용할 뿐 개념은 같다. MSA는 개발 방법의 혁신을 이끌기도 한다. 아래는 MSA에서의 개발 구조를 묘사하고 있다.

 CICD

그 자체로 완결성을 가지는 모듈(애플리케이션)을 개발 하기 때문에, 각 애플리케이션 별로 독립적인 CICD 파이프라인을 구성 할 수 있다. 애플리케이션은 독자적인 데이터베이스 캐시를 가질 수 있기 때문에 애플리케이션에 대한 주도권을 가지고 빠른 개발이 가능하다. 내가 혹은 팀이 만드는 모듈은 코드의 복잡도가 낮으면 낮은 결합도를 가지기 때문에 부담 없이 새로운 기술, 언어를 선택 할 수 있다. 이는 개발 조직 전체의 혁신을 촉진한다.

MSA의 시작

레거시가 있는 상황에서는 현재 상황을 파악하고 계획을 세우는게 중요하다. 이러한 것들이 중요한 이유는 이러하다.

소프트웨어의 구조는 그 조직의 의사결정구조를 반영한다.

MSA를 위해서는 조직의 의사결정구조를 바꿔야 된다는 이야기가 되겠다. 회사가 여러분에게 "이제 우리는 클라우드 기술을 도입하겠어 MSA 그거 좋다고 하더군 한번 써보자고. 방안을 만들어와" 이런 과제를 던졌다면 여러분은 기술 스택을 찾는게 아닌 조직구성과 정책을 세팅하는 일을 먼저해야 한다. 새로운 기술의 도입은 역할과 책임의 문제라는 것이다.

그 후 기술 스택을 조사한다.

기술스택들

 기술 스택

언어, 모니터링, CICD, Container Orchestration Tool, 모니터링, 스토리지 모든 영역에서 사용 할 수 있는 트랜디한 기술들을 펼쳐서 고민한다. 기술은 원칙에 근거해서 선택해야 한다. 클라우드 기반의 서비스일 경우 원칙은 아래와 같이 정리 할 수 있다. 이들 조건을 고려해서 아래와 같은 기술 스택을 선택했다.

 선택한 기술 스택

무난한 기술들을 선택했다. 다만 컨테이너 오케스트레이션 도구로 k8s는 배제했다. k8s를 배제한 이유는 너무 높은 복잡도 때문일 것이다.

전체 기능의 조사와 분류

... 계속

참고