Software-as-a-Service(SaaS)는 소프트웨어 제공 방식의 혁신적인 변화를 대표하는 비즈니스 모델입니다. 여기서 중요한 점 2가지는 as-a-Service에서 알 수 있듯이 클라우드 기반의 서비스라는 점과 비즈니스 모델이라는 점입니다. 많은 사람들이 헷갈려 하거나 잘못 이해하는 부분입니다. 가령, 소프트웨어를 인터넷으로 접속할 수 있게 해주면 SaaS인가요?와 같은 단순한 접근을 하는데 이런 식의 접근은 대부분 실패를 경험하게 됩니다. 또한 (기술적으로) SaaS를 만들면 되는 것이 아닌가요? 라는 식의 기술 위주의 접근도 매우 위험한 접근 방식입니다. SaaS는 위의 정의에서 언급했듯이 “비즈니스 모델”입니다. 구체적이고 디테일한 비즈니스 모델이 정립되지 않으면, SaaS로서 제대로 동작할 수 없습니다.
SaaS 비즈니스를 하기 위해 사전에 알아야 할 것과 SaaS의 유형, 각 유형별 구현 시 준비해야할 사항들에 대해서 알아보도록 하겠습니다. 본 기고 글에서는 SaaS의 Infra는 AWS를 이용하는 것으로 설명을 준비하였습니다.
1. SaaS 비즈니스 모델
SaaS는 전통적인 온프레미스 소프트웨어와 달리, 클라우드를 통해 소프트웨어를 서비스로 제공하며 사용자는 인터넷을 통해 언제 어디서나 접근할 수 있어야 합니다. SaaS 비즈니스 모델의 핵심 특징은 다음과 같습니다:
1.1. 구독 기반 수익 모델
SaaS는 일반적으로 월간 또는 연간 구독 방식으로 제공됩니다. 이는 고객에게 낮은 초기 비용과 예측 가능한 운영 비용을 제공하며, 서비스 제공업체에게는 안정적이고 반복적인 수익 흐름을 보장합니다.
1.2. 멀티테넌트 아키텍처
SaaS 애플리케이션은 일반적으로 여러 고객(테넌트)이 동일한 인프라와 코드 베이스를 공유하는 멀티테넌트 아키텍처를 채택합니다. 이는 리소스 활용을 최적화하고 운영 비용을 절감하지만, 테넌트 간 격리와 보안을 보장하기 위한 세심한 설계가 필요합니다.
1.3. 지속적인 가치 제공
SaaS 모델에서는 고객 유지가 새로운 고객 획득만큼 중요합니다. 서비스 제공업체는 지속적인 업데이트, 새로운 기능 추가, 성능 개선을 통해 고객에게 지속적인 가치를 제공해야 합니다. CI/CD를 활용하여 이러한 지속적 배포 파이프라인을 지속적으로 가동하여, SaaS의 가치를 지속적으로 고객에게 제공해야 합니다.
1.4. 확장성과 유연성
SaaS 비즈니스 모델의 주요 장점 중 하나는 수요에 따라 쉽게 확장할 수 있다는 점입니다. 클라우드의 탄력적 인프라는 SaaS 비즈니스가 성장함에 따라 자원을 동적으로 할당하고 확장할 수 있게 해줍니다.
2. SaaS SLA(Service Level Agreement)
SaaS 제공 업체와 고객 간의 관계는 서비스 수준 계약(SLA)을 통해 공식화됩니다. SLA는 서비스 품질, 가용성, 성능 기준을 정의하고, 이러한 기준이 충족되지 않을 경우의 보상 조치를 명시합니다. 따라서 SaaS 제공 업체는 이러한 기준을 충족할 수 있는 서비스 수준을 유지할 수 있는 높은 수준의 역량과 성숙도를 가지고 있어야 합니다.
| SLA | 내용 |
| 가용성 보장 | 대부분의 SaaS SLA는 서비스 가용성에 대한 약속(일반적으로 99.9% 또는 그 이상)을 포함합니다. AWS와 같은 클라우드에서 SaaS를 구현할 때는 여러 가용 영역과 리전을 활용하여 고가용성 아키텍처를 설계할 수 있습니다. |
| 성능 지표 | SLA는 응답 시간, 처리량, 지연 시간과 같은 성능 지표에 대한 기준을 설정합니다. AWS CloudWatch를 사용하여 이러한 지표를 모니터링하고, AWS X-Ray를 통해 분산 애플리케이션의 성능을 추적할 수 있습니다. |
| 데이터 관리 및 보안 | 데이터 보호, 백업 정책, 복구 시간 목표(RTO), 복구 지점 목표(RPO)와 같은 데이터 관리 약속도 SLA에 포함됩니다. AWS Backup, Amazon S3의 버전 관리, AWS KMS(Key Management Service)와 같은 서비스를 활용하여 이러한 요구 사항을 충족할 수 있습니다. |
| 지원 응답 시간 | SLA는 일반적으로 문제 심각도에 따른 지원 응답 시간 약속을 포함합니다. |
| SLA 모니터링 및 보고 | SLA 준수를 입증하기 위해서는 철저한 모니터링과 보고 시스템이 필요합니다. AWS CloudWatch 및 3rd party 모니터링 도구 등을 활용하여 서비스 상태를 모니터링하고 보고할 수 있습니다. |
3. SaaS 비용 구조
사실 SaaS 비즈니스를 기획하는데 있어서 필자가 생각하기에 가장 중요하면서도 가장 어려운 영역인 것 같습니다. SaaS 비즈니스의 비용 구조를 이해하는 것은 수익성 있는 가격 전략을 수립하는 데 필수적입니다. SaaS 애플리케이션을 운영할 때 고려해야 할 주요 비용 요소는 다음과 같습니다.
3.1. 인프라 비용
AWS에서 SaaS를 운영할 때 가장 기본적인 비용은 컴퓨팅(EC2, Lambda), 스토리지(S3, EBS), 데이터베이스(RDS, DynamoDB), 네트워킹(데이터 전송) 등의 인프라 리소스에 대한 비용입니다. AWS의 종량제 가격 모델은 사용한 만큼만 지불하는 유연성을 제공하지만, 효율적인 자원 관리가 필요합니다.
3.2. 운영 비용
SaaS 애플리케이션의 운영 비용에는 모니터링, 로깅, 보안, 백업, 재해 복구와 같은 활동이 포함됩니다. 이러한 내용이 SLA에도 포함되어 있기 때문에 SaaS 제공 업체의 입장에서는 반드시 포함이 되는 비용입니다. 모니터링, 변경관리, Backup 같은 서비스를 활용하여 이러한 운영 작업을 자동화하고 효율화 해야 합니다.
3.3. 개발 및 유지보수 비용
지속적인 개발, 기능 추가, 버그 수정, 보안 패치는 SaaS 비즈니스의 중요한 부분입니다. CI/CD 파이프라인을 통한 자동화 구축을 하여 개발 및 배포 프로세스를 최적화할 수 있습니다. 특히 이러한 부분은 테넌트 관리에서 중요한 부분을 차지하며 상당히 기술적으로 어려운 부분을 차지합니다.
3.4. 고객 획득 및 유지 비용
마케팅, 영업, 고객 지원, 온보딩과 같은 고객 관련 활동에 대한 비용도 SaaS 비용 구조의 중요한 부분입니다. 예를 들어 고객 사용 경험을 위한 무료 Tier의 경우도 마케팅 비용에 들어가며 SaaS 제공 업체의 비용 부담으로 들어갑니다. 따라서 이러한 부분을 비용 최적화 전략에 반드시 반영해야 합니다.
3.5. 비용 최적화 전략
AWS에서 SaaS 비용을 최적화하기 위한 몇 가지 전략은 다음과 같습니다.
– 예약 인스턴스 및 Savings Plans: 예측 가능한 워크로드에 대해 예약 인스턴스나 Savings Plans를 활용하여 EC2 및 기타 서비스 비용을 절감할 수 있습니다.
– 오토스케일링: 수요에 따라 자원을 자동으로 조정하여 과다 프로비저닝을 방지합니다.
– 서버리스 아키텍처: 적절한 경우 AWS Lambda, API Gateway, DynamoDB와 같은 서버리스 서비스를 활용하여 유휴 용량에 대한 비용을 줄입니다.
– 비용 할당 태그: 리소스에 태그를 지정하여 테넌트별 비용을 추적하고 분석합니다.
사실 SaaS 비즈니스를 기획하는데 있어서 필자가 생각하기에 가장 중요하면서도 가장 어려운 영역인 것 같습니다. SaaS 비즈니스의 비용 구조를 이해하는 것은 수익성 있는 가격 전략을 수립하는 데 필수적입니다. SaaS 애플리케이션을 운영할 때 고려해야 할 주요 비용 요소는 다음과 같습니다.
3.1. 인프라 비용
AWS에서 SaaS를 운영할 때 가장 기본적인 비용은 컴퓨팅(EC2, Lambda), 스토리지(S3, EBS), 데이터베이스(RDS, DynamoDB), 네트워킹(데이터 전송) 등의 인프라 리소스에 대한 비용입니다. AWS의 종량제 가격 모델은 사용한 만큼만 지불하는 유연성을 제공하지만, 효율적인 자원 관리가 필요합니다.
3.2. 운영 비용
SaaS 애플리케이션의 운영 비용에는 모니터링, 로깅, 보안, 백업, 재해 복구와 같은 활동이 포함됩니다. 이러한 내용이 SLA에도 포함되어 있기 때문에 SaaS 제공 업체의 입장에서는 반드시 포함이 되는 비용입니다. 모니터링, 변경관리, Backup 같은 서비스를 활용하여 이러한 운영 작업을 자동화하고 효율화 해야 합니다.
3.3. 개발 및 유지보수 비용
지속적인 개발, 기능 추가, 버그 수정, 보안 패치는 SaaS 비즈니스의 중요한 부분입니다. CI/CD 파이프라인을 통한 자동화 구축을 하여 개발 및 배포 프로세스를 최적화할 수 있습니다. 특히 이러한 부분은 테넌트 관리에서 중요한 부분을 차지하며 상당히 기술적으로 어려운 부분을 차지합니다.
3.4. 고객 획득 및 유지 비용
마케팅, 영업, 고객 지원, 온보딩과 같은 고객 관련 활동에 대한 비용도 SaaS 비용 구조의 중요한 부분입니다. 예를 들어 고객 사용 경험을 위한 무료 Tier의 경우도 마케팅 비용에 들어가며 SaaS 제공 업체의 비용 부담으로 들어갑니다. 따라서 이러한 부분을 비용 최적화 전략에 반드시 반영해야 합니다.
3.5. 비용 최적화 전략
AWS에서 SaaS 비용을 최적화하기 위한 몇 가지 전략은 다음과 같습니다.
– 예약 인스턴스 및 Savings Plans: 예측 가능한 워크로드에 대해 예약 인스턴스나 Savings Plans를 활용하여 EC2 및 기타 서비스 비용을 절감할 수 있습니다.
– 오토스케일링: 수요에 따라 자원을 자동으로 조정하여 과다 프로비저닝을 방지합니다.
– 서버리스 아키텍처: 적절한 경우 AWS Lambda, API Gateway, DynamoDB와 같은 서버리스 서비스를 활용하여 유휴 용량에 대한 비용을 줄입니다.
– 비용 할당 태그: 리소스에 태그를 지정하여 테넌트별 비용을 추적하고 분석합니다.
4. SaaS 유형
AWS에서 SaaS 애플리케이션을 구현할 때 선택할 수 있는 두 가지 주요 모델이 있습니다: 공유 모델과 전용 모델입니다.
4.1. Shared Model (공유 모델)
공유 모델은 여러 테넌트가 동일한 애플리케이션 인스턴스와 기본 인프라를 공유하는 진정한 멀티테넌트 접근 방식입니다. 주요 특징은 아래와 같습니다.
– 모든 테넌트가 동일한 코드 베이스와 인프라를 공유
– 테넌트 간 리소스 공유로 비용 효율성 향상
– 중앙 집중식 업데이트 및 유지 관리
– 논리적 테넌트 격리에 의존
AWS에서 구현
AWS에서 Shared Model로 구현할 때 구현 방식입니다.
| 구분 | 구현 방식 |
| 데이터 격리 | Amazon RDS의 파티셔닝 전략 또는 DynamoDB의 파티션 키를 사용하여 테넌트 데이터 격리 활용 |
| 컴퓨팅 리소스 | ECS 또는 EKS 클러스터에서 애플리케이션 실행 |
| 인증 및 권한 부여 | Amazon Cognito와 AWS IAM을 사용한 테넌트별 액세스 제어 |
| API 관리 | 단일 API Gateway 배포로 모든 테넌트 서비스 |
4.2. Dedicated Model (전용 모델)
전용 모델은 각 테넌트에게 격리된 리소스와 때로는 별도의 인프라 및 애플리케이션 인스턴스를 제공합니다. 주요 특징은 아래와 같습니다.
– 테넌트별 전용 리소스
– 향상된 격리 및 보안
– 테넌트별 사용자 지정 가능
– 더 높은 비용 구조
AWS에서 구현
AWS에서 Dedicated Model로 구현할 때 구현 방식입니다.
| 구분 | 구현 방식 |
| 데이터 격리 | 테넌트별 전용 RDS 인스턴스 또는 DynamoDB 테이블 구성 |
| 컴퓨팅 리소스 | 테넌트별 전용 ECS 또는 EKS 클러스터, Lambda 함수 사용 |
| 네트워크 격리 | 테넌트별 별도의 VPC 구성 |
| 리소스 관리 | AWS Organizations 및 AWS Control Tower를 사용한 테넌트별 AWS 계정 활용 |
5. SaaS Shared Model 구현
공유 SaaS 모델을 AWS에서 효과적으로 구현하기 위한 주요 고려 사항은 다음과 같습니다. 아래의 고려 사항을 SaaS Shared Model 구현 시 상황에 맞게 적용이 반드시 필요합니다.
5.1. 멀티테넌트 데이터 아키텍처
Shared Model에서는 데이터 아키텍처가 특히 중요합니다. 일반적인 접근 방식은 다음과 같습니다:
– Pool Model: 모든 테넌트 데이터가 동일한 테이블에 저장되며 테넌트 ID 열로 구분됩니다. Amazon RDS 또는 Amazon Aurora를 사용하여 구현할 수 있으며, 인덱싱과 파티셔닝 전략이 중요합니다.
– Bridge Model: 테넌트별 테이블과 공유 테이블의 조합을 사용합니다. Amazon DynamoDB는 이러한 유연한 스키마 접근 방식에 적합합니다.
– 스키마 분리: 단일 데이터베이스 내에서 테넌트별 스키마를 사용합니다.
5.2. 동적 테넌트 컨텍스트
공유 애플리케이션 계층은 현재 요청을 처리 중인 테넌트의 컨텍스트를 인식해야 합니다. 애플리케이션을 모든 Shared Model 이용자들이 함께 사용하기 때문입니다. AWS API Gateway와 AWS Lambda를 조합하여 요청 헤더나 토큰에서 테넌트 ID를 추출하고 처리 로직 전체에 전파하는 시스템을 구축할 수 있습니다. Amazon Cognito 사용자 풀과 ID 풀을 사용하여 테넌트 컨텍스트와 함께 인증을 관리할 수 있습니다. 이와 같은 테넌트 ID를 통한 테넌트 구분은 Shared Model에서는 필수입니다.
5.3. 리소스 공유 및 제한
Shared Model에서는 테넌트가 시스템 리소스를 공정하게 사용하도록 보장하는 것이 중요합니다. 때문에 Shared Model에서는 Soft Limit을 두어 모든 사용자의 가용성을 보장해야 하며, 이러한 제한 요소는 하나의 마케팅으로 사용될 수도 있습니다. 주요 Limit으로는 API limit, Database Limit, Computing Limit이 있습니다.
5.4. 멀티테넌트 캐싱 전략
효율적인 캐싱은 공유 SaaS 모델의 성능을 최적화하는 데 중요합니다. Amazon ElastiCache(Redis 또는 Memcached)를 사용하여 테넌트 인식 캐싱 계층을 구현할 수 있습니다. 캐시 키에 테넌트 ID를 포함시켜 테넌트 데이터 격리를 보장할 수 있습니다. 이러한 방식은 사용자의 접근성과 사용성에 많은 도움이 됩니다.
6. SaaS Dedicated Model 구현
Dedicated Model은 테넌트에게 더 높은 수준의 격리와 사용자 지정을 제공합니다. 조금 더 쉽게 정리하면 더 많은 비용을 지불하는 사용자를 위한 전용 인프라를 제공한다고 보면 됩니다. 이 모델을 효과적으로 구현하기 위한 주요 고려 사항은 다음과 같습니다.
6.1. 테넌트별 리소스 프로비저닝
Dedicated Model에서는 각 테넌트에 대해 전용 리소스를 프로비저닝해야 합니다. AWS CloudFormation, AWS CDK, Terraform과 같은 인프라스트럭처 코드(IaC) 도구를 사용하여 이 프로세스를 자동화할 수 있습니다. 테넌트 온보딩 시 템플릿화된 스택을 배포하여 일관된 환경을 보장할 수 있습니다.
6.2. 테넌트 격리 전략
Dedicated Model에서는 다양한 수준의 격리를 구현할 수 있습니다. 여기에서 가장 고비용의 높은 수준의 격리는 계정 격리입니다. 그리고 이러한 테넌트 격리를 위한 중앙 집중식 관리가 필요합니다. 중앙 집중식 관리를 통해 테넌트 격리를 실행해야 합니다.
– 인프라 격리: 테넌트별 전용 EC2 인스턴스, ECS 클러스터 또는 EKS 노드 그룹
– 데이터 격리: 테넌트별 RDS 인스턴스, DynamoDB 테이블 또는 S3 버킷
– 네트워크 격리: 테넌트별 VPC, 서브넷 또는 보안 그룹
– 계정 격리: AWS Organizations를 사용하여 테넌트별 AWS 계정
6.3. 비용 최적화
전용 모델은 일반적으로 공유 모델보다 비용이 더 많이 들지만, 다음과 같은 전략으로 비용을 최적화할 수 있습니다. 과도한 비용 전가는 고객의 이탈로 이어질 수 있기 때문입니다.
– 예약 인스턴스 및 Savings Plans: 장기 약정으로 비용 절감
– 오토스케일링: 테넌트 워크로드에 따라 리소스 조정
– 적절한 크기 조정: 테넌트 요구 사항에 맞는 인스턴스 유형 및 크기 선택– 수명 주기 정책: 불필요한 리소스 자동 정리
7. SaaS Tenant 관리
효과적인 테넌트 관리는 성공적인 SaaS 운영의 핵심입니다. SaaS 테넌트를 관리하기 위한 주요 고려 사항은 다음과 같습니다.
7.1. 테넌트 모니터링 및 미터링
테넌트 활동과 리소스 사용을 모니터링하는 것은 비용 할당, 성능 최적화, 청구를 위해 중요합니다. AWS CloudWatch, AWS Cost Explorer, AWS Budgets를 활용하여 테넌트별 사용량과 비용을 추적할 수 있습니다. 또한 AWS Cost and Usage Report와 비용 할당 태그를 사용하여 테넌트별 비용 분석을 수행할 수 있습니다.
7.2. 테넌트 마이그레이션 및 업그레이드
SaaS 애플리케이션이 발전함에 따라 테넌트를 새로운 버전이나 인프라로 마이그레이션해야 할 수 있습니다. 주로 배포 전략 및 Versioning에 따라 어떤 버전의 테넌트를 이용하는지 확인 및 관리할 수 있어야 하며, 블루/그린 배포 전략을 사용하여 테넌트 업그레이드 중 다운타임을 최소화할 수 있습니다.
결론
사실 필자가 많이 아쉬운 부분은 국내 기업이 SaaS에 대해 제대로 이해하고 접근하는 경우를 많이 보지 못했다는 점이다. SaaS는 처음에 정의했던 것 처럼 ‘비즈니스 모델’이다. 여러 기술적인 요소를 언급했지만 비즈니스 모델, 과금 체계 등이 정의되고 이에 최적화된 아키텍처로 구현하는 것이 핵심입니다. 따라서 SaaS 애플리케이션을 구현할 때는 비즈니스 요구 사항, 규정 준수 요건, 고객 기대치에 가장 적합한 모델을 선택하는 것이 중요합니다. 또한 많은 경우, 하이브리드 접근 방식이 최적일 수 있으며, 일부 구성 요소는 공유 모델을 사용하고 다른 구성 요소는 전용 모델을 사용할 수 있습니다.
참고 링크
https://github.com/aws-samples/saas-reference-architecture-ecs/blob/main/DEVELOPER_GUIDE.md