19P by neo 8일전 | favorite | 댓글 12개

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 환경에 의존하고 싶지 않음

kubernetes 가 제 밥줄이고 한때는 이것이 정답이다 라고 믿었던 시절이 있습니다만
시간이 지날수록 많은 문제들을 경험하고 시간을 낭비하게 되는 스스로를 찾게되네요.

남한테는 k8s 추천하지만 제 서비스에 사용하진 않을 것 같습니다. k8s도 k8s지만 그냥 컨테이너도 지쳤습니다.

silver bullet이 어디 있겠습니까. 상황에 맞게 잘 쓰면 되는거겠죠 ㅎㅎ
트렌디한거라고 무비판적으로 kubernetes를 도입하면 힘들어질 수 있는데 그래도 좀 규모가 큰 환경에서는 괜찮은 도구라고 생각하고 있습니다.
도입을 하더라도 도입만 하고 끝나면 제대로 못쓰게 될거에요.
그리고 어떤 도구든 마찬가지지만 100% 개발자나 사용자의 니즈를 충족시킬 수는 없기 때문에 적절한 수준의 자동화는 필수일 것 같습니다.

저도 글쓴이의 생각과 비슷합니다.
아직 회사 규모가 kube를 사용할정도가 아니기도하구요.

모든 개발자가 Kube를 이용해서 관리를 할 수 있을꺼라는 것은 저만의 생각이었어요.
회사의 개발자의 평균보다 못하게 인프라를 구축하고 문제를 해결할 수 있도록 가이드해주는게 더 낫더라구요...

쿠버네티스는 구축만 되면 꿀빠는 일만 남았는데 ... ㅠㅠ

AWS 를 사용중이라면 ECS 와 비슷하다고 생각하면 될까요?

네 그것이라고 보시면 됩니다. :)

kubernetes를 못쓰는게 잘못이지 kubernetes가 별로 라고 하기에는 좀 그렇네요.

???: 저는 AI 가 필요하지 않았고, 여러분도 아마 필요하지 않을겁니다.

어떤 제품이건 트레이드오프가 되는 부분들이 있을텐데

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가 필요하지 않으며, 좋은 시스템 관리자가 더 중요함을 강조함