by
Mar 30. 2022
Virtual Private Cloud
퍼블릭 클라우드 플랫폼 프로덕트 매니지먼트 (01)
클라우드 프로덕트에서 중요한 멀티테넌시
퍼블릭 클라우드 플랫폼에서 멀티테넌시(Multi-Tenancy)를 이야기 할 때는 아래 세 가지 케이스를 구분할 필요가 있다. 프로덕트를 기획하거나 고객을 대할 때 신경써야 할 포인트가 조금씩(...!?) 다르다.
1. CSP 사업자 입장에서 철저한 리소스 보안은 물론, 사업적 측면에서 규모의 경제를 달성하기 위해, 안전하고 유연하며 성능 좋은 멀티테넌트 환경을 고객에게 제공해야 한다. CSP 사업의 근본 조건이다.
2. CSP가 제공하는 퍼블릭 클라우드 위에 SaaS를 구축하고자 하는 솔루션 사업자 입장에서, 자사의 애플리케이션을 멀티테넌트 아키텍처로 만드는 것은 (물론 당연히) 필수이다. 다만 기존 온프레미스 환경에 설치형 소프트웨어를 제공하던 사업자들에게 멀티테넌트 아키텍처로의 전환은 소프트웨어 전체를 엎어야 하는 과제가 될 수 있다. 글로벌 CSP들은 SaaS 사업자를 위한 Well-Architected Framework나 구현 지침을 제공하고 있는데, 개중에서도 뭐든지 하여튼 Azure가 정리를 참 잘 해 두었다. 물론 적용의 고통은 별개...
3. 엔터프라이즈 규모의 고객이 인프라 및 통합 개발환경을 퍼블릭 클라우드로 이전하고자 할 때, 자사의 디지털 운영 환경과 정책에 따라 멀티테넌트 환경을 구성해야 할 수 있다. (물론 엔터프라이즈에서 SaaS를 도입할 때도 같은 과제가 있다.) 이때 테넌트란 고객 기업 내 임직원 조직을 임의로 구분한 것을 말한다. 고객은 퍼블릭 클라우드에서 제공하는 거버넌스 관리 서비스들을 이리저리 조합하여 최적의 테넌트 환경을 구성해야 한다.
멀티테넌시 전략을 짤 때는 1) 관리하는 서비스와 조직의 범위(테넌트 정의), 2) 빌링 추적 및 최적화와 같은 관리 용이성, 3) 리소스, 테넌트, 인터넷 간 보안 정책, 4) 일관된 CI/CD나 협업과 같은 운영 편의 등을 다각도로 검토해야 한다.
퍼블릭 클라우드에서 제공하는 서비스를 조합하여 테넌트 정책을 구성할 때는, 계정(Account), 조직(Organization), 프로젝트 등 리소스 그룹, IAM 정책, 빌링 태그 등 가입과 초기 환경설정 단계에서부터 기본적인 고민거리가 많이 생기기 때문에 Solution Architect들의 주도면밀한 컨설팅이 필요하다고 본다. 그렇지만 개인적으로는 사용자 쪽에서 Virtual Private Cloud에 대한 이해를 높이고 스마트하게 사용할 줄 아는 것이 플랫폼으로서의 퍼블릭 클라우드빨을 잘 받는 기본인 듯 하다. 계정을 하나 더 만드는 건 처음엔 쉽지만 나중에는 최악의 선택이 될 수도 있다.
(쓰레드는 다소 짧고 가볍지만, 레딧에서도 멀티테넌트 접근 방식에 대해 오간 얘기가 있다.)
Virtual Private Cloud
VPC는 사용자가 직접 정의하여 만드는 가상화된 사설 네트워크이다. 모든 글로벌 CSP에서 제공하고, 네이버 클라우드도 2021년 9월에 VPC 서비스를 첫 릴리즈 했다. Azure에서는 Virtual Network라는 이름을 사용한다. CSP간 약간씩 서비스 차이가 있지만 AWS 기준으로는 대략 아래 도식도의 구성을 하고 있다.
VPC간, VPC와 고객 Site간에 더 많은 연결 방법이 제공되지만, 그림 그리기가 너무 복잡하므로 TGW로 퉁쳐보도록 하자오브젝트가 많아보이지만 기본 컨셉은 간단(...)하다.
1) 완전히 독립된 네트워크 공간을 만든다.
2) 독립된 네트워크 간 상호 보안적 통신을 할 수 있도록 인터페이스 모듈을 조립한다.
3) 조립한 모듈에 규칙을 설정하고 격리된 네트워크끼리 패킷이 잘 주고 받아지는지 본다.
조립 모듈은 아래 유형만 잘 구분해서 기억해두면 나머지는 따라온다.
게이트웨이 3종인 인터넷 게이트웨이(IGW), NAT 게이트웨이(NGW), 트랜짓 게이트웨이(TGW)
서브넷, 라우팅 테이블, 엘라스틱 IP
보안그룹 2종인 네트워크 ACL(NACL), 시큐리티 그룹
그리고 VPC 모듈은 아니지만 로드밸런서
서비스 이름이 VPC인 만큼 추상화의 기준이 되는 단위도 VPC다. VPC 내부적으로는 서브넷과 인스턴스 리소스끼리의 통신을, VPC 바깥쪽으로는 다른 리전과 계정, 외부 DC간의 통신을 설정한다. 모두 인터페이스 조립과 규칙 설정을 통해 이루어진다. 하나의 VPC는 큰 사설 CIDR 대역을 차지하는 네트워크 한 판에 해당한다. 그 안에 서로 중복되지 않는 더 작은 CIDR 대역으로 퍼블릭 타입 서브넷과 프라이빗 타입 서브넷을 나눈 뒤 서비스 목적에 따라 리소스를 배포한다.
퍼블릭 서브넷 위에 있는 리소스가 인터넷을 통해 외부와 패킷을 주고받으려면 1) 인터넷 게이트웨이 설정, 2) 라우팅 테이블 설정, 3) 네트워크 ACL 설정, 4) 시큐리티 그룹 설정, 5) 엘라스틱 IP 설정까지 마친 후, 3~4번의 보안 그룹에서 허용할 IP/포트와 인바운드/아웃바운드 규칙을 설정해주어야 한다. 프라이빗 서브넷은 NAT 게이트웨이를 통해 제한적으로 아웃바운드를 허용하여 보안을 강화한다. NAT 게이트웨이는 AWS VPC에서 마치 퍼블릭 서브넷 위 하나의 인스턴스로 구성된 모양을 하고 있지만, 왜 이렇게 구성했는지는 좀 파악이 필요하다.
다른 리전, 다른 계정의 VPC와의 프라이빗 통신, 그리고 완전한 외부 데이터센터와의 프라이빗 통신은 요즘 트랜짓 게이트웨이 인터페이스를 밀고 있는 듯 하다. 기존 VPC 피어링 기능으로도 다른 리전/계정의 VPC간 통신을 할 수 있지만, 두 VPC간 연결만 가능하다. 반면에 트랜짓 게이트웨이는 거대 클라우드 간 라우터라는 컨셉으로 N개 VPC와 온프레미스간 통신을 지원한다. 그러나 TGW로 멀티테넌시 환경을 구성하는 정도가 되면 디지털 트랜스포메이션에 상당한 진전을 이루었...
누가 얼마나 스마트해져야 할까?
나도 직관적이고 추상화된 서비스를 좋아하는 기획자이지만, AWS의 VPC 인터페이스에 익숙해지고 보면 약간이라도 생략되고 추상화된 네트워크 서비스는 확실히 좀 불안하다. 멀티테넌시는 보안이 핵심이고 보안에는 예외를 둘 수가 없다. 물론 Low-Level 모듈을 잔뜩 늘어놓고 사용자에게 책임을 위임하는 CSP 서비스가 무시무시한건 맞지만, 네트워크와 인프라 레벨은 꼭 퍼블릭 클라우드가 아니더라도 어플리케이션 기획자나 개발자에게 진입장벽이 높다. 그리하여 비록 엔지니어들끼리 아래와 같은 논쟁이 있다 하더라도...
