Figma가 12개월 이내에 K8s로 마이그레이션한 방법

 (figma.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Figma는 이미 컨테이너화된 핵심 서비스를 ECS에서 EKS 기반 Kubernetes로 옮기며, 다운타임 없이 장기 플랫폼 한계를 줄이는 이전을 목표로 삼음
  • ECS에서는 StatefulSets 부재, Helm chart 기반 OSS 운영 어려움, 노드 격리 제약이 컸고 Kubernetes는 CNCF 생태계와 Keda·Karpenter·Istio 같은 선택지를 열어줌
  • 마이그레이션은 서비스 실행·배포·도구 추상화는 유지하고 오케스트레이션만 바꾸는 방식으로 범위를 좁혔으며, Bazel 기반 서비스 정의와 3개 EKS 클러스터 구성은 초기 범위에 포함함
  • 전환 과정에서는 부하 테스트, Weighted DNS 기반 점진적 트래픽 이전, 실제 서비스 조기 이전, 원시 YAML 은닉, 서비스 오너 협업으로 롤백 가능성을 확보함
  • 2024년 1월까지 최고 우선순위 서비스 대부분이 EKS로 이전됐고, 과잉 프로비저닝 비용 절감·신뢰성 향상·개발자 경험 개선을 얻은 뒤 로깅·자동 확장·Graviton 전환을 이어가고 있음

ECS에서 Kubernetes로 옮긴 이유

  • Figma는 2023년 초 이미 모든 서비스를 컨테이너로 실행하고 있었고, 오케스트레이션 플랫폼으로 AWS Elastic Container Service(ECS)를 사용 중이었음
  • 다음 세대 컴퓨트 플랫폼을 검토하면서 ECS 위에 계속 쌓는 방식은 장기적으로 원하는 기능을 만들기 어렵다고 봄
  • Figma는 수천 개 마이크로서비스를 운영하는 회사가 아니어서 Kubernetes 이전의 범위를 현실적으로 관리할 수 있었음
    • 격리나 성능 때문에 새 서비스가 필요한 경우는 있지만, 핵심 서비스들이 기본적인 모듈화와 트래픽 격리를 제공함
    • 새 제품도 새 서비스를 만들기보다 기존 핵심 서비스 안에 로직을 추가해 지원하는 경우가 많음

ECS에서 부족했던 기능

  • ECS는 Kubernetes의 StatefulSets를 지원하지 않아, etcd 같은 강한 일관성 합의 데이터 저장소 운영이 까다로웠음
    • Figma는 etcd 컨테이너 시작 시점에 클러스터 멤버십을 동적으로 갱신하는 커스텀 코드로 우회함
    • 이 방식은 취약하고 유지보수가 어려웠으며, Kubernetes에서는 StatefulSets의 상태 있는 네트워크 할당을 쓰는 것이 일반적임
  • ECS에서는 Helm charts로 정의된 서비스 묶음을 실행하기 어려웠음
    • 여러 팀이 Temporal 같은 OSS 소프트웨어를 실행하고 싶어 했지만, ECS에서는 각 서비스를 Terraform 정의로 수동 포팅해야 했음
  • ECS on EC2에서 문제가 있는 단일 EC2 머신을 우아하게 종료하는 작업도 번거로웠음
    • EKS에서는 나쁜 노드를 cordon 처리하면 API 서버가 종료 절차를 존중하며 Pod를 다른 머신으로 옮길 수 있음

CNCF 생태계와 플랫폼 선택

  • ECS를 계속 쓰면 Cloud Native Computing Foundation(CNCF) 생태계의 오픈소스 기술을 활용하기 어려웠음
  • 자동 확장은 다음 세대 컴퓨트 플랫폼에서 중요한 관심사였음
    • 당시 Figma는 컨테이너화된 서비스에 자동 확장을 적용하지 않았음
    • 야간과 주말처럼 트래픽이 낮은 시간에도 피크 부하를 처리할 수 있도록 서비스를 프로비저닝해 불필요한 비용이 발생함
    • Kubernetes 생태계의 Keda는 CPU 사용률뿐 아니라 AWS SQS 큐 길이와 Datadog 커스텀 메트릭 기반 확장을 지원함
  • 서비스 메시도 장기적으로 필요할 가능성이 있었음
    • 기존 서비스 간 트래픽은 AWS Application Load Balancers(ALB)와 Network Load Balancers(NLB)를 통해 라우팅됨
    • NLB는 새 타깃 등록과 기존 타깃 제거에 몇 분이 걸려 긴급 배포 속도를 늦추고 사고 평균 복구 시간을 늘림
    • Envoy는 더 높은 커스터마이즈 가능성과 커스텀 필터 실행을 제공함
    • Figma는 이미 주요 서비스 앞단에 독립 Envoy 머신 클러스터를 프록시로 두고, 사고 중 부하를 줄이는 커스텀 필터를 사용한 적이 있음
    • EKS에서는 Istio 같은 오픈소스 선택지가 많지만, ECS에서는 유사 기능을 직접 다시 만들어야 했음

인기 플랫폼이 주는 운영상 이점

  • Figma는 어떤 서비스나 소프트웨어의 최대 사용자가 되지 않으려 함
    • 가장 큰 사용자는 거친 부분과 확장 한계에 가장 먼저 부딪히기 쉬움
    • Kubernetes는 많은 대기업이 거대한 컴퓨트 플랫폼에 사용하고 있어, Figma는 그보다 훨씬 작은 사용자에 속함
  • Kubernetes는 벤더 종속을 줄이는 데 도움이 됨
    • EKS는 벤더가 지원하는 컨트롤 플레인의 장점을 제공함
    • 서비스가 일반적인 Kubernetes에서 실행되도록 작성되므로, 다른 벤더 지원 Kubernetes 플랫폼이나 자체 호스팅 플랫폼으로 옮기는 부담이 크지 않음
  • Kubernetes 경험이 있는 엔지니어를 채용하기 쉬움
    • 기존 경험을 가진 엔지니어가 빠르게 적응하고, Figma에 새로운 결정이 될 수 있는 영역에 맥락을 제공할 수 있음

마이그레이션 범위 설정 원칙

  • 큰 마이그레이션에서는 바꾸려는 핵심 시스템만 교체하고, 플랫폼 사용자에게 보이는 추상화는 가능한 한 유지하는 것이 안전함
  • Figma는 ECS 대신 EKS에서 실행되도록 옮기되, 서비스 실행 방식·배포 방식·서비스 상호작용 도구는 바꾸지 않는 쪽으로 범위를 좁힘
  • 기능 변경처럼 보이지 않는 작업도 2차 효과를 만들 수 있어, 대규모 마이그레이션 일정이 쉽게 커질 수 있음
  • 예외는 두 가지였음
    • 새 시스템이 기존 시스템처럼 동작하게 만들기 위해 과도한 추가 작업이 필요한 경우, 2차 효과를 감수하고 새 방식을 택할 수 있음
    • 나중에 바꾸기 어렵거나 비용이 큰 one-way door 결정은 처음부터 새 방식을 적용할 수 있음

범위에 포함한 개선

  • 개발자 경험

    • 기존 ECS 서비스 정의는 주로 Terraform으로 생성·수정했음
    • Terraform 적용으로 인스턴스 0개짜리 ECS task set 템플릿을 만들고, 이후 배포 과정에서 템플릿을 복제해 이미지 해시를 대체한 뒤 인스턴스 수가 0이 아닌 task set을 ECS에 배포함
    • 환경 변수 하나를 추가할 때도 Terraform 작성·적용 후 배포를 실행해야 했고, 순서를 지키지 않으면 코드에서 환경 변수를 안전하게 사용할 수 없어 버그가 발생함
    • EKS에서는 서비스 정의를 한 곳에 두고 변경을 한 단계로 배포하도록 바꿈
    • Figma는 Bazel 설정 파일로 서비스를 정의하는 단순한 내부 방식을 만들고, 서비스 정의 YAML과 Ingress 같은 구성 YAML을 자동 생성함
    • YAML은 코드 커밋 시 CI 도구에서 생성되고, 사내 배포 시스템을 통해 적용됨

  • 신뢰성

    • 각 서비스에 대해 3개의 EKS 클러스터가 Pod를 실행하고 트래픽을 받도록 구성함
    • 모든 운영이 클러스터 단위로 일어나면 전체 장애를 서비스의 3분의 1 영향으로 줄일 수 있음
    • 재시도 요청이나 비동기 처리가 가능한 서비스에서는 사용자 중단이 최소화되는 경우가 많음
    • 이 구성은 배포 파이프라인 등 운영 복잡도를 크게 높였지만, 나중에 추가하기보다 마이그레이션 시점에 바로 적용할 가치가 있다고 판단함

  • 비용 효율

    • 복잡한 비용 최적화 작업은 마이그레이션 범위에 많이 넣지 않았지만, 노드 자동 확장은 처음부터 지원함
    • ECS on EC2 서비스에서는 배포 중 급증을 처리하기 위해 머신을 과잉 프로비저닝했음
    • EKS에서는 Karpenter를 사용해 수요에 따라 노드를 동적으로 확장·축소함

범위에서 제외한 작업

  • 기존 로깅 파이프라인은 복잡했음
    • 모든 로그를 CloudWatch에 먼저 기록함
    • Lambda가 로그를 읽어 특정 패턴 삭제와 태그 추가 같은 변환을 수행함
    • 이후 Datadog과 Snowflake에 기록함
    • 중간 저장소인 CloudWatch 비용이 커지고 있었음
  • Figma는 EKS 스택에서 사이드카로 로그를 처리하고 전달할 수 있는 CNCF 프로젝트 Vector 도입을 계획함
  • 하지만 로그 포워더 로직을 Vector 설정으로 포팅하는 2차 효과를 감수할 가치가 없다고 보고 마이그레이션 범위에서 제외함
  • Pod 수준 자동 확장도 마이그레이션에 포함하지 않았음
    • 복잡도가 너무 높다고 판단함
    • 나중에 쉽게 추가할 수 있는 작업으로 봄
  • 제외된 작업들은 이후 후속 작업이 됐고, 다른 서비스의 EKS 이전과 병행하면서 개선을 제공할 수 있었음

안전한 실행 방식

  • 기존 ECS 스택이 비교적 안정적이었기 때문에, 새 EKS 스택과 이전 과정도 최소한 그만큼 신뢰성 있어야 했음

  • 부하 테스트

    • Figma는 “Hello, World” 서비스를 만들고, Figma의 가장 큰 서비스와 같은 수의 Pod가 실행되도록 확장함
    • 이 테스트로 전체 플랫폼을 지원하는 핵심 컴퓨트 서비스들의 크기와 스케일을 조정해야 함을 발견함
    • Kyverno는 클러스터 보안 검증 도구로, 충분히 크게 구성되지 않으면 새 Pod 시작을 늦출 수 있었음

  • 점진적 롤아웃

    • Weighted DNS 항목을 사용해 기존 ECS 서비스에서 EKS 대응 서비스로 트래픽을 조금씩 옮김
    • 세밀한 트래픽 전환과 되돌리기 제어가 안전한 마이그레이션의 핵심이었음
    • 예상하지 못한 영향은 알려지지 않은 변곡점에서 발생할 수 있으므로, 영향 범위를 줄이고 빠르게 롤백할 수 있어야 했음

  • 실제 서비스 조기 실행

    • 실제 워크로드를 시스템에 올리면 스테이징만으로는 알 수 없는 많은 것을 배울 수 있음
    • Figma는 스테이징 환경 구축을 끝내기 전에도 서비스 하나를 먼저 이전함
    • 이 조기 이전은 워크로드 실행 능력을 종단 간으로 검증하고 병목과 버그를 찾는 데 도움이 됨

  • YAML 추상화

    • 사용자에게 원시 Kubernetes YAML로 서비스를 직접 정의하게 하면 혼란스러울 수 있음
    • Figma는 사용자에게 golden path를 제공하고, 특별한 경우에만 커스터마이즈할 수 있게 함
    • 사용자가 무엇을 커스터마이즈할 수 있고 해야 하는지 명확히 하면서 기본 일관성을 강제해 유지보수와 향후 변경을 단순화함

  • 서비스 오너 협업과 인력 배치

    • 새 서비스 설정은 플랫폼 팀이 맡았고, 모니터링과 알림 업데이트는 서비스 상태를 가장 잘 아는 서비스 오너와 긴밀히 협업함
    • 마이그레이션 시작 전에도 서비스 오너와 선택지와 트레이드오프를 충분히 논의함
    • 큰 규모의 마이그레이션은 예상하지 못한 문제, 복잡한 상호작용, 일반적인 버그를 만들 수 있어 깊은 기술 전문성과 디버깅 역량을 갖춘 팀이 필요했음

실제 마이그레이션 일정과 결과

  • 2023년 1분기에 계획을 만들고 마이그레이션 진행 동의를 얻음
  • 2023년 2분기에는 스테이징 환경을 만들고 단일 서비스를 이전함
  • 2023년 3분기에는 프로덕션화, 부하 테스트, 추가 서비스 이전 준비에 집중함
  • 2023년 4분기부터 2024년 1월 첫 주까지 서비스 트래픽을 천천히 전환함
  • 2024년 1월까지 최고 우선순위 서비스 대부분을 새 EKS 클러스터로 이전함
    • 핵심 비즈니스 로직을 담은 모놀리스
    • Figma 파일 편집의 멀티플레이어 측면을 처리하는 복잡한 서비스
    • 모든 클라이언트에 실시간 업데이트를 푸시하는 Livegraph 100x 구성 서비스들
  • 결과적으로 배포를 위한 과잉 프로비저닝 비용을 줄이고, 3개 클러스터 실행으로 신뢰성을 높였으며, 개발자 사용성을 개선함
  • 전체 작업은 작은 사고와 낮은 고객 영향으로 진행됨
  • 한 운영자가 프로덕션 클러스터 하나에서 CoreDNS를 파괴하고 재생성하는 작업을 실수로 수행한 사고가 있었음
    • 이전 구성이라면 전체 장애가 됐을 상황임
    • 3개 클러스터 구성에서는 요청의 3분의 1로 영향이 제한됨
    • 대부분의 다운스트림 서비스가 요청을 재시도하면서 최종적으로 성공함

출시 후 도구 개선

  • Figma는 서비스 오너가 클러스터에서 발생하는 일을 디버깅할 수 있도록 도구를 만들었음
    • 실행 중인 인스턴스 수 확인
    • 컨테이너 셸 접속
    • 긴급 스케일링 같은 운영 작업 수행
  • 출시 직후 이 접근 도구가 충분히 사용자 친화적이지 않다는 피드백을 받음
  • 복잡도의 원인은 두 가지였음
    • 3개 클러스터 도입으로 사용자가 여러 클러스터에 걸쳐 명령을 실행하고 명령마다 클러스터 이름을 추가해야 했음
    • Kubernetes RBAC 역할을 활용해 더 세분화된 권한을 제공하면서, 사용자가 자신에게 어떤 역할이 있고 특정 작업에 어떤 역할이 필요한지 이해해야 했음
  • Figma는 다른 작업을 즉시 멈추고 도구가 적절한 클러스터와 역할을 자동 추론하도록 수정함
  • 사용자는 특히 한밤중 긴급 상황에서 역할을 찾는 데 시간을 낭비하지 않아도 됨

다음 단계

  • 남은 서비스 이전을 계속하면서 새 컴퓨트 플랫폼 개선을 병렬로 진행 중임
  • 현재 집중 영역은 다음과 같음
    • 로깅 파이프라인 설계 단순화
    • Keda를 통한 수평 Pod 자동 확장 지원
    • Figma에서 가장 비용이 큰 서비스를 Graviton 프로세서로 이전해 비용을 절감하고, 향후 다른 서비스도 Graviton에서 실행할 경로 마련
  • 아직 깊게 투자하지 못한 영역도 탐색할 계획임
    • 서비스 메시 오퍼링을 살펴보며 네트워킹 스택의 신뢰성과 관측 가능성 개선
    • AWS Controllers for Kubernetes(ACKs)로 더 많은 리소스를 관리해 Terraform 의존을 줄이고 스택을 단순화·통합
    • 개발 환경에서 서비스를 실행하는 방식과 다른 환경에서 실행하는 방식을 통합하기 위해 개발자 경험 팀과 협업

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 개인적으로 Kubernetes를 좋아함. 작지만 복잡한 맞춤형 전자상거래 쇼핑몰 여러 개를 운영하면서, 마케팅·재무·고객지원까지 같이 맡고 있음
    예전에는 전용 서버에서 돌렸는데, 스택이 꽤 복잡해서 배포가 악몽이었고 결국 배포에 대한 부담이 작은 회사의 속도를 늦추고 있었음
    Kubernetes를 배우고 이전하는 데 한 달이 걸렸고, 프론트엔드, 상품 관리자, 물류 대시보드, 배송 경로 최적화, OSRM, ERP, 추천 엔진, 검색 등 약 25개 서비스를 운영함
    클러스터 설정을 한곳에 모으면서 반복 가능한 구조로 정리하게 됐고, 각 서비스의 상태와 실행 중인 버전을 정확히 알 수 있게 됨. 무중단 롤링 배포도 가능해졌고, 복잡하긴 하지만 프로그래머는 원래 복잡한 것을 다룸. Nginx 설정 파일도 복잡함
    깊이 들어갈수록 Kubernetes의 아키텍처가 왜 타당한지 이해하게 되고, 12-factor를 철저히 지키도록 강제함. 수입이 스택의 가용성과 안정성에 직접 연결되어 있다면 고가용성은 단순히 “있으면 좋은 것” 이상임. 호스팅 비용도 월 400달러 정도라 그렇게 비싸지 않음

    • Figma는 이전에도 ECS에서 돌고 있었으니 단순히 전용 서버만 쓰던 것은 아님
      Kubernetes를 믿는 편이지만, 정말 복잡하긴 함. 어려운 문제를 풀어주는 도구임. 멀티 클라우드라면 고민할 필요가 없고, 로컬과 1:1로 대응되는 복잡한 인프라를 원한다면 잘 맞음
      하지만 개발자가 100명 미만이고 AWS에 컨테이너만 배포한다면, 2024년에 ECS + Fargate 대신 EKS를 쓰는 건 제정신이 아니라고 봄
    • 여러 개의 작고 복잡한 맞춤형 전자상거래 쇼핑몰을 운영한다면, Kubernetes의 멀티테넌시 부족은 어떻게 처리하는지 궁금함

  • 인프라 기반을 개선하려는 마이그레이션 자체는 좋음. 다만 동기 중 하나가 팀들이 Terraform으로 변환하지 않고 Helm 차트를 쓰게 하려는 것이었다는 점은 의외였음
    실제로 임의의 Helm 차트를 수정 없이 안정적으로 쓰는 경우를 별로 보지 못했고, 사용을 장려하면 결국 팀들이 차트를 포크하고 수정하게 됨. Helm은 워낙 끔찍한 도구라서 자체 맞춤형 Helm 차트를 유지보수하고 싶지는 않음
    차라리 Terraform으로 다시 작성하는 편이 로컬 버전을 유지보수하기 쉽다고 봄. 반례가 있다면 듣고 싶음. 요즘은 Helm의 indent 4 광기와 다단계 문자열 템플릿 문제가 사라졌을 수도 있으니

    • Helm 차트와 Terraform은 서로 다른 것이라고 봄. Terraform은 S3 버킷, EKS 클러스터, EKS 워커, RDS 같은 클라우드 리소스를 배포하는 데 더 적합함
      Kubernetes 워크로드를 Terraform으로 관리할 수도 있지만 추천하진 않음. Kubernetes 자체에 상태가 있는데 Terraform도 상태를 가지면 Terraform + Kubernetes 조합이 고통스러워짐. Helm은 Kubernetes용으로 만들어졌고 Terraform은 아님
      그렇다고 Helm을 좋아하는 것도 아님. 템플릿화된 YAML은 별로고, indent 4 광기도 여전히 있음. Kustomize는 단순할 때는 좋지만 앱이 복잡해지면 Helm보다 더 나쁘다고 봄. 예를 들어 여러 환경에 대해 Ingress, TLS 인증서, external-dns가 있는 앱을 배포하려면, 한 변수를 세 군데에서 쓰면 될 일을 리소스를 세 번 패치해야 함
      Helm도 Terraform도 인기가 많아서 많이 언급되지만, 결국 이 둘을 대체할 아직 대중화되지 않은 도구가 나올 것 같음
    • 현재 다니는 BigCo에서는 Terraform으로 인프라와 배포를 모두 터무니없는 규모로 관리하는데, 악몽임
      Terraform의 문제는 워크스페이스당 권장 리소스 수인 약 100~200개를 넘지 않도록 워크스페이스를 설계해야 한다는 점임. 그렇지 않으면 건드리지도 않았고 건드릴 생각도 없는 데이터베이스나 네트워크까지 확인하느라 plan이 크게 느려져 배포 시간이 늘어남
      실제로는 서로를 트리거하는 Terraform 워크스페이스 격자를 만들게 되는데, 이를 제대로 지원하는 좋은 오픈소스 도구가 현재 없음
      지금 보기에 최선은 Terraform이 ArgoCD 같은 지속적 배포 도구를 인프라 일부로 설치하고, 일상적인 배포는 CD 도구가 맡게 하는 것임. 그리고 대부분의 CD 도구는 배포를 Helm 같은 것으로 패키징하라고 요구함
    • Helm 얘기를 하자면, 개인적으로 이제는 깊이 혐오하게 됨. 처음 나왔을 때는 훌륭했고 필요한 공백을 채워줬음
      하지만 너무 많은 함정이 있어서 다른 엔지니어들이 만든 작업을 다시 하고 디버깅하는 데 시간을 쓰게 됨
      timoni라는 새 도구가 탄력을 받길 바람. Helm에 대해 가진 거의 모든 불만을 해결해줌. 더 나은 해법을 찾고 있다면 timoni를 확인해볼 만함
    • 우리 팀도 공개 Helm 차트에서 말한 문제들을 겪었음. 자기 환경에서 제대로 동작시키려면 항상 뭔가를 커스터마이즈해야 함
      우리는 공개 Helm 차트는 그대로 쓰고, 커스터마이징은 kustomize —enable-helm로 처리하는 방식을 택했음
    • Helm 차트를 작성하는 일이 딱히 즐겁지는 않다는 데 동의하지만, 사용하는 쪽은 꽤 괜찮을 수 있음
      우리 경우에는 합리적인 기본값을 제공하는 단일 애플리케이션/서비스 기반 Helm 차트가 있고, 모든 배포가 이를 확장함. 사용하는 쪽에서 필요한 Helm values 설정은 최소이고, 자체 템플릿을 넣어야 했던 경우도 거의 없음. 기반 차트가 충분한 조절 지점을 노출하기 때문임
      서드파티 차트는 상당수를 그대로 배포할 수 있었고, 가끔 필요한 기능을 upstream에 PR로 추가했음. 드물게 래핑하거나 포크해야 했지만, 그대로 배포한 서드파티 차트가 훨씬 많음
      커스텀 차트를 유지보수할 때는 helm unittest (https://github.com/helm-unittest/helm-unittest)가 회귀를 피하는 데 큰 도움이 됨
      Terraform으로 ArgoCD를 포함한 몇몇 Kubernetes 리소스를 관리하긴 하지만, 일반적으로는 ArgoCD를 통해 Helm 차트를 배포하는 방식이 훨씬 관리하기 쉽고 생산적이었음

  • HN에서 이렇게 반 Kubernetes 정서가 많은 게 의아함. 대부분의 댓글 작성자가 Heroku, fly.io, render.com 같은 서비스에 익숙한 개발자라서인지, 아니면 VM에서 앱을 돌려서인지 궁금함

    • 지난 10년쯤 소프트웨어에서 불필요한 복잡성이 폭발한 데 질린 사람이 많고, 그럴 만도 함
      이는 특정 사례에 한정된 문제가 아니라 업계 전반의 심하게 어긋난 인센티브와 어느 정도의 저금리 시대 골드러시가 만든 문제임
      솔직히 지금 모습대로라면 다른 분야에서는 꽤 쓸모없는 장인으로 보일 것 같음. 도구와 메타 작업에 건강하지 못하게 집착하면서, 특정 도구를 쓰기 위해 합리적인 자원 사용은 계속 창밖으로 던져버림. 일종의 “잠시 곤란한 처지에 놓인 FAANG 엔지니어” 같은 상황임
    • 개인적으로는 상상 속의 이론적 비즈니스 요구, 예를 들어 언젠가 멀티 클라우드가 필요하다거나 온프레미스 배포가 필요할 수 있다는 이유 때문에 Kubernetes를 쓰자는 데 약간 짜증이 남
      AWS에서 선택할 수 있는 배포 모델, 예컨대 EC2의 VM 이미지, Elastic Beanstalk, ECS/Fargate, Lambda 대신 Kubernetes 위에 구축하면 얼마나 더 오래 걸리고, 얼마나 더 많은 전문성이 필요하고, 얼마나 더 취약해지고, 얼마나 더 많은 돈이 드는지 설명하기가 어려움
      직접 ELK 스택이나 Prometheus를 설치·유지하고 싶지 않음. CNI 플러그인, Kafka, 고가용성 Postgres, Argo, Helm, 컨트롤 플레인 업그레이드와 씨름하고 싶지도 않음. AWS의 대응 서비스로는 거의 즉시 시작할 수 있고 유지보수도 거의 없으며 비용도 보통 0에 가까운 지점에서 선형적으로 시작함
      비즈니스 문제를 훨씬 빠르고 효율적으로 풀 수 있음. 기대치를 크게 뛰어넘을 수 있는 상황과 팀 전체가 몇 분기씩 뒤처지는 상황의 차이임
      다만 진짜 멀티 클라우드나 온프레미스 요구가 있다면 Kubernetes 말고는 쓰고 싶지 않음. Kubernetes를 이해하는 숙련된 엔지니어가 많은 큰 회사라면 그렇게 나쁘지 않을 수도 있음. 적어도 내가 일한 곳들은 그렇지 않았음
    • 싫어하는 사람이 많다는 건 어떤 면에서는 성공의 신호이기도 함
      기업들이 주로 오픈소스 인프라로 옮겨가는 모습을 보는 건 좋음. 그중 상당수는 CNCF (https://landscape.cncf.io), ASF, 그리고 GitHub의 여러 프로젝트에서 나옴
    • 어떤 상황에서는 쓸 가치가 있지만, 너무 자주 카고 컬트처럼 도입되는 기술 중 하나임
    • 나에게는 VM 쪽 문제가 큼. 커널 취약점이 있으면 악성 코드가 컨테이너를 탈출해 Kubernetes 호스트를 뒤질 수 있다는 생각이 불편함
      kata-containers가 그 불안을 해결해주고 Kubernetes를 즐기게 해줄 수도 있을 것 같음
      전반적으로 Kubernetes에는 개인적으로 멋지다고 느껴지는 게 없음. 컨테이너, 로드 밸런서, 메가바이트 단위 YAML은 이미 다 봤고, 시도해볼 만큼 흥미로운 느낌이 들지 않음

  • 이 정도 규모의 회사에서는 정상일 수도 있지만, 이런 거대한 마이그레이션이나 기술 프로젝트의 의사결정을 따라가기 어렵다. 결정이 사용자나 회사의 필요에서 나온 것처럼 보이지 않기 때문임
    Figma가 예전에 데이터베이스 관련으로 올린 비슷한 글에서도 같은 느낌을 받았음
    예를 들어 Kubernetes로 가고 싶은 이유가 ECS에서는 etcd/Helm을 쓸 수 없기 때문이라면, 왜 etcd/Helm을 쓰고 싶은지부터 물어야 함. 그게 정말 그렇게 중요한가? 회사의 목표를 달성하는 방법이 정말 정확히 그 방식뿐인가?
    결정이 사용자의 욕구에 기반하면 하위 결정들이 타당한지 검증하기 쉽지만, 기술적 욕구에 기반하면 그 기술적 욕구의 맥락에서는 하위 결정들이 그럴듯해 보여도 여전히 사용자 맥락에서 타당한지는 불확실함
    내가 이 규모의 조직을 이해하지 못하는 것이거나, 이 규모의 조직이 가치 있는 일을 식별하고 추론하는 것 자체가 근본적으로 어려운 것이거나 둘 중 하나 같음

    • 글쓴이인데, 좋은 질문이고 프레이밍도 좋다고 봄. 적어도 이 결정을 포함한 몇몇 큰 결정에서는 “이 규모의 조직이 가치 있는 일을 식별하고 추론하는 것이 근본적으로 어렵다”는 말에 동의함
      우리는 본질적으로 플랫폼 팀이고, 실제 제품 경험을 만드는 Figma 개발자들을 지원하는 도구를 만드는 다른 플랫폼 팀을 위한 도구를 만들 때가 많음. 최종 사용자에서 멀어질수록 올바른 결정을 추론하기가 더 어려워지지만, 동시에 큰 레버리지도 생김
      플랫폼을 제대로 만들면 그 효과가 다른 모든 엔지니어가 효율적이고 효과적으로 일하는 능력에 영향을 줌. 그중 많은 영향은 간접적임
      etcd와 Helm을 지원할 수 없으니 다른 우회 방법을 찾으라고 하는 선택지도 분명 있었음. 다만 이 둘은 우리가 Compute 플랫폼을 잘못된 기본 구성 요소 위에서 운영하고 있다는 결론으로 밀어붙인 추가 데이터 포인트였음
      추론이 어렵더라도 잘하려고 노력할 가치가 큼. 플랫폼 팀으로서 최고의 플랫폼에 도달하기 위해 올바른 일을 하고 있는지 확인하는 방법이기 때문임. 그래서 이 결정을 내리는 데 많은 시간을 썼고, 글로 쓰기에 흥미로운 주제라고 생각했음
    • 사람들이 ECS에서 Kubernetes로 옮기는 이유는 클라우드 제공자에 종속되지 않는 도구와 제품을 쓰기 위해서임
      큰 회사의 Kubernetes 마이그레이션 상당수는 멀티 클라우드나 온프레미스 하이브리드에 대한 욕구, 비용·가용성·락인 위험 완화가 동력일 가능성이 큼
    • VM 500대 이상을 관리하는 건 일이 많음
      VM 업그레이드, 인증, 백업, 로그 로테이션 등을 모두 맞춰야 함
      Kubernetes에서는 각자에게 네임스페이스, 정책, 볼륨을 주고, DaemonSet과 Kubernetes/클라우드 네이티브 스택 덕분에 자동 로그 집계도 가능함
      자가 치유 등도 있고, 얼마나 나아지는지 설명하기 어려울 정도임
    • Helm을 좋아하진 않지만, etcd의 좋은 대안은 놀라울 정도로 적음
      예컨대 분산 환경의 .pid 파일에 해당하는 용도로 쓸 수 있는 고가용성이면서 일관성 있는 데이터 저장소가 별로 없음. 떠오르는 건 Zookeeper 정도인데, 운영 측면에서 정말 고통스럽고 오래된 JVM 버전을 요구하며 그럼에도 전반적으로 불안정함
    • 이런 일이 왜 생기는지에 대한 이론은 여기 있음: https://lethain.com/grand-migration/

  • Terraform 코드가 적용되면 인스턴스 0개짜리 ECS task set을 만들어 서비스 템플릿을 띄우고, 이후 개발자가 서비스를 배포하면서 이 템플릿 task set을 복제하고 여러 수동 작업을 해야 했다는 부분은 ECS의 문제라기보다 Terraform + ECS 배포 관리 방식을 과하게 복잡하게 만든 것처럼 들림
    실제 배포 전에 검증하려고 템플릿을 생성하는 부분은 이해함. 하지만 이건 좀 애매함

    • 글쓴이인데, 이것이 ECS의 근본적인 한계가 아니라는 데 전적으로 동의함. 이 설정을 계속 개선해서 더 나은 것으로 만들 수도 있었음
      그래서 이 항목을 마이그레이션 과정에 포함하기로 한 작업으로 의도적으로 분류했고, 마이그레이션을 시작한 근본적인 이유에는 넣지 않았음
    • 동의함. ECS 배포는 꽤 고통 없고 단순함
      다만 이 방식이 필요해지는 몇 가지 시나리오는 상상할 수 있음. 예를 들어 ECS에 배포된 서비스가 많아서 Terraform 상태 크기가 커지는 경우임. 그러면 plan과 apply가 크게 느려지고, 템플릿 기반으로 구성을 그대로 복제해 Terraform 상태를 샤딩하는 편이 훨씬 안전해질 수 있음
    • 정말 동의함. 두 회사에서 Terraform으로 ECS 인프라를 구축했는데, 이런 작업에 수동 단계는 전혀 없었음
      환경 변수를 Terraform 파일에 추가하고, 머지한 뒤 CI가 배포하게 하는 정도가 전부였음. 우리가 하는 대부분의 설정 변경은 그 과정으로 처리됐음

  • “Kubernetes로 마이그레이션하는 데 몇 년이 걸릴 수 있다”니 대체 뭘 읽고 있는 건지 모르겠음
    누구에게 그렇다는 건가? 회사들이 왜 이런 마이그레이션을 굳이 하는지도 잘 모르겠음. 비즈니스 가치는 어디 있고, 고객에게 주는 이득은 어디 있나? Figma가 할 수 있으니까 하는 “예술을 위한 예술” 프로젝트 같은 건가?

    • 나도 이 문장에 꽤 놀랐고, 1년 안에 Kubernetes로 옮겼다고 자랑하는 듯한 부분도 놀라웠음
      약 30년 된, 그에 따른 짐이 있는 매우 자리 잡힌 회사에서도 우리는 훨씬 짧은 시간에 Kubernetes로 옮겼음. 다만 모든 것을 Kubernetes로 옮기려 하지 않았고, 이득을 볼 수 있는 것만 옮겼음
      우리의 제안은 대략 이랬음. Kubernetes로 옮기면 연말에 계획된 데이터센터 이전 때 점검 말고는 아무것도 할 필요가 없음. 아니면 새 머신이나 VM에 앱을 재배포하고 그에 따른 온갖 골칫거리를 처리해야 함. 이미 컨테이너화되어 있지 않다면 지금 컨테이너화하면 나머지는 우리가 처리함
      대부분이 이전했고 결과에 매우 만족했음. 반면 지연 시간에 민감하거나 고성능 컴퓨팅 영역에 있는 서비스들은 억지로 옮길 이유가 없었고, 끼워 맞추려는 시도도 하지 않았음
    • “최근 인수됐고, 써야 할 리소스가 많다”는 문제를 해결해줌

  • 여기서 벗어나는 데는 얼마나 걸릴까?

    • 얼마나 많은 Kubernetes 네이티브 코드가 있느냐에 달림. Kubernetes API를 많이 사용하는, Kubernetes에서 실행되도록 설계된 애플리케이션도 있음
      앱이 이미 마이크로서비스화되어 있다면 다시 되돌리는 것도 간단하지 않음

  • 처음 들어보는 멋진 이름의 CNCF 프로젝트 6개를, 겉보기에는 단순한 기능을 얻기 위해 아무렇지 않게 언급하는 블로그 글을 읽으면 내가 시대에 뒤처진 느낌이 듦
    전문 소프트웨어 개발에서 나이가 들어 퇴장할 때가 된 건지 진지하게 궁금해짐

    • 그렇진 않음. 개별 기여자 일이 여전히 많음
      단지 조직 확장의 한 접근법, 즉 플랫폼 팀이 하드웨어, 로깅, 재시도 등을 추상화하는 방식에 익숙하지 않다는 뜻일 뿐임
      유일한 접근법은 아니니 다른 방식에는 익숙할 수도 있음

  • 이 글은 Kubernetes로 얻을 이득과 이유를 명확하고 조리 있게 설명해서 좋음
    많은 팀이 무엇을 얻는지도, 애초에 필요한지도 모른 채 뛰어드는데, 여기서 제시한 이유들은 괜찮아 보임

  • 순수한 궁금증인데, 제정신인 사람이 1년 안에 마이그레이션했다고 자랑할 만한 다른 현대적 시스템이나 서비스가 뭐가 있을까?

    • 답하기 어려운 질문임. 모든 시스템이 규모, 범위, 영향 면에서 같지는 않음
      Kubernetes 같은 시스템은 대개 인프라의 핵심이라 실행 중인 모든 것에 영향을 줌. 여기에 글에서 나온 팀 제약까지 더하면 1년이 그렇게 나쁘게 들리진 않음
      바로 떠오르는 예로는 예전에 Amazon이 Oracle에서 완전히 Amazon/오픈소스 관계형 데이터베이스로 옮긴 일이 있음. 다만 그건 여러 해가 걸렸던 것으로 기억함. 1년 안에 끝냈다면 분명 자랑했을 것임
    • 1년 넘게 걸리는 마이그레이션은 많이 봤음
      기술 자체보다 기술 부채, 통합 복잡도, 투입 인력의 문제인 경우가 더 큼
답변달기