해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 22 - Test in Production with Kubernetes and Telepresence
1. 느리고 비효율적인 테스트 과정
개발 환경은 점차 발전해왔지만, 각 단계마다 생산성을 저해하는 문제점들이 존재했다.
1. 프로덕션 직접 테스트의 문제점
-
높은 서비스 장애 위험: 코드의 사소한 실수 하나가 전체 운영 서비스의 중단으로 이어질 수 있음.
-
부족한 안전장치: 배포 전 오류를 걸러낼 CI/CD 파이프라인이나 격리된 테스트 단계가 없어 매우 위험함.
2. 공용 스테이징 환경의 문제점
-
매우 느린 피드백 속도: 개발자가 코드를 수정한 시점부터 QA팀 등을 통해 테스트 결과를 받기까지 몇 주가 소요될 수 있음.
-
업무 연속성 저하: 피드백을 받을 때쯤이면 개발자는 이미 해당 작업의 맥락을 잊어버려 버그를 수정하는 데 더 많은 시간이 걸림.
-
환경 충돌 및 의존성: 여러 개발자가 하나의 환경을 공유하기 때문에 다른 사람의 코드로 인해 테스트 환경이 불안정해지거나 테스트가 지연될 수 있음.
3. 개인별 스테이징 환경의 문제점
-
반복적이고 긴 대기 시간: 환경이 개인화되었어도, 코드 수정 시마다 커밋 → 푸시 → CI 빌드 → 배포라는 전체 사이클을 반복해야 함.
-
CI/CD 파이프라인 병목 현상: 특히 도커 이미지를 빌드하는 CI 과정이 10분 이상 소요되는 등 가장 큰 시간을 차지하며 생산성을 저해
-
생산성 저하: 작은 버그 하나를 수정하기 위해서도 긴 대기 과정을 계속 반복해야 하므로 개발 흐름이 끊기고 전체적인 작업 효율이 떨어짐.
2. 텔레프레즌스 (Telepresence)
이처럼 길고 반복적인 배포 과정을 단축시켜주는 해결책이 바로 텔레프레즌스이다.
텔레프레즌스는 커밋, 푸시, CI 빌드, 배포 과정 없이 내 컴퓨터 (로컬 환경)에서 작성한 코드를 원격 쿠버네티스 클러스터에서 즉시 테스트할 수 있게 해주는 도구이다.
텔레프레즌스 공식 사이트
https://telepresence.io/
로컬에서 텔레프레즌스를 이용한 서비스 개발 및 디버깅 방법 (쿠버네티스)
https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/local-debugging/
2-1. 텔레프레즌스 단계별 작동
1단계: 클러스터에 연결 (Connect)
먼저 개발자는 자신의 로컬 컴퓨터에서 텔레프레즌스 CLI(명령줄 인터페이스)를 통해 원격 쿠버네티스 클러스터에 연결해야 한다.
# 터미널에서 해당 명령어를 통해 실행
telepresence connect-
Traffic Manager 설치: 해당 명령어를 통해 쿠버네티스 클러스터 내에 'Traffic Manager'라는 컴포넌트를 배포함. (텔레프레즌스의 핵심 제어 센터 역할)
-
보안 터널 생성: 로컬 컴퓨터와 클러스터의 Traffic Manager 사이에 양방향 네트워크 터널을 생성
해당 연결을 통해, 개발자의 로컬 컴퓨터는 클러스터 내부의 네트워크에 접근할 수 있게 된다.
예를 들어, 클러스터 내부에서만 사용 가능한 서비스 주소 (my-service.default.svc.cluster.local) 에 로컬 컴퓨터에서 직접 접근할 수 있다.
2단계: 트래픽 가로채기 (Intercept)
연결이 완료되면, 개발자는 클러스터 내의 특정 마이크로서비스로 가는 트래픽을 자신의 로컬 컴퓨터로 가져오도록 '인터셉트'를 생성한다.
# <서비스이름> 서비스를 로컬의 <로컬포트> 포트로 연결하는 명렁어
telepresence intercept <서비스이름> --port <로컬포트>-
에이전트(Agent) 삽입: 텔레프레즌스가 클러스터에서 실행 중인 orders-service의 기존 Pod를 '텔레프레즌스 에이전트'가 포함된 프록시 파드로 교체함.
-
트래픽 캡처: 1번 과정으로 인해, orders-service로 들어오는 모든 네트워크 요청은 원래의 애플리케이션 대신 해당 에이전트 프록시가 먼저 받게 됨.
-
트래픽 리디렉션: 텔레프레즌스 에이전트는 캡처한 트래픽을 1단계에서 생성한 보안 터널을 통해 개발자의 로컬 컴퓨터(localhost:8080)로 그대로 전달
3단계: 로컬에서 개발 및 즉시 테스트 (Develop & Instant Test)
이후, 개발자는 VS Code, IntelliJ 등 자신이 선호하는 IDE에서 orders-service의 소스 코드를 열고 디버깅 모드로 실행하면된다.
이후, 클러스터의 다른 서비스가 로컬과 연결된 서비스를 호출하게 되면, 해당 요청은 '텔레프레즌스 에이전트'를 거쳐 터널을 통해 개발자의 로컬 컴퓨터에 있는 IDE에 도달한다.
개발자는 실시간으로 들어온 요청을 디버깅하고, 변수를 확인하고 코드에 Breakpoint를 설정할 수 있다.
이후, 코드를 수정하고 저장만하면 다음 요청부터는 수정된 코드가 적용된다. 즉, commit, puch, 빌드, 배포 과정이 완전히 생략되는 것이다.
따라서, 텔레프레즌스를 사용하여 개발자는 실제 클러스터의 트래픽을 이용하여 마치 로컬 함수를 테스트하듯 빠르고 직관적으로 개발을 진행할 수 있다.
2-2. 심화 기능: 팀 협업을 위한 개인 인터셉션
지금까지 설명한 방식은 특정 서비스로 가는 모든 트래픽을 개발자의 로컬 환경으로 가져오는 '전역 인터셉션' 방식이었다.
혼자 개발할때는 문제가 없지만, 여러 개발자가 동일한 스테이징 환경을 공유하여 같은 서비스를 테스트하는 상황에서는 문제가 될 수 있어, 텔레프레즌스는 '개인 인터셉션 (Personal Intercept)' 기능을 제공한다.
개인 인터셉션을 생성하면, 텔레프레즌스는 고유한 프리뷰(Preview) URL을 제공하며, 해당 URL로 접속하면 요청에 특수한 HTTP 헤더(Header)가 자동으로 포함된다.
- 내 요청: 프리뷰 URL을 통해 들어온 요청 (특수 헤더 포함)만 식별하여 개발자의 로컬 컴퓨터로 전달됨.
- 다른 팀원의 요청: 일반적인 경로로 들어온 요청은 헤더가 없으므로, 원래 클러스터에 배포된 서비스로 정상적으로 전달됨.
해당 기능 덕분에 여러 개발자가 서로의 작업에 전혀 영향을 주지 않고 동일한 환경에서 동시에 로컬 개발 및 테스트를 진행할 수 있다.
2-3. 기타 특징
-
텔레프레즌스는 오픈소스 프로젝트로, 누구나 자유롭게 사용하고 기여할 수 있다.
-
클릭 기반의 UI를 선호하는 사용자를 위해 도커 데스크톱(Docker Desktop) 확장 기능을 제공하여 더 편리하게 사용할 수 있다.
3. 결론
마이크로서비스 아키텍처가 보편화되면서 개발의 복잡성은 증가했고, 과거의 단순한 로컬 개발 환경에서 누렸던 '빠른 피드백 루프'는 점차 사라졌다.
코드를 조금만 수정해도 커밋, 빌드, 배포라는 길고 지루한 과정을 반복해야 했고, 이는 개발자의 생산성을 크게 저해하는 요인이 되었다.
텔레프레즌스는 이러한 현대 클라우드 네이티브 개발 환경의 고질적인 문제를 해결하는 강력한 솔루션이다.
원격 쿠버네티스 클러스터를 마치 내 로컬 컴퓨터의 일부처럼 확장하여, 복잡한 배포 과정 전체를 생략하고 코드 수정 결과를 즉시 확인할 수 있게 해준다.
이를 통해, 개발자가 불필요한 기다림 없이 코드 작성과 문제 해결에만 집중할 수 있도록 도와주어, 더 빠른 개발이 가능해진다.
