Steppay의 SaaS Builder Toolkit for AWS를 활용한 AWS SaaS 아키텍처 패턴 적용

Steppay는 SaaS 비즈니스에 필요한 SaaS 요금제를 만드는 기능부터 구독 및 미납 관리, 요금 결제 등 다양한 기능을 갖춘 결제 솔루션을 통합하여 제공하는 B2B SaaS(Software-as-a-Service) 스타트업입니다. Steppay의 결제 관리 솔루션인 Steppay를 사용하면 기존의 복잡하고 관리가 어려웠던 SaaS 비즈니스의 요금 관리를 웹에서 쉽게 관리할 수 있습니다. 2024년 12월 현재 현대카드, 아이지에이웍스, SCI평가정보, 비즈니스캔버스, 고위드 등 다양한 기업이 Steppay 솔루션을 활용하고 있습니다. 이번 글에서는 Steppay가 Amazon ECS(Amazon Elastic Container Service)로 마이그레이션을 진행하며 ECS 기반의 SaaS Architecture Pattern을 적용한 사례를 공유합니다.

Steppay의 SaaS 솔루션 소개

Steppay는 국내 최초 SaaS 구독 전문 플랫폼으로, 일반/구독 결제, 다양한 과금 모델링, 구독 전문 관리 등 구독에 특화된 솔루션을 제공합니다. 고객은 별도의 서비스를 구축할 필요 없이 단건 결제는 물론 사용량이나 계정 수 기반의 요금제를 만들어 판매할 수 있습니다. 또한 비즈니스 효율성을 높이기 위해 애드온 형태로 몰인몰, 다중 통화 지원, 기업 간 대금 거래 등 다양한 기능을 제공하고 있습니다. 만약 고객이 이미 자사 서비스를 보유하고 있다면, 제공되는 API를 통해 쉽게 연동하여 Steppay의 결제 솔루션을 활용할 수 있습니다. Steppay와 함께하면 결제 시스템 구축과 관리를 쉽고 빠르게 할 수 있습니다.

기존 아키텍처에서의 고민

솔루션을 처음 개발할 때, Steppay는 SaaS 결제 솔루션에 필요한 여러 가지 기능을 모두 제공하고자 하는 목표가 있었습니다. 또한 적은 인력으로 새로운 서비스를 개발하고 운영해야 했기 때문에 확장성과 개발 편의성 및 효율적인 사용자 온보딩을 고려하여 Kubernetes를 기반으로 한 마이크로서비스 아키텍처를 도입했습니다. 그 결과 그림 1과 같이 CI/CD Pipeline, 인증, 모니터링 등의 공통 작업을 통합하여 처리하고 여러 마이크로서비스가 DB를 공유하는 아키텍처가 만들어졌습니다.

그림 1. AWS SaaS 아키텍처 패턴 적용 전의 Steppay 아키텍처

그림 1의 아키텍처로 서비스를 운영하며 Steppay는 아래와 같이 두 가지 고민을 하게 되었습니다.

1) Kubernetes 운영 과정에서의 고민

Steppay의 개발팀은 Kubernetes 클러스터를 운영하면서 여러 가지 기술적인 어려움에 부딪혔습니다. 먼저 서비스가 증가하며 자연스럽게 수가 늘어난 클러스터 간의 네트워크 설정, 보안 정책 관리, 잦은 클러스터 버전 업데이트 등의 운영 작업을 처리하는 일이 점점 어려워졌습니다. 따라서 Steppay 팀은 복잡해진 Kubernetes를 운영하기 위해 인력 채용에 나섰지만, 스타트업 생태계에서 Kubernetes에 대한 전문 지식과 많은 운영 경험을 가진 전문가를 구하는 것이 쉽지 않았습니다.

서비스가 많아지고, 사용자가 기하급수적으로 증가함에 따라 사용하는 컴퓨팅 리소스에 대한 비용도 빠르게 증가했습니다. 한 예로 Kubernetes를 처음 도입할 때에는 서비스에 필요한 최소 컴퓨팅 리소스 사양이 4 vCPU와 8GB의 성능을 갖춘 컴퓨팅 노드 3개면 충분했습니다. 그러나 이 리소스 사양은 점차 증가하여 최근에는 서비스 유지에 필요한 컴퓨팅 리소스가 8 vCPU와 16GB의 성능을 갖춘 컴퓨팅 노드 10개 이상으로 증가했습니다. 심지어 이러한 리소스 요구 사항은 비용 절감을 위해 리소스 최적화를 완료한 뒤의 결과입니다. 그 밖에도 앞서 언급한 기술적 측면의 어려움에 더해 운영의 복잡성 때문에 운영에 필요한 인력도 이전보다 크게 늘어 TCO 관점의 비용도 많이 증가했습니다.

2) 테넌트 격리 및 서비스 보안 강화에 대한 고민

Kubernetes에서는 테넌트 격리를 위한 다양한 기능과 방법론을 제공하고 있습니다. 예를 들어, Control Plane 수준의 격리 방안으로는 네임스페이스, 접근 제어, 쿼터 등이 있고, Data Plane 수준의 격리 방안으로는 네트워크 격리, 스토리지 격리, 컨테이너 샌드박싱 그리고 노드 격리 등이 있습니다. Steppay에서는 여러 격리 방식 중 Control Plane 영역에 대해 네임스페이스 기반의 Pooled 방식을 활용하고 있었습니다. 이 방식은 서비스에 공통으로 필요한 기능을 하나로 통합하여 관리할 수 있는 등 리소스를 효율적으로 활용할 수 있는 장점이 있었지만, B2B 고객들 사이에서 점점 자신만의 격리된 리소스를 제공받는 Silo 방식에 대한 요구가 많아지고 있었습니다.

하지만 Silo 방식의 구현을 위해서는 테넌트가 온보딩 될 때 자동으로 해당 테넌트를 위한 격리된 리소스가 생성되어야 하고, 이 리소스에 대한 과금을 위해 미터링 시스템 구조를 변경해야 했습니다.

Steppay는 이 두 가지 고민 해결에 도움을 받기 위해 Steppay를 담당하는 AWS 어카운트 팀 및 AWS SaaS Factory 팀과 여러 차례 만나 해결 방법을 함께 논의했습니다. 그리고 Amazon ECS 기반의 AWS SaaS 아키텍처 패턴이 적용된 SaaS Builder Toolkit for AWS(SBT)를 적용하여 서비스를 마이그레이션하기로 결정했습니다.

AWS SaaS 아키텍처 패턴과 ECS Reference 아키텍처 소개

SaaS 아키텍처 패턴

SaaS는 최종 사용자에게 애플리케이션을 제공하는 클라우드 기반 소프트웨어 모델입니다. 고객은 SaaS 서비스를 사용하면 서비스의 유지 관리 방식이나 기본 인프라 관리 방식에 대해 고민할 필요가 없습니다. 또한 고객은 모든 기능을 한 번에 크게 구매할 필요 없이 사용량에 따른 요금제 모델 또는 구독 기반으로 요금을 지불합니다.

SaaS는 모든 고객이 동일한 버전의 애플리케이션을 실행하는 환경에서 제공됩니다. 이러한 이유로 SaaS 환경에서는 단일 공유 프로세스를 통해 모든 테넌트에게 새 기능을 배포할 수 있는 장점이 있습니다. 또한 모든 테넌트를 관리하고 운영할 수 있는 공통된 운영 환경을 통해 테넌트를 관리하고 모니터링하여, 운영 오버헤드를 늘리지 않고 새 테넌트를 추가할 수 있습니다.

AWS는 지난 몇 년 동안, SaaS 아키텍처 영역을 Application Plane과 Control Plane으로 더욱 명확하게 구분하여 멀티테넌트 아키텍처의 두 영역으로 식별했습니다. 이 접근 방식은 SaaS 솔루션을 구축할 때 해결해야 하는 책임과 서비스에 대한 경계를 제공함으로써 고객, 파트너 및 광범위한 SaaS 커뮤니티의 공감을 불러일으켰습니다.

• Control Plane은 테넌트를 관리하고 운영하는 역할을 담당합니다. Control Plane은 모든 멀티테넌트 SaaS 모델의 기반이 되는 요소이며, 멀티테넌트 경험을 통해 소프트웨어가 여러 고객(테넌트)에게 동일한 서비스를 제공하면서 독자적인 데이터와 설정을 할 수 있도록 제공합니다. 이러한 것들은 Control Plane을 통해 효과적으로 통합되고 관리되며 전체 사용자 경험을 높이는 데 중요한 역할을 합니다. Control Plane은 멀티테넌트 환경을 관리할 수 있는 Identity 및 온보딩, 테넌트 등록, 테넌트 관리, 테넌트 프로비저닝, 사용자 관리, 결제, 메트릭과 같은 다양한 공유 서비스를 포함합니다.
• Application Plane은 SaaS에서의 멀티테넌트의 핵심 기능이 표현되는 영역입니다. Application Plane은 고객(테넌트)에게 애플리케이션의 독특한 가치를 제공하는 비즈니스 로직과 마이크로서비스를 포함합니다.
  SaaS 아키텍처에 대한 상세한 내용을 확인하고 싶다면 AWS SaaS 아키텍처 백서를 확인해 보시길 바랍니다.

Amazon ECS SaaS 레퍼런스 아키텍처

Amazon ECS는 AWS의 완전관리형 컨테이너 오케스트레이션 서비스로, 컨테이너화된 애플리케이션을 대규모로 실행하고 관리할 수 있게 해줍니다. AWS는 ECS를 활용한 SaaS 레퍼런스 아키텍처를 통해 멀티테넌트 SaaS 애플리케이션 구축에 필요한 실질적인 구현 방법을 제시합니다. 이 레퍼런스는 ECS의 Task Definition, Service, 클러스터를 활용해 티어(예시 : Basic/Advanced/Premium)에 따라 컨테이너를 어떻게 구성하고 운영할 수 있는지 상세히 보여줍니다.

그림 2. ECS SaaS 레퍼런스 아키텍처

이 레퍼런스 아키텍처는 SBT를 활용하여 구축되었습니다. SBT는 멀티테넌트 SaaS 애플리케이션 구축을 위한 재사용 가능한 구성 요소와 추상화를 제공하는 프레임워크로, 테넌트 온보딩, 사용자 관리와 같은 일반적인 SaaS Control Plane 기능을 미리 구현해 놓았습니다. SBT를 Control Plane으로 활용함으로써, 개발자들은 보일러 플레이트 코드 작성 없이 핵심 비즈니스 로직 개발에 집중할 수 있습니다. Application Plane에서는 Amazon API Gateway와 Amazon ECS Service Connect를 활용한 서비스 라우팅, Security Group을 통한 트래픽 격리, Amazon DynamoDB의 세분화된 액세스 제어 등 실제 SaaS 운영에 필요한 AWS 서비스들의 구체적인 활용 방안을 제시합니다.

레퍼런스 아키텍처는 크게 Control Plane과 Application Plane으로 구성됩니다. Control Plane에는 SBT가 제공하는 테넌트 온보딩, 사용자 관리, 테넌트 관리 서비스가 포함되어 있으며, Application Plane에는 실제 비즈니스 로직을 처리하는 마이크로서비스가 위치합니다. Application Plane의 서비스들은 티어에 따라 다르게 구성됩니다. 예를 들어 Steppay의 경우에는, Basic 티어는 모든 테넌트가 컴퓨팅 리소스를 공유하고, 데이터베이스는 하나의 스키마에서 논리적으로만 분리가 되어 있는 반면, Premium 컴퓨팅 리소스는 마찬가지로 공유하지만, 테넌트별로 독립된 스키마로 데이터를 분리하여 데이터에 대한 격리 수준을 다르게 제공합니다. 그리고 Advanced 티어는 모든 컴퓨팅 리소스 및 독립적인 스키마로 데이터를 분리하는 형태로 서비스를 제공함으로써 보다 높은 격리 수준을 제공합니다. 이러한 티어별 접근 방식을 통해 SaaS 제공자는 테넌트의 요구사항에 맞는 적절한 격리 수준을 선택할 수 있습니다.

ECS SaaS 레퍼런스 아키텍처에 대한 상세한 내용을 확인하고 싶다면, ECS SaaS 레퍼런스에 대한 Github 저장소를 확인해 보시길 바랍니다.

SBT를 적용한 Steppay의 새로운 SaaS 아키텍처

그림 3. SBT 활용한 Steppay 아키텍처ecs

Steppay는 Amazon ECS 기반의 SaaS 아키텍처 패턴을 적용하며 기존의 고민이었던 Kubernetes 운영상의 고민과 테넌트 격리 및 보안 강화에 대한 고민을 모두 해결할 수 있었습니다. Amazon ECS를 선택하며 Fargate를 통한 서버리스 아키텍처를 적용했습니다. Fargate를 사용하면 서버의 OS 수준에서의 업데이트 관리, Scale In & Out 관리 등 서버 관리에 대한 많은 부분을 AWS가 담당하여 적은 인원으로도 효율적인 서비스 운영이 가능했습니다. 또한, 기존에 사용하던 3rd-party 솔루션인 Datadog과 GitHub Actions를 함께 사용하여 모니터링과 CI/CD 구성을 할 수 있어 개발팀은 서비스 개발과 운영에 필요한 새로운 도구를 다시 학습하지 않아도 되어 편리했습니다.

또한 SBT에서는 테넌트 온보딩, 티어 관리, 테넌트 유저 관리, 시스템 관리, 빌링 등 SaaS 비즈니스를 위한 핵심 기능들이 포함된 레퍼런스 아키텍처를 제공하고 있습니다. Steppay는 이 레퍼런스 아키텍처를 참고하여 SBT의 Control Plane을 서비스 요구사항에 맞게 수정하였고, 테넌트 관리와 온보딩과 같은 관리 작업을 모두 자동화할 수 있었습니다. 또한, SBT의 Application Plane에서 코어 유틸로 제공하는 프로비저닝 스크립트를 사용하여 새로운 테넌트의 Application 배포를 쉽게 프로비저닝할 수 있습니다. 그 결과 기존 Pooled 방식 외에도 테넌트별로 완전히 격리된 전용 리소스를 제공하는 Silo 방식이 적용된 Advanced 티어를 추가할 수 있었습니다.

마무리

이번에 Amazon ECS로의 마이그레이션과 AWS SaaS Architecture 패턴 적용을 통해 Steppay는 다음과 같은 주요 성과를 달성했습니다.

1. Kubernetes 운영 관련 문제 해결 및 테넌트 격리와 보안 강화 실현
2. Fargate를 통한 서버리스 아키텍처로 효율적인 서비스 운영 가능
3. 기존 3rd-party 툴과의 원활한 통합으로 개발팀의 생산성 유지
4. SBT 레퍼런스 아키텍처를 활용한 테넌트 관리 및 온보딩 자동화
5. 새로운 테넌트의 Application 배포 프로세스 간소화
6. Pooled 방식 외에 Silo 방식의 Advanced 티어 추가로 서비스 다각화

이러한 성과들은 Steppay의 SaaS 비즈니스 모델을 더욱 강화하였고, 보다 효율적이고 안정적으로 서비스를 운영할 수 있는 인프라 기반을 마련하였으며 테넌트 관리 방법을 고도화하고, 서비스 티어를 더욱 세분화하는데 기여했습니다.

Steppay는 궁극적으로 전 세계에서 편리하고 쉽게 사용할 수 있는 금융 플랫폼이 되는 것을 목표로 계속 성장하고 있습니다. Steppay는 AWS와의 협업을 통해 안정적이고 확장 가능한 클라우드 인프라를 구축하여, 글로벌 사용자들에게 더욱 편리하고 신뢰할 수 있는 서비스를 제공하기 위해 노력할 것입니다.