Yingxiong Network 고객 사례: Kubernetes 부하 테스트와 Profiling | Guance

고객 환경

Yingxiong Network는 인터랙티브 엔터테인먼트 기업입니다. 공개 사례는 게임 로그인 트래픽 증가에 Kubernetes와 HPA로 대응하고 부하 테스트로 서비스 동작을 검증한 과정을 설명합니다.

오토스케일에도 성능 근거가 필요

컨테이너를 늘린다고 처리량이 항상 선형 증가하지 않으며 컴퓨팅, 공유 의존성, 코드 제약을 조사해야 합니다.

오토스케일에도 성능 근거가 필요

스케일 이후 처리량이 정체됨

공개 테스트에서 Pod를 늘린 뒤 추가 증가가 제한됐고 리소스 수만으로 이유를 설명할 수 없었습니다.

스케일 이후 처리량이 정체됨

도입 방식

APM, 로그, 프로파일링으로 부하 테스트 분석

DataKit으로 트레이스와 로그를 수집하고 APM에서 의심 서비스와 Redis를 확인한 뒤 Lock Wait Time, Socket I/O Read Time 등의 Profile 신호로 빈번한 Redis 호출 코드 경로를 찾았습니다.

APM, 로그, 프로파일링으로 부하 테스트 분석

도입 후 변화

코드 제약에 재현 가능한 근거 추가

트레이스, Redis, Profile을 바탕으로 구현을 변경하고 같은 리소스로 재시험해 해당 조건의 개선을 확인했습니다. 다른 환경의 결과를 보장하지 않습니다.

관련 Guance 기능

인프라 모니터링 애플리케이션 성능 모니터링 실사용자 모니터링 지속적 프로파일링 API 신세틱 모니터링

자주 묻는 질문

Pod를 늘려도 처리량이 늘지 않을 수 있는 이유는 무엇인가요?

공유 캐시, DB, 네트워크, 락, 코드 경로가 제약일 수 있습니다. HPA는 복제본을 늘리지만 공유 병목을 제거하지 않습니다.

이 사례에서 Profiling은 무엇을 보여 줬나요?

Lock Wait Time과 Socket I/O Read Time을 APM 및 Redis 상태와 함께 분석해 빈번한 Redis 호출을 찾았습니다.

부하 테스트 결과를 성능 보장으로 사용할 수 있나요?

사용할 수 없습니다. 특정 코드, 리소스, 트래픽 모델, 테스트 환경의 기록이며 다른 워크로드는 별도로 검증해야 합니다.

다른 고객 사례

ANTA Group

ANTA Group

분산된 오픈소스 모니터링을 공통 풀스택 흐름으로 통합했습니다.

ComfortDelGro

ComfortDelGro

기존 트레이스를 이전하고 선택한 배포 경계에서 텔레메트리를 관리했습니다.

KONE

KONE

AWS 리소스, RUM, APM, 로그, 사용자 정의 수집을 연결했습니다.