이 문서는 다양한 컨테이너화된 워크로드 집합을 실행하고 Google Kubernetes Engine(GKE) 및 Cloud Run의 이점을 모두 활용하여 Google Cloud Platform에 애플리케이션을 배포하려는 인프라 관리자와 애플리케이션 운영자를 대상으로 합니다. 하이브리드 전략은 비용과 성능, 관리 오버헤드를 최적화할 수 있는 이점이 있습니다.
이 문서를 읽기 전에 다음 사항을 숙지해야 합니다.
스테이트리스(Stateless) 워크로드와 스테이트풀(Stateful) 워크로드
GKE와 Cloud Run을 함께 사용하는 이유는 무엇인가요?
GKE와 Cloud Run은 컨테이너화된 애플리케이션을 실행하는 데 있어서 서로 다른 이점을 제공하며 지원하는 워크로드 복잡성 수준도 서로 다릅니다. 하지만 두 플랫폼 중 하나만 선택할 필요는 없습니다. 필요에 따라 두 플랫폼 간에 워크로드를 마이그레이션하여 GKE와 Cloud Run의 장점을 동시에 활용할 수 있습니다.
두 런타임을 사용해서 워크로드를 배포할 때의 이점은 다음과 같습니다.
GKE와 Cloud Run은 비교적 높은 수준의 이식성을 제공합니다.
두 플랫폼 모두 표준 컨테이너 이미지를 배포 아티팩트로 사용합니다. 어느 플랫폼에서든 애플리케이션에 동일한 이미지를 수정 없이 사용할 수 있으므로, GKE와 Cloud Run 사이에 워크로드를 원활하게 마이그레이션할 수 있습니다. 컨테이너 이미지가 Artifact Registry에 저장되어 있는 한 GKE와 Cloud Run 사이의 마이그레이션을 위해 지속적 통합 설정을 업데이트할 필요가 없습니다.
GKE와 Cloud Run에는 둘 다 선언적 API 모델이 사용됩니다. Cloud Run Admin API v1은 Kubernetes API와 호환되도록 설계되었습니다. 즉, 배포, 서비스, 수평형 포드 자동 확장 처리와 같은 익숙한 Kubernetes 개념을 사용하여 Cloud Run 서비스를 마이그레이션할 수 있습니다. 이러한 유사성 덕분에 두 플랫폼 간에 구성을 쉽게 변환할 수 있습니다.
리소스는 YAML 파일로 동일한 선언 및 표준 구조를 사용해서 표현되며, 따라서 런타임 간에 쉽게 마이그레이션할 수 있습니다. Kubernetes 배포의 YAML 파일과 Cloud Run 서비스를 비교하는 예시는 다음과 같습니다.
GKE와 Cloud Run은 모두 Cloud Logging 및 Cloud Monitoring과 원활하게 통합되어 있으며, 플랫폼에 관계없이 애플리케이션 측정항목을 관측할 수 있는 Google Cloud 콘솔의 중앙 집중식 뷰를 제공합니다. 또한 두 플랫폼 모두에서 서비스 수준 목표(SLO) 모니터링을 사용하고 Cloud Monitoring 대시보드에서 SLO를 통합적으로 파악할 수 있습니다.
GKE 리소스 또는 Cloud Run 서비스에는 Cloud Deploy를 사용해서 지속적 배포를 구현할 수 있습니다. 또한 필요에 따라서는 동시 배포를 사용해서 GKE 및 Cloud Run 모두에 애플리케이션을 동시에 배포할 수 있습니다.
GKE 및 Cloud Run에서 서비스에 대해 외부 및 내부 부하 분산기를 사용하여 고급 트래픽 관리를 효율적으로 수행할 수 있습니다. 여기에는 두 플랫폼에서 동일한 애플리케이션에 대해 서로 다른 URL을 배포하고 실행할 수 있도록 외부 엔드포인트를 노출하는 기능이 포함됩니다. 또한 GKE와 Cloud Run에서 동일한 서비스에 대해 트래픽을 분할하여 한 플랫폼에서 다른 플랫폼으로 마이그레이션을 원활하게 지원할 수 있습니다.
Google Cloud는 두 런타임을 모두 사용할 때 보안 상황을 개선할 수 있는 보안 도구를 제공합니다. OS 스캔을 사용하면 어느 플랫폼이나 플랫폼에 배포하기 전에 컨테이너에서 취약점을 스캔할 수 있습니다. 중앙 Binary Authorization 정책을 사용하면 사용자가 정의한 정책에 따라 이미지 배포를 허용하거나 차단하도록 GKE 및 Cloud Run 제어 영역과의 통합을 강화할 수 있습니다. 보안 팀은 VPC 서비스 제어를 사용하여 GKE 및 Cloud Run 리소스 간에 미세 조정된 경계 제어를 정의할 수 있습니다.
GKE와 Cloud Run 비교
GKE와 Cloud Run의 최고 특성을 활용하고 이들 간에 언제 워크로드를 이동해야 하는지 알기 위해서는 두 서비스가 서로 어떻게 다른지 이해하는 것이 중요합니다.
| 특성 | GKE | Cloud Run |
|---|---|---|
| 배포 및 관리 | 노드 구성, 네트워킹, 확장, 업그레이드를 포함하여 Kubernetes 클러스터 관리를 수행합니다. Google Cloud는 기본 인프라를 관리하고 클러스터 운영을 간소화할 수 있는 도구를 제공하지만 핵심 Kubernetes 특성은 여전히 사용자가 관리해야 합니다. |
Google Cloud의 확장 가능한 인프라에서 직접 컨테이너를 실행합니다. 소스 코드와 컨테이너 이미지를 제공하면 Cloud Run이 컨테이너를 자동으로 빌드합니다. 클러스터를 만들거나 인프라를 프로비저닝 및 관리할 필요가 없습니다. |
| 제어 및 유연성 | Kubernetes 클러스터를 완전히 제어합니다. 노드 구성, 네트워크 정책, 보안 설정, 부가기능에 대해 고급 맞춤설정을 만들 수 있습니다. |
기본 인프라를 제한적으로 제어합니다. 환경 변수, 통화, 네트워크 연결과 같은 것을 구성할 수 있지만 기본 인프라 또는 환경을 맞춤설정할 수 없습니다. 단순성 및 속도에 적합합니다. |
| 애플리케이션 유형 | 스테이트리스(Stateless) 및 스테이트풀(Stateful) 애플리케이션을 모두 지원하며 특정 리소스 요구가 있는 복잡한 애플리케이션 적합합니다. | 스테이트리스(Stateless), 요청 또는 이벤트 기반 서비스, 웹 서비스, 함수에 적합합니다. |
| 가격 책정 모델 | 작업 모드(표준 또는 Autopilot), 클러스터 크기, 토폴로지에 관계없이 시간 및 클러스터당 지불 방식입니다. | 종량제 요금으로, 100밀리초 단위로 반올림됩니다. |
사용 사례
대규모 전자상거래 플랫폼을 빌드하는 소매업 회사의 플랫폼 관리자라고 가정해 보세요. 배포해야 하는 컨테이너화된 워크로드는 다음과 같습니다.
프런트엔드 웹사이트 및 모바일 앱: 제품 둘러보기, 검색, 결제를 처리하는 스테이트리스(Stateless) 웹 애플리케이션입니다.
제품 인벤토리 관리: 제품 가용성 및 업데이트를 관리하는 스테이트풀(Stateful) 서비스입니다.
추천 엔진: 각 사용자에 대해 개인화된 제품 추천을 생성하는 복잡한 마이크로서비스입니다.
일괄 처리 작업: 제품 카탈로그 업데이트 및 사용자 행동 분석과 같은 주기적인 태스크를 포함합니다.
이러한 워크로드는 스테이트리스(Stateless) 및 스테이트풀(Stateful) 서비스 혼합을 나타내므로 최적 성능을 위해 GKE 및 Cloud Run의 모든 이점을 활용하도록 결정합니다. 워크로드에 대해 하이브리드 접근 방법을 구현하는 한 가지 방법은 다음과 같습니다.
Cloud Run 워크로드의 적합성 기준을 읽은 후 웹사이트 및 모바일 앱, 일괄 처리 작업에 대해 Cloud Run을 사용하도록 결정합니다. Cloud Run에 이러한 서비스를 배포하면 다음과 같은 이점이 있습니다.
자동 확장을 통해 수동 조작 없이 트래픽 급증 및 대규모 일괄 작업을 처리합니다.
종량제 모델의 비용 효율성. 사용자가 탐색 또는 결제할 때 그리고 일괄 작업 수행 중 리소스가 사용될 때만 비용을 지불합니다.
즉시 사용 가능한 업데이트로 배포 속도를 높이고 사용자 환경을 개선합니다.
다른 Google Cloud 서비스와 쉽게 통합할 수 있습니다. 예를 들어 이벤트 기반 처리의 경우 Cloud Functions를 사용해서 Cloud Run에서 일괄 처리 작업을 시작하고 원활한 워크플로를 지원할 수 있습니다.
제품 인벤토리 관리는 세부적인 제어와 잠재적인 커스텀 스토리지 솔루션이 필요한 스테이트풀(Stateful) 서비스입니다. 영구 스토리지를 제공하고 제품 데이터 영구성 및 신뢰성을 위해 볼륨을 연결할 수 있으므로 GKE를 사용해서 이 서비스를 배포하도록 결정합니다.
추천 엔진은 GKE의 이점을 활용하는 복잡한 마이크로서비스입니다. GKE를 사용하면 복잡한 종속 항목을 관리하고 리소스 할당 및 확장을 세밀하게 제어할 수 있습니다.
GKE는 복잡한 마이크로서비스 아키텍처, 스테이트풀(Stateful) 애플리케이션, 커스텀 인프라 또는 네트워크 구성이 필요한 워크로드, Kubernetes에 대한 심층 제어가 필수적인 시나리오에 가장 적합합니다. Cloud Run은 이벤트 기반 앱에 가장 적합합니다. 스테이트리스(Stateless) 웹 서비스, API, 일괄 작업, 종량제 가격 책정을 활용하는 기타 워크로드에 이상적입니다.
앞의 예시는 GKE와 Cloud Run을 조합하여 전자상거래 플랫폼에 대해 강력하고 유연한 솔루션을 제공하는 방법을 보여줍니다. 스테이트리스(Stateless) 워크로드에 대한 서버리스 효율성과 복잡한 마이크로서비스 및 스테이트풀(Stateful) 구성요소에 대한 Kubernetes 제어를 포함하여 두 플랫폼의 이점을 모두 얻을 수 있습니다.
고려사항
GKE와 Cloud Run은 서로를 보완해서 복잡한 애플리케이션 환경 내의 여러 다른 요구를 해결합니다.
다음은 워크로드 배포를 위해 하이브리드 접근 방법을 채택할 때 고려할 사항입니다.
비용 효율성 및 확장성을 위해서는 Cloud Run에서 스테이트리스(Stateless) 마이크로서비스를 실행합니다.
GKE에 심층적인 맞춤설정이 필요한 복잡한 스테이트풀(Stateful) 애플리케이션을 배포합니다.
Google Cloud에서 비공개 네트워크를 사용할 경우 Cloud Run 서비스에서 GKE 클러스터의 리소스에 액세스하기 위해서는 직접 VPC 이그레스를 사용하여 가상 프라이빗 클라우드(VPC) 네트워크에 요청을 전송할 수 있습니다. GKE 클러스터에서 Kubernetes 서비스에 액세스하려면 Cloud Run 서비스가 클러스터의 VPC 네트워크에 연결되어 있어야 하고 Kubernetes 서비스가 내부 패스 스루 네트워크 부하 분산기를 사용해야 합니다.
Cloud Run 및 GKE 사이에 트래픽을 마이그레이션하려면 전역 외부 애플리케이션 부하 분산기를 사용하여 외부 엔드포인트를 노출할 수 있습니다. 두 런타임 모두 서비스 앞에 부하 분산기를 구현할 때는 Cloud Run과 GKE에 동일한 애플리케이션을 배포하여 한 플랫폼에서 다른 플랫폼으로 점진적으로 트래픽을 이동할 수 있습니다.
비공개 IP를 사용해서 가상 프라이빗 클라우드에서 Cloud Run 서비스를 노출하려면 내부 부하 분산기를 사용합니다.
워크로드가 이미 Cloud Run에 있으면 항상 필요에 따라 GKE로 마이그레이션할 수 있습니다.
GKE와 Cloud Run을 함께 사용하지 않아야 하는 경우
GKE와 Cloud Run은 많은 컨테이너화된 워크로드에 대해 뛰어난 접근 방법을 제공하지만 둘을 동시에 사용하는 것이 적합하지 않은 경우도 있습니다. 하이브리드 접근 방법 채택을 결정하지 않아야 하는 경우의 예시는 다음과 같습니다.
긴밀하게 결합된 마이크로서비스: 마이크로서비스가 서로 크게 종속되어 있고 낮은 지연 시간의 커뮤니케이션이 자주 필요한 경우에는 개별 플랫폼으로 이를 관리함으로써 복잡성이 증가할 수 있습니다. 플랫폼 간의 빈번한 네트워크 호출도 오버헤드와 잠재적 병목 현상을 일으키고 성능에 영향을 줄 수 있습니다.
커스텀 종속 항목이 포함된 기존 애플리케이션: 애플리케이션이 Cloud Run에서 지원되지 않는 특정 라이브러리, 프레임워크, 구성에 의존되어 있을 때는 애플리케이션의 일부로 이를 사용할 때 상당한 리팩터링 또는 문제 해결이 필요할 수 있습니다. 이는 서버리스 이점을 반감하고 플랫폼 특정 유지보수 오버헤드를 가져옵니다.
워크로드를 예측 가능한 예산 제약조건: 워크로드에 일관적인 리소스 요구사항이 포함되어 있고 예산이 한정적일 경우 GKE의 노드당 지불 모델이 Cloud Run의 종량제 결제보다 더 비용 효율적일 수 있습니다. 워크로드가 예측 가능한 경우에는 Cloud Run의 자동 확장 이점을 완전히 활용하지 못할 수 있으므로 GKE의 고정 비용이 더 매력적입니다.
궁극적으로 최상의 접근 방법은 특정 요구 및 우선순위에 따라 달라집니다. 하이브리드 GKE 및 Cloud Run 아키텍처를 결정하기 전에 애플리케이션 요구사항, 리소스 제약조건, 팀 전문성을 신중하게 평가해야 합니다.
다음 단계
Cloud Run에서 GKE로 마이그레이션에서 Cloud Run 서비스를 Kubernetes 배포로 변환하는 방법 알아보기
Kubernetes에서 Cloud Run으로 마이그레이션에 따라 Kubernetes 배포를 Cloud Run 호환 컨테이너로 패키징