이 페이지에서는 Cloud Run을 사용하여 신뢰할 수 없는 코드를 호스팅하는 멀티 테넌트 아키텍처를 만들기 위한 권장사항을 제공합니다. Google Cloud 고객으로서 '테넌트'는 자체 고객 중 하나로 정의되고 '신뢰할 수 없는 코드'는 플랫폼에서 실행하기 위해 이러한 테넌트가 제공하는 코드입니다.
사용 사례
이러한 아키텍처의 사용 사례는 다음과 같습니다.
- 앱 호스팅 플랫폼: 고객이 코드를 배포하는 플랫폼을 제공합니다. 예를 들어 웹 호스팅 플랫폼 (고객이 웹 서버 제공) 또는 Functions-as-a-Service 플랫폼 (고객이 함수 제공)이 있습니다.
- 에이전트 호스팅 플랫폼: 고객이 SDK를 사용하여 AI 에이전트를 빌드하고 플랫폼이 백그라운드에서 이를 실행합니다.
- 미세 조정된 모델 플랫폼: 고객별로 AI 모델을 맞춤설정하는 기능을 제공합니다. 그런 다음 플랫폼에서 GPU를 활용하여 주문형으로 실행합니다.
- 사용자 정의 함수: 소프트웨어를 통해 고객이 코드를 사용하여 커스텀 로직을 정의할 수 있습니다. 예를 들어 분석 엔진을 제공하고 고객이 커스텀 함수를 작성하도록 허용하거나 API 게이트웨이를 제공하고 고객이 자체 커스텀 로직에 따라 요청을 필터링하거나 변형하도록 허용할 수 있습니다.
- Software as a Service (SaaS) 확장성: SaaS를 제공하고 고객이 확장 프로그램을 사용하여 기능을 확장하도록 허용할 수 있습니다. 이러한 확장 프로그램은 고객 또는 파트너가 작성할 수 있습니다.
Google Cloud 고객은 이러한 사용 사례를 위해 프로덕션에서 Cloud Run을 성공적으로 사용하고 있습니다.
멀티 테넌트 플랫폼의 과제
이러한 아키텍처를 만들 때 발생하는 일반적인 문제는 다음과 같습니다.
- 보안: 제공된 코드를 스캔하거나 정제할 수 없습니다. 신뢰할 수 없는 코드에는 악의적인 작업이나 취약한 종속 항목이 포함될 수 있습니다. 적절하게 격리되지 않으면 신뢰할 수 없는 코드가 다른 테넌트에 속한 민감한 정보에 액세스할 수 있습니다. 컨테이너에 코드를 패키징하는 것만으로는 보안 경계가 충분히 강력하지 않습니다. 또한 최소 권한의 원칙을 적용하여 코드가 수행할 수 있는 작업을 제한해야 합니다.
- 비용 효율성: 각 테넌트가 플랫폼에 고정 비용을 발생시키는 경우 이러한 아키텍처는 비용이 많이 들 수 있습니다.
- 테넌트 관리: 수십만 명의 테넌트를 관리하는 것은 특히 데이터 삭제와 관련하여 어려울 수 있습니다.
Cloud Run의 장점
Cloud Run 기반 아키텍처는 보안, 비용 효율성, 테넌트 관리와 같은 많은 이점을 제공하는 일반적인 과제에 대한 솔루션을 제공합니다.
보안
Cloud Run은 이 아키텍처와 관련된 즉시 사용 가능한 보안 기능을 제공합니다.
- 컴퓨팅 격리: Cloud Run은 동일한 서비스의 컨테이너 인스턴스 또는 다른 프로젝트의 다른 서비스의 컨테이너 인스턴스 간에 엄격한 격리를 보장합니다. 컨테이너 보안 및 실행 환경에 대한 자세한 내용은 보안 설계 개요를 참조하세요.
- 보안 업데이트: 대규모 재배포 없이 배포된 워크로드의 운영체제와 런타임을 최신 상태로 유지하고 패치를 적용하기 위해 기본 이미지의 자동 보안 업데이트를 사용 설정할 수 있습니다.
- 네트워크 격리: Cloud Run은 컨테이너를 샌드박스 처리할 뿐만 아니라 멀티 테넌트 네트워킹 스택도 제공합니다.
- 서비스 ID: Cloud Run 워크로드는 제한된 권한이 있는 전용 ID를 갖도록 구성할 수 있습니다.
비용 효율성
- 0으로 축소 및 사용한 만큼만 지불: Cloud Run 인스턴스는 사용하지 않을 때 자동으로 0으로 축소되므로 호스팅된 워크로드가 실행되어야 할 때만 요금이 청구됩니다. 따라서 '상시 사용' 가상 머신을 활용하는 아키텍처에 비해 리소스 사용률이 매우 높습니다.
- 요청당 청구: 0으로 축소하는 것 외에도 요청이 처리될 때만 요금이 청구되는 훨씬 더 세분화된 청구 모델을 활용하여 비용 효율성을 더욱 높일 수 있습니다.
- 주문형 및 빠른 시작: 축소 시 Cloud Run 서비스는 빠르게 다시 확장할 수 있으므로 배포된 애플리케이션의 최종 사용자가 지연 시간을 거의 인식하지 못합니다.
- 자동 비용 라벨 지정: Cloud Run에서 보고하는 모든 비용에 라벨이 지정되므로 테넌트의 비용 기여 분석 및 추적을 자동화할 수 있습니다.
- 총 비용 절감을 위한 약정: 결제 계정 수준에서 가변형 약정 사용 할인을 사용하여 기준 Cloud Run 사용량에 대한 지출을 최적화할 수 있습니다.
테넌트 관리
주문형 특성으로 인해 여러 Google Cloud 프로젝트를 사용할 때 Cloud Run 비용이 더 높지 않으므로 Google Cloud 프로젝트 구성에 설명된 대로 테넌트 관리가 가능합니다.
멀티 테넌트 플랫폼의 대상 아키텍처
개략적으로 권장되는 아키텍처는 다음과 같습니다.
Google Cloud 프로젝트 정리
Google Cloud 조직, 오프라인 결제를 설정하고 계정팀에 연락하여 리셀러 계정으로 활동하고 있음을 알려야 합니다.Google Cloud 는 악용 완화를 위한 적절한 커뮤니케이션 채널이 마련되도록 귀하와 협력할 수 있습니다.
폴더를 사용하여 Google Cloud 프로젝트를 구성해야 합니다. 특히 퍼스트 파티 코드를 실행하는 프로젝트를 테넌트의 신뢰할 수 없는 코드를 실행하는 프로젝트와 다른 폴더에 넣어야 합니다. 테넌트의 프로젝트와 리소스를 만들 때 휴먼인더루프가 필요하지 않도록 테넌트 온보딩을 자동화해야 합니다.
Google에서는 테넌트당 Google Cloud 프로젝트를 하나씩 사용하는 것을 권장합니다. 동일한 프로젝트에서 여러 테넌트를 호스팅할 수도 있지만 다음과 같은 추가 제한사항이 있습니다.
프로젝트당 Google Cloud 단일 테넌트 (권장)
이 아키텍처에서 플랫폼의 각 테넌트는 전용Google Cloud 프로젝트에서 호스팅되며, 여기에는 다음과 같은 여러 이점이 있습니다.
- 간단한 보안: Google Cloud 프로젝트는 포함된 모든 리소스에 대한 엄격한 경계입니다. 즉, 테넌트가 여러 Cloud Run 서비스, Cloud Storage 버킷과 같은 여러Google Cloud 리소스에 액세스해야 하는 경우 프로젝트를 보안 경계로 사용할 수 있습니다.
- 제한이 적음:
- 특정 프로젝트의 리소스 수는 제한되어 있습니다. 예를 들어 Cloud Run은 프로젝트에서 리전당 1,000개의 서비스만 만들 수 있습니다. 서비스 계정 수 및 기타 관련 리소스에도 유사한 한도가 있습니다.
- 프로젝트 수는 그 자체로 할당량이며 늘릴 수 있습니다. Google Cloud 조직의 경우 이 수에 제한이 없습니다. 결제 계정당 프로젝트 수에는 100,000개의 소프트 한도가 있으며, Google에 문의하여 이 한도를 늘릴 수 있습니다. 조직에서 여러 결제 계정을 만들고 '계정 그룹' (현재 비공개 프리뷰)으로 그룹화할 수도 있습니다.
- 더 간편한 모니터링 및 관리:
- 테넌트별로 프로젝트를 사용하면 데이터 삭제 프로세스가 더 쉬워집니다. 테넌트의 데이터를 삭제하면 해당 프로젝트가 삭제됩니다.
- Google Cloud Monitoring 및 Logging은 프로젝트 전반에서 작동하며 전체 Fleet을 모니터링할 수 있습니다.
- 프로젝트 수준 할당량을 사용하면 지정된 테넌트의 Cloud Run 리소스 사용률을 제한하여 자체 가격 책정 등급에 맞게 한도를 조정할 수 있습니다.
- 커스텀 조직 정책을 사용하면 사용 가능한 리전 또는 최대 CPU/메모리 할당과 같은 폴더의 특정 제한사항을 모든 프로젝트에 적용할 수 있습니다.
Google Cloud 프로젝트를 만들고 API 및 리소스를 초기화하면 지연 시간이 발생할 수 있으므로 필요할 때 테넌트에 할당하는 사전 생성된 프로젝트 풀을 사용하는 것이 좋습니다.
Google Cloud 프로젝트당 여러 테넌트 (권장하지 않음)
동일한 Google Cloud프로젝트에서 여러 테넌트를 호스팅할 수 있지만 Google에서는 이 아키텍처를 권장하지 않습니다.
많은 Google Cloud 서비스에는 프로젝트별 리소스 한도가 있습니다. 예를 들어 Cloud Run에는 프로젝트의 리전당 조정할 수 없는 Cloud Run 서비스 한도가 1,000개 있습니다. 따라서 프로젝트당 여러 테넌트를 호스팅하려면 여전히 Google Cloud 프로젝트의 Fleet을 관리해야 하므로 전반적으로 테넌트 관리 복잡성이 증가합니다. 보안 관점에서Google Cloud 프로젝트는 보안 경계로 설계되었으므로 동일한 프로젝트에서 두 개의 고유한 테넌트를 호스팅하려면 보안에 더 주의해야 합니다. 예를 들어 전용 서비스 계정과 세분화된 권한을 사용합니다.
여러 리전에 배포
안정성과 확장성을 위해 Google은 테넌트 배포를 여러 Google Cloud 리전에 분산하는 것을 권장합니다. 각 테넌트 애플리케이션은 단일 리전에 배포되지만 테넌트마다 다른 리전을 사용할 수 있습니다. 리전 선택은 무작위로 수행되거나 지연 시간을 최적화하기 위해 테넌트의 위치를 고려할 수 있습니다.
요청 라우팅 및 커스텀 도메인
테넌트의 Cloud Run 서비스를 최종 사용자에게 노출하려면 자체 도메인을 추가하고 자체 라우팅 로직을 사용해야 합니다. 예를 들어 하위 도메인을 테넌트의 서비스를 호스팅하는 Google Cloud 프로젝트에 매핑합니다.
커스텀 라우팅 서비스를 구현할 수 있지만 Google에서는 라우팅 로직에 Service Extensions와 함께 전역 외부 애플리케이션 부하 분산기를 사용하는 것이 좋습니다. 서비스 확장 프로그램은 플러그인 (로직이 요청 처리와 함께 인라인으로 실행됨) 또는 콜아웃 (라우팅 로직이 Spanner와 같은Google Cloud의 확장 가능한 멀티 리전 데이터베이스 중 하나를 호출할 수 있는 별도의 Cloud Run 서비스에 위임됨)으로 구현할 수 있습니다.
애플리케이션 부하 분산기를 사용하면 Cloud CDN을 활용하여 캐싱 레이어를 추가하고 Cloud Armor를 사용하여 플랫폼에 추가 DDoS 공격 보호를 추가할 수 있습니다.
평판 및 악용
신뢰할 수 없는 코드를 실행할 수 있는 호스팅 플랫폼은 악용될 수 있습니다.
제공하는 평판 등급마다 다른 Cloud Billing 계정을 사용하는 것이 좋습니다. 예를 들어 무료 등급 테넌트는 고액 유료 고객과 동일한 결제 계정에 연결되어서는 안 됩니다. Google은 이러한 결제 계정을 다양한 평판 수준으로 고려할 수 있습니다.
Google Cloud 프로젝트 구성에 설명된 대로 결제 계정별로 분리하는 것 외에도 폴더를 사용하여 프로젝트를 구성해야 합니다. Google은 폴더 내의 모든 리소스가 설정된 최댓값을 초과하여 소비하지 않도록 폴더 수준 할당량을 설정하여 플랫폼 비용을 더 효과적으로 관리할 수 있도록 지원합니다.
기본적으로 Google은 Google Cloud 서비스 약관에 따라 악용 워크로드를 자동으로 중단합니다. Google은 Cloud Logging에 악용 감지 이벤트를 로깅할 수도 있으며, 이를 통해 조치를 취할 수 있습니다.