GN⁺: 저는 Kubernetes가 필요하지 않았고, 여러분도 아마 필요하지 않을겁니다

Kubernetes를 떠나 Google Cloud Run을 선택한 이유

Kubernetes 도입의 배경

• 2013년 출시한 온라인 3D 편집 플랫폼 Clara.io에서 베어메탈 서버를 사용해 인프라를 최적화했으나, 하드웨어 관리와 모니터링에 과도한 작업 필요.
• 2018년 Threekit.com 프로젝트에서 Kubernetes를 선택. 당시 Azure, AWS, Docker가 Kubernetes를 표준으로 채택하며 주류화.

Kubernetes의 한계

1. 비용 문제:

   • 관리 노드, 클러스터 중복 구성 등 기본 클러스터 구축 비용이 큼.
   • 느린 오토스케일링으로 서비스 과잉 프로비저닝 필요, 미사용 리소스 비용 발생.

2. 작업량 관리의 어려움:

   • 작업 스케줄링이 복잡하며, 내장 스케줄러 및 Argo도 대량 작업에서는 비효율적.

3. 복잡성 과부하:

   • 풍부한 기능이 단순 작업도 복잡하게 만듦.
   • Kubernetes 관리에 전담 DevOps 인력이 필요하며, 이는 비용 상승으로 이어짐.

Google Cloud Run으로 전환

Cloud Run은 Kubernetes의 복잡성을 대체하며 간소화된, 비용 효율적인 환경을 제공.

새로운 설정

• Docker 컨테이너 기반 인프라:
  • 자동 스케일링 서비스와 장기 실행 작업용 컨테이너 포함.
  • Cloud Run은 컨테이너 배포, 스케일링, 가동 중단 관리 및 작업 실행을 자동화.

Cloud Run의 장점

1. 비용 효율성:

   • CPU 및 메모리 사용 시간에 따라 요금 부과.
   • 유휴 서비스에는 비용이 발생하지 않음.
   • 예: Web3D Survey 사이트는 월 500,000회 트래픽을 처리하면서 $4/월로 운영 가능.

2. 빠르고 안정적인 오토스케일링:

   • Kubernetes보다 빠른 몇 초 내 스케일링.
   • 수요 급증을 신속히 처리 가능.

3. Kubernetes 관리 부담 없음:

   • Cloud Run은 Google의 Borg 기반으로 Kubernetes 클러스터 관리 불필요.

4. 간단한 비동기 작업:

   • Cloud Run Tasks를 사용해 자동 재시도, 대량 작업 실행이 간편.

Kubernetes의 잠재적 문제: 클러스터 락인

• Kubernetes 기능에 의존하면 클러스터 외부 리소스 통합이나 확장이 어려워짐.
• 특정 인프라에 의존하게 되어 확장과 마이그레이션이 복잡하고 비용 증가.

Cloud Run 사용에 대한 일반적인 질문

“GCP 종속성이 걱정되지 않나요?”

• Docker 기반 설정으로 AWS 같은 다른 클라우드로의 마이그레이션이 약 1주일이면 가능.
• 현실적으로 정치적 요인 외에는 클라우드 제공자를 변경하는 경우가 드물음.

“Cloud Run도 결국 Managed Kubernetes 아닌가요?”

• Cloud Run은 Knative 인터페이스를 사용하나, Kubernetes가 아닌 Google의 Borg 위에서 작동.
• Kubernetes의 복잡성을 없애고 간소화된 인터페이스 제공.

현 워크플로의 단점

1. 서비스 이름 관리의 불편함:

   • 로컬 및 서버에서 일관된 구성 관리를 위한 추상화 계층 필요.
   • Kubernetes의 네임 관리 기능이 부재.

2. Cloud Run Task 에뮬레이션 부족:

   • 로컬에서 작업 개발 시 로그 출력 캡처 및 추적을 포함한 간단한 에뮬레이션 환경 부재.

결론

• Cloud Run은 비용, 속도, 확장성, 간소화 측면에서 최적의 솔루션
• 대기업이나 복잡한 요구사항이 있는 경우 Kubernetes가 유용할 수 있으나,
• 간소성과 효율성이 중요한 프로젝트에서는 Cloud Run이 훨씬 실용적
• PS: Kubernetes의 특정 확장을 추가하는 것으로 문제를 해결할 수도 있겠지만, 이는 복잡성을 더할 뿐이며, 단순한 필요를 초과하는 Kubernetes 환경에 의존하고 싶지 않음