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

Contents

joinc는 AWS를 이용해서 도매 상품 중개/판매 서비스를 운영하고 있다. 초기 쇼핑몰을 빠르게 전개하는데 중점을 뒀기 때문에 백오피스에 기술부채를 가지고 있다. CTO는 기술 부채를 없애기를 원한다. CTO는 솔류션 아키텍트에게 빌링 시스템의 개선을 요구했다. 주요 요구 사항은 아래와 같다.

1. 비용 효율적이어야 한다.
2. 운영 인력이 충분하지 않다. 효율적으로 운영 할 수 있도록 한다.
3. 이제 서비스가 안정화 단계에 들어섰다. 지속적으로 확장 될 것으로 예상되는 바, 유연한 확장이 가능하도록 구축한다.

현재 빌링 시스템은 "고객의 구매 요청을 엑셀로 받아서 메뉴얼하게처리"하는 수준이다. 한마디로 새로 구축해야 한다.

기능은 단순하다.

1. 파일을 읽어서 고객 별로 청구서를 만들어서 고객과 도매상인에게 Email로 전송 한다.
2. 청구서는 향후 사용 할 수 있도록 안전한 스토리지에 보관해야 한다.

요구사항 전에 제약 조건이 있다. 기존 시스템의 변경을 최소화해야 한다. 중개/판매 시스템은 구매정보를 파일로 저장하는데, 이 과정은 최소한 변경하지 않아야 한다.

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

올바른 솔류션을 제안하기 위해서는 시스템의 작동 프로세스를 알고 있어야 한다.

1. 상품 구매 정보를 파일로 올린다.
2. 상품 데이터베이스로 부터, 상품 가격을 읽어서 빌링 정보를 생성한다.
3. 빌링 정보를 토대로 청구서를 작성한다.
4. 청구서를 안전한 장소에 저장한다.
5. 청구서를 PDF, HTML 등으로 만들어서 Email로 전송한다.

요구사항 몇 개와 (매우 간략화된) 기존 빌링 시스템 설명으로 부터, AWS 솔류션을 후보를 제안 할 수 있다.

• S3 : S3는 고가용성, 고내구성, (거의)무한대의 공간을 제공하는 객체 스토리지 서비스(Object Storage Service)다.
• DynamoDB : 상품별 빌링 정보, 청구서를 저장한다.
• SQS : 이 시스템은 크게 "상품별 빌링 정보 생성 시스템, 청구서 시스템, 청구서 발송/전송 시스템"으로 구성된다. SQS를 이용해서 이들을 분리하고, 메시지 기반으로 작업을 처리하게 한다.
• SES : Email을 전송한다.
• Lambda : S3, DynamoDB 에 데이터가 쌓일 때 Lambda를 호출해서 작업을 처리하게 한다.

이 시스템은 완전한 서버리스(ServerLess)로 구성될 것이다.

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 서비스를 호출하여, 각 고객사에게 청구서를 전달한다.

이 시스템은 아래와 같이 기존 서비스와 "느슨하게" 통합 될 것이다.

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

• S3를 이용한 분리 : REST API를 이용해서 디커플링 하는 방법을 생각해볼 수 있겠다. 이 시나리오는 "기존 시스템 변경을 취소화"해달라는 요구 사항이 있다. S3로 구성 할 경우, 파일의 저장소만 S3로 하면 되므로 기존 시스템 변경 없이 빌링 시스템과 연계 할 수 있다. REST API를 사용 할 수 있는 환경이라고 하더라도 S3를 이용해서 서버리스로 개발하는게 비용, 유지/보수 관점에서 더 나은 선택이다.
• SQS(메시지 대기열 서비스)를 이용해서 빌링 서비스를 구성하는 각 컴포넌트들을 분리 할 수 있다. 각 컴포넌트들을 분리하면서, 컴포넌트 단위의 확장이 가능하다. 또한 프로세스가 데이터를 처리하지 못하더라도 큐에 데이터가 남아있기 때문에 메시지의 손실 없이 안전하게 처리 할 수 있다. 빌링 서비스는 돈과 직결되는데, 큐를 버퍼로 사용 함으로써 견고한 시스템을 구성할 수 있다.
• Lambda는 ServerLess 서비스로 어떠한 컴퓨팅 자원을 전개 할 필요 없이, 코드를 업로드하는 것으로 실행 할 수 있다. Lambda는 이벤트 소스로 SQS를 설정 할 수 있다.

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

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

개발자 입장에서 얻는 이점은 아래와 같다.

1. 서버 단위가 아닌 처리량 혹은 실행 시간에 대한 비용을 지불한다. 효율적인 비용 계획을 수립 할 수 있다.
2. 운영/관리를 AWS가 책임진다. 운영/관리 업무의 대부분에서 벗어날 수 있다.

AWS의 서버리스 서비스하면 FaaS인 Lambda를 생각하지만 그 외에도 다양한 서버리스 제품들이 있다.

• Amazon API Gateway
• Amazon DynamoDB
• Amazon S3
• Amazon Kinesis
• Amazon Aurora
• AWS Fargate
• Amazon SNS
• Amazon SQS
• Amazon EFS
• Amazon RDS Proxy
• Amazon AppSync
• AWS Step Functions
• Amazon Athena
• Lambda @Edge
• Amazon Event Bridge

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