techlist.io
KREN
figma

12개월 이내에 K8 (새 탭에서 열림)

k8sterraformcontainershelmservice-meshenvoyaws-eksautoscaling

Figma는 ECS에서 Kubernetes(EKS)로 이전해 플랫폼의 기능과 확장성을 높이기로 결정했고, 핵심 서비스 대부분을 12개월 이내에 안전하게 옮겼습니다. ECS의 StatefulSet·Helm 지원 부족과 운영상의 불편, CNCF 생태계 활용 한계가 주요 전환 이유였습니다. 특히 Figma는 수천 개의 마이크로서비스를 운영하는 구조가 아니었기 때문에 대규모 마이그레이션의 범위를 현실적으로 통제할 수 있었습니다.

기존 Figma의 컴퓨트 플랫폼

  • 2023년 초 Figma의 모든 서비스는 이미 컨테이너화되어 있었고, AWS ECS에서 실행되고 있었습니다.
  • ECS는 컨테이너 워크로드를 빠르게 운영하기에 좋은 플랫폼이었지만, 장기적으로 필요한 기능을 확장하기에는 한계가 있었습니다.
  • Figma는 모든 기능을 별도 마이크로서비스로 분리하지 않았습니다.
    • 성능이나 격리가 필요한 경우에만 새 서비스를 만들었습니다.
    • 대부분의 제품 기능은 기존 핵심 서비스에 로직을 추가하는 방식으로 구현했습니다.
  • 따라서 Kubernetes 전환 대상 서비스 수가 수천 개에 달하지 않았고, 이전 작업의 범위를 관리할 수 있었습니다.

ECS에서 겪은 기능적 한계

  • StatefulSet 부재

    • ECS에는 Kubernetes의 StatefulSet처럼 파드에 지속적인 식별자와 네트워크 정체성을 제공하는 기능이 없었습니다.
    • Figma는 ECS에서 etcd 클러스터를 운영하기 위해 컨테이너 시작 시 클러스터 멤버십을 동적으로 갱신하는 커스텀 코드를 작성했습니다.
    • 이 방식은 취약하고 유지보수가 어려웠습니다.
    • Kubernetes에서는 StatefulSet을 이용해 etcd 인스턴스의 안정적인 네트워크 정체성을 제공할 수 있습니다.

  • Helm 차트 활용 부족

    • Temporal 같은 오픈소스 소프트웨어를 도입하려면 ECS 환경에 맞게 각 서비스를 Terraform으로 직접 포팅해야 했습니다.
    • Kubernetes에서는 Helm 차트를 통해 관련 서비스와 설정을 표준화된 방식으로 설치하고 관리할 수 있습니다.

  • 노드 장애 대응의 불편

    • ECS on EC2에서 문제가 있는 EC2 인스턴스 하나를 우아하게 종료하는 작업이 복잡했습니다.
    • EKS에서는 노드를 cordon 처리한 뒤 API 서버가 파드를 다른 노드로 이동시키도록 할 수 있습니다.
    • 이 과정에서 파드의 정상 종료 절차도 준수할 수 있습니다.

CNCF 생태계 활용

  • ECS를 계속 사용하면 Kubernetes와 함께 발전한 CNCF 오픈소스 생태계를 충분히 활용하기 어려웠습니다.
  • Figma가 특히 관심을 가진 영역은 자동 확장이었습니다.
    • 당시 컨테이너 서비스에 자동 확장을 적용하지 않아, 야간이나 주말처럼 트래픽이 낮은 시간에도 최대 부하를 감당할 자원을 미리 provision해야 했습니다.
    • 그 결과 불필요한 인프라 비용이 발생했습니다.
  • Kubernetes 생태계의 KEDA는 다음과 같은 기준으로 자동 확장을 지원합니다.
    • CPU 사용률
    • AWS SQS 큐 길이
    • Datadog의 커스텀 메트릭
  • ECS에도 일부 자동 확장 기능은 있지만, Figma는 Kubernetes 생태계의 성숙한 오픈소스 도구를 활용하는 편이 장기적으로 유리하다고 판단했습니다.

서비스 메시와 트래픽 처리

  • Figma는 서비스 간 트래픽을 AWS ALB와 NLB를 통해 라우팅하고 있었습니다.
  • NLB에서 새 대상을 등록하거나 기존 대상을 제거하는 데 몇 분이 걸려 긴급 배포와 장애 복구가 느려지는 문제가 있었습니다.
  • Figma는 이미 주요 서비스 앞에 독립적인 Envoy 프록시 클러스터를 운영하고 있었습니다.
    • 장애 상황에서 부하를 줄이는 커스텀 필터를 적용하기 위한 목적이었습니다.
  • 장기적으로는 전체 서비스에 Envoy 기반 서비스 메시를 도입할 가능성이 있다고 보았습니다.
  • EKS에서는 Istio 같은 서비스 메시 솔루션을 활용할 수 있지만, ECS에서는 이런 생태계를 직접 구축하거나 많은 부분을 커스텀 구현해야 했습니다.

전환을 결정한 기준

  • 단순히 새로운 기술을 도입하는 것이 아니라, 다음 세 가지를 종합해 판단했습니다.
    • 현재 ECS에서 발생하는 운영 및 개발 비용
    • 자동 확장과 서비스 메시 등 미래 요구사항
    • 마이그레이션을 합리적인 기간 안에 완료할 수 있는지 여부
  • Figma는 대규모 작업이 플랫폼을 실제로 개선하고, 사용자에게 다운타임을 유발하지 않으면서 완료될 수 있어야 한다는 원칙을 강조했습니다.
  • 결론적으로 Kubernetes는 StatefulSet, Helm, 자동 확장, 서비스 메시 등 Figma가 필요로 하던 기능을 더 자연스럽게 제공하는 기반으로 평가되었습니다.

Figma와 유사하게 컨테이너 기반 서비스를 운영하면서 ECS의 기능적 한계가 커지고 있다면 Kubernetes 전환을 검토할 수 있습니다. 다만 서비스 수와 운영 복잡도를 먼저 평가하고, 자동 확장·상태 저장 워크로드·트래픽 관리처럼 실제로 필요한 기능을 기준으로 이전의 효과를 판단하는 것이 바람직합니다.