*이 포스팅은 제가 일터에서 TW로 일하며 라이팅했던 작업물들입니다.
https://medium.com/stclab-tech-blog/multi-tenant-saas-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%8A%A4%ED%86%A0%EB%A6%AC-5d92cc0eb3f3
Multi-Tenant SaaS 아키텍처 디자인 스토리
안녕하세요.
STCLab에서 SaaS Tech Lead를 맡고 있는 Liam(정대범)이라고 합니다.
이번에 독자들에게 공유하고자 하는 글의 주제는 바로 SaaS(Software-as-a-Service)입니다.
SaaS란 무엇이며 STCLab이 SaaS를 하는 목적과 목표를 제시하고, 나아가 SaaS 구현 과정에서 고민했던 부분들을 함께 나누고자 합니다.
STCLab R&D에서 SaaS를 개발하고 있는 다양한 개발자들의 이야기를 시리즈로 구성해 소개할 예정입니다.
STCLab은 유량 제어 솔루션 ‘NetFUNNEL’, 빅데이터 수집 및 분석 솔루션 ‘Data Surfer’ 등 굴지의 제품들을 출시하며 국내에서 많은 인지도를 얻었습니다. 이러한 국내 성공의 경험을 바탕으로 글로벌 시장으로의 진출을 목표로 하고 있습니다.
국내 시장에서 STCLab은 그동안 개별 기업들의 로컬 환경에 솔루션을 직접 설치하는 온프레미스(On-premise, 설치형 제품) 방식으로 활동했습니다. 하지만 온프레미스 및 구축형 솔루션은 글로벌 확장의 한계가 있는데요. 저희는 기존 Legacy 형태로 설치되고 판매되고 있던 자사 제품들을 Cloud 기반의 SaaS Application으로 전환하고자 합니다.
이번 포스팅에서는 SaaS란 무엇이며 STCLab의 SaaS Application 설계 과정을 깊이 있게 나누는 시간을 준비했습니다.
STCLab의 SaaS 목표
SaaS 팀에서 정리한 STCLab 제품의 SaaS 목표를 정리하고 제품 소개를 통해 제품에 대한 이해도를 높여보겠습니다.
목적과 목표
기존 Legacy에 설치되고 있던 자사의 SW 제품(NetFUNNEL, Data Surfer)을 SaaS 형태로 글로벌 시장에 선보이는 것.
기존 Global CSP 인프라에 기반해 Self-Service가 가능한 Multi-tenant 환경을 구축하여 상기 목적을 달성
Short-term Goal; AWS 기반의 Multi-tenant SaaS Application 개발
제품 소개
NetFUNNEL
넷퍼넬(NetFUNNEL)은 고객에게 원활한 디지털 서비스를 제공하기 위한 가상 대기실 솔루션(Virtual Waiting Room)입니다. 실시간으로 엔드 유저의 서비스 경험을 모니터링하고, 서비스 상황에 맞게 유저 트랜잭션을 제어해 최적의 서비스 성능을 보장합니다.
넷퍼넬은 실제 사용자 수 기반의 다양한 서비스 현황 정보를 실시간으로 제공하는 소프트웨어 알고리즘 기반의 디지털 트랜잭션 관리 솔루션으로서 STCLab의 트래픽 매니지먼트 솔루션입니다.
넷퍼넬은 수많은 애플리케이션 성능 관리(Applicaton Performance Management) 시스템들의 취약점을 보완한 새로운 서비스 제어 시스템입니다. 시스템에 진입하는 트래픽을 분석 및 제어하고, 요청 받은 서비스에 IT자원을 할당해 애플리케이션 전체 성능을 제어하는 애플리케이션 성능 제어 솔루션(Application Performance Control Solution)입니다.
기존의 애플리케이션 성능 관리 시스템은 서비스 트래픽을 모니터링하여 수집된 자료를 토대로 성능 저하 원인을 규명하고, 최상의 애플리케이션 가용성을 확보하기 위한 모니터링 위주의 시스템입니다. 이 시스템은 장애 발생 후 대응하는 방식으로 운영되기 때문에 문제를 수습하는데 많은 자원을 소요할 수밖에 없다는 한계를 갖고 있습니다.
넷퍼넬은 사전에 시스템 처리 용량을 초과하지 않도록 미리 트래픽을 제어합니다. 서비스별 리소스 관리와 APM 연동으로 다양하고 효율적인 서비스 운영이 가능합니다.
SaaS란
- 기존 Legacy 형태로 Delivery되던 Software 제품이 Cloud Computing의 발전으로 Cloud 환경에서 고객에게 서비스로 전달되는 형태를 갖춘 Software 제품을 의미합니다.
- 고객 및 사용자가 온라인에서 자신만의 환경(Tenant)을 On-demand로 스스로 신청(Self-Service)하고 서비스 받을 수 있어야 합니다.
SaaS의 요건
그렇다면 SaaS Application이 되기 위해서 어떤 요건들이 있어야 할까요?
SaaS App의 요건에는 여러 가지가 있지만 그 중에서도 제가 가장 중요하게 생각하는 요건은 Self-Service(셀프 서비스)와 Multi-tenant(멀티 테넌트)입니다.
- 첫 번째 Self-Service는 고객이 on-demand로 언제 어디서나 자신이 필요할 때 서비스를 그 즉시 신청하고 경험할 수 있게 한다는 내용입니다.
기존에는 고객이 제품이나 서비스를 신청하면 기술 전문가가 파견되어 각 기업의 Legacy 환경에 설치를 진행해야 했습니다.
하지만 SaaS Application은 고객이 원하면 그 즉시 on-demand로 스스로 설치 및 제공될 수 있어야 합니다. 이를 위해서는 우리가 고객 환경을 자동적으로 On-boarding해야 할 뿐 아니라, 고객의 사용량에 따라 자동으로 청구와 결제가 이루어지는 Metering, Billing 자동화도 구성해야 합니다.
- 다음은 Multi-Tenant 요건입니다.
고객이 공유하는 Cloud Resource 환경을 고객별 환경(Tenant)으로 분리(seperation) 또는 격리(isolation)할 수 있어야 합니다. Legacy 고객 환경은 그 자체로 자연스럽게 물리적으로 분리되어 있습니다.
반면에 Cloud라고 하는 거대한 가상화 Infrastructure에서는 인프라 리소스가 자연스럽게 공유되고 있습니다. 이는 Cloud 기본 사상을 가상화로 인한 리소스 ‘공유’라는 측면에서 이해하면 Make Sense한 내용입니다. 따라서 각 고객별 자신만의 환경(tenant)을 분리하거나 격리하고자 하는 요건을 고려해 이러한 고객들의 환경을 ‘Tenant’라고 하고, 우리는 그러한 다중 고객 환경 즉, 멀티 테넌트를 고려해 위 Tenant Onboarding 및 Tenant Management를 구성해야 합니다.
그렇다면 어떻게 이 두 가지 요건을 고려한 아키텍처를 설계할 수 있을까요?개발 이야기는 앞으로 상세하게 소개해드리겠지만 아키텍처 디자인은 쉽지 않았습니다.
Tenant Isolation 기준에는 다양한 기준이 있는데요.
각 기준의 명확한 장단점을 이해하고 ‘유지 보수와 비용 측면’ 그리고 ‘Cloud Service Provider(CSP)에 dependent한 policy의 측면’ 등 많은 복합 요건들을 고려해 STCLab이 장기적으로 아키텍처를 운영했을 때 가장 유리하다고 판단되는 아키텍처를 설계해야 했습니다.
CSP 선정, AWS
STCLab은 수많은 Global CSP 중에서 세계적으로 가장 많은 사랑을 받고 있는 AWS에서 SaaS Application을 구현하기로 했습니다. Microsoft의 Azure나 Google GCP, 혹은 국내에서는 KT Cloud와 Naver Cloud와 같은 굴지의 CSP가 있지만, 글로벌 진출을 고려해 전 세계 가장 많은 데이터 센터를 보유하고 가장 많은 점유율을 가지고 있는 AWS를 선택했습니다.
이제 가장 먼저, AWS와 친해지는 작업이 필요하다고 생각했습니다.
글을 쓰는 지금도 아직 AWS의 모든 기능을 다 활용해본 것은 아닙니다. 역시 AWS 서비스와 친해지기까지는 어느 정도 시간이 필요했습니다. Cloud에 익숙하지 않거나 AWS를 처음 접하시는 분들이라면 수많은 서비스와 솔루션, 그리고 수많은 문서 및 자료들을 보면서 도대체 어떻게 접근해야 할지 잘 모르시는 분들이 많을 것 같습니다(저 역시 그랬습니다).
그래서 일단은 AWS의 다양한 솔루션들 중에서도 기본이라고 생각하는 서비스들은 다 한번씩 써보고 매뉴얼을 읽어가면서 친해지는 노력을 좀 많이 했던 것 같습니다. 많이 보면 친해집니다.
이 모든 작업의 이유는 AWS라는 CSP 사의 리소스를 최대한 잘 활용할 수 있기 위함입니다. 결국 우리의 SaaS Application은 CSP에서 정한 정책과 규칙 내에서 최대한 리소스를 잘 활용할 수 있어야 하기 때문입니다.
가장 큰 고민, Multi-Tenant 아키텍처
SaaS Blue print by SaaS architecture fundamentals
멀티 테넌트 아키텍처를 설계하는 일은 기존의 싱글 테넌트 아키텍처 설계만 경험했던 저에겐 조금 낯선 분야였습니다.
각종 아티클을 참고하면서 많은 도움을 얻었는데 그 중에서도 AWS Blog에서 가장 도움을 많이 받을 수 있었습니다. AWS에서는 자사의 리소스들을 활용하여 Tenant의 단위를 설정하는 기준에 대해 전문적인 아티클을 제공하고 있었습니다.
그 중 AWS에서 제안하는 Tenant 분리 및 격리 기준과 STCLab에서 선정한 Tenant 기준에 대해 설명드리겠습니다.
ref: SaaS Tenant Isolation Strategies, August 2020, https://d1.awsstatic.com/whitepapers/saas-tenant-isolation-strategies.pdf
Silo vs Pooled
AWS에서는 크게 두 가지 개념의 Tenant Isolation 전략, Silo Isolation 그리고 Pooled Isolation이 있습니다. 두 개념의 가장 큰 차이점은 Tenant 간 리소스 공유 여부인데요.
Silo 방식은 말 그대로 Tenant의 리소스를 Silo화하여 서로 공유하지 않겠다는 뜻이고, Pooled 방식은 리소스를 서로 공유한다는 개념입니다.
여기서 리소스란 Computing, Storage, DB, Network처럼 AWS가 제공하는 가상화된 인프라 리소스를 의미합니다. Silo 방식은 그러한 인프라 리소스를 Tenant마다 격리하여 사용한다는 것입니다.
인프라 리소스 단위로 격리하기 때문에 Silo Isolation에는 여러 이점이 있는데요.
제가 생각하는 가장 중요한 이점은 격리 기준에 따라 상이하지만, 일반적으로 특정 Tenant의 장애나 이슈가 다른 tenant에 영향을 미치지 않고, 오로지 해당tenant만을 위한 환경을 제공한다는 것입니다.
또한 특정 Tenant가 유독 다른 tenant에 비해 트래픽이 높아 리소스 사용량이 증가해도 그것이 다른 Tenant에 영향을 미치지 않는다는 장점이 있습니다. 반면 Tenant마다 별도의 리소스를 할당해야 하기 때문에 리소스를 공유하는 Pooled 방식보다 비용 측면에서는 아쉬운 점이 있습니다.
반면 Pooled Isolation 전략은 Tenant간 리소스를 공유한다는 특징이 있는데, 이 특징으로 인해 비용 측면과 관리 측면에서 보다 간편하다는 장점이 있습니다.
하지만 리소스를 공유하기 때문에 발생하는 문제도 있습니다. 대표적인 문제가 위에서 설명한 Noisy Neighbor(리소스를 유독 많이 점유하는; 말 그대로 시끄러운 이웃) 이슈가 있는데요. 환경을 공유한다는 특징 때문에 여러 문제가 발생할 수 있습니다.
저희는 Silo와 Pooled Isolation 전략 중 어느 하나의 전략을 전체 아키텍쳐에 적용하는 것이 아니라 상황에 따라 두 전략을 모두 적절하게 적용하는 게 맞다고 판단했습니다.
예컨대 고객 데이터 중 절대로 공유하면 안 되는 데이터는 무조건 별도의 DB Instance에서 격리가 되어야 한다고 생각했고, 모든 Tenant가 공통으로 사용하는 정적 리소스를 담는 Storage는 공유해도 상관 없다고 생각했습니다.
또한 저희 STCLab의 Application인 NetFUNNEL은 서비스의 비즈니스적 특성상 특정 트래픽이 몰렸을 때 가상 대기실을 운영해 트래픽을 관리하는 목적이 크므로, 일정 부분 tps(transcation per second)를 보장해줘야 한다는 요건이 있어 Computing 리소스 또한 격리되는 것이 맞다고 판단했습니다.
이렇게 리소스에 대한 공유 정책을 세워놓고 보니, 지향하는 바는 Silo Isolation에 가깝다고 판단이 되었습니다.
그렇다면 결국 “하나의 Tenant는 AWS의 어떤 단위로 매칭할 수 있을까? Silo Level은 어떤 것이 있을까?” 같은 질문들이 생겼고, AWS에서는 여러 Silo Level을 제시하고 있었습니다.
- Account-level Silo Strategy
Account-level Silo Strategy; Figure6-Account-based Silo and Isolation, SaaS Tenant Isolation Strategies
- VPC-level Silo Strategy
VPC-level Silo Strategy, Figure7-VPC Silo Isolation, SaaS Tenant Isolation Strategies
- Subnet-level Silo Strategy
Subnet-level Silo Strategy; Figure8-Subnet Silo Isolation, SaaS Tenant Isolation Strategies
1. Account-level Silo
Account 레벨의 Silo는 저희가 가장 먼저 검토하고 가장 빠르게 시도할 수 있는 선택지라고 생각했습니다.
AWS의 Account별 1개의 Tenant를 구축하고 관리하는 것입니다. 이 방식은 여러모로 장점이 있다고 생각했는데, 가장 큰 장점은 AWS의 Resource Quota(할당량) 정책에서 보다 자유롭다는 점입니다.
AWS에서는 한 계정에서 생성할 수 있는 리소스의 할당량을 Quota 정책으로 운영하고 있습니다. 예컨대 VPC는 특정 Region에서 최대 5개까지 생성할 수 있습니다. 이러한 리소스 Quota는 결국 장기적으로는 Tenant의 확장에 걸림돌이 될 수 있겠다는 생각을 했습니다.
하지만 이 방식은 Tenant 관리가 곧 AWS Account 관리라는 의미입니다. Tenant의 생성, 삭제, 보존 등과 같은 Life Cycle에 맞춰 Account의 Life Cycle을 관리해야 한다는 큰 태스크가 있습니다. 결국 다른 방식을 찾아야 했습니다.
ref: Service Endpoints and Quotas,
Service endpoints and quotas — AWS General Reference
2. VPC-level Silo, Subnet-level Silo
VPC(Virtual Private Cloud) 혹은 Subnet 단위의 Silo 방식은 Network 리소스 레벨로 Tenant를 격리하고자 하는 전략입니다. VPC는 AWS에서 운영하는 폐쇄형 가상 네트워크이고, Subnet은 하나의 VPC 내부에서 나뉘는 세부적인 IP 대역을 의미합니다.
폐쇄형 가상 네트워크라는 점에서 VPC-level이 갖는 장점은 명확한데요. 바로 네트워크 수준으로 격리를 하기 때문에 다른 Tenant 간의 보안이 확실하다는 강점이 있습니다. 보안성이 특히 중요한 고객 데이터의 경우, 그리고 고객이 Tenant 인프라에 직접 접근 제어 권한을 가질 수 있는 경우엔 이같은 네트워크 수준의 격리가 필요할 수 있겠다고 생각했습니다.
3. Instance-level Silo
Instance-level Silo는 명시적으로 참고 문헌에서 언급하고 있지는 않지만 하나의 VPC에서 Instance 레벨로 Tenant를 격리하고자 하는 전략입니다. 보안 측면에서 하나의 Instance는 다른 Instance에 대한 액세스 접근 권한을 제어할 수 있습니다. 예컨대 Security Group(보안 그룹)을 설정해서 Inbound Traffic을 기본적으로 제어할 수 있는데, 가장 간편한 방법으로 많이 사용되고 있습니다.
저희는 관리의 용이성이 크고, 가장 빠르게 해볼 수 있는 접근으로 Tenant를 Instance level로 구분짓기로 하고, 이를 기반으로 아키텍처를 설계해 보았습니다.
저희는 먼저 추상적인 레벨에서 다음과 같은 아키텍처를 설계했습니다.
전체 아키텍처는 크게 AWS의 4단계의 Layer(Surffy Client, Surffy Service, Infra, AWS Service)로 구성되어 있습니다.
먼저 Surffy Client는 고객용 Client인 Customer Client, 그리고 고객의 End User가 활용하는 End-user Client가 있습니다. Customer Client는 자사의 서비스를 활용하는 B2B 고객들을 위한 Client로서, 예컨대 ‘xx 쇼핑몰’을 운영하는 IT 관리자를 위한 Client Application이라고 할 수 있습니다.
반면에 End-user Client는 그 해당 ‘xx 쇼핑몰’의 쇼핑몰 고객용 Application입니다. 이 End-user Client에 심어진 자사의 Surffy Agent가 실제로 해당 쇼핑몰 전용의 Tenant 서버와 통신을 주고 받으며 Surffy 서비스를 이용하게 되는 것입니다. 그 외에는 전반적인 우리 Surffy 시스템을 관리할 시스템 관리자 혹은 어플리케이션 관리자가 활용할 Admin Client가 있을 것입니다.
이러한 Client들은 Surffy Service Layer에 있는 각종 서비스들을 활용하게 될 것입니다.
크게 Core Service 그리고 Tenant Service로 나뉘게 될텐데요.
Tenant Service는 말 그대로 고객이 활용하는 고객 전용 환경에서 제공되는 STCLab의 주력 서비스를 의미합니다. NetFUNNEL, Data Surfer 등 저희의 주력 제품과 제품의 각종 설정, 모니터링 데이터 그리고 분석 기능을 담당하는 Tenant Common 기능으로 이루어져 있습니다.
Core Service는 그러한 Tenant들을 관리하는 기능을 포함해, 조직이나 사용자, 제품과 상품, 결제와 청구, 수집과 측정, 분석 등을 의미합니다. 그리고 STCLab의 Surffy(SaaS 공통 서비스)가 이 서비스들을 포함한다고 보시면 됩니다.
Core 서비스 중 가장 중요한 서비스는 바로 Tenant Management 서비스일 것입니다. 여기서 XX Management란 XX이라는 리소스의 상태를 관리(생성, 수정, 삭제)하는 기능을 내포하는데, Multi-tenant SaaS Application에서 중요한 부분이 바로 고객의 요구사항에 맞춰 Tenant의 상태를 관리하는 것입니다. (On-demand, Self-Service 요건)
특징적으로, Tenant 관리 서비스 내부 구현체는 CSP에 종속적일 것입니다. 위 그림(추상 레벨의 Overall Arcitecture by Surffy)을 보시면, 맨 아래 AWS Service는 우리의 CSP가 AWS이기 때문에 그러한 CSP 측에서 제공하는 다양한 서비스들을 활용해 Tenant 관리를 해야 할 것입니다.
위의 추상적인 전체 아키텍처를 실제 AWS 상의 각종 인프라 리소스 단위를 기준으로 구현해 최종적으로 표현할 수 있었습니다.
저희는 Core 서비스와 Tenant 서비스를 위한 workload를 AWS Account 기준으로 크게 분리했습니다. Tenant들만의 환경을 account로 따로 grouping하여 tenant group을 관리하고자 하였으며, 이는 추후에 tenant group 단위의 격리 기준(tier 구분 같은)이 필요할 때를 대비한 것입니다.
그리고 위에서 언급한 것처럼, 1개의 VPC에서 tenant들을 Instance-level로 묶어 표현한 것을 볼 수 있습니다. 또한 Tenant #1과 Tenant #2는 보안 그룹을 이용해 격리 정책을 만들어, 각각의 인스턴스가 다른 Tenant의 인스턴스에 접근할 수 없도록 하였습니다.
현재 버전의 아키텍처에서는 Tenant 간의 리소스 공유를 최소화하고 있는데, 그 이유는 가상 대기실 서비스의 특성 상 부하가 많이 걸리는 고객들을 위해서는 성능이 보장된 dedicated된 workload가 필요하다고 생각했기 때문입니다.
즉, Noisy Neighbor를 최소화하기를 희망했습니다. 추후 저희 시스템의 운영 비용을 최소화하기 위해서, 공유 리소스와 Noisy Neighbor를 용인할 수 있는 일부 Tier에서는 공유 리소스 정책을 추진하는 것도 Future Work로 고려하고 있습니다.
Core 환경
Core 환경의 핵심인 WAS와 DB는 각각 EC2, RDS를 활용했습니다. EC2는 ALB(Application Load Balancer)를 활용하여 부하 분산을 하고, RDS는 Active-Stanby 기능을 활용하기 위해 이중화 구성을 하였습니다. RDS는 AWS 인스턴스 중에서도 가격이 제일 많이 나가는 서비스인데, 이중화 구성, 보안, 백업 등 DB를 운영하면서 발생할 수 있는 각종 문제들을 예방 관리하고 있어 안전성을 우선한다면 RDS를 쓰는 것을 추천합니다.
Client Application의 경우에는 Cloudfront와 S3를 활용하여 정적 리소스로 배포하고 있습니다. Cloudfront는 일종의 CDN 서비스이고, S3는 Object Storage입니다. 그 둘의 조합으로 AWS에서는 정적 리소스를 유저에게 매우 빠르게 delivery할 수 있습니다. 이용자가 surffy 도메인에 접속하면 Cloudfront에 캐싱된 리소스를 확인하고 가져오게 됩니다. Cloudfront는 원본 origin server(여기에선 S3)의 리소스에 변동이 있으면 오리진 서버로부터 리소스를 가져와서 제공하고, 변동이 없다면 클라이언트에게 캐싱하고 있는 리소스를 빠르게 제공합니다. 물론, Node.js Runtime 서버를 EC2 인스턴스에 구현하여 해당 React App을 Serving해도 되지만 S3와 같은 object storage에 정적 리소스로 담아서 활용하면 인스턴스 비용을 절감할 수 있어 더 장점이 많다고 생각했습니다.
또한 AWS에서는 Cognito라고 하는 Auth 서비스를 제공하고 있습니다. User Pool, Identity Pool 등을 만들어서 관리하는 기능을 제공하는 서비스인데, 인증 및 인가를 위한 Token 관리를 Java Logic 상에서 따로 구현할 필요 없이 가볍게 활용할 수 있었습니다. Client가 발급 받은 Token을 검증(verification)하는 로직은 구현을 해야 하지만, 그 외의 것들은 신경 쓰지 않고 비즈니스 로직 개발에만 집중할 수 있어서 매우 편리하다고 생각합니다.
Tenant 환경
Tenant 환경은 크게 NLB(Network Load Balancer), Netfunnel 서버, Tenant API 서버, 그리고 DBMS로 이루어져 있습니다. Netfunnel 서버는 End-user Client에 내장된 Surffy Agent의 가상 대기실 관련 요청을 처리하는 역할을 수행합니다. 반면에 그 이외 DB I/O 작업에 관련된 비즈니스 서비스는 Tenant API가 담당하게 됩니다. 이들 모두는 하나의 End-point로 노출하기 위해 Load Balancer를 앞단에 배치시켰는데요. 저희는 L7 Layer에서의 Routing 기능(Path, Caller IP, Request Header 등에 의한 Forwarding Rule 지정 기능)까지는 필요하지 않다고 판단하여 보다 빠른 Network Load Balancer를 활용하게 되었습니다.
나가며
STCLab의 Surffy SaaS App을 설계 및 구축하면서 배우고 느낀 Multi-tenant SaaS 아키텍쳐에 대해 개괄적으로 설명드렸는데요.
이번 SaaS 아키텍처 설계 작업에 많은 도움을 주신 AWS 관계자분들, 특히 SaaS Center와 ISV 파트너 팀께 감사의 인사를 드리고 싶습니다.
7월 20–21일 양일간 진행되었던 AWS SaaS Academy Workshop이 많은 도움이 되었는데요. SaaS에 대한 개념과 이를 구축하기 위해 고려해야 하는 설계 포인트를 꼼꼼하게 챙길 수 있었습니다. 특히 SaaS 컨설팅 경험이 풍부하신 전문 Architect님들, 그리고 비슷한 목적을 가진 다른 기업 관계자분들 간에 서로 정보를 공유할 수 있었던 네트워킹도 무척 좋았습니다.
Multi-tenant SaaS에 대한 개념과 그것을 위한 조건, Isolation 전략 등 Multi-Tenant App을 설계하기 위한 개념들을 설명했고, 추상적인 레벨에서의 서비스 아키텍처와 이를 구현하기 위한 AWS 상의 구현 레벨의 아키텍처를 소개하였습니다.
설계상 아직 반영되어야 할 것이 더욱 많습니다. 많은 설계안을 하나의 그림 안에 표현하기보다는 전체를 개괄하는 총론이라고 생각해주시면 감사하겠습니다.
다음 포스팅에선 Core 서비스에서 각각의 서비스 기능들이 어떻게 아키텍처 상에 반영되는지, 어떻게 구현했는지에 대해 자세하게 풀어보겠습니다.
감사합니다.
Published by STCLab R&D Technical writer, Janghyun lee
