Overview
안녕하세요 🙂
AWS 인프라 환경에서 SaaS 서비스를 제공하기 위한 아키텍처 기초에 대한 백서를 제공하고 있습니다.
이번 글에서는 ‘AWS SaaS Architecture Fundamentals White Paper 1‘에서 이야기한 Control Plane, Application Plane에 대한 이야기를 좀 더 구체적으로 기록하려고 합니다.
이 글은 원문을 해석하는 데 오역 및 주관적인 관점이 포함 될 수 있음을 미리 말씀드립니다.
Core services
이전에 이야기한 제어 계층의 코어 서비스는 SaaS 환경을 제어하기 위한 서비스 목록의 집합입니다.
다음은 각 서비스를 간단하게 요약 정리한 내용입니다.
Onboarding
모든 솔루션은 SaaS 환경에 새로 참여하는 테넌트에게 원활한 배포 메커니즘을 제공해야 합니다.
SaaS 솔루션에 참여하는 방식으로 테넌트가 직접 참여하거나, 참여하는 방식을 managed service 형식으로 제공 할 수 있습니다.
모든 참여 프로세스에 대하여 안정성, 효율성 및 반복성을 보장하여야 합니다.
일반적으로 온보딩 서비스는 다른 코어 서비스를 이용하여 사용자, 테넌트, 격리 정책, 프로비저닝, 테넌트 단위 리소스를 생성합니다.
Tenant
테넌트 서비스는 각 테넌트의 정책, 속성 및 상태를 중앙에서 관리 할 수 있도록 하는 서비스입니다.
핵심은 서비스가 관리하는 테넌트가 사용자를 의미하지 않는다는 것입니다. 이전에 언급하였던 것처럼 테넌트는애플리케이션 환경이며, 그렇기 때문에 한 테넌트는 많은 사용자를 포함하고 있을 가능성이 매우 높습니다.
Identity
SaaS 시스템은 인가된 사용자가 테넌트에 접속 할 수 있는 인증 및 권한 기능을 제공해야 합니다.
인증 서비스는 온보딩 및 사용자 프로필 관리에 영향을 미칩니다.
Billing
SaaS를 채택하는 과정에서 일반적으로 조직은 새로운 과금 모델을 선택합니다. 경우에 따라 PG사의 서비스를 이용하기도 합니다.
코어 서비스는 신규 테넌트의 온보딩 및 테넌트에 사용된 비용 정보에 대한 실데이터를 수집하여 제공하는 것에 중점을 둡니다.
Metrics
SaaS는 테넌트의 리소스 사용량과 같은 시스템 정보를 수집하고 분석 할 수 있어야 합니다.
또한 이렇게 수집한 정보는 효과적으로 visualized 되어야 합니다.
수집하여 가공된 데이터를 기반으로 테넌트의 서비스 운영과 제품 및 사업 전략에 활용 될 수 있습니다.
Admin user management
SaaS는 사용자 레벨 즉, 일반 사용자와 관리자를 구분 할 수 있어야 합니다.
여기서 이야기하는 관리자는 SaaS 프로바이더의 관리자를 의미합니다.
관리자는 SaaS 운영 환경 전체에 대한 관리를 수행합니다.
Re-defining multi-tenancy
SaaS와 multi-tenancy는 밀접한 관련이 있는 용어입니다.
조직에서 SaaS와 멀티 테넌시를 동일하게 생각하는 경향이 있는데, 정리하자면 SaaS는 비즈니스 모델에 가까운 용어이며, 멀티 테넌시는 아키텍처 또는 인프라에 가까운 용어라고 정리 할 수 있습니다.
앞에서와 마찬가지의 방식으로 고전적인 멀티 테넌시 방식부터 정리하고자 합니다.
예를 들면, EC2 인스턴스는 여러 테넌트가 동일한 인프라를 사용하기 때문에 멀티 테넌트라고 이야기 할 수 있습니다.
다만, 이렇게 사용한다고 해서 SaaS의 개념을 포함하지는 않습니다. SaaS에서 정의하는 특성은 코어 서비스, 즉 멀티 테넌트 환경을 지원하는 인프라를 갖추어야 한다는 것입니다.
다음은 SaaS 환경에서의 멀티 테넌시를 표현한 다이어그램입니다.
기존의 SaaS 다이어그램과 다른 점을 몇 가지 찾을 수 있을 것입니다.
다이어그램에서 이야기하고자 하는 바는 다음과 같습니다.
기본적으로, 제품 서비스는 모든 리소스를 공유합니다.
주문 서비스는 테넌트 별 별도의 스토리지를 제공합니다.
카탈로그 서비스는 모든 테넌트에 별도로 제공하지만, 스토리지는 공유하는 형태입니다.
SaaS 환경에서는 이러한 특성의 변형이 일반적입니다.
이웃 소음 문제, 티어링 모델, 격리 요청과 같은 요구사항을 만족하기 위해 SaaS 솔루션 일부를 선택적으로 공유하거나 단일화 할 수 있어야 합니다.
따라서, 단순한 멀티 테넌트 용어 사용으로는 SaaS의 특성을 전부 담아내기 힘든 부분이 있습니다.
기술적인 관점으로 접근하였을 때, 일부는 멀티 테넌트가 아닌 환경도 있기 때문입니다.
결과적으로는 전체 SaaS 환경을 멀티 테넌트로 설명하는 것이 가장 합리적이라고 할 수 있습니다. SaaS 환경은 멀티 테넌트 모델에서 운영, 관리되기 때문입니다.
Removing the single-tenant term
멀티 테넌트(Multi-tenant)라는 용어를 사용하게 되면서 단일 테넌트(Single-tenant)를 사용하게 되는 것은 당연할 수 있습니다.
멀티 테넌트를 정의하기 위하여 사용한 다이어그램에서 예로 들었던 변형 구조의 서비스도 전부 멀티 테넌트라고 이야기 할 수 있습니다.
단일 테넌트라는 용어는 혼란을 야기할 수 있어 사용하지 않는 것을 권장합니다.
Introducing silo and pool
앞서 언급한 다양한 모델에 대한 “멀티 테넌시”라는 용어를 정의하기 위해 SaaS 구축 시 사용하는 모델에 대한 용어를 정의합니다.
SaaS 환경에서 리소스를 점유 방법에 대한 특성을 두 가지로 구분하여 Silo와 Pool이라 정의합니다.
기본적으로 silo 모델은 하나의 테넌트에 하나의 리소스가 할당되는 것이며, pool 모델은 모든 테넌트가 모든 리소스를 공유하는 것을 의미합니다.
하지만 중요한 것은 두 가지 모델이 SaaS 모델의 전부가 아니라는 것입니다.
두 모델은 테넌트 전체에 적용 될 수도 있고, DB 또는 스토리지와 같은 일부 영역에 선택적으로 적용 될 수 있는 개념입니다.
다음 다이어그램은 SaaS 환경에서 사일로 및 풀 모델을 세분화하여 사용하는 컨셉을 보여줍니다.
다이어그램에서 표현하고자 하는 것은 개별 마이크로서비스 단계에서 다양한 모델을 채택하여 사용 할 수 있다는 부분입니다.
복잡해 보일 수 있겠지만, SaaS 솔루션 설계 및 구축 과정에서 요구사항에 맞는 사일로/풀 모델을 결정해야 할 것입니다.
사일로/풀 모델 선택에 고려해야 할 요인으로는 이웃 소음 문제, 격리, 테넌트 티어 및 기타 다양한 원인이 있을 수 있다는 이야기입니다.
Full stack silo and pool
사일로와 풀은 전체 SaaS의 스택을 설명 할 수 있습니다.
이러한 접근으로, 모든 테넌트의 리소스는 전용 또는 공용 방식으로 배포됩니다.
다음 다이어그램은 SaaS 환경에서 구현되는 예시를 제공합니다.
다이어그램에서 세 종류의 풀 스택 테넌트 배포 예시를 확인 할 수 있습니다.
먼저, 풀 방식의 테넌트 환경입니다.
테넌트는 CPU, 스토리지와 같은 모든 리소스를 풀 방식으로 공유합니다.
나머지 두 스택은 사일로 테넌트 환경을 보여줍니다.
테넌트 3, 4는 다른 테넌트와 공유되지 않는, 전용 리소스를 보유합니다.
SaaS 환경에서 풀, 사일로 방식을 혼재하여 사용하는 경우는 일반적이지 않습니다.
* 백서에서는 두 방식에 대한 개론을 이야기하므로 상세한 내용을 묘사하지는 않습니다.
* 다만, 백서에서 기록하지는 않았으나, 브릿지 모델을 참고하시면 좋을 것 같습니다.
https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/saas-lens/bridge-model.html
예를 들면, Basic 티어 테넌트가 보통 수준의 요금을 지불하고 시스템을 사용하는 경우 풀 방식으로 제공하면 될 것입니다.
반면, Premium 티어 테넌트가 그 수준에 맞는 요금을 지불하게 된다면, 사일로 방식으로 제공받을 권리가 생길 것입니다.
티어 구분이 있는 모델에서, Premium 티어의 애플리케이션 커스터마이징을 허용하지 않는 것이 중요합니다.
모든 풀, 사일로 스택에서 동일한 구성과 버전을 보장받는 것이 핵심이며, 새 버전을 배포하는 경우에 모든 테넌트에 동일하게 배포되어야 합니다.
SaaS vs Managed Service Provider(MSP)
SaaS와 MSP 모델 경계에서 발생하는 모호함도 있습니다.
MSP 모델을 보면 SaaS 모델과 유사한 목표가 몇 가지 있습니다.
그러나 MSP 모델을 조금 더 깊게 살펴보면 실제로 두 모델은 다르다는 것을 알 수 있습니다.
다음은 MSP 환경의 개념을 정리한 다이어그램입니다.
먼저, 왼쪽은 MSP 모델의 고객입니다.
일반적으로 모든 고객에게 서비스 환경과 소프트웨어를 프로비저닝하는 자동화 환경이 제공됩니다.
오른쪽은 고객의 서비스 환경을 관리하는 운영팀을 나타냅니다.
MSP 모델은 SaaS와는 다르게 모든 고객이 동일한 버전을 실행 할 필요가 없습니다.
MSP 모델을 단순화하면 소프트웨어 프로바이더에게 설치 및 운영 관리 권한을 위임하여 관리하도록 하는 것입니다.
정리하자면, 관리 책임의 부담을 줄이는 것이 SaaS에서 추구하는 것과는 같다고 할 수 없다는 이야기입니다.
MSP는 고객 별 별도의 버전을 허용하고 이것을 별도의 운영 환경이라고 간주하기 때문입니다.
Conclusion
나머지 내용은 다른 백서 및 기술 문서에서 더 상세하게 다루며, SaaS의 핵심 컨셉을 이해하기 위해 필수적인 내용은 아니라고 생각하여 정리하지 않고 마치려 합니다.
자세한 내용은 다른 기술 문서 또는 여기서 소개하는 백서를 읽어보셔도 좋을 것 같습니다.
Reference
AWS SaaS Architecture Fundamentals White Paper PDF
문의: info@bespinglobal.com | 대표번호: 02-1688-1280