GN⁺: 저는 Kubernetes가 필요하지 않았고, 여러분도 아마 필요하지 않을겁니다
(benhouston3d.com)Kubernetes를 떠나 Google Cloud Run을 선택한 이유
Kubernetes 도입의 배경
- 2013년 출시한 온라인 3D 편집 플랫폼 Clara.io에서 베어메탈 서버를 사용해 인프라를 최적화했으나, 하드웨어 관리와 모니터링에 과도한 작업 필요.
- 2018년 Threekit.com 프로젝트에서 Kubernetes를 선택. 당시 Azure, AWS, Docker가 Kubernetes를 표준으로 채택하며 주류화.
Kubernetes의 한계
-
비용 문제:
- 관리 노드, 클러스터 중복 구성 등 기본 클러스터 구축 비용이 큼.
- 느린 오토스케일링으로 서비스 과잉 프로비저닝 필요, 미사용 리소스 비용 발생.
-
작업량 관리의 어려움:
- 작업 스케줄링이 복잡하며, 내장 스케줄러 및 Argo도 대량 작업에서는 비효율적.
-
복잡성 과부하:
- 풍부한 기능이 단순 작업도 복잡하게 만듦.
- Kubernetes 관리에 전담 DevOps 인력이 필요하며, 이는 비용 상승으로 이어짐.
Google Cloud Run으로 전환
Cloud Run은 Kubernetes의 복잡성을 대체하며 간소화된, 비용 효율적인 환경을 제공.
새로운 설정
-
Docker 컨테이너 기반 인프라:
- 자동 스케일링 서비스와 장기 실행 작업용 컨테이너 포함.
- Cloud Run은 컨테이너 배포, 스케일링, 가동 중단 관리 및 작업 실행을 자동화.
Cloud Run의 장점
-
비용 효율성:
- CPU 및 메모리 사용 시간에 따라 요금 부과.
- 유휴 서비스에는 비용이 발생하지 않음.
- 예: Web3D Survey 사이트는 월 500,000회 트래픽을 처리하면서 $4/월로 운영 가능.
-
빠르고 안정적인 오토스케일링:
- Kubernetes보다 빠른 몇 초 내 스케일링.
- 수요 급증을 신속히 처리 가능.
-
Kubernetes 관리 부담 없음:
- Cloud Run은 Google의 Borg 기반으로 Kubernetes 클러스터 관리 불필요.
-
간단한 비동기 작업:
- Cloud Run Tasks를 사용해 자동 재시도, 대량 작업 실행이 간편.
Kubernetes의 잠재적 문제: 클러스터 락인
- Kubernetes 기능에 의존하면 클러스터 외부 리소스 통합이나 확장이 어려워짐.
- 특정 인프라에 의존하게 되어 확장과 마이그레이션이 복잡하고 비용 증가.
Cloud Run 사용에 대한 일반적인 질문
“GCP 종속성이 걱정되지 않나요?”
- Docker 기반 설정으로 AWS 같은 다른 클라우드로의 마이그레이션이 약 1주일이면 가능.
- 현실적으로 정치적 요인 외에는 클라우드 제공자를 변경하는 경우가 드물음.
“Cloud Run도 결국 Managed Kubernetes 아닌가요?”
- Cloud Run은 Knative 인터페이스를 사용하나, Kubernetes가 아닌 Google의 Borg 위에서 작동.
- Kubernetes의 복잡성을 없애고 간소화된 인터페이스 제공.
현 워크플로의 단점
-
서비스 이름 관리의 불편함:
- 로컬 및 서버에서 일관된 구성 관리를 위한 추상화 계층 필요.
- Kubernetes의 네임 관리 기능이 부재.
-
Cloud Run Task 에뮬레이션 부족:
- 로컬에서 작업 개발 시 로그 출력 캡처 및 추적을 포함한 간단한 에뮬레이션 환경 부재.
결론
- Cloud Run은 비용, 속도, 확장성, 간소화 측면에서 최적의 솔루션
- 대기업이나 복잡한 요구사항이 있는 경우 Kubernetes가 유용할 수 있으나,
- 간소성과 효율성이 중요한 프로젝트에서는 Cloud Run이 훨씬 실용적
- PS: Kubernetes의 특정 확장을 추가하는 것으로 문제를 해결할 수도 있겠지만, 이는 복잡성을 더할 뿐이며, 단순한 필요를 초과하는 Kubernetes 환경에 의존하고 싶지 않음
silver bullet이 어디 있겠습니까. 상황에 맞게 잘 쓰면 되는거겠죠 ㅎㅎ
트렌디한거라고 무비판적으로 kubernetes를 도입하면 힘들어질 수 있는데 그래도 좀 규모가 큰 환경에서는 괜찮은 도구라고 생각하고 있습니다.
도입을 하더라도 도입만 하고 끝나면 제대로 못쓰게 될거에요.
그리고 어떤 도구든 마찬가지지만 100% 개발자나 사용자의 니즈를 충족시킬 수는 없기 때문에 적절한 수준의 자동화는 필수일 것 같습니다.
kubernetes 가 제 밥줄이고 한때는 이것이 정답이다 라고 믿었던 시절이 있습니다만
시간이 지날수록 많은 문제들을 경험하고 시간을 낭비하게 되는 스스로를 찾게되네요.
남한테는 k8s 추천하지만 제 서비스에 사용하진 않을 것 같습니다. k8s도 k8s지만 그냥 컨테이너도 지쳤습니다.
저도 글쓴이의 생각과 비슷합니다.
아직 회사 규모가 kube를 사용할정도가 아니기도하구요.
모든 개발자가 Kube를 이용해서 관리를 할 수 있을꺼라는 것은 저만의 생각이었어요.
회사의 개발자의 평균보다 못하게 인프라를 구축하고 문제를 해결할 수 있도록 가이드해주는게 더 낫더라구요...
managed 서비스를 쓰면 딱히 관리에 어려움을 느끼진 못했어서,,
어떤 도구든 적당한 선에서 사용하면 유용한데 쿠버네티스는 유독 '복잡한 설정이 가능함'이 주로 비판되는 것 같다는 생각이 드네요.
Hacker News 의견
-
"클라우드 기술"에 대한 불만을 표현하며, Kubernetes 사용 시 YAML 파일을 수정하고 오류를 해결하는 데 많은 시간을 소비하게 됨을 언급함. 클라우드 통합을 피하고 직접 서버를 설정하고 싶다는 의견을 가짐
-
Kubernetes는 DevOps와 관리 시간 외에도 상당한 인프라 비용이 발생함. 클라우드 제공자의 관리형 Kubernetes를 사용하는 것이 더 효율적임을 제안함
-
Kubernetes는 컨테이너 오케스트레이션 도구가 아닌 컴퓨터 클러스터를 만드는 도구로, 클러스터가 필요하지 않다면 Kubernetes를 사용하지 않아도 됨을 설명함
-
DevOps에 대한 과도한 투자가 줄어들고 있으며, Kubernetes에 대한 비판적인 시각을 공유함. 작은 스타트업에서는 단일 서버로도 충분할 수 있음을 강조함
-
Cloud Run 사용 시 주의할 점으로 TCP 연결 제한, 실행 환경 선택, 자동 확장 설정 등을 언급함
-
Cloud Run은 작은 스타트업에 적합하지만, 보안 아키텍처의 기본 요소인 방화벽 제어가 부족함을 지적함. 결국 VPC가 필요하게 될 것임을 설명함
-
Google Cloud Run과 Kubernetes의 비교는 공정하지 않다고 주장하며, 각각의 장단점을 설명함. Kubernetes는 복잡한 작업에 적합함을 강조함
-
Kubernetes는 학습 곡선이 가파르지만 적절히 사용하면 강력한 도구임을 설명함
-
Kubernetes에 대한 비판에 동의하지 않으며, 복잡한 앱을 배포할 때 Kubernetes API가 필요할 수 있음을 강조함
-
Kubernetes의 복잡성은 주로 시스템 관리 작업에서 발생하며, Kubernetes 자체는 안정적임을 설명함
-
IaC와 CM은 구성을 줄이고 관리하기 쉽게 만들어야 하지만, 실제로는 더 많은 노력이 필요하다는 점을 지적함. 많은 경우 Kubernetes가 필요하지 않으며, 좋은 시스템 관리자가 더 중요함을 강조함