▲

GN⁺: 12개월 이내에 K8s로 마이그레이션한 방법

 (figma.com)
1P by neo 3달전 | favorite | 댓글 1개

쿠키 설정 및 뉴스레터 구독

  • 이 웹사이트는 성능, 개인화, 마케팅 목적으로 쿠키, 픽셀 태그, 로컬 스토리지를 사용함.
  • 필수 쿠키만 기본적으로 활성화됨.
  • 뉴스레터 구독 가능.

Figma의 Kubernetes로의 마이그레이션

  • 작성자: Ian VonSeggern, Figma 소프트웨어 엔지니어링 매니저
  • 주제: Figma가 12개월 이내에 Kubernetes로 마이그레이션한 과정과 이유

Figma의 컴퓨팅 플랫폼

  • 2023년 초, 모든 서비스를 컨테이너로 실행하는 작업을 완료함.
  • AWS의 Elastic Container Service(ECS)를 사용하여 컨테이너화된 작업을 신속하게 시작함.
  • 장기적인 관점에서 컴퓨팅 플랫폼의 차세대 버전을 고려하게 됨.

Kubernetes 기능의 부족

  • ECS의 몇 가지 제한 사항으로 인해 많은 엔지니어링 시간이 소요됨.
  • Kubernetes의 StatefulSets 기능이 ECS에 없어, etcd 클러스터를 실행하는 데 어려움이 있었음.
  • Helm 차트를 통한 서비스 정의 지원 부족.
  • ECS에서 EC2를 실행할 때 단일 EC2 머신을 종료하는 것이 어려움.

Cloud Native Computing Foundation 생태계 접근

  • ECS를 사용하면 CNCF 생태계의 오픈 소스 기술을 활용하지 못함.
  • Kubernetes 생태계는 자동 확장 기능이 뛰어남.
  • 서비스 메시 도입 가능성 고려.

인기 있는 플랫폼의 장점

  • Kubernetes는 많은 대기업이 사용하여 안정성이 검증됨.
  • 벤더 종속성을 피할 수 있음.
  • Kubernetes 경험이 있는 엔지니어를 고용하기 쉬움.

마이그레이션 범위 설정

  • 안전한 마이그레이션을 위해 핵심 시스템 변경을 최소화함.
  • EKS로의 이전을 목표로 함.
  • 일부 개선 사항을 마이그레이션 범위에 포함시킴.

마이그레이션에 포함된 개선 사항

  • 개발자 경험: 서비스 정의 및 배포 프로세스를 단순화함.
  • 신뢰성 향상: 세 개의 EKS 클러스터를 사용하여 서비스의 신뢰성을 높임.
  • 비용 효율성: 노드 자동 확장을 지원하여 비용 절감.

범위에서 제외된 작업

  • 로그 파이프라인 복잡성 해결 작업 제외.
  • 포드 레벨 자동 확장 작업 제외.

안전한 마이그레이션 수행

  • 로드 테스트: 클러스터의 성능을 이해하기 위해 로드 테스트를 수행함.
  • 점진적 롤아웃 메커니즘: 가중치 DNS 항목을 사용하여 점진적으로 트래픽을 이전함.
  • 실제 서비스 실행: 스테이징 환경에서 실제 서비스를 실행하여 문제를 조기에 발견함.
  • 사용자 정의 YAML 최소화: 사용자에게 혼란을 줄 수 있는 YAML 정의를 최소화함.
  • 서비스 소유자와 긴밀히 협력: 서비스 소유자와 협력하여 모니터링 및 경고를 업데이트함.
  • 적절한 인력 배치: 예상치 못한 문제를 해결할 수 있는 팀을 구성함.

마이그레이션 결과

  • 2024년 1월까지 주요 서비스를 EKS 클러스터로 마이그레이션함.
  • 비용 절감, 신뢰성 향상, 개발자 경험 개선 등의 이점을 얻음.

출시 후 기간

  • 클러스터 및 역할 자동 추론을 통해 사용자 접근 도구를 개선함.
  • 로그 파이프라인 단순화, 수평 포드 자동 확장 지원, Graviton 프로세서로의 마이그레이션 등의 작업을 계획함.

GN⁺의 정리

  • Figma는 ECS에서 Kubernetes로의 마이그레이션을 통해 비용 절감, 신뢰성 향상, 개발자 경험 개선을 달성함.
  • CNCF 생태계의 오픈 소스 기술을 활용하여 자동 확장 및 서비스 메시 도입 가능성을 높임.
  • 마이그레이션 과정에서 로드 테스트, 점진적 롤아웃, 실제 서비스 실행 등의 안전한 방법을 사용함.
  • 출시 후 사용자 접근 도구를 개선하고 추가적인 최적화 작업을 계획함.
▲
neo 3달전  [-]
Hacker News 의견

  • k8s를 좋아하는 사용자가 있음

    • 여러 소규모 복잡한 커스텀 전자상거래 상점을 운영함
    • 마케팅, 재정, 고객 서비스까지 모두 처리함
    • 이전에는 전용 서버를 사용했으나 배포가 악몽이었음
    • k8s로 이동하는 데 한 달이 걸렸음
    • 25개의 다양한 서비스를 운영함
    • 클러스터 구성을 한 곳에 모아 서비스 상태를 정확히 알 수 있게 됨
    • 다운타임 없이 롤링 배포가 가능해졌음
    • 복잡하지만 프로그래머로서 복잡함에 익숙함
    • k8s 아키텍처를 이해하면 더 많은 것을 배울 수 있음
    • 고가용성(HA)이 매우 유용함
    • 월 400달러 정도의 호스팅 비용이 듦

  • 인프라 개선을 위한 마이그레이션이 좋음

    • Helm 차트를 사용하기 위해 Terraform으로 변환하지 않는 것이 놀라움
    • Helm 차트를 수정 없이 사용하는 것이 일관되지 않음
    • Helm은 유지보수가 어려운 도구임
    • Terraform으로 다시 작성하는 것이 더 나음
    • Helm의 문제점이 해결되었는지 궁금함

  • HN에서 많은 반-k8s 의견이 놀라움

    • 많은 댓글 작성자가 Heroku, Fly.io, Render.com 등의 서비스를 사용하거나 VM에서 앱을 실행하는 개발자일 가능성이 있음

  • Terraform과 ECS를 사용한 배포 관리가 과도하게 복잡함

    • 환경 변수를 추가하는 것조차 복잡함
    • 템플릿 생성 부분은 이해하지만, 전체적으로 복잡함

  • Kubernetes로의 마이그레이션이 몇 년이 걸린다는 의견에 의문을 가짐

    • 기업들이 왜 이런 마이그레이션을 시도하는지 이해하지 못함
    • 고객에게 어떤 이익이 있는지 의문임
    • 기술적 욕구에 기반한 결정이 사용자에게 의미가 있는지 의문임

  • 대규모 조직의 결정이 사용자나 회사의 필요에 기반하지 않는 것 같음

    • Figma의 이전 데이터베이스 관련 게시물에서도 비슷한 느낌을 받음
    • 기술적 욕구에 기반한 결정이 사용자에게 의미가 있는지 의문임

  • 현대 시스템이나 서비스 중 1년 이내에 마이그레이션을 자랑할 만한 것이 있는지 궁금함

  • 현장 보고서를 읽는 것을 좋아함

    • 항상 새로운 것을 배움
    • 공유해줘서 고마움

  • 이 기사가 Kubernetes의 이점을 명확하게 설명함

    • 많은 사람들이 이점을 알지 못하고 Kubernetes로 전환함
    • 여기서 제시된 이유는 좋음

  • 마이그레이션을 중단하는 데 얼마나 걸릴지 궁금함

답변달기