SaaS 길라잡이

테넌트: B2B 비즈니스(고객사) / B2C (소프트웨어 최종 사용자) / SaaS 설계 (테넌트 인증/로깅)
SaaS 테넌트별 소비 패턴 파악(사용량 기반 SaaS 비즈니스 핵심)
컨테이너: 리소스 효율 (비용 효율성) 관리형 서비스(EKS): 관리 부담을 낮추면서 고가용성 및 높은 확장성 제공
매니지드 워커 노드 + 파게이트 등 옵션을 더하면서 관리의 부담 경감시키는 장점
테넌트 간 환경을 공유하면서 인프라 활용도를 높이는 구조를 가져감
테넌트를 나누는 주된 요인
- SaaS 멀티테넌트는 한 회사의 여러 팀이 가지는 멀티 테넌트와 비교해본다면 각 테넌트가 서로 다른 이해 조직
-> 첫번째 고려사항 보안 / 컴플라이언스(A테넌트의 데이터가 B에게 노출된다면 SaaS 솔루션의 신뢰성을 심각하게 훼손)-보안 규정 및 준수
-> 리소스를 여러 테넌트에게 공정하게 분배(특정 테넌트가 공유 환경의 CPU, 메모리, 네트워크 등을 과도하게 소진)
-> SaaS 애플리케이션에 전반적인 성능 영향을 주는 것을 원하지 않음(리소스의 고른 분배)

SaaS 비즈니스 전략 -> 프리미엄 / 베이직 등 티어별로 요금제 구분하는 것을 대부분 고려함(티어링 전략)-부가기능 제공, 유지보수 

풀 모델과 사일로 모델
테넌트 분리 : 공유 모델 / 단독 모델 / 혼합 모델 (공유 + 단독)
EKS 환경 대입
공유(Pool) 모델: 단일 클러스터를 여러 테넌트가 공유, 리소스 비용이나 운영 효율성 면에서 유리
단독(Silo) 모델: 테넌트마다 고유한 EKS 클러스터를 생성하는 것은 비용 부담과 운영의 복잡성을 높이지만, 
여전히 다른 테넌트로부터의 보안 위협이나 리소스 소진의 영향을 최소화할 수 있는 가장 안전한 방법
모델을 선택하는 것은 양자택일의 문제라기보다는 티어링으로 접근할수도 있을 것
스탠다드 이하 요금제 - 공유 클러스터 / 프리미엄 단독 클러스터 수준의 보안, 가용성, 성능 제공하는 식의 구성도 가능

SaaS 아키텍팅은 비즈니스 목적에 따라, 어떻게 기술을 적용할 것인지 정해 나가는 과정

클러스터 공유하는 모델 중심(규모의 경제)
네임스페이스: 클러스터를 논리적으로 나눌 수 있게 해주면서도 멀티테넌시를 구현하기 위해 유용한 구성 요소들을 네임스페이스 범위로 가짐
공유모델이라고 해도 여전히 클러스터 내에서 테넌트 간 보안을 위한 격리 / 리소스 분배, 티어에 따른 차별화된 경험 중요
구성요소
1. 테넌트 간 안전한 네트워크 통신 제어를 위한 네트워크 정책 
2. 권한을 부여하는 기준이 되는 서비스 어카운트
3. 테넌트별 리소스 할당량을 정의할 수 있는 리소스 쿼터 등이 있음

네임스페이스를 이용한 테넌트 분리
쿠버네티스는 클러스터 내 모든 파드들은 원래 제한 없이 통신이 가능
But 멀티테넌트 환경에서는 테넌트 간 엄격한 네트워크 격리가 필수 !!
1. 쿠버네티스 네트워크 정책을 적용
- 파드 셀렉터, 레이블, IP범위, 포트 번호를 이용해 OSI 레이어 3~4 계층에서 파드 간 통신을 제한 
- 네트워크 정책은 꼭 필요하지만 어떤면에서는 충분치 않다고 느낄수 있음
-> 이를 보완하기 위해 티게라 캘리코나 실리움 등의 플러그인 고려해볼 수 있음
- 인그레스, 이그레스를 동시에 제약을 걸어야 한다거나 룰의 순서를 지정하는 등 더 구체적인 정책 지정하고 네임스페이스의 범위를 넘어선 글로벌 네트워크 정책이 
있으면 일관된 관리가 가능하다거나 Istio나 AWS App Mesh 등 서비스 메시와 통합하여 7계층 수준의 보안 정책이 필요한 경우에 유용  

 

참고자료: Amazon EKS 기반 멀티테넌트 SaaS 길라잡이 - 김지민 솔루션즈 아키텍트, AWS :: AWS Summit Korea 2022