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

• 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년간 기업이 확장하고 성공할 수 있는 가장 빠르고 안전한 방법 구축