▲

GitPod, Kubernetes를 떠나기로 결정 + GitPod Flex 발표

 (gitpod.io)
11P by xguru 16일전 | favorite | 댓글 3개
  • GitPod은 6년간 쿠버네티스를 사용해 "원격 개발 환경 플랫폼"을 구축해 왔고, 1.5백만 사용자를 지원하며 매일 수천 개의 개발 환경을 제공 중
  • 그러나 쿠버네티스는 개발 환경 구축에 적합하지 않다는 것을 깨달음
  • 이것은 프로덕션 워크로드에 쿠버네티스를 쓸지/말지에 대한 이야기가 아니며, K8s에 애플리케이션을 배포하기 위한 개발자 경험을 만드는 방법에 대한 주제도 아님
    → 클라우드에서 개발 환경을 구축하는 방법(또는 하지 않는 방법)에 대한 이야기임

[개발 환경이 특별한 이유]

  • 상태가 많고 상호작용이 활발함
    • 노드 간에 이동할 수 없음
    • 많은 양의 소스 코드, 빌드 캐시, 도커 컨테이너, 테스트 데이터 등이 자주 변경되고 마이그레이션 비용이 높음
    • 프로덕션 서비스와 달리 개발자와 환경 간에 1대1 상호작용이 일어남
  • 개발자는 소스 코드와 변경 사항에 깊이 연관되어 있음
    • 소스 코드 변경 사항을 잃거나 시스템에 의해 차단되는 것을 좋아하지 않음
    • 개발 환경은 실패에 특히 민감함
  • 예측 불가능한 자원 사용 패턴을 가짐
    • 대부분의 시간 동안 CPU 대역폭이 많이 필요하지 않지만, 수백 ms 내에 여러 코어가 필요할 수 있음
    • 그보다 느리면 용납할 수 없는 지연과 무응답으로 나타남
  • 광범위한 권한과 기능이 필요함
    • 프로덕션 워크로드와 달리 루트 액세스와 패키지 다운로드/설치 능력이 필요함
    • 프로덕션 워크로드에서는 보안 문제가 되는 것들이 개발 환경에서는 예상되는 동작임 (루트 액세스, 확장된 네트워크 기능, 추가 파일시스템 마운트 등)
  • 이러한 특성 때문에 일반적인 애플리케이션 워크로드와 구분되며, 인프라 결정에 큰 영향을 줌

[현재 시스템: Kubernetes]

  • Gitpod 초기에는 쿠버네티스가 인프라로 이상적인 선택처럼 보였음
    • 확장성, 컨테이너 오케스트레이션, 풍부한 생태계 등이 클라우드 개발 환경에 대한 비전과 잘 맞았음
  • 그러나 규모가 커지고 사용자 기반이 증가하면서 보안과 상태 관리 측면에서 어려움을 겪음
    • 쿠버네티스는 잘 제어된 애플리케이션 워크로드를 실행하도록 설계되었지, 다루기 힘든 개발 환경을 위한 것이 아님
  • 대규모로 쿠버네티스를 관리하는 것은 복잡함
    • GKE, EKS 같은 관리형 서비스가 일부 문제를 완화해주지만 그만의 제약과 한계가 있음
  • CDE를 운영하려는 많은 팀이 쿠버네티스의 복잡성을 과소평가하는 경향이 있음
    • 이는 이전의 자체 관리형 Gitpod 제품에 상당한 지원 부하로 이어짐

자원 관리의 어려움

  • CPU, 메모리 할당이 가장 큰 난제
  • 노드에서 환경을 공유하는 것은 매력적이지만, 실제로는 noisy neighbor 효과가 크게 나타남
  • CPU 문제
    • 개발 환경은 CPU가 많이 필요하지 않다가도 순간적으로 많이 필요
    • CFS 기반 솔루션, 사용자 정의 컨트롤러 등을 실험했지만 예측이 어려움
    • 정적 CPU 제한을 써도 여러 프로세스가 경쟁하는 문제 발생
  • 메모리 관리
    • 고정 메모리를 할당하는 건 간단하지만 제한적
    • 오버부킹은 프로세스 종료로 이어질 수 있음
    • 스왑 공간이 도입되며 오버부킹 필요성은 다소 완화됨

스토리지 성능 최적화

  • IOPS, 지연 시간이 개발 환경 경험에 영향
  • 다양한 설정을 실험하며 속도, 안정성, 비용, 성능의 균형을 찾음
    • SSD RAID 0
    • EBS, 영구 디스크 등 블록 스토리지
    • PVC
  • 백업/복원은 비용이 많이 드는 작업

오토스케일링과 시작 시간 최적화

  • 시작 시간 최소화가 최우선 목표
  • 하나의 노드에서 여러 작업 공간을 실행하면 공유 캐시 때문에 시작 시간이 개선될 거라 생각했지만 그렇지 않았음
  • 쿠버네티스가 시작 시간에 하한선을 부과함
  • 스케일 아웃 방법의 진화
    • 고스트 작업 공간, 밸러스트 포드 등을 사용해 스케일 아웃 실험
    • 오토스케일러 플러그인 도입으로 확장 전략이 크게 개선됨
  • 피크 부하 대응을 위한 비례 오토스케일링
    • 비어있는 포드를 시작해 수요 급증에 신속히 대응
  • 이미지 풀 최적화를 위한 다양한 시도
    • 데몬셋 사전 풀, 레이어 재사용 최대화, 미리 구운 이미지, Stargazer와 지연 풀링, Registry-facade + IPFS

네트워킹 복잡성

  • 개발 환경 액세스 제어
    • 환경 간 완전히 격리되어야 함
    • 네트워크 정책이 도움이 되지만, 서비스 수가 많아지면 신뢰성 문제 발생
  • 네트워크 대역폭 공유
    • CNI가 네트워크 셰이핑을 지원하기도 하지만 또 다른 제어 대상

보안과 격리: 유연성과 보호의 균형

  • 사용자에게 유연성을 주면서 보안 환경을 제공하는 것이 가장 큰 도전
  • 사용자에게 루트 권한을 주는 것은 결함이 많음
  • 사용자 네임스페이스가 더 세밀한 해법
    • 파일 시스템 UID 변환, 마스킹된 proc 마운트, FUSE 지원, 네트워크 기능 제공, 도커 활성화
  • 사용자 네임스페이스 구현의 어려움
    • 성능 영향, 호환성 문제, 복잡성, 쿠버네티스 버전 대응

[Micro VM 실험]

  • 쿠버네티스의 한계를 느끼며 Firecracker, Cloud Hypervisor, QEMU 등 마이크로 VM(uVM) 기술을 중간 지점으로 탐색하기 시작함
  • 자원 격리 개선, 다른 워크로드(쿠버네티스 등)와의 호환성, 보안 강화를 기대하면서도 컨테이너화의 이점을 유지할 수 있을 거란 기대감이 있었음
  • 마이크로 VM의 장점
    • 클라우드 개발 환경에 대한 목표와 잘 부합하는 매력적인 이점들을 제공함
    • 자원 격리 향상: 오버부킹 능력은 떨어지지만 컨테이너 대비 자원 격리가 개선됨. 공유 커널 자원 경합이 사라져 개발 환경별 성능 예측 가능성이 높아짐
    • 메모리 스냅샷과 빠른 재개: Firecracker의 userfaultfd 기능은 메모리 스냅샷을 지원함. 이는 실행 중인 프로세스를 포함해 머신 전체를 거의 즉시 재개할 수 있게 해줌. 개발자 입장에선 환경 시작이 훨씬 빨라지고, 작업을 중단한 지점에서 바로 재개할 수 있음
    • 보안 경계 개선: uVM은 강력한 보안 경계 역할을 할 수 있어, 쿠버네티스에서 구현한 복잡한 사용자 네임스페이스 메커니즘이 불필요해짐. 이는 중첩된 컨테이너화(개발 환경 내에서 도커나 쿠버네티스 실행)를 포함해 더 광범위한 워크로드와 완전히 호환될 수 있음
  • 마이크로 VM의 어려움
    • 그러나 마이크로 VM 실험 결과 몇 가지 중대한 과제가 드러남
    • 오버헤드: 경량 VM이라도 uVM은 컨테이너보다 더 많은 오버헤드를 야기함. 성능과 자원 활용 모두에 영향을 미치는데, 이는 클라우드 개발 환경 플랫폼에서 중요한 고려사항임
    • 이미지 변환: OCI 이미지를 uVM에서 사용 가능한 파일 시스템으로 변환하려면 사용자 정의 솔루션이 필요함. 이미지 관리 파이프라인이 복잡해지고 시작 시간에 잠재적 영향을 줌
    • 기술별 제한사항
      • Firecracker: GPU 지원 부재(일부 개발 워크플로에 점점 더 중요해지고 있음), virtiofs 지원 부재(효율적인 파일 시스템 공유 옵션 제한)
      • Cloud Hypervisor: userfaultfd 지원 부재로 스냅샷과 복원 프로세스가 느려짐(uVM의 주요 장점 상쇄)
    • 데이터 이동 문제: uVM으로 인해 대용량 메모리 스냅샷을 다뤄야 해서 데이터 이동이 더 어려워짐. 스케줄링과 시작 시간 모두에 영향을 미치는데, 이는 클라우드 개발 환경 사용자 경험의 핵심 요소임
    • 스토리지 고려사항: 마이크로 VM에 EBS 볼륨을 연결하는 실험은 새로운 가능성을 열어주었지만 새로운 의문도 제기함
      • 영구 스토리지: 연결된 볼륨에 작업 공간 콘텐츠를 보관하면 S3에서 데이터를 반복적으로 가져올 필요가 없어져 시작 시간 개선과 네트워크 사용량 감소 기대
      • 성능 고려사항: 작업 공간 간에 높은 처리량의 볼륨을 공유하면 I/O 성능 개선이 기대되지만, 효과적인 할당량 구현, 지연 관리, 확장성 보장 등에 대한 우려도 제기됨
  • 마이크로 VM 실험의 교훈
    • 마이크로 VM이 최종적으로 주요 인프라 솔루션이 되진 않았지만, 실험을 통해 귀중한 통찰을 얻음
    • 개발 환경을 위한 전체 작업 공간 백업과 런타임 상태 일시 중단/재개 경험이 마음에 들었음
    • 처음으로 쿠버네티스에서 벗어나는 것을 고려하게 됨. KVM과 uVM을 포드에 통합하려는 노력 끝에 쿠버네티스 외부 옵션을 탐색하게 됨
    • 안정적인 시작 성능, 안정적인 작업 공간(데이터 손실 방지), 최적의 머신 활용이라는 세 가지를 모두 제공하기 위한 핵심 요소로 스토리지를 다시 한번 인식하게 됨

쿠버네티스는 개발 환경 플랫폼으로서 매우 도전적임

  • 앞서 언급했듯이, 개발 환경을 위해서는 개발 환경의 고유한 상태성을 존중하는 시스템이 필요함
  • 개발자가 생산성을 발휘하는 데 필요한 권한을 부여하면서도 안전한 경계를 보장해야 함
  • 이 모든 것을 운영 오버헤드를 낮게 유지하고 보안을 타협하지 않으면서 해내야 함
  • 오늘날 쿠버네티스로 이 모든 것을 달성하는 것은 가능하지만 상당한 비용이 듦
  • 애플리케이션 워크로드와 시스템 워크로드의 차이를 어려운 방식으로 배웠음
  • 쿠버네티스는 믿을 수 없을 정도로 훌륭함
  • 열정적인 커뮤니티의 지원을 받으며 진정으로 풍부한 생태계를 구축함
  • 애플리케이션 워크로드를 실행한다면 쿠버네티스는 여전히 좋은 선택임
  • 그러나 개발 환경과 같은 시스템 워크로드의 경우 쿠버네티스는 보안과 운영 오버헤드 측면에서 엄청난 도전을 안겨줌
  • 마이크로 VM과 명확한 자원 예산이 도움이 되지만, 비용이 더 지배적인 요인이 됨
  • 그래서 수년간 개발 환경을 쿠버네티스 플랫폼에 효과적으로 역설계하고 강제로 적용한 후, 한 걸음 물러서서 미래 개발 아키텍처가 어떤 모습이어야 할지 고민하게 됨
  • 2024년 1월, 이를 구축하기 시작해서, 10월에 Gitpod Flex를 출시함
  • 인터넷 규모에서 개발 환경을 안전하게 실행하기 위한 6년 이상의 엄청나게 어렵게 얻은 통찰력이 아키텍처 기반에 녹아들었음

개발 환경의 미래

  • Gitpod Flex에서는 쿠버네티스의 기본적인 측면, 즉 제어 이론의 자유로운 적용과 선언적 API를 이어받으면서 아키텍처를 단순화하고 보안 기반을 개선함
  • 쿠버네티스에 크게 영감을 받은 컨트롤 플레인을 사용하여 개발 환경을 오케스트레이션함
  • 개발 환경에 특화된 필요한 추상화 계층을 도입하고, 불필요한 인프라 복잡성을 대부분 제거함
  • 이 모든 것을 제로 트러스트 보안을 최우선으로 하면서 진행함
  • 이 새로운 아키텍처 덕분에 데브컨테이너를 원활하게 통합할 수 있게 됨
  • 또한 데스크톱에서 개발 환경을 실행할 수 있는 능력도 열림
  • 이제 쿠버네티스 플랫폼의 무거운 짐을 더 이상 지지 않아도 되므로, Gitpod Flex는 3분 이내에 자체 호스팅으로 배포할 수 있고, 원하는 수의 리전에 배포 가능
  • 이는 규정 준수에 대한 더 세밀한 제어와 조직 경계 및 도메인을 모델링할 때 더 큰 유연성을 제공함

(원래는 다른 글이지만 같이 묶는게 좋을 것 같아서 함께 옮겨봅니다.)

Gitpod Flex

  • 제로 트러스트 개발 환경을 위한 첫번째 자동화 플랫폼
  • 노트북, 클라우드, 온프레미스에서 실행되도록 설계되었으며, 소스 코드, 데이터, 지적 재산을 사설 네트워크 내에 유지
  • 개발 환경부터 시작해 소프트웨어 개발 라이프사이클 자동화를 위한 빌딩 블록 제공
  • 자동화(Automations)
    • 저장소나 API를 통해 정의된 프로그래밍 가능한 작업과 서비스
    • 개발자 스스로 해결할 수 있도록 지원하고, 개발자 생산성 팀이 개발 환경 개선을 중앙 집중화할 수 있도록 도움
    • 단순 스크립트 실행 이상의 기능 제공
    • 데이터베이스 프로비저닝 및 시딩, 개발자 워크플로 맞춤화, 임시 클러스터 실행, LLM 기반 에이전트 워크플로 설정, 글로벌/지역 보안 및 규정 준수 중앙 집중 적용 등 가능
  • 제로 트러스트 환경(Zero-trust environments)
    • 모든 행위자와 서비스를 '결코 신뢰하지 않고 항상 검증'
    • 악의적 행위자 완전 차단, 공격 노출 영역 크게 축소, 맬웨어나 코드 유출 위험 감소
    • 지속적 평가 및 명시적 검증, 검증된 엔터프라이즈급 암호화, 세분화된 접근 제어, 네트워킹에 대한 완전한 제어, 완전한 감사 로그 포함
    • 소스 코드, 데이터, 지적 재산권을 사설 네트워크 내에 유지하는 것이 가장 중요
  • Gitpod Desktop
    • 로컬 개발 환경 표준화 및 자동화 가능
    • Apple Silicon부터 지원 시작
    • 지연 시간 제로화, 개발용 Docker Desktop의 더 빠르고 가벼우며 간단한 대체재, 로컬 컴퓨팅 활용한 비용 최적화, 클라우드나 엔드포인트 중단 대비한 재해 복구 지원 제공
  • Development Container 지원
    • Dev Container 사양을 완벽하게 통합
    • 기존 Dev Container 설정을 변경 없이 사용 가능
    • VS Code 및 기타 지원 도구와 호환성 제공
    • 로컬이나 클라우드에서 일관되게 작업 가능
    • Dev Container 표준 채택으로 개발 환경 정의, 공유, 관리가 더 쉬워짐

앞으로 10년간 소프트웨어 개발 자동화의 발판이 될 것

  • 우리가 개발 환경을 너무 좁게 생각해왔음
  • 개발환경은 IDE, 종속성, 도구 이상의 것으로 소프트웨어가 만들어지는 근본적인 공간
  • 코드 프로토타입 제작, 사람과 기계에 의한 형성, 테스트, 리팩토링, 컴파일, 패키징, 서명, 배포가 이뤄지는 곳
  • 개발 맥락, 워크플로, 통찰력에 대한 비할 데 없는 접근성 제공해 다른 개발 플랫폼과 차별화된 기능 제공
  • 제품의 비전
    • 지속적 통합(CI)이 개발 환경과 융합
    • 소프트웨어 개발의 시스템 기록(System of record) 역할
    • 차세대 개발자 도구를 위한 플랫폼
  • 단순히 코딩 관행 개선을 넘어 스타트업부터 포춘 50대 기업까지 앞으로 10년간 기업이 확장하고 성공할 수 있는 가장 빠르고 안전한 방법 구축
▲
bus710 16일전  [-]

쿠버네티스 잘하는 사람 구하기도 어려운데, 여기서 대안으로 제시하는 것들을 이해하고 시도하려는 사람들을 구하기는 더 어렵겠다는 생각이 드네요.

답변달기
▲
ahwjdekf 15일전  [-]

보안 핑계로 가상데스크탑 8gb메모리 사양 , 강제 사용하게 하는 만드는 국내 기업들. 씁쓸하네

답변달기
▲
xguru 16일전  [-]

Hacker News 의견

  • 개발자는 자신이 사용하는 개발용 기기를 소유해야 함. 일관된 환경이 필요하다면, 개발자가 자신의 기기를 소유하고 안정적인 VM 이미지를 제공받아야 함. 원격 호스트로 개발 환경을 옮기는 시도는 대부분 실패함. 개발자에게 적절한 하드웨어를 제공하는 것이 원격 자원보다 비용 효율적임. 로컬 스택 실행을 지원해야 하며, 이는 컨테이너를 통해 일관성을 유지하는 데 도움이 됨. 로컬 환경에 데이터를 생성하는 도구가 필요하며, 이는 자동화 가능함. 데이터 관리의 단점이 있지만, 대부분의 회사는 소스 코드보다 팀의 실행력이 중요함.

  • Kubernetes를 프로덕션 워크로드에 사용하는 것은 별개의 문제이며, 클라우드에서 개발 환경을 구축하는 방법에 대한 이야기임. Kubernetes의 복잡한 엔지니어링 트레이드오프에 대한 흥미로운 기사

  • Kubernetes의 문제점과 시도한 해결책을 설명하지만, 최종적으로 선택한 대안에 대한 설명이 부족함. Gitpod Flex라는 새로운 솔루션을 언급하지만, 이에 대한 정보가 별로 없음

  • Kubernetes는 상태가 없는 워크로드에 적합하지만, 상태가 있는 경우 LXC가 더 적합함. LXC는 K8S와 유사하게 클러스터화 가능하며, 데이터 평면에 도구를 노출함. VM과 유사하게 시스템 인스턴스를 제공하며, Docker 컨테이너와 유사한 성능을 가짐. 선언적 문법을 사용하며, Kubernetes 클러스터의 기초 계층으로 사용 가능함.

  • CI 솔루션을 구축하면서 Kubernetes를 선택한 것은 문제를 제대로 이해하지 못한 것임. 보안 목적으로 Firecracker와 같은 도구를 사용해야 함.

  • Kubernetes는 개발 환경에 적합하지 않음. 개발 환경은 항상 변화하는 상태에 있음. 클라우드 개발 환경의 필요성을 이해하지 못함. 컨테이너화된 앱의 목적은 팀 간 개발 환경 동기화를 피하는 것임.

  • Kubernetes 논문은 저지연 및 고지연 워크플로우 조합을 유일한 사용 사례로 언급함. Gitpod의 문제에 Kubernetes를 고려하는 것은 정당화하기 어려움.

  • Gitpod와 유사한 프로젝트를 진행했으며, Kubernetes를 대체하기 위해 마이크로 VM을 사용하는 것이 이해되지 않음. Kubernetes는 외부 컨테이너를 조정할 수 있으며, 마이크로 VM을 실행하는 데 사용될 수 있음. 가장 큰 문제는 스토리지 관련 문제임.

  • Kubernetes에서 개발 환경을 구축하는 것은 낭비적임. 제품이 고객의 인프라에 자체 호스팅되는 경우, 디버깅과 지원이 어려움. 네트워크, 메모리, 컴퓨트, 스토리지 문제를 엔지니어에게 노출하는 것이 효과적임. Kubernetes는 큰 팀에게는 업그레이드임.

답변달기