kakao2026년 8월 6일

개인화된 Airflow 테스트 환경 구축 및 운영 경험 (새 탭에서 열림)

수천 개의 Airflow DAG를 운영하는 카카오 데이터서비스 조직은 테스트 과정의 반복 작업과 환경 간 차이, 리소스 충돌 문제를 해결하기 위해 PR 단위의 개인 Airflow 환경인 AirZone을 구축했습니다. AirZone은 GitHub PR 코멘트에서 생성·삭제를 요청하면 Kubernetes Job과 전용 Helm 차트로 격리된 Airflow를 배포합니다. 사용자는 인프라를 직접 구성하지 않고 실제 운영 환경과 유사한 하둡·인증 환경에서 DAG를 테스트할 수 있습니다. ## 기존 테스트 방식의 한계 - **로컬 Airflow** - Airflow뿐 아니라 하둡 인증, 연결 설정, Docker 환경까지 직접 구성해야 합니다. - 초기 구축 비용이 크고, 로컬 환경과 운영 환경의 차이로 인해 실제 배포 후 실패할 수 있습니다. - **개발용 Airflow** - 코드를 커밋하고 푸시한 뒤 GitHub webhook, submodule 업데이트, DAG 파일 처리 과정을 기다려야 합니다. - DAG를 수정할 때마다 동기화 지연이 반복되어 개발 속도를 떨어뜨렸습니다. - **테스트용 Airflow** - SSH 컨테이너에 로컬 파일을 복사해야 하므로 코드 수정 때마다 추가 작업이 필요합니다. - 실제 데이터와 하둡에 접근하려면 prod VPN을 연결해야 하는 불편도 있었습니다. - **Production Airflow에서의 테스트** - 테스트 DAG가 스케줄러와 워커 자원을 점유해 다른 프로젝트의 실행을 지연시킬 수 있습니다. - 과도한 리소스 사용으로 노드 장애가 발생하면 같은 노드의 다른 태스크까지 중단될 위험이 있습니다. ## AirZone의 핵심 요구사항 - Kubernetes나 Helm을 몰라도 브라우저에서 Airflow 환경을 생성하고 삭제할 수 있어야 합니다. - 사용자는 DAG 검증에만 집중하고, 인프라 구성은 AirZone이 담당해야 합니다. - Jupyter Notebook을 제공해 별도 로컬 환경 없이 코드를 수정할 수 있어야 합니다. - 운영 환경과 유사한 DAG 실행 환경과 하둡 인증 방식을 제공해야 합니다. - PR마다 독립된 Airflow를 생성해 사용자와 테스트 작업을 서로 격리해야 합니다. ## PR 단위의 격리된 환경 - 레포지터리명과 PR 번호를 조합해 Kubernetes 네임스페이스를 생성합니다. - Airflow 웹 서버, 스케줄러, PostgreSQL, Jupyter, DAG PVC, 로그가 PR별로 분리됩니다. - 한 PR의 테스트가 다른 프로젝트의 스케줄러·워커 자원을 침범하지 않습니다. - 리뷰어는 PR에 남은 링크로 특정 코드 상태의 실행 결과를 직접 확인할 수 있습니다. - PR이 종료되면 네임스페이스를 기준으로 관련 리소스를 쉽게 정리할 수 있습니다. ## 요청 처리와 배포 작업의 분리 - `airzone-api`는 PR 존재 여부, PR이 열려 있는지, 네임스페이스 중복 여부 등 요청의 유효성만 검증합니다. - 실제 Helm 설치와 헬스체크는 별도의 Kubernetes Job이 수행합니다. - API가 수 분이 걸리는 배포 작업을 직접 기다리지 않으므로 빠르게 응답할 수 있습니다. - Job별로 상태와 로그가 독립적으로 남아 실패 단계와 원인을 추적하기 쉽습니다. - 실패한 Job을 삭제한 뒤 새 Job을 생성하는 방식으로 배포를 재시도할 수 있습니다. - 생성 요청은 `create-airzone-{namespace}`, 삭제 요청은 `delete-airzone-{namespace}` 형식의 Job 이름을 사용합니다. ## GitHub PR 코멘트를 사용자 인터페이스로 활용 - PR 생성 이벤트를 webhook으로 받아 저장소, 브랜치, PR 번호, 요청자 정보를 확인합니다. - 사용자가 선택할 수 있도록 하둡 환경별 AirZone 생성 링크를 PR 코멘트에 남깁니다. - 생성 완료 결과와 접속 정보도 PR에 표시해 별도 플랫폼 없이 테스트를 시작할 수 있습니다. - 다만 Jupyter 토큰과 Kubernetes 네임스페이스 토큰처럼 민감한 정보는 공개 범위가 넓은 PR 대신 카카오워크로 전달합니다. - 요청 접수와 배포 완료 시점에 카카오워크 알림을 보내 진행 상태를 알립니다. ## 전용 Helm 차트로 구성한 Airflow 기존 운영용 Airflow 차트가 아닌 AirZone 전용 Helm 차트를 만들어 테스트 환경에 필요한 구성만 묶었습니다. - **Airflow 구성** - 웹 서버와 스케줄러를 배포합니다. - `KubernetesExecutor`, DAG 스캔 주기, 로그 설정, 하둡 관련 변수를 테스트 환경에 맞게 설정합니다. - **데이터베이스와 저장소** - 개인 환경용 PostgreSQL을 함께 배포합니다. - scheduler와 Jupyter가 같은 DAG 작업 디렉터리를 사용하도록 DAG PVC를 공유합니다. - **DAG 동기화** - PR의 head repository와 branch 정보를 받아 해당 코드만 동기화합니다. - Git 초기화 컨테이너 등을 통해 배포 환경에 테스트 대상 DAG를 준비합니다. - **인증과 보안** - 사용자·공용 principal, 키탭, Jupyter 토큰을 환경에 주입합니다. - 하둡 접근에 필요한 Kerberos 인증을 운영 환경과 유사하게 구성합니다. - dkos에서 제공하는 TLS 인증서도 테스트 환경에 반영합니다. - **운영 연동** - 여유 있는 노드 그룹과 같은 리전의 `storageClass`를 선택합니다. - Airflow 로그를 Elasticsearch와 Kibana에서 확인할 수 있도록 연결 정보를 주입합니다. - Jupyter를 함께 제공해 브라우저에서 DAG와 관련 코드를 수정할 수 있게 합니다. ## 자동 정리와 운영 구조 - 생성·삭제 요청은 Kubernetes Job으로 처리합니다. - PR 종료 후 남아 있는 AirZone은 매일 실행되는 CronJob이 자동으로 회수합니다. - 사용자에게는 “PR 코멘트의 링크를 누르는 기능”으로 단순하게 보이지만, 운영자는 요청·설치·헬스체크·알림·정리 단계를 각각 추적할 수 있습니다. - 운영 환경에서 불필요한 PGBouncer나 외부 DB 연결 등은 제외해 개인 테스트 환경의 복잡도와 비용을 줄였습니다. AirZone과 같은 구조를 도입할 때는 테스트 환경을 운영 환경과 최대한 유사하게 유지하되, PR 또는 브랜치 단위로 리소스를 격리하는 것이 중요합니다. 또한 긴 배포 작업은 API 요청과 분리하고, Kubernetes Job의 상태·로그·재시도 기능을 활용하면 장애 대응과 운영 추적이 훨씬 쉬워집니다.

helmk8spostgresqlapache-spark+3

gitlab2026년 7월 8일

GitLab 패치 릴리스: 19.1.2, 19.0.4, 18.11.7 | GitLab 문서 (새 탭에서 열림)

2026년 7월 8일 GitLab은 CE/EE용 패치 버전 19.1.2, 19.0.4, 18.11.7을 출시했다. 이번 릴리스는 XSS·HTML 인젝션·권한 우회·자격 증명 노출 등 여러 보안 취약점과 버그를 수정했으며, 자체 호스팅 사용자는 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐고, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 정기 릴리스와 고위험 취약점에 대응하는 비정기 긴급 패치로 나뉜다. - 정기 패치는 매월 둘째·넷째 수요일에 배포된다. - 영향을 받는 모든 자체 관리형 설치 환경은 Omnibus, 소스 코드, Helm Chart 등 배포 방식과 관계없이 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점 상세 이슈는 수정 버전 출시 후 90일이 지나면 공개된다. ## 취약점: XSS와 HTML 인젝션 - **CVE-2026-6896** - GitLab EE의 취약점 증거 테이블 렌더러에서 사용자 입력 sanitization이 충분하지 않았던 문제다. - Developer 권한의 인증 사용자가 다른 사용자의 브라우저 세션에서 임의 스크립트를 실행할 수 있었다. - CVSS 8.7로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - EE 13.11 이후 버전 중 18.11.7, 19.0.4, 19.1.2 이전 버전에 영향을 준다. - **CVE-2026-13320** - CE/EE의 Wiki 마크업 렌더링 과정에서 HTML 인젝션이 가능했던 문제다. - 인증 사용자가 다른 사용자의 브라우저 세션에서 스크립트를 실행할 수 있었다. - CVSS 7.3이며, 높은 권한과 특정 조건이 필요하다. - CE/EE 15.7 이후 버전 중 각 패치 버전 이전 릴리스가 영향을 받는다. ## 자격 증명 및 저장소 보안 문제 - **CVE-2026-11827** - EE 저장소 미러링 기능의 권한 검사가 부족했다. - Maintainer 권한 사용자가 다른 사용자의 저장된 자격 증명을 획득할 수 있었다. - CVSS 4.9이며, EE 9.5 이후 버전에 영향을 준다. - **CVE-2025-12506** - Git 태그·브랜치 이름 해석이 모호하게 처리되는 문제다. - 공격자가 웹 인터페이스에 표시되는 저장소 내용과 다운로드 가능한 실제 내용이 다르게 보이는 저장소를 만들 수 있었다. - CE/EE 16.5 이후 버전에 영향을 주며 CVSS는 3.5다. ## 권한 검증 및 정보 노출 문제 - **CVE-2026-8472** - EE Work Items 기능에서 비공개 프로젝트의 메타데이터 접근 권한 검사가 누락됐다. - 최소 권한을 가진 인증 사용자가 비공개 프로젝트의 Work Item 정보를 읽을 수 있었다. - CVSS 4.3이다. - **CVE-2026-7492** - 커밋 토론 표시와 프로젝트 간 참조 페이지에서 권한 검사가 제대로 이뤄지지 않았다. - 비인증 사용자가 비공개 프로젝트의 존재 여부를 추론할 수 있었다. - CE/EE에 영향을 주며 CVSS는 4.3이다. - **CVE-2026-13151** - EE 그룹 수준 설정에 대한 권한 검사가 부정확했다. - 인증 사용자가 자신의 권한 범위를 넘어 그룹 설정을 수정할 수 있었다. - CVSS 2.7이며 GitLab 내부에서 발견됐다. - **CVE-2026-6352** - EE의 컴플라이언스 위반 관리 GraphQL 작업에서 권한 검사가 부족했다. - Auditor 수준 사용자가 컴플라이언스 위반 기록을 수정할 수 있었다. - CVSS 2.7이다. ## 버그 수정 및 기술 변경 ### 19.1.2 - OAuth 애플리케이션 등록 및 생성 시 `organization_id`를 설정하도록 수정했다. - 제약 조건 검증 전에 `oauth_applications`의 `NULL organization_id` 값을 보완하는 백필을 추가했다. - Go 버전을 1.25.11로 업데이트했다. - 멀티 아키텍처 태그를 레거시 레지스트리 경로에서 처리할 때 발생하던 HTTP 500 오류를 수정했다. - 외부 에이전트 흐름에서 커밋 작성자와 커미터의 신원을 사용하도록 개선했다. - ClickHouse 23.x에서 `ci_finished_builds` 엔진 교체가 동작하도록 수정했다. - Duo Workflow 이벤트 조회를 최신 체크포인트로 제한하고 커서 페이지네이션을 적용했다. - Developer가 작성한 Merge Request의 승인 규칙 재정의 회귀 문제를 수정했다. - 커밋 설명을 지나치게 미리 가져오면서 발생하던 커밋 페이지 메모리 누수를 해결했다. - 더 이상 필요하지 않은 `ActiveUserCountThresholdWorker` cron 스케줄을 제거했다. - 레지스트리 인증, OAuth 처리, 빌더 이미지 리비전 등 관련 구성도 백포트 및 조정했다. ### 19.0.4 및 18.11.7 - 19.0.4에도 OAuth 애플리케이션 등록 시 `organization_id`를 설정하는 수정이 백포트됐다. - CI_JOB_TOKEN을 이용한 레지스트리 인증 방식과 같은 일부 수정 사항이 19.0 안정화 브랜치에 반영됐다. - 18.11.7은 위 보안 취약점들이 수정된 18.11 계열의 권장 패치 버전이다. ## 실용적인 권장 사항 자체 호스팅 GitLab 운영자는 현재 지원 중인 계열에 맞춰 **19.1.2, 19.0.4, 18.11.7 중 하나로 즉시 업그레이드**하는 것이 좋다. 특히 EE에서 저장소 미러링, Work Items, 컴플라이언스 관리, 취약점 증거 렌더링을 사용하는 환경은 패치 적용 전까지 권한과 외부 입력 처리 기능을 우선 점검해야 한다.

helmgitlabgraphqloauth+4

gitlab2026년 5월 28일

GitLab 패치 릴리스: 19.0.1, 18.11.4, 18.10.7 | GitLab Docs (새 탭에서 열림)

2026년 5월 27일 GitLab은 CE/EE용 패치 릴리스 19.0.1, 18.11.4, 18.10.7을 공개했습니다. 이번 릴리스에는 인증·인가 오류, 정보 노출, 서비스 거부 등 7건의 보안 취약점과 다양한 버그 수정이 포함되어 있어, 영향을 받는 모든 자체 관리형 설치 환경은 즉시 업그레이드하는 것이 권고됩니다. GitLab.com은 이미 패치가 적용됐으며 GitLab Dedicated 고객은 별도 조치가 필요하지 않습니다. ## 릴리스 대상과 업그레이드 권고 - 대상 버전: - GitLab 19.0.1 - GitLab 18.11.4 - GitLab 18.10.7 - CE와 EE 모두에 해당하는 수정이 있으며, 별도 배포 유형이 명시되지 않은 경우 Omnibus, 소스 설치, Helm Chart 등 모든 설치 방식에 영향을 줍니다. - GitLab 패치 릴리스는 일반적으로 매월 둘째·넷째 수요일에 제공되며, 심각한 취약점에는 긴급 패치가 별도로 배포될 수 있습니다. - 보안 취약점의 상세 이슈는 패치된 릴리스가 공개된 뒤 30일 후 이슈 트래커에 공개됩니다. ## Duo AI 워크플로 실행 주체 혼동 - **CVE-2026-4868** - GitLab EE에 영향을 주는 부적절한 접근 제어 취약점입니다. - 인증된 사용자가 특정 조건에서 다른 사용자의 신원으로 Duo AI 워크플로를 실행하도록 만들 수 있었습니다. - CVSS **8.2**로 이번 릴리스에서 가장 심각한 취약점입니다. - 수정 대상: - 18.8 이상 18.10.7 미만 - 18.11 이상 18.11.4 미만 - 19.0 이상 19.0.1 미만 ## Wiki 입력 검증 부족에 따른 서비스 거부 - **CVE-2026-1402** - GitLab CE/EE의 Wiki 기능에서 입력값 검증이 충분하지 않아, 인증된 사용자가 특정 조건에서 서비스 거부를 유발할 수 있었습니다. - CVSS **6.5**입니다. - 17.1부터 18.10.7 미만, 18.11.4 미만, 19.0.1 미만 버전이 영향을 받습니다. ## GraphQL WorkItem API의 비인가 프로젝트 열람 - **CVE-2026-6713** - GraphQL WorkItem API의 권한 검사가 잘못되어, 인증되지 않은 사용자가 비공개 프로젝트를 열거할 수 있었습니다. - 프로젝트 내용 전체가 노출된다는 의미는 아니지만, 비공개 프로젝트의 존재나 식별 정보가 노출될 수 있는 문제입니다. - CVSS **5.3**이며 GitLab CE/EE에 영향을 줍니다. - 수정 버전은 18.10.7, 18.11.4, 19.0.1입니다. ## Duo Workflows 및 Operations 권한 우회 - **CVE-2026-5296** - GitLab EE의 Duo Workflows API 취약점입니다. - 그룹 수준에서 foundational flow가 활성화된 경우, Developer 권한 사용자가 특정 조건에서 워크플로 제한을 우회할 수 있었습니다. - CVSS **4.3**입니다. - **CVE-2026-2601** - GitLab EE Operations 기능의 권한 검사 오류입니다. - Developer 권한 사용자가 다른 프로젝트의 민감한 배포 데이터를 볼 수 있었습니다. - CVSS **4.3**입니다. - 두 취약점 모두 18.10.7, 18.11.4, 19.0.1에서 수정되었습니다. ## CI/CD 및 토큰 인증 관련 취약점 - **CVE-2026-8716** - Pipelines에서 ref 유형 이름을 잘못 해석해, 인증된 사용자가 의도하지 않은 다른 ref의 CI 데이터를 볼 수 있었습니다. - GitLab CE/EE에 영향을 주며 CVSS는 **4.3**입니다. - **CVE-2026-2710** - 차단된 Project Access Token이 특정 인증 엔드포인트를 통해 계속 비공개 리소스에 접근할 수 있었습니다. - GitLab CE/EE에 영향을 주며 CVSS는 **4.3**입니다. - 두 취약점 모두 18.10.7, 18.11.4, 19.0.1에서 해결되었습니다. ## 19.0.1의 주요 버그 수정 - GitLab Credits 대시보드의 평가판 CTA 오류를 수정했습니다. - 작업 토큰의 세분화된 권한에 저장소 쓰기 권한 옵션을 추가했습니다. - Helm 기반 릴리스 환경 QA를 제거했습니다. - API 보안 수정 지침을 릴리스 노트에 반영했습니다. - 19.0 최종 릴리스 관련 변경 사항을 백포트했습니다. ## 18.11.4의 주요 버그 수정 - Ruby 스레드 스케줄러 우선순위 패치를 적용했습니다. - Elasticsearch 인덱서 버전을 5.14.7로 업데이트했습니다. - Zlib를 3.2.3으로 업데이트하고 GitLab Shell을 14.50.0으로 올렸습니다. - Wiki 페이지 이동 시 댓글이 사라지는 문제를 수정했습니다. - 성공한 빌드가 삭제되는 문제와 SyncPolicyWorker 타임아웃 문제를 해결했습니다. - CI/CD 프로젝트 생성 테스트, Epic 보드, swimlane 등 불안정한 기능과 테스트를 수정했습니다. - AI Workflows 범위와 subgroup 프로비저닝 서비스 계정 관련 기능을 보완했습니다. - 파이프라인 취소 및 trace 처리, 다이어그램 프록시의 허용 엔드포인트 전달을 개선했습니다. - 고급 검색 대량 인덱싱에서 기본 데이터베이스 연결을 사용하도록 수정했습니다. - 라이선스 승인 규칙 워크플로의 성능을 개선했습니다. - `num_context_lines=0`일 때 발생하던 off-by-one 오류를 수정했습니다. ## 실용적인 권장 사항 자체 관리형 GitLab 운영자는 현재 지원 중인 브랜치에 맞춰 즉시 19.0.1, 18.11.4 또는 18.10.7로 업그레이드하는 것이 좋습니다. 특히 Duo AI/Workflows, GraphQL WorkItem, Wiki, CI/CD, Project Access Token, Operations 기능을 사용하는 환경은 업그레이드 전까지 권한과 비공개 데이터 접근 로그를 점검해야 합니다.

helmgitlabci-cdgraphql+4

gitlab2026년 5월 7일

Kubernetes에서 Gitaly로 GitLab 스택 통합하기 (새 탭에서 열림)

GitLab 18.11부터 Gitaly on Kubernetes가 정식 지원되면서, GitLab의 모든 구성 요소를 Kubernetes에서 운영할 수 있게 되었습니다. 기존의 Kubernetes와 VM을 함께 사용하는 하이브리드 구조를 없애고, 인프라 운영과 모니터링을 단일 Kubernetes 환경으로 통합할 수 있습니다. 다만 현재 Gitaly Cluster(Praefect)는 Kubernetes를 아직 지원하지 않아 완전한 고가용성은 제공되지 않습니다. ### Kubernetes 환경에 맞춘 Gitaly의 변화 - Git 작업은 메모리 사용량이 크고 패턴을 예측하기 어렵습니다. - Gitaly는 Git 프로세스를 별도 cgroup에서 실행해 메모리 초과로 프로세스가 종료되더라도 주 Gitaly 프로세스가 영향을 받지 않도록 합니다. - Kubernetes에서 이 구조를 구현하기 위해 다음 작업이 필요했습니다. - `containerd` 환경에서 cgroupfs에 쓰기 권한을 부여 - init container로 `/sys/fs/cgroup`를 마운트 - 해당 경로를 쓰기 가능하도록 설정 - 이를 통해 Git 프로세스의 OOM(메모리 부족) 종료가 Gitaly 전체 장애로 이어지는 것을 방지합니다. ### Pod 재시작과 서비스 중단 문제 - VM에서는 Omnibus가 Gitaly 바이너리를 교체하고 소켓을 유지한 채 graceful reload를 수행할 수 있습니다. - Kubernetes에서는 Helm 업그레이드, 노드 드레이닝, 설정 변경 등으로 StatefulSet Pod가 교체되면 프로세스가 강제 종료된 뒤 재시작됩니다. - Gitaly Sharded처럼 자체 고가용성을 제공하지 않는 구성에서는 이 방식이 일시적인 중단을 일으킬 수 있습니다. - 이를 보완하기 위해 Rails 등 Gitaly 클라이언트의 요청 재시도 시간을 설정할 수 있게 했습니다. - Gitaly가 재시작되는 동안 요청을 재시도 - 사용자는 짧은 시간 동안 약간 높은 지연을 경험할 수 있음 - 재시작이 완료되면 요청은 최종적으로 성공 ### 업그레이드 중에도 높은 성공률 유지 - VM 기반 Gitaly와 Kubernetes 기반 Gitaly에서 일반적인 Git 작업을 실행한 뒤, 테스트 중간에 업그레이드를 수행하는 벤치마크를 진행했습니다. - 두 환경의 요청 성공률은 거의 동일했습니다. - Kubernetes에서는 Pod 종료 시 프로세스가 즉시 끝나고 소켓도 닫히지만, 클라이언트 재시도 덕분에 대부분의 요청이 성공했습니다. - 모든 작업에서 100% 성공률을 보장하려면 Gitaly Cluster(Praefect)가 필요합니다. - 그러나 Praefect는 현재 Kubernetes를 지원하지 않으며, Kubernetes 지원의 정식 제공을 준비 중입니다. ### 인프라 통합의 효과 - 기존 하이브리드 배포 사용자는 Gitaly를 VM에서 Kubernetes 클러스터로 이전할 수 있습니다. - 별도의 Gitaly VM fleet를 유지·모니터링할 필요가 없어집니다. - GitLab 전체를 Kubernetes가 관리하는 단일 환경으로 통합할 수 있습니다. - Kubernetes를 이미 운영 중인 신규 GitLab 사용자도 Helm chart를 통해 Kubernetes 네이티브 방식으로 GitLab을 배포할 수 있습니다. ### 설치 방법과 배포 형태 - 권장 설치 방법은 GitLab Helm chart를 사용하는 것입니다. - 설치 전 Gitaly on Kubernetes 공식 문서를 확인해 주요 설정과 일반적인 문제를 검토해야 합니다. - Gitaly는 두 가지 형태로 배포할 수 있습니다. - 전체 GitLab 설치의 일부로 배포 - 외부 Gitaly 구성 요소로 별도 배포 - 구체적인 설정 방법과 주의사항은 Gitaly on Kubernetes 문서에서 각 시나리오별로 제공합니다. ### 실용적인 결론 GitLab을 Kubernetes 중심으로 운영하는 팀이라면 Gitaly를 클러스터로 통합하는 것이 운영 복잡성을 줄이는 현실적인 선택입니다. 다만 무중단 고가용성이 반드시 필요한 환경은 Praefect의 Kubernetes 지원 여부를 확인한 뒤 도입을 결정하는 것이 좋습니다.

helmk8sgitlabgit+4

figma2024년 8월 7일

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

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 전환을 검토할 수 있습니다. 다만 서비스 수와 운영 복잡도를 먼저 평가하고, 자동 확장·상태 저장 워크로드·트래픽 관리처럼 실제로 필요한 기능을 기준으로 이전의 효과를 판단하는 것이 바람직합니다.

helmk8sterraformcontainers+4