nGrinder는 네이버에서 개발해 오픈소스 소프트웨어로 공개한 부하 테스트 플랫폼입니다. 가상의 사용자를 모방해 타깃 서버에 부하를 가하는 부하 테스트 플랫폼의 특성상 상당히 많은 스레드를 사용해 HTTP 요청을 발생시킵니다. nGrinder에서 사용하던 HTTP 클라이언트에는 스레드 수가 많아질수록 부하 테스트 양의 증가가 미미해진다는 한계가 있었습니다. I/O를 처리하는 스레드가 많아짐에 따라 컨텍스트 스위칭 비용이 증가해 부하를 생성하는 작업에 컴퓨팅 리소스를 원활하게 제공하지 못하는 것이 원인이라 생각했고, 이런 문제를 해결하고자 HttpClient 5를 적용했습니다. 이 글에서는 nGrinder에 HttpClient 5를 적용하면서 분석한 HttpCore 5와 HttpClient 5의 특징과 작동 방식을 소개하겠습니다. HTTP/2와 비동기 응답 처리를 지원하는 HTTPCLIENT 5 Apache HttpClient(이하 HttpClient)는 Java 언어를 사용하는 많은 웹 개발자가 한 번쯤은 들어 봤을 만한 라이브러리이다. HttpClient는 HTTP 통신을 이용해 메시지 송수신을 손쉽게 처리할 수 있게 만들어진 라이브러리로, 오픈소스 소프트웨어로 공개되어 있는 HTTP 클라이언트이다. 2021년 7월 현재 가장 많이 사용되고 있는 HttpClient는 HttpClient 4.x이며, 수많은 다른 artifacts에서 사용되고 있다. 이 글에서 소개할 HttpClient 5는 HttpClient의 최신 버전이다. 'httpclient5'라는 별도의 artifact 이름으로 배포되고 있고, 2021년 7월 현재 5.1 버전까지 릴리스되었다. 별도의 artifact로 배포되는 이유에 대한 설명은 없지만, 기존의 구현체와 호환되지 않는 완전히 새로운 구조를 가졌기 때문이라 판단된다. 새로운 구조를 가진 HttpClient 5는 HTTP/2를 지원하고, 기반 기술부터 완전히 비동기 방식으로 변경되어 비동기 응답 처리를 지원한다. HTTP/2 지원 HttpClient 5의 첫 번째 특징은 HTTP/2를 지원한다는 것이다. HTTP 클라이언트를 생성할 때 다음과 같이 사용할 버전 정책을 옵션으로 지정할 수 있다. CloseableHttpAsyncClient client = HttpAsyncClients.custom() .setVersionPolicy(HttpVersionPolicy.NEGOTIATE) .build(); HttpVersionPolicy가 지원하는 정책은 FORCE_HTTP_1과 FORCE_HTTP_2, NEGOTIATE이다. 기본적으로는 NEGOTIATE 정책을 사용해 HTTP/2를 지원하는 서버에는 HTTP/2를 사용한 요청을 보내고, HTTP/2를 지원하지 않는 서버에는 HTTP/1.1을 사용한 요청을 보낸다. FORCE_HTTP_1과 FORCE_HTTP_2 방식은 각각 HTTP/1.1과 HTTP/2를 사용한 요청을 보낸다. 만약 HTTP/2를 지원하지 않는 서버에 FORCE_HTTP_2 방식을 사용한 클라이언트

전편(실시간 댓글 개발기(part.1) -DAU 60만 Alex 댓글의 실시간 댓글을 위한 이벤트 기반 아키텍처) 에서는 기본적인 테스트 환경 구축에 대한 설명을 드렸다면, 이번에는 테스트 진행에 대해서 공유하고자 합니다. 목표는 라이브 댓글 서버 한대당 10k 커넥션을 안정적으로 유지하고 2800TPS를 받을 수 있도록 하는 것인데요, 안정화를 위해서 Spring WebSocket 기능 뿐만 아니라 Tomcat, VIP, 물리장비, Docker 컨테이너 등에 대해서 메모리 및 file descriptor, configuration 등을 튜닝하였고 이를 위해 nGrinder, jcmd, Neo, FastThread.io, 직접 제작한 Golang Client 등 다양한 툴을 활용하였습니다. 너무 많은 것들을 동시다발적으로 튜닝하다보니 일관된 흐름으로 풀어내지 못한 것이 아쉽긴 하지만 가능한한 비슷한 것들을 묶어서 정리해보았습니다. 확인 및 튜닝 항목 위에서 언급한 바와 같이 한개의 변수만을 바꾸어가며 차근차근 진행이 되지 못하고 한번에 다양한 방면의 변수들을 동시 다발적으로 테스트 한 경우가 많았지만, 진행된 테스트들을 크게 분류 해보자면 다음과 같습니다. VIP 최대 커넥션 수 조절 최대 TPS 조절Virtual/Physical Machine fileDescriptor 수 조절 CPU, 메모리 사용률 모니터링Docker fileDescriptor 수 조절Tomcat 최대 동시 커넥션 리밋 조절Spring WebSocket Application 연결이 한번 발생할 때 생성되는 process와 task 개수 및 사이즈 SimpleBroker 설정 조절 몇 개월 동안 위 항목들에 대한 수많은 테스트와 튜닝을 진행하면서 알게 된 사실들이 많지만 그 중 핵심 내용들만 다뤄보고자 합니다. 어플리케이션 분석 툴 소개 Neo 도입 우선 위 테스트들을 진행 하면서 소켓 관련 스프링 내부의 구조를 파악하기 위해 클라이언트를 소량으로 테스트하거나, 대량으로 테스트를 하더라도 커넥션이 성공적으로 맺어졌는지 집중적으로 확인할 필요가 있습니다. 또한 실제로 트래픽이 들어왔을 때 정확히 어떤 리소스가 어떻게 사용이 되는지에 대한 이해가 꼭 필요합니다. 이 부분을 더 정확하게 파악하기 위하여 당시 사내 자바 모니터링 시스템인 Neo를 사용해보기로 했습니다. Neo의 분석 메뉴에서 메소드 분석 탭에 들어가면 관리 기능을 통해서 특정 장비의 Thread Dump를 쉽게 뜰 수 있습니다. 분석 키워드는 기본적으로 kakao, daum 두 개가 등록되어 있는데, 우리는 spring messaging 패키지의 분석을 수행했으므로 messaging 키워드만 남겨놓고 분석 시작 버튼을 눌렀습니다. 분석이 끝나면 위 그림과 같이 분석 키워드에 매칭되는 메소드 목록을 보여주며, 그 중 하나를 클릭하면 쓰래드의 상태를 표시해줍니다. 위 그림은 현재 서버 상태의 스크린샷을 뜬 것으로써 특이사항은 없는데요, 아쉽게도 장애 시점의 스크린샷을 남긴 것이 없는 관계로 기억을 더듬어보면 위

Redis 테스트를 진행했습니다. 계기: Redis 성능 측정과 Key/Value 값 저장 문제 최근 서비스 고도화를 위해 회사의 중요 서비스들을 MSA로 변환하던 중, 성능 향상 및 용도를 이유로 개발팀은 Redis 도입을 고려하고 있었습니다. 그러다 최근 api 하나의 버전이 업데이트된 이후 덜컥 장애가 발생했습니다. 확인해보니 APM을 통해서 분석을 하던 도중 이번에 도입된 Redis에서 적재된 key 값을 가져오지 못하여 AWS RDS에 그대로 부하가 쏠려 문제가 발생했던 것이었습니다. 문제가 발생한 API는 Look-Aside-Caching 방법을 사용하고 있습니다. 원인 분석 회의에서 두 개의 궁금한 사항이 생겼습니다. 해당 Key/Value를 Redis에 세팅을 하지 못한 이유가 무엇이었을까? 그리고 생성된 Redis 사이즈가 과연 우리 서비스 애플리케이션에서 사용하기에 적절한 용량인가? 회의 중에 주요 원인은 어느 정도 밝혀진 상태였지만 아직까지 회사에는 표준 Redis 규격이 없었으며, 성능 테스트를 통한 Redis Sizing 작업의 모델이 될 만한 좋은 케이스가 없었습니다. 그래서 원인 분석을 위해 간단하게 테스트한 다음, 추후에 테스트 데이터를 많이 쌓아 표준 사이징을 해보기로 했습니다. 측정/테스트 도구를 찾아보자 Redis는 기본적으로 성능을 테스트하고 용량 측정을 도와주는 redis-benchmark 명령어를 지원해줍니다. 이 명령어를 사용하여 임의의 Key/Value를 생성 및 호출하고 다양한 옵션을 사용해서 폭넓게 성능 측정을 할 수 있습니다. 다만 저희 컬리에서는 redis-benchmark 명령어만으로 성능 측정을 하기는 힘들었습니다. 이유는 다음과 같습니다. AWS에서 Elasticache를 사용합니다. Elasticache에서는 redis-benchmark 명령어를 외부에서 받지 못합니다. AWS Elasticache에서는 성능에 영향을 주는 명령어들이 disable 되어 있습니다. 발생된 문제를 재현하여 검증을 하고 싶었습니다. Redis 문제를 해결하고 그 경험을 팀에 공유하고 싶었습니다. redis-benchmark 사용법 redis-benchmark는 기본적으로 주요 명령어(PINK, SET, GET, LPUSH, RPUSH, LPOP, RPOP, SADD, HSET, STOP, LRANGE, MSET)을 10만회씩 실행해서 성능을 측정 합니다. # 기본적으로 Redis 서버를 지정하고 명령어를 실행하면 기본값으로 주요 명령어를 10만번씩 호출 합니다. $ redis-benchmark -h <Redis 서버 IP> -p 6379 ====== PING_INLINE ====== 100000 requests completed in 0.95 seconds 50 parallel clients 3 bytes payload ... 아래의 옵션을 사용하면 다양한 테스트가 가능합니다. -h: Redis 서버를 지정합니다. Default는 127.0.0.1 -p: Redis Port를 지정합니다. Defaul

김준우 2020.02.18. 다나와 이벤트 서비스를 클라우드로 전환하기 위한 부하 테스트를 진행하였습니다. 다나와 이벤트서비스는 이벤트가 없으면 아주 적은 트래픽이 발생 하지만, 이벤트가 시작되면 동시에 2만 요청까지 발생됩니다. 대량 처리가 가능한 서버를 구축을 하게 되면 비용이 많이 소모되며 이벤트가 없으면 자원낭비가 발생합니다. 그래서 이벤트 서비스는 구글 클라우드(GCP)에서 제공하는 Cloud Run을 사용해보기 위해 부하 테스트 및 과금 정책에 대해 공유 합니다. Cloud Run 이란? 완전 관리형 환경 또는 Anthos에서 스테이트리스(stateless) 컨테이너를 실행할 수 있습니다. 구글에서 가지고 있는 커다란 쿠버네티스 클러스터에 서비스를 배포할 수 있고, Anthos라고 직접 구성한 클러스터에 연동하여 서비스를 배포할 수 있습니다. 모든 언어, 라이브러리, 바이너리까지 지원이되고, 자동확장기능을 지원합니다. 내부적으로 오픈소스인 Knative 기반으로 빌드됩니다. stress 테스트 시나리오 Cloud Run 샘플 프로젝트 배포 대량 요청 전송 모니터링 및 결과 레포팅 Cloud Run 샘플 프로젝트 구성 샘플 프로젝트는 동시 접속을 위해 500ms 지연시키는 페이지를 구성합니다. 지연시키는 이유는 동시접속시 부하를 가중시키는 효과를 보기 위함입니다. index.php nGrinder 구성 부하 테스트로 네이버에서 개발된 nGrinder 를 사용합니다. GCP VM을 사용하여 컨트롤러 1대와 에이전트 90대를 구성하여 동시에 요청을 보낼수 있도록 구성합니다. 명령어는 gcloud가 구성되어 있어야 사용가능합니다. docker hub에 ngrinder controller 와 agent를 제공하고 있어 설치 과정없이 바로 Controller를 생성합니다. gcloud beta compute --project=event-web-poc instances create-with-container controller --zone=asia-northeast1-b --machine-type=n1-standard-4 --subnet=default --network-tier=PREMIUM --metadata="google-logging-enabled=true,startup-script=docker run -d -p 80:80 -p 16001:16001 -p 12000-12009:12000-12009 --name=agent ngrinder/controller" --maintenance-policy=MIGRATE --scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/servi