메뉴

문서정보

목차

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를 배제한 이유는 너무 높은 복잡도 때문일 것이다.

kubernetes는 핫 하기는 하지만 실제 운영하는 엔지니어들은 "불호"인 경우가 있다. 나 역시 "굳이?" 라는 입장인데, 이유는 "대부분의 경우에 너무 복잡하기 때문"이다. 다른 말로 오버테크놀로지, 과대 기술. 예를 들어 ECS는 kubernetes로 할 수 있는 거의 모든 일을 훨씬 단순하게 할 수 있다. 실제 인프라를 담당하는 주변 엔지니어들은 대부분 ECS 정도 였고, EKS(AWS의 관리형 kubernetes 서비스)를 그리 좋아하진 않았다.

멀티 클라우드 혹은 하이브리드 클라우드를 대비해서 굳이 EKS를 선택하기도 하는데, 그럴 만한 가치가 있는지 모르겠다. 일단 멀티 클라우드라는 것이 필요한지 의문이다.

  1. 업체종속성(Lock-in) 탈피 : 특정 기술에 종속되는 것을 업체종속성 혹은 락인이라고 한다. 한 업체에 종속되는 것은 위험하니 다양한 클라우드 제공자의 서비스를 사용하는게 효율적이고 안전하다는 이야기다. 그럴듯 하지만 현실에서 MySQL에만 종속되면 안된다는 이유류 MS-SQL, PostgreSQL를 섞어서 사용하는 경우가 있는지를 생각해 보자. 당장 운영은 누가 ? 라는 물음이 생기기 마련인데, 클라우드는 규모와 복잡성에서 데이터베이스에 비할 바가 아니다. AWS 하나만 해도 제대로된 팀 구성이 쉽지 않은데, 멀티 클라우드를 운영 할 수 있는 회사가 얼마나 될지 모르겟다.
  2. 단일 클라우드 취약점 : 2019년에 DNS 문제로 인한 AWS 리전 장애가 발생했다. 가용성 존(availability zone) 단위 시스템 레벨에서의 가용성을 보장한다고해도 글로벌 시스템에서의 오류로 전체 시스템이 실패 할 수 있음을 목도했다. 그렇다면 두 개 이상의 클라우드로 구성하면 최악의 경우에도 대비할 수 있겠군 ? 이라는 가정에서 출발 한다. 매년 수십억을 부어서 99.99% 가용성을 99.995% 로 올려야 하는 서비스라면 OK.
그러는 나도 kubernetes를 하고 있다. 왜 ? 워낙 핫 해서다. 내가 간과하고 있는 무언가 있는게 아닌가 라는 생각이 들기 때문이다.

기술스택을 좀 더 살펴보자.

스토리지 프레임워크 Tools Monitoring Container Orchestration Tools TypeScript는 ES5의 슈퍼셋이라고 한다. 자바스크립트 쪽은 큰 관심이 없는 분야이긴 하다. 그냥 틈틈히 jQuery나 Vuejs를 사용하고 있다.

전반적으로 CSP가 제공하는 관리형 서비스 대신, 직접 구축하는 방향으로 개발한 것 같다. IaaS 위에 전부 구축한 느낌인데, 아래의 이유 때문이 아니었을까 싶다.

전체 기능의 조사와 분류

MSA에서 애플리케이션들은 서로 격리되며 REST로 느슨하게 묶이기 때문에 효과적으로 묶는 작업이 필요하다. 너무 큼지막하게 묶어버리면 모노리딕과 다른점이 없을테고, 너무 쪼개버리면 관리와 개발이 힘들어 질 것이다.

이론적으로는 업무 도메인을 쪼갤 수 있는 단위로 분류하고, 각 도메인에 기능을 API단위로 나열하면 된다. 쪼갠 다음에 재분류한다는 점에서 전문화와 비슷한 측면이 있다.

 기능의 전수 조사

이렇게 도메인과 기능들이 정의가 되면, MSA 를 위한 기본 데이터가 갖춰진 셈이다. 중복을 확인하고 라우팅 경로를 재 조정하고 나서 도메인을 결합하면 MSA를 구성하는 서비스가 만들어진다.

 도메인 결합

이 서비스들은 독립적인 서비스 이름과 도메인 이름(URL)을 가지게 된다. Kubernetes 에서라면 아래와 같이 구성 될 것이다.

 EKS 구성

EKS를 기준으로 했으나 다른 오케스트레이션 시스템을 이용해도 차이는 없을 것이다.
  1. Application Load balancer를 이용해서 유저 요청을 Service로 라우팅한다. API를 제대로 관리하고 싶다면 API-Gateway를 사용해도 된다.
  2. MSA의 각 서비스를 POD로 구성한다. 이 POD는 사용자 요청에 따라서 Scale-in/out 될 것이다.
  3. 각 POD는 APP Mesh를 사이드킥으로 가진다. APP Mesh를 이용해서 service discovery & 라우팅을 한다.
차이가 있다면, 기술 스택을 이루는 소프트웨어의 대부분을 AWS 클라우드에 위임시켰다는 것이다. EKS가 아닌 ECS(AWS의 컨테이너 서비스)를 사용하더라도 마찬가지인데 컨트롤 플레인, 노드, 데이터 플레인, ingress control, service discovery를 모두 위임한다. 따라서 (이론적으로) 개발자는 코드만 신경쓰면 된다. 운영자 역시 운영 복잡도가 낮출 수 있다는 장점이 있다.

PAYCO Shop는 아래와 같은 구조를 가진다.

 PAYCO Shop

여러가지 오픈소스 솔류션의 조합이라는 점을 제외하면 아키텍처에서 차이는 없다. 이후 service discovery를 Eureka대신 Zookeeper를 사용 한 것등은 아키텍처 수준에서의 변경은 아니므로 언급하지 않겠다.

설정변경 관리

모노리딕 아키텍처에서는 설정도 중앙에서 통제하므로 비교적 쉽게 관리 할 수 있다. 반면 MSA는 독립적인 여러 개의 서비스로 구성된다. 각 서비스는 자신만의 스토리지, SQL, NoSQL, 사이드킥을 관리하기 때문에 설정을 관리하는 것 역시 과업이 된다. PAYCO 쇼피은 spring cloud config server를 이용해서 설정을 관리 한다. GitHub에 설정을 저장하고 각 MSA 서비스가 실행될때, 설정을 불러서 적용하는 방식이다.

AWS라면 AWS Systems Manager Parameter Store(SSM)정도를 사용 할 것이다.

Container

요즘에 MSA에서 Container(그냥 도커라고 하겠다.)는 기본인 것 같다. Container를 사용하는 이유는 아래와 같을 것이다. 도커 이미지는 deb, yum, pip 와 같은 패키징된 애플리케이션이다. 따라서 도커 이미지를 저장하기 위한 저장소가 필요하다. AWS에서는 ECR(Elastic Container Registry) 쓰면 될 일이다. 여차저차한 이유로 직접 구축해야 한다면 Nexus 3가 가장 무난한 선택이 될 것이다.

CICD 파이프라인

개발에서 배포까지 CICD 파이프라인을 위한 기술 스택은 정리가 된 것 같다. PAYCO 쇼핑의 구성은 아래와 같다.

 CICD 파이프라인

동영상의 그림을 그대로 사용했다. GitHub의 위치와 파이프라인이 분리된 느낌으로 약간 그림이 이상한 것 같기는 하지만 실제 영상의 내용을 보면 git 저장소에서 시작하여 jenkins로 빌드 & 배포하는 CICD 파이프라인을 따라가고 있을 것 같다.

앞서 클라우드를 IaaS 에 가깝게 사용하고 있다고 언급한 적이 있는데, Ansible를 이용해서 서버로 배포하는 시스템을 직접 구성한 것으로 보인다. 해당 시점에서 사용하고 있는 클라우드 서비스가 컨테이너 기반의 CICD 전부를 지원하지 않았기 때문으로 보인다.

혹은 기존에 익숙하게 사용하고 있던 CICD 패턴을 사용하는게 개발/운영에 더 맞다고 판단해서 이렇게 했을 수도 있다. 금융서비스의 경우 망분리와 변경관리등 일반 인터넷 서비스에서는 찾아볼 수 없는 복잡한(왜 이렇게 해야하지 ? 이해하기 힘든)개발 과정을 지켜야 할 수 있다. 이런 경우라면 일반적이지 않은 CICD 파이프라인이 나올 수 있을 것이다.

AWS에서는 일반적으로 아래와 같이 CICD 파이프라인을 구성 할 것이다.

 CICD 파이프라인

파이프라인을 구성하는 모든 솔류션이 매니지드라는 점이 특징이다. 필요에 따라서 Git 저장소 역할을 하는 CodeCommit은 GitLab, BigHub, BitBucket으로 CICD 툴인 CodeBuild, CodeDeploy는 jenkins, gitlab 등으로 유연하게 구성 할 수 있다. ECS Fargate와 같은 Serverless 컨테이너 오케스트레이션 서비스를 사용할 경우 관리해야 할 서버가 없으니 Ansible 등의 툴을 사용해야 할 필요도 없다.

모니터링

모니터링의 카테고리는 다음과 같다. PAYCO의 모니터링 구조는 아래와 같다.

 PAYCO 모니터링 구조

AWS에서는 아래와 같이 구성 할 수 있을 것이다.

 AWS 모니터링 환경 구성

아주 간단하게 묘사하고 있다. 핵심 특징은 아래와 같다.
  1. CloudWatch 로 통합 : AWS 로깅 & 모니터링 시스템의 핵심에는 CloudWatch가 있다. AWS의 모든 서비스들은 CloudWatch로 메트릭을 전송한다. 다른 애플리케이션들도 CloudWatch Log Agent를 이용해서 CloudWatch로 메트릭을 전송 할 수 있다. 예를들어 EKS(Kubernetes)라면 LogStash Cloudwatch 플러그인을 이용해서 로그들을 CloudWatch로 보낼 수 있다. CloudWatch는 그 자체로 이벤트 알람 설정, 대시보드 구성을 할 수 있다. 정교한 모니터링이 필요하다면 ElsaticSearch로 로그를 색인하고 Kibana로 대시보드를 구성 할 수 있다.
  2. S3 : 로그는 분석이 필요 할 수 있다. 모든 로그들은 S3에 저장해서 Athena, EMR 등을 이용해서 분석한다. 분석한 정보는 BI툴인 QuickSight로 시각화 한다. tableau 등의 다른 BI를 사용해도 된다.
  3. CloudTrail : 계정, 권한, AWS API와 관련된 인프라의 주요 로그들은 CloudTrail 로 모니터링 할 수 있다. 보안 모니터링, 인프라 변경 모니터링을 위해서 널리 사용한다.

문서화

프론트 앤드 개발자와 백 앤드 개발자는 다른 환경에서 다른 기술 셋으로 일을 하기 때문에 보통 서로 다른 팀으로 구성을 한다. 그리고 API를 이용해서 커뮤니케이션 한다. 워드, 위키(컨플루언스)로 API 문서를 만들기도 하고 별도의 문서화 툴을 이용하기도 한다. 요즘에는 Swagger를 꽤 사용하는 것 같다.

Swagger는 RESTful 기반의 웹 서비스의 핵심 요소인 API를 설명하고 생성, 시각화(문서화)하기 위해서 만든 툴이다. Swagger가 API를 기술하기 위해서 만든 문서 양식이 OpenAPI Specification(OAS)이다. 지금은 OAS 3.0 버전까지 나왔다. 처음에는 Swagger의 일부였으나 지금은 분리되서 독립적인 프로젝트로 관리하고 있다. RESTful API 양식으로는 가장 널리 사용하고 있다.

 Swagger

MSA 환경에서는 두 개 이상 백 앤드 팀이 서비스를 개발하기 때문에 프론트 앤드 뿐만 아니라 백 앤드 팀간의 커뮤니케이션이 중요해 진다. 개발, 스테이징, 배포로 이어지는 CICD 파이프라인을 구성했다면, 품질관리 조직과도 커뮤니케이션을 해야 한다. 이들 커뮤니케이션의 핵심에 API 문서가 있다.

Java는 어노테이션을 이용해서 API 문서를 만들어 낸다고 한다. 나는 go 언어로 개발하면서 swagger를 사용한 적이 있는데 어노테이션, 주석 혹은 별도의 swagger yaml 파일 등 코드와는 별 상관 없이 만들어지기 때문에 코드 변경이 문서에 정확히 반영하기가 쉽지 않다.

PAYCO 쇼핑은 아래와 같은 방법으로 해결 했다고 한다.
  1. Spring REST Docs : 테스트 코드가 통과를 해야만 문서를 만들어지게 한다.
  2. OpenAPI 3.0 : swagger yaml 파일로 출력되게 한다.
  3. Swagger UI : OpenAPI 3.0을 따르는 swagger yaml 문서를 웹에 출력한다.
AWS API-Gateway OpenAPI v2.0, OpenAPI v3.0 정의 파일을 지원한다. 개발하면서 정의한 Swagger 문서를 API Gateway에 로딩 할 수 있다.

정리

AWS Cloud Native 에서의 MSA

PAYCO 쇼핑은 Cloud Native 환경에서의 MSA 라고 보기에는 힘든 측면이 있다. AWS 위에서 MSA를 적용하고 싶다면 아래의 원칙을 따르면 도움이 될 것이다.

복잡도를 위임한다. 각 모듈을 직접 개발하거나 최고의 오픈소스 솔류션들을 조합해서 멋진 시스템을 만들고 싶을 것이다. 그게 아니면 안되는 경우가 아니면 "위임" 하는 것을 우선으로 한다. 복잡도를 플랫폼에 위임하는 것은 최선의 전략이다.

퍼블릭 클라우드의 각 서비스는 고객이 가장 원하는 기능들을 평균해서 제공하기 때문에, 개별 기능이나 성능으로 보자면 오픈 소스에 부족한 경우가 많다. API Gateway 보다는 Zuul이, ECR 보다는 Nexus 3, CodePipeLine 보다는 오픈소스 솔류션 조합, APP Mesh 보다는 istio가 더 나을 것이다. kinesis 보다는 왠지 kafka가 더 나을 것 같은 느낌. 여러가지 이유가 있을 수 있다.

대체 불가능한게 아니라면 그냥 클라우드 서비스 쓰자.

참고