kakao·2026년 5월 21일·4분 읽기큐레이션 요약

메시징 서버의 스트레스 테스트 노하우와 AI 가 덜어 준 부분

메시징 서버의 안정적 운영을 위해서는 실서비스와 동일한 환경에서 상시 스트레스 테스트를 수행하고, 실제 트래픽 패턴과 최악의 시나리오를 재현해야 한다. 테스트는 단순히 서버가 장애 없이 버티는지를 보는 것이 아니라 RPS, 지연 시간, 오류율, 시스템 자원 등을 계층적으로 분석해 병목 원인을 찾아내는 과정이다. 관측성 도구, 프레임워크, OS·보안 시스템, 신규 기능 변경 전후에도 스트레스 테스트를 적용해야 운영 장애를 예방할 수 있다. ## 상시 스트레스 테스트 환경 구성 - 테스트 대상 서버는 실운영 서버와 동일한 JVM heap, CPU·메모리 한도, 네트워크 사양으로 구성한다. - 운영 서버 대수가 다르면 측정값을 그대로 비교하기 어렵기 때문에 필요한 경우 수치 보정을 적용한다. - 부하 생성에는 Locust를 사용하며, 클러스터 리소스에 따라 수백 개의 워커 파드까지 확장한다. - 부하 생성 클라이언트의 자원 부족이 서버 성능 측정에 영향을 주지 않도록 클라이언트 리소스를 충분히 확보한다. - 경우에 따라 `org.openjdk.jmh:jmh-core`를 이용해 프레임워크나 프로토콜 자체를 벤치마크한다. ## 실제 트래픽을 반영한 시나리오 설계 - 여러 사용자 동작을 실제 환경의 비율에 맞춰 조합한다. - 평시 정오에는 메시지 전송, 채팅방 입장, 채팅방 목록 조회, 메시지 조회가 비교적 고르게 분포한다. - 신년 자정에는 메시지 전송 비중이 52%에서 61%로 증가하고, 채팅방 목록 조회는 18%에서 8%로 감소한다. - 같은 RPS라도 READ·WRITE 프로토콜 비율에 따라 병목 지점과 최대 처리량이 달라질 수 있다. - 새로운 시나리오마다 부하 코드를 새로 작성하지 않고, 사용자 수·요청 비율·동시성 등 설정값을 조합해 다양한 트래픽을 재현한다. ## 변경 유형별 스트레스 테스트 ### 관측성과 로깅 인프라 추가 - Logstash, Fluent Bit, OpenTelemetry, Vector DB 등 관측성 컴포넌트가 애플리케이션 처리량과 응답 시간에 미치는 영향을 확인한다. - 메트릭 수집 때문에 애플리케이션 부하가 증가하거나 CPU·메모리·네트워크 사용량이 변하지 않는지 측정한다. - 높은 트래픽에서 내부 메트릭과 알림 시스템 자체가 지연되는지도 검증한다. ### 프로토콜·프레임워크 벤치마크와 포팅 - 비즈니스 로직을 제외하고 동일한 I/O 부하를 주어 프로토콜이나 프레임워크별 성능을 비교한다. - WebFlux, virtual thread 등 기술 선택을 추상적인 장점이 아니라 실제 RPS, latency, CPU 사용량으로 판단한다. - CPU 부하와 I/O 대기 시간을 단계적으로 늘려 현재 서비스가 CPU-bound인지 IO-bound인지 확인한다. - C++에서 Kotlin으로 메인 서버를 포팅할 때도 전후 시스템 지표를 비교하고, GC 튜닝 등을 통해 성능 차이를 줄였다. ### OS 변경과 보안 시스템 도입 - 온프레미스 호스트 OS 변경, 백신, 보안·모니터링 에이전트 추가가 고부하 상황에서 미치는 영향을 검증한다. - 평상시에는 드러나지 않던 slab 메모리 누수나 백신 동작 시 리소스 급증이 대규모 트래픽에서 문제가 될 수 있다. - 적용 전후 응답 시간과 처리량이 악화되지 않는지 확인한 뒤 인프라 변경을 진행한다. ### 메시징 도메인 특화 임계 상황 - 한 채팅방에서 여러 사용자가 동시에 메시지를 전송하는 상황을 재현한다. - 자정 메시지 burst, 수백 명 규모의 단체 채팅방 입장 등 최악의 시나리오를 별도로 검증한다. - 신규 기능도 부하 상황에서 예상되는 병목을 먼저 파악한 후 출시한다. ## 지표를 계층적으로 분석하는 방법 ### 엔드포인트 지표 - **RPS**: 워커 수를 점진적으로 늘려 포화 지점을 찾거나, 동일한 부하에서 RPS가 안정적으로 유지되는지 확인한다. - 예상보다 낮은 RPS에서 포화되거나 처리량이 급격히 흔들리면 내부 원인 분석으로 넘어간다. - **Latency**: - P50은 대부분 사용자의 일반적인 경험을 나타낸다. - P95·P99는 최악의 응답 시간과 내부 병목을 파악하는 데 유용하다. - P95·P99가 급증하면 처리량 한계나 대기열 문제를 의심한다. - P50 자체가 목표치나 실제 환경보다 높아도 비정상으로 판단한다. - **Error rate**: - 5xx는 서버 처리 한계에 도달했을 가능성이 있다. - timeout은 클라이언트 자원 부족이나 타임아웃 설정을 확인해야 한다. - 400 오류는 테스트 데이터나 비즈니스 시나리오가 잘못되었을 가능성이 있다. ### 시스템 자원 지표 - 본문은 시스템 자원 레이어 설명 중간에서 끝나지만, 엔드포인트 지표에서 이상이 발견되면 CPU·메모리·네트워크 등 하위 시스템 지표를 세부적으로 확인하는 방식으로 이어진다. - 스트레스 테스트 결과는 단순한 성공·실패가 아니라, 어느 계층에서 병목이 발생했는지 추적하는 디버깅 과정으로 해석해야 한다. 실무에서는 운영과 유사한 테스트 환경을 상시 유지하고, 평시 트래픽뿐 아니라 도메인 특유의 폭증 시나리오까지 자동화하는 것이 중요하다. 또한 변경 사항을 도입할 때 RPS, P50/P95/P99 latency, 오류율, 시스템 자원을 동일한 기준으로 비교해 정량적으로 판단하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

performance-testing옵저버빌리티Kotlinopen-telemetry+4

figma·2023년 8월 28일·4분 읽기큐레이션 요약

Figma를 빠르게 유지하기

Figma는 2018년 한 대의 MacBook으로 운영하던 성능 테스트 체계가 제품과 조직의 성장으로 한계에 이르자 전면적인 개편을 추진했습니다. 플러그인, FigJam, Dev Mode 등 기능이 늘고 코드베이스가 복잡해지면서 기존의 소수 대형 파일 테스트만으로는 성능 회귀를 조기에 발견하기 어려워졌습니다. 이에 Figma는 모든 코드 변경을 대상으로 실제 하드웨어에서 병렬 성능 테스트를 실행하고, 10분 이내에 결과를 제공하는 확장 가능한 시스템을 목표로 삼았습니다. ## 한 대의 MacBook으로 시작한 성능 테스트 - 2018년 Figma는 한 대의 MacBook에서 동일한 테스트 시나리오를 반복 실행했습니다. - 테스트 결과와 실행 시간은 약 한 시간 간격으로 공유 대시보드에 기록됐습니다. - 당시에는 소수의 대형 디자인 파일만으로도 주요 성능 문제를 확인할 수 있었습니다. - 문서 렌더러 구조를 개선하고 WebAssembly 관련 버그를 해결하면서 Figma의 성능을 약 3배 향상시킨 사례도 있었습니다. - 작은 조직에서 단일 컴퓨터로 테스트하는 방식은 단순하고 비용이 낮다는 장점이 있었습니다. ## 제품과 조직의 성장으로 드러난 한계 - 5년 동안 코드베이스가 커지고 다음과 같은 기능이 추가됐습니다. - 플러그인 - Community 기능 - FigJam - Dev Mode - 수많은 제품 업데이트 - 기존에 사용하던 몇 개의 대형 디자인 파일은 늘어나는 기능과 예외 상황을 충분히 대표하지 못했습니다. - 기능별로 세밀한 성능 테스트를 작성하는 것이 이상적이었지만, 엔지니어와 매니저가 400명 이상으로 늘면서 모든 변경 사항을 한 사람이 추적하기 어려워졌습니다. - 성능 테스트 대상과 코드 변경이 많아지면서 단일 노트북만으로는 출시 전 성능 회귀를 안정적으로 발견할 수 없었습니다. - 원격 근무가 시작된 뒤에도 사무실에 있던 MacBook은 계속 테스트를 실행했고, 결국 2020년 10월 과열됐습니다. - 다른 노트북으로 같은 환경을 재현하려 했지만 테스트가 원활하게 실행되지 않아 새로운 시스템이 필요해졌습니다. ## 세밀한 성능 테스트의 필요성 - **세밀한 성능 테스트(granular performance test)**는 특정 기능이나 사용 패턴을 대규모 조건에서 검증하는 테스트입니다. - 예를 들어 Figma는 다음과 같은 상황을 시뮬레이션할 수 있습니다. - 100명의 협업 편집자가 동시에 파일을 편집 - 여러 사용자가 레이어를 이동 - 동시에 새로운 텍스트 입력 - 사용자가 빠르게 화면을 패닝 - 이런 테스트는 특정 기능의 성능 영향을 정확하게 파악하는 데 유용합니다. - 하지만 기능 수와 엣지 케이스가 계속 증가하면 모든 기능을 수동으로 테스트하는 방식은 조직 규모에 맞게 확장되지 않습니다. ## 새 성능 테스트 시스템의 목표 - Figma는 시스템을 처음부터 다시 설계하며 세 가지 문제를 해결하려 했습니다. - 성능에 영향을 줄 수 있는 기능의 증가 - 테스트 하드웨어 운영의 어려움 - 신뢰할 수 있는 성능 지표의 부족 - 메인 모노레포에 제출되는 **모든 코드 변경**을 테스트해 성능 회귀를 개발 초기에 발견하는 것을 목표로 삼았습니다. - 사용자가 버그를 보고한 뒤 대응하는 대신, 기능이 배포되기 전에 성능 문제를 예방하려 했습니다. - Figma 사용자는 하루에도 여러 시간 제품을 사용하기 때문에 작은 지연도 작업 흐름에 큰 영향을 줄 수 있다고 판단했습니다. - 성능을 기능 개발 이후의 사후 대응이 아니라 개발 과정에 포함되는 품질 기준으로 다루려 했습니다. ## 병렬 실행과 10분 성능 가드레일 - 테스트 대기 시간을 줄이기 위해 여러 테스트를 동시에 실행하는 **병렬 실행(parallel runs)**을 핵심 전략으로 채택했습니다. - 기존 CI에서도 클라우드 러너를 이용한 병렬 테스트를 이미 활용하고 있었습니다. - 성능 테스트 역시 수십 개의 스트레스 시나리오를 동시에 실행해야 목표 시간을 달성할 수 있었습니다. - 성능 가드레일 검사는 개발 흐름을 방해하지 않도록 **10분 이내**에 완료되어야 한다는 기준을 세웠습니다. - 모든 풀 리퀘스트를 실제 하드웨어에서 테스트하려면 피크 시점에 동일한 성능의 테스트 러너 약 100대가 필요했습니다. - 따라서 새로운 체계는 단순히 테스트 수를 늘리는 것이 아니라, 하드웨어를 효율적으로 운영하고 결과를 빠르게 수집하는 구조여야 했습니다. ## 실용적인 결론 성능 테스트는 제품과 조직이 작을 때는 단일 장비와 소수의 대표 시나리오만으로도 충분할 수 있지만, 기능·코드·팀 규모가 커지면 자동화와 병렬화가 필수입니다. 특히 사용자 경험에 직접 영향을 주는 성능은 출시 후 모니터링하는 것보다 모든 코드 변경 단계에서 회귀를 차단하는 가드레일로 운영하는 편이 효과적입니다.

원문 읽기(새 탭에서 열림)

performance-testingCI/CDwebassemblymonorepo+2