메뉴

문서정보

AWS 기반 Billing 서비스 아키텍처 - ServerLess

목차

시나리오 - 빌링 시스템

joinc는 AWS를 이용해서 도매 상품 중개/판매 서비스를 운영하고 있다. 초기 쇼핑몰을 빠르게 전개하는데 중점을 뒀기 때문에 백오피스에 기술부채를 가지고 있다. CTO는 기술 부채를 없애기를 원한다. CTO는 솔류션 아키텍트에게 빌링 시스템의 개선을 요구했다. 주요 요구 사항은 아래와 같다.
  1. 비용 효율적이어야 한다.
  2. 운영 인력이 충분하지 않다. 효율적으로 운영 할 수 있도록 한다.
  3. 이제 서비스가 안정화 단계에 들어섰다. 지속적으로 확장 될 것으로 예상되는 바, 유연한 확장이 가능하도록 구축한다.
현재 빌링 시스템은 "고객의 구매 요청을 엑셀로 받아서 메뉴얼하게처리"하는 수준이다. 한마디로 새로 구축해야 한다.

기능은 단순하다.
  1. 파일을 읽어서 고객 별로 청구서를 만들어서 고객과 도매상인에게 Email로 전송 한다.
  2. 청구서는 향후 사용 할 수 있도록 안전한 스토리지에 보관해야 한다.
요구사항 전에 제약 조건이 있다. 기존 시스템의 변경을 최소화해야 한다. 중개/판매 시스템은 구매정보를 파일로 저장하는데, 이 과정은 최소한 변경하지 않아야 한다.

시스템 아키텍처링

시스템을 위한 High-Level 아키텍처링을 개발하기로 했다. 아키텍터링은 이해당사자들에게 리뷰되어서, 전체 시스템에 대한 이해를 공유할 수 있게 될 것이고, 시스템의 리스크를 줄이게 될 것이다.

올바른 솔류션을 제안하기 위해서는 시스템의 작동 프로세스를 알고 있어야 한다.
  1. 상품 구매 정보를 파일로 올린다.
  2. 상품 데이터베이스로 부터, 상품 가격을 읽어서 빌링 정보를 생성한다.
  3. 빌링 정보를 토대로 청구서를 작성한다.
  4. 청구서를 안전한 장소에 저장한다.
  5. 청구서를 PDF, HTML 등으로 만들어서 Email로 전송한다.
요구사항 몇 개와 (매우 간략화된) 기존 빌링 시스템 설명으로 부터, AWS 솔류션을 후보를 제안 할 수 있다. 이 시스템은 완전한 서버리스(ServerLess)로 구성될 것이다.

 Billing 시스템

  1. 사용자가 JSON 파일을 업로드 한다. 여기에는 구매 상품 정보를 포함하고 있다. 사용자는 기존 중개/판매 시스템이 될 것이다. 기존 중개/판매 시스템은 다른 코드를 수정할 필요 없이 S3로 파일을 업로드하는 코드만 추가하면 된다.
  2. S3는 객체 생성, 삭제 이벤트가 발생 할 때 Lambda 함수를 실행하도록 설정 할 수 있다. 객체가 생성될때(파일을 업로드 할 때) S3가 이벤트를 게시하도록 s3:ObjectCreated:* 를 지정하고 이를 처리하기 위한 Lambda를 등록한다.
  3. S3에 파일이 업로드되면 Lambda 함수가 생성된다. 이 Lambda 함수는 상품정보가 저장된 DynamoDB를 읽어서 상품에 대한 빌링 정보를 설정한다. 상품 코드, 상품 명, 상품 카테고리, 가격 등이 중요 정보일 것이다.
  4. 빌링정보가 만들어지면 DynamDB에 저장하고, SQS에 빌링정보가 만들어 졌음을 게시한다.
  5. SQS에 큐에 빌링 정보가 들어가면 Lambda를 실행한다.
  6. Lambda 함수는 DynamoDB에서 빌링정보를 읽어서 청구서(invoide)를 생성한다. 생성된 청구서는 DynamoDB에 저장한다.
  7. 청구서 생성 Lambda 함수는 청구서 문서를 SQS에 개시한다.
  8. SQS는 청구서 문서를 읽어서 PDF, HTML로 만들어서 S3에 저장한다.
  9. SQS는 Lambda 함수를 호출하여 SNS 서비스를 호출하여, 각 고객사에게 청구서를 전달한다.
이 시스템은 아래와 같이 기존 서비스와 "느슨하게" 통합 될 것이다.

 기존 시스템과 빌링 시스템의 통합

이 시스템 아키텍처의 특징, 장점, 단점을 리뷰해 보자.

결과적으로 솔류션 아키텍트는 기존 시스템의 변경을 최소화하면서, 비용/운영 효율적인 서버리스 빌링 시스템을 구축 할 수 있었다.

Serverless

AWS에 따르면 서버리스 애플리케이션이란 "컴퓨팅, 데이터베이스, 스토리지, 스트림 처리, 메시지 대기열 등의 백앤드 구성요소를 구축하기 위해서 서버를 프로비저닝하거나 유지 및 관리 할 필요가 없는 애플리케이션"을 의미한다.

개발자 입장에서 얻는 이점은 아래와 같다.
  1. 서버 단위가 아닌 처리량 혹은 실행 시간에 대한 비용을 지불한다. 효율적인 비용 계획을 수립 할 수 있다.
  2. 운영/관리를 AWS가 책임진다. 운영/관리 업무의 대부분에서 벗어날 수 있다.
AWS의 서버리스 서비스하면 FaaS인 Lambda를 생각하지만 그 외에도 다양한 서버리스 제품들이 있다.

정리

이미지/문서 파일 처리 시스템이 이와 비슷한 구성을 가질 수 있다. 관련 아키텍처 문서도 만들어봐야 겠다.