[리포트] SaaS 아키텍처 패턴: 개념부터 구현까지 #reinvent #SAS305-R

AWS re:Invent 2022

#SaaS

#한국어블로그

#AWS

LimChaejeong

2023.02.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요, 임채정입니다.
지금 라스베가스에서는 11월 28일부터 12월 2일까지 re:invent를 진행했습니다.
해당 블로그는 「SaaS architecture patterns: From concept to implementation」 세션을 정리한 리포트입니다.

아젠다

세션 개요
SaaS 아키텍처 패턴의 특징
Control plane patterns
Application plane patterns
마무리

1. 세션 개요

개요

SaaS architecture varies across domains, stacks, and customer requirements. However, there are well-defined patterns that must be addressed by every SaaS solution. Identity, onboarding, tenant isolation, data partitioning, tiering—these are among the patterns that, while implemented differently on AWS stacks and services, are core to most SaaS solutions. In this session, take a detailed look at the landscape of these SaaS patterns. For each one, move from concept to implementation, looking at the permutations of architecture and code that are used to bring these patterns to life with different compute, storage, identity, networking, and management constructs.

발표자

Tod Golding, Principal Partner Solutions Architect, AWS

발표 난이도

300 - Advanced

2. SaaS 아키텍처 패턴의 특징

먼저 SaaS 아키텍처의 블루프린트는 없습니다.
아키텍처 패턴에는 어떤 조건을 원하느냐에 따라 너무 많은 패턴이 있기 때문입니다.

패턴에서 SaaS 구성

SaaS 아키텍처는 메니지먼트, 어플라케이션, 테넨시, 파라미터 를 통해 만들어집니다.

메니지먼트
비즈니스를 관리하고 운영하는 방법.
비즈니스를 관리하고 운영하는 방법과 관리 및 운영에 관한 패턴 그룹이 있습니다.
메트릭, 분석, 청구, 프로비저닝 등을 정할 필요가 있습니다.

어플라케이션
하위 도메인은 어떻게 얻는지 등과 하위 도메인이 특정 테넌트 워크로드에 어떻게 도달하게 할건지 등을 판단할 필요도 있고 어떤 식으로 배포할건지와 라우팅 등의 결정이 필요합니다.

테넨시
사용자와 테넌트를 어떻게 연결할지 테넌트를 시스템으로 끌어들이기 위해 필요한 모든 작업을 어떻게 조율할 지 살펴봐야 할 영역이 방대합니다. 그리고 계층화도 해야 합니다.

파라미터
사업목표, 출시 기간 등의 결정도 물론 필요합니다.

이처럼 다음과 같은 항목들을 어떻게 정하느냐에 따라 다양한 패턴이 나올 수 있습니다.

the two halves of SaaS

"the two halves of SaaS (SaaS의 반쪽 2가지)"라는 핵심 개념이 있습니다.

컨트롤 플레인

새로운 SaaS 애플리케이션을 구축을 시작할 때 먼저 시작해야 하는 부분입니다.
어플리케이션 관련을 제외한 모든 테넌트에게 공통적인 부분을 말합니다.
컨트롤 플레인은 멀티 테넌트가 아니라 모든 멀티 테넌트를 관리하는 하나의 서비스 세트입니다.
개별적으로 관리할 수 있고, 개별적으로 배포할 수 있으며, 개별적으로 버전을 관리할 수 있습니다.
많은 사람들이 컨트롤 플레인에 대해서는 생각하지 않고 넘어가는 경우가 많습니다.

테넌트를 환경에 도입하는 방법, 온보딩은 어떻게 할 것이며, ID는 어떻게 작동할건지에 대한 핵심 컨트롤 플레인을 구축하고 그것을 토대로 애플리케이션 플레인을 구축합니다.
컨트롤 플레인이 애플리케이션 플레인을 어떻게 구성하고 설정하고 운영할지 결정해야 합니다.

어플리케이션 플레인

실제 어플리케이션과 관련된 부분입니다.

3. Control plane patterns

3-1. Onboarding orchestration

Onboarding : 조직 내에 새로 합류한 사람이 빠르게 조직의 문화를 익히고 적응하도록 돕는 과정 (적응 지원)
orchestration : 컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 구성, 관리, 조정을 의미

-> Onboarding orchestration : 컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 구성, 관리, 조정 등에 적응하도록 돕는 패턴

새로운 테넌트가 들어와서 이 등록 서비스를 누르면 이를 조정하고 조율하는 별도의 서비스가 필요합니다.
여기에는 움직이는 부분이 많기 때문에 상태와 상태를 추적하려면 등록 서비스가 필요합니다.

② 가장 기본적인 첫 번째 작업은 테넌트를 생성하는 것입니다.
글로벌 고유 식별자를 부여하고, 이름을 얻고, 어떤 티어에 속하는지 파악하는 등 기본적인 작업을 수행합니다.

③ 또한 사용자를 만들어야 합니다.
이 사용자가 들어와서 우리 시스템에서 ID를 만들어야 합니다. (이 첫 번째 사용자는 보통 테넌트 관리자입니다.)

④ 그리고 여기에서 Identity provider 가 필요합니다.
그리고 여기서 가장 중요한 것은 사용자 지정 클레임인데 속성 값, 아이덴티티 등을 안에 넣는 것입니다.
예를 들어 그 자산 가치, 테넌트 ID, 테넌트 역할, 최소한 테넌트 계층 등을 여기에 넣습니다.

⑤ 또한 격리 정책이 필요하면 만들어야 합니다.

⑥ 그리고 어딘가에서 청구와 연결해야 됩니다.
이 때, 부분 유료화를 할 수도 있지만 일반적으로는 여기에 누군가를 구축할 것입니다.

⑦ 그리고 청구 청구 관리를 실제 청구 기능을 해주는 제공업체에도 연결해야 합니다.

⑧ 마지막으로 프로비저닝도 생각해야 됩니다.
여기서 중요한 점은 테넌트 단위로 생성하거나 테넌트 단위로 구성해야 하는 모든 인프라도 여기서도 온보딩의 일부입니다.
이 모든 것의 핵심은 움직이는 부분이 많다는 것입니다.

이 모든 것이 완료되면 고객을 구축하는 방법을 알고, 고객이 보유한 인프라를 프로비저닝하고, 테넌트 관리의 일부로 정책이나 라우팅을 설정하고 테넌트 관리의 일부로 아이덴티티를 모두 관리할 수 있습니다.
이를 달성하면 컨트롤 플레인 내부에 큰 진전을 이룬 것입니다.

3-2. Tenant-aware identity

①②③ 웹 앱을 누르면 웹 앱은 ID 공급자에게 리디렉션하고, ID 공급자는 토큰을 반환합니다.

이 그림이 특별한 점은 반환되는 토큰이 OIDC라는 점과 이 토큰이 반환된다는 점입니다.
온보딩 단계의 사용자 지정 클레임에 넣을 때 추가 테넌트 컨텍스트가 포함된다는 점입니다.
이제 이 토큰을 전달하고 이 토큰을 통과시키면 전형적인 구현 방식이 됩니다.

④⑤ 이 토큰을 전달하면 첫 번째 애플리케이션 서비스로 전달됩니다.
이제 모든 테넌트 컨텍스트가 바로 거기에 있습니다.
컨텍스트를 얻기 위해 다른 곳으로 이동할 필요가 없습니다. 이 모든 것이 제가 권한 부여 및 인증 정보를 공유한 방식에 내장되어 있습니다.
인증 정보를 해당 서비스와 공유하는 방식에 모두 포함되어 있습니다.

그리고 이제 다른 서비스를 다운스트림으로 호출할 때 동일한 토큰을 전달합니다.

3-3. Billing configuration and instrumentation (청구 구성 및 계측)

또한 결제 행태도 결정해야 됩니다.
사실 직접 구축하지 않고 외부 결제 제공업체를 통하는 게 간단하고 좋은 것같습니다.
하지만 일부 기업에서는 더 큰 엔터프라이즈 스토리의 일부이기 때문에 그 스토리와 함께 작업해야 합니다.

청구 기능을 제공하는 솔루션으로 제공업체에 가서 계정을 설정하는것으로 간단하게 사용할 수도 있습니다.
또한, 요금제를 구성해야 하는데 요금제마다 청구 방식과 청구 가능한 단위가 다르기 때문에 요금제를 설정하는 방법은 매우 다양합니다.
소비량과 요금이 얼마인지에 대한 모든 계획을 미리 구성해야 합니다.

3-4. Metrics instrumentation and aggregation (측정 기준 계측 및 집계)

SaaS 솔루션 내부의 앱 빌더가 솔루션 전반에서 의미 있는 활동과 이벤트, 비즈니스에 의미 있는 활동과 이벤트, 제품 소유자에게는 부분적으로 의미 있는 활동과 이벤트들을 파악할 필요가 있습니다.
테넌트들이 우리 시스템의 리소스를 어떻게 소비하고 있지 어떻게 확장되고 있지 어떤 기능을 사용하고 있지에 대한 분석도 필요하고 기능의 소비가 시스템 내의 이벤트 및 활동, 규모와 어떤 상관관계가 있지 등을 파악하는게 좋습니다.

데이터의 집계에는 Redshift와 Firehose, Elasticsearch 등의 서비스를 사용할 수 있고 이를 통해 데이터를 수집하고, 웨어하우스에 저장하고, 데이터에 대해 좋은 분석을 할 수 있게 해줍니다.
또한, 일부 소스나 시스템 이벤트는 CloudWatch를 가져올 수 있고 특정 애플리케이션 이벤트를 가져와서 도메인에서 의미 있고 사용자 환경에 대한 의미 있는 메트릭을 나타내는 것도 중요합니다.

4. Application plane patterns

4-1. Full stack silo patterns

AWS에서 테넌트당 계정은 종종 전체 스택 사일로 모델입니다. 이는 좋은 모델이지만 계정 제한과 같은 많은 주의 사항이 있습니다. 신중하게 선택한 매개변수 세트를 사용하여 선택해야 하며 반드시 주의해야 할 사항입니다.

또 다른 변형은 다운데 그림과 같이 테넌트당 VPC입니다. 적어도 이제 하나의 계정으로 모든 것을 관리할 수 있게 되어 관리하기가 조금 더 쉬워졌습니다. 계정 간 액세스에 대해 걱정할 필요가 없으며 사일로의 모든 장점을 그대로 누릴 수 있습니다.

계정이 사일로보다 더 절대적인 개념일 수도 있지만, VPC를 사용하면 테넌트 환경의 경계를 확실히 설정하고 테넌트 환경에 꽤 엄격한 경계를 설정하고 꽤 편안하게 사용할 수 있습니다.

모두 동일한 버전을 사용하고 동일한 메커니즘을 통해 동일하게 배포됩니다, 모두 같은 운영 시스템을 사용합니다. 이것이 바로 멀티 테넌트를 유지하는 이유입니다.

4-2. Full stack fool patterns

풀 스택 풀은 정말 간단합니다. 모든 테넌트를 동일한 VPC에 배치하면 됩니다. 모두 리소스를 공유하기만 하면 되니까요. 람다나 다른 기술도 사용할 수 있으며, 이 경우와 마찬가지로 모든 테넌트를 하나의 클러스터에 넣고 EKS용 클러스터에서 실행하거나 람다에서 실행할 수 있습니다.

4-3. Mixed mode deployment model

4-1 과 4-2 를 섞어놓은 형태의 모델로 두 패턴들의 장점을 모두 가지고 있습니다.

4-3. Pod-based deployment model

Pod-based deployment model은 풀을 생성하고 해당 풀에 대한 포드를 생성한 다음 특정 테넌트를 프로비저닝하여 특정 테넌트를 프로비저닝한 다음, 테넌트를 분할하여 포드를 확장 단위로 사용하게 됩니다. 온보딩이 더 복잡해져서 관리 작업이 조금 더 복잡해지긴 하지만 꽤 매력적인 모델입니다.

이는 포드 기반 배포를 수행하는 다중 지역 환경에서 많이 나타납니다. 다른 리전으로 이동하고 싶을 때 해당 리전에서 해당 포드를 실행하면 됩니다.