이 페이지에서는 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를 갖도록 구성할 수 있습니다.
비용 효율성
- Scale-to-zero 및 사용량 기반 요금제: Cloud Run 인스턴스는 사용하지 않을 때 자동으로 0으로 확장되므로 호스팅된 워크로드가 실행되어야 할 때만 요금이 청구됩니다. '상시 사용 설정' 가상 머신을 활용하는 아키텍처에 비해 매우 효율적인 리소스 사용이 가능합니다.
- 요청별 청구: 0으로 확장하는 것 외에도 요청이 처리될 때만 청구되는 더욱 세분화된 청구 모델을 활용하여 비용 효율성을 더욱 높일 수 있습니다.
- 주문형 및 빠른 시작: 축소된 경우 Cloud Run 서비스는 빠르게 다시 확장될 수 있으므로 배포된 애플리케이션의 최종 사용자가 인식하는 지연 시간이 거의 없습니다.
- 자동 비용 라벨 지정: Cloud Run에서 보고하는 모든 비용에 라벨이 지정되므로 비용 기여도 분석 및 테넌트 추적을 자동화할 수 있습니다.
- 총비용 절감을 위한 약정: 결제 계정 수준에서 가변형 약정 사용 할인을 사용하여 기준 Cloud Run 사용량의 지출을 최적화할 수 있습니다.
테넌트 관리
Cloud Run은 주문형이므로 여러 Google Cloud 프로젝트를 사용해도 비용이 높아지지 않아 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 는 프로젝트 전반에서 모니터링 및 로깅 작업을 수행하며 전체 기기를 모니터링할 수 있습니다.
- 프로젝트 수준 할당량을 사용하면 특정 테넌트의 Cloud Run 리소스 사용량을 제한하여 자체 가격 책정 등급에 맞게 한도를 조정할 수 있습니다.
- 커스텀 조직 정책을 사용하면 사용 가능한 리전 또는 최대 CPU/메모리 할당과 같은 폴더의 특정 제한사항을 모든 프로젝트에 적용할 수 있습니다.
Google Cloud 프로젝트를 만들고 API와 리소스를 초기화하는 데 지연 시간이 발생할 수 있으므로 필요할 때 테넌트에 할당하는 사전 생성된 프로젝트 풀을 사용하는 것이 좋습니다.
Google Cloud 프로젝트당 여러 테넌트 (권장되지 않음)
동일한 Google Cloud프로젝트에 여러 테넌트를 호스팅할 수 있지만 Google에서는 이 아키텍처를 권장하지 않습니다.
많은 Google Cloud 서비스에는 프로젝트별 리소스 한도가 있습니다. 예를 들어 Cloud Run에는 프로젝트의 리전당 Cloud Run 서비스가 1,000개로 조정할 수 없는 제한이 있습니다. 따라서 프로젝트당 여러 테넌트를 호스팅하려면 여전히 Google Cloud 프로젝트를 관리해야 하므로 전체적으로 테넌트 관리 복잡성이 증가합니다. 보안 관점에서Google Cloud 프로젝트는 보안 경계로 설계되어 있으므로 동일한 프로젝트에서 두 개의 서로 다른 테넌트를 호스팅하는 경우 보안에 더욱 주의해야 합니다. 예를 들어 전용 서비스 계정과 세부적인 권한을 사용하여
요청 라우팅 및 커스텀 도메인
테넌트의 Cloud Run 서비스를 최종 사용자에게 노출하려면 자체 도메인을 추가하고 자체 라우팅 로직을 사용해야 합니다. 예를 들어 테넌트의 서비스를 호스팅하는 Google Cloud 프로젝트에 하위 도메인을 매핑합니다.
맞춤 라우팅 서비스를 구현할 수 있지만, 라우팅 로직에는 서비스 확장 프로그램이 있는 전역 외부 애플리케이션 부하 분산기를 사용하는 것이 좋습니다. 서비스 확장 프로그램은 플러그인(로직이 요청 처리와 함께 인라인으로 실행됨) 또는 콜아웃(라우팅 로직이Google Cloud의 확장 가능한 다중 리전 데이터베이스(예: Spanner) 중 하나를 호출할 수 있는 별도의 Cloud Run 서비스에 위임됨)으로 구현할 수 있습니다.
애플리케이션 부하 분산기를 사용하면 Cloud CDN을 활용하여 캐싱 레이어를 추가하고 Cloud Armor를 사용하여 플랫폼에 추가 DDoS 공격 보호를 추가할 수도 있습니다.
평판 및 악용
신뢰할 수 없는 코드를 실행할 수 있는 호스팅 플랫폼은 악용될 수 있습니다.
제공하는 평판 등급마다 다른 Cloud Billing 계정을 사용하는 것이 좋습니다. 예를 들어 무료 등급 테넌트는 고액 지불 고객과 동일한 결제 계정에 연결하면 안 됩니다. Google은 이러한 청구 계정을 다양한 평판 수준에서 고려할 수 있습니다.
Google Cloud 프로젝트 구성에 설명된 대로 결제 계정별로 구분하는 것 외에도 폴더를 사용하여 프로젝트를 구성해야 합니다. Google에서는 폴더 내 모든 리소스가 설정된 최댓값을 초과하지 않도록 폴더 수준 할당량을 설정하여 플랫폼 비용을 더 효과적으로 관리할 수 있도록 지원합니다.
기본적으로 Google은 Google Cloud 서비스 약관에 따라 악용 워크로드를 자동으로 삭제합니다. 또한 Google은 Cloud Logging에 악용 감지 이벤트를 기록할 수 있으며, 사용자는 이에 따라 조치를 취할 수 있습니다.