avatar

정지원

DevOps Engineer
Channel.io
mailMailgithubGitHublinkedinLinkedin

소개

문제를 해결하는 데에 즐거움을 느끼는 데브옵스 엔지니어입니다.

상황에 맞는 최선의 선택을 하기 위해 고민합니다.
프로젝트에 할당된 기간, 확장성, 지속 가능성, 비용 효율성을 고려하여 아키텍처를 설계하고 기술을 활용합니다.

기술이 가진 책임과 영향력을 이해하고, 조심스럽지만 과감하게 행동합니다.
이를 위해 단순히 기술을 사용하는 것을 넘어, 근본적인 원리를 이해하기 위해 노력합니다.

문제를 분석하고, 원인을 파악하여 해결하는 과정을 좋아합니다.
특히, 다양한 관점으로 문제를 바라보고 여러 가능한 해결 방법에 대해 토론하는 것에서 즐거움을 느낍니다.
  👉🏼 Kubernetes 환경에서 WebRTC 서비스의 묵음 현상 분석기

일을 찾아서 움직이는 성향 덕분에, 자연스럽게 일의 우선순위를 수시로 조정하며 진행합니다.
주어진 업무 외에도 팀에 도움이 되는 방향이 있다면 먼저 제안하고 움직이며, 전체적인 효율과 팀의 방향성을 함께 고려하여 기술적인 의사결정을 내립니다.

커리어

Channel Corporation - DevOps Engineer [2022.05 ~ ]

입사 직후 Kubernetes 도입 및 서비스 운영 환경 설계를 주도하였고, 기존 ECS 기반의 인메모리 DB 및 메인 서버를 포함한 전체 시스템을 EKS로 성공적으로 마이그레이션하였습니다.
Meet팀 소속으로 채널톡 전화 서비스 관련 DevOps 업무를 수행하며 WebRTC 서버 구축, 아키텍처 설계 참여, STT 비용 최적화 및 속도 개선을 이루었습니다.
Terraform CI에서 권한 확인을 위한 어플리케이션 개발, 오퍼레이터 패턴으로 개발된 내부 배포 시스템의 기능 추가 등 개발 업무에도 참여하였습니다.
현재는 글로벌 인프라 확장 및 멀티 클러스터 환경을 고려한 프로비저닝 자동화와 아키텍처 설계를 진행하고 있습니다.

SI Analytics - DevOps Engineer [2021.03 ~ 2022.02]

온프레미스 환경에서 총 21대의 물리 서버(CPU + GPU)와 44대의 VM으로 구성된 5개의 Kubernetes 클러스터를 구축 및 운영하였습니다.
각 클러스터는 Control Plane 노드 3대를 구성하고 HAProxy를 활용해 고가용성을 확보하였으며, etcd 및 쿠버네티스 리소스에 대한 주기적인 백업과 복원이 가능한 환경을 구성하였습니다.
또한, 클러스터 전반에 적용될 정책을 설계하고, Admission Controller를 활용하여 보안성과 일관성을 강화하였습니다.
Grafana, Loki, Prometheus, Alertmanager를 연동한 모니터링 시스템을 구축하였으며, DCGM Exporter에 필요한 메트릭을 추가하고 직접 바이너리를 빌드하여 GPU 관련 정보를 연구자들에게 제공하였습니다.

프로젝트

[채널톡] - ECS에서 EKS로의 마이그레이션 프로젝트 리드

인메모리 데이터베이스 마이그레이션

  • 배경

    • ECS에서 모든 서비스를 EKS로 이전하는 전사적 마이그레이션을 수행함
    • 실시간으로 동작하는 인메모리 데이터베이스와 이를 처리하는 Gateway 역시 이전 대상에 포함되어 있었으며, 서비스의 실시간 응답성과 신뢰성을 유지하는 것이 핵심 요구사항이었음
    • 인메모리 데이터 갱신은 DynamoDB Streams를 기반으로 하며, 컨테이너 재기동 시 DynamoDB로부터 초기 데이터를 로딩하도록 되어 있어 DynamoDB Read 부하 또한 고려가 필요했음

  • 주요 조치

    • ECS 및 EKS 서비스를 동일 도메인에서 호출 가능하도록 구성하고, 서비스 디스커버리를 Cloud Map에서 ALB 기반으로 통일함
    • 내부 직원용 채널을 대상으로 Header 및 URL Path 조건을 활용한 Canary Testing 환경을 구축하여 실제 서비스 트래픽 적용 전 QA를 완료함
    • ALB Listener Rule의 Weight 조절을 통해 약 1주일간 점진적 트래픽 이전을 수행, 안정적으로 전체 서비스를 EKS로 전환함
    • 컨테이너당 하나의 DB 타입만 처리하는 구조적 특성을 고려하여, 동일한 DB 타입 컨테이너는 서로 다른 노드에 스케줄링되도록 설정함

  • 기술 부채 및 개선 인식

    • 현재 구조에서는 DynamoDB 이벤트 유실을 방지하기 위해 DynamoDB Streams를 ECS와 EKS로 둘 다 보내주었으나, 이벤트를 보존하거나 재처리하는 구조는 미흡함
    • Redis, SQS, Kafka 등의 중간 큐를 도입한 Pub/Sub 아키텍처였다면 일시적 장애나 재배포 시에도 이벤트 보존 및 유연한 재처리가 가능했을 것으로 판단됨

AWS Client 초기화 오류 해결 및 표준화 기여

  • 배경
    • ECS에서 EKS로 마이그레이션 과정에서 동일한 코드가 ECS 환경에서는 정상적으로 IAM 권한을 가져왔으나, EKS 환경에서는 권한을 가져오지 못하는 문제가 발생함
    • 테스트 용도로 AWS Client 초기화 시, Custom Endpoint Resolver를 사용하고 있었음
  • 원인 분석 및 해결
    • 로그 분석을 통해 Node Role을 Assume하는 것을 인지하고, AWS SDK 코드 레벨에서 Custom Endpoint Resolver가 STS 요청에 대한 Endpoint를 덮어쓰고 있음을 확인함
    • ECS 환경에서는 기본 Credentials Provider Chain에서 STS보다 우선하는 ECS Task Metadata Endpoint를 통해 자격 증명을 가져오므로 해당 문제 발생하지 않았음
    • 동일 패턴을 사용하는 타 프로젝트에 해결 방안을 공유하고 수정 가이드를 제공하여, 전체 개발팀의 불필요한 트러블슈팅 시간을 절감하고 개발 효율 증대에 기여함

기타 작업

  • 모든 애플리케이션에 적용 가능한 공용 Helm Chart 개발
    • 지속적으로 고도화하여 현재 약 80여개의 애플리케이션에서 활용 중
  • ArgoCD를 활용하여 GitOps 방식을 도입하고, 기존 ECS 대비 훨씬 직관적이고 빠른 배포 파이프라인을 구축
    • 이로 인해 개발팀의 배포 관련 문의가 50% 이상 감소하여, 운영 효율성을 크게 향상시킴
  • Monorepo 기반 Helm Chart Repository 및 CI/CD 자동화 구축
    • GitHub Actions 기반의 CI 파이프라인을 구축하여 Monorepo 내 Helm Chart의 빌드, 테스트, AWS ECR 업로드를 자동화하고, SemVer를 통해 버전을 관리함
  • 모든 GPU 인스턴스를 Spot 타입만 사용하도록 구성하여 온디맨드 타입 대비 약 60% 이상의 비용을 절감함

[채널톡] - Meet 서비스

WebRTC 서비스 묵음현상 트러블슈팅 (자세히 설명한 블로그 글 👉🏼 (Link))

  • 배경
    • 실시간 음성 처리의 안정성을 위해 트래픽 급증 시간대에 대비해 WebRTC 서버를 평소보다 2배로 미리 증설하는 조치를 시행함
    • 하지만 다음 날 아침부터 통화 중 묵음 현상이 약 25%에서 발생하며, 원인을 쉽게 파악하기 어려운 예기치 못한 장애가 발생함
  • 원인 분석
    • 문제의 원인을 파악하기 위해 다양한 가설을 세우고 이를 검증하는 과정을 반복함
    • 최종적으로 “AWS의 EIP(Elastic IP) 할당은 API 응답과 실제 네트워크 반영 사이에 짧지만 유의미한 시간차가 발생할 수 있다”는 가설을 세우고, 테스트 및 AWS 공식 답변을 통해 이를 확인함
  • 해결
    • 이를 기반으로, EIP가 제대로 적용되었는지 확인하는 방어 로직을 구현하여 서버 스케일링 시 EIP 할당 상태를 검증하도록 개선함
    • 테스트 환경에서 재현 테스트 후 오류가 더 이상 발생하지 않는 것을 확인하고, 해당 방어 로직을 Production 환경에 당일 바로 배포하여 문제를 해결

LiveKit Egress 스케일링 기준 수립

  • 배경

    • 음성 기능만 사용하는 상황에서 README의 기본 리소스 설정은 CPU 리소스의 약 15~30%만 실제 사용해 상당한 CPU 낭비 발생함
    • LiveKit Egress는 내부적으로 CPU Capacity와 Usage를 직접 관리하였기 때문에 Kubernetes HPA와 메커니즘이 충돌하였음

  • 최적화 및 결과

    • Egress에서 리소스를 관리하는 부분을 코드레벨에서 분석하여 워커 어피니티를 기반으로 트래픽을 CPU Idle이 작은 인스턴스에 집중시키는 로직을 코드 레벨에서 확인함. 요청을 분산하지 않고 Capacity가 가득 찰 때까지 요청을 집중시킴
    • 서비스 기획 단계에서 정의된 최대 사용자 및 룸(Room) 수를 기준으로 부하 테스트를 수행함
    • 스케일링 메커니즘 충돌 해결을 위해 K8s HPA는 CPU 사용률을, Egress는 트랙 및 룸별 CPU cost를 통제하며 실험을 진행했음
    • 실험을 통해 CPU 사용률이 요청 대비 평균 60%를 유지하도록 최적의 스케일링 기준을 수립함
    • 스로틀링 발생이 민감한 서비스 특성 고려, 항상 1~2대의 서버를 예비로 확보하는 정책 적용함
    • 결과적으로 수립된 스케일링 기준은 현재까지 큰 수정 없이 안정적으로 운영 중이며, CPU 리소스 효율성을 극대화하여 비용 절감에 기여함

Livekit 카나리 배포 전략 설계

  • 배경
    • Livekit을 서비스 중단 없이, 비즈니스 영향도를 낮춘 업데이트를 위해 카나리 배포 전략을 제안함
    • 동일한 룸 내에서는 피어 간 서버 버전이 일치해야 함
  • 전략
    • 애플리케이션 레벨에서 채널 ID를 2로 나눈 나머지를 기준으로 트래픽을 라우팅하도록 구성함
    • 비즈니스 영향도를 최소화하기 위해 주요 고객사는 기존의 안정적인 버전을 사용하도록 별도로 관리함
    • 외부 Redis에서 카나리 배포 비율을 조절할 수 있도록 구현하여, 런타임에 재배포 없이 빠른 롤백이 가능하도록 함

[채널톡 & SI Analytics] 모니터링 시스템 구축 및 최적화

아키텍처 설계

  • 고가용성을 위해 Prometheus에 Replication 및 Sharding을 적용하여 Fault Tolerance를 확보하고, 메트릭의 장기 저장을 위해 Thanos를 도입함
  • Loki는 모든 컴포넌트를 개별 배포하고 Read/Write 파이프라인에 캐싱을 적용하여 효율을 높임

최적화

  • Thanos는 시간대별 요청량 패턴을 분석하여 컴포넌트를 분리하고, 각각 독립적으로 스케일링되도록 구성하여 성능을 최적화함
  • Recording Rule
    • 자주 사용되는 복잡한 집계 쿼리를 Recording Rule로 미리 계산하여 대시보드 로딩 시간을 단축함
    • 고해상도 메트릭 쿼리의 샘플 수 제한 문제를 Recording Rule로 해결하여 쿼리 성공률과 응답 시간을 개선함
  • Promtail의 Pipeline Stage와 Loki의 설정을 통해 여러 줄의 로그를 포함한 대용량 로그 수집을 안정적으로 지원함
  • Cardinality
    • 애플리케이션 개발자들에게 Cardinality를 낮추도록 가이드함. 특히, 채널별로 필터링이나 그룹핑을 해야할 때에는 label이 아닌 structured metadata를 활용하여 안정적으로 인덱스를 받아오고 쿼리 효율을 높일 수 있도록 가이드함
    • 기본적으로 추가되는 불필요한 Label을 삭제하여 Cardinality를 낮추고, TSDB 상태 모니터링을 통해 Stream 수를 감소시켜 Latency를 개선함
  • Exporter 추가 시 일정 기간 후 메트릭 활용도를 확인하고, Relabeling을 통해 불필요한 메트릭을 수집하지 않도록 설정함

블로깅

Kubernetes 환경에서 WebRTC 서비스의 묵음 현상 분석기

Kubernetes 환경의 Meet 서비스 스케일링 과정에서 발생한 WebRTC 묵음 현상에 대해 원인을 분석하고 해결해나가는 과정을 채널톡 기술블로그에 작성하였습니다

학력

충남대학교 - 컴퓨터공학과 [2015.02 ~ 2022.02]

학점 3.76/4.5 (전공 3.86/4.5)