Inflearn コミュニティ Q&A

tlsdlek119395

投稿した質問数

6週間で完成！バックエンド職務経歴書の差別化戦略4選 - 似たり寄ったりの書類の中で目を引く方法

2-9. 負荷テスト - k6 実習

k6 부하테스트 중인데 개선 전 성능이 너무 안나와서 고민

解決済みの質問

作成

編集済み

1. 현재 학습 진도

부하테스트

2. 어려움을 겪는 부분

부하 테스트의 코드를 통해 성능 개선 사례를 적으려고 합니다. 하지만 현재 평균 req_duration 즉 레이턴시가 너무 낮게 나옵니다. vus를 300으로 두었는데 아마 커넥션 풀이 모자라서 대기가 길어지는게 원인 같긴 합니다. 하지만 이걸 떠나서도 vus 300치고 너무 느리다고 판단되어서 이걸 개선했다고 포트폴리오에 쓰는게 의미가 있을지 걱정됩니다.

또한 커넥션 풀이 모자라다고 대기업 개발자들이 항상 aws의 사양을 up시켜 커넥션 풀만 늘려서 해결하는 해결 방식을 사용하지는 않을 것 같은데 보통 성능 최적화를 통해 커넥션풀 점유를 짧게 해서 최대한 커넥션풀 고갈을 방지하는 방식으로 해결하나요?

만약 그렇다면 성능 최적화 하는 방법에 부하를 분산하기 위한 kafka, redis, msa같은 기술들이 들어가는 건가요?

마지막으로 성능 최적화를 포트폴리오 이력에 쓸 때 적절한 vus수가 궁금합니다 예를들어 면접관이 봤을 때 300명이라면 너무 적다고 판단되지 않을까 걱정되어서 어느 정도의 대략적으로 vus가 적정 인원인지가 궁금합니다,

3. 시도해보신 내용

시도하진 않았지만 개선할 방법으로는 강의에서 제공해주신 mysql의 실행계획을 통해 index 추가와 커넥션풀 사이즈 늘리는 것 그리고 캐싱 도입을 생각하고 있긴합니다.

javaspringmysqlredis이력서

回答 2

dingcodingco

インストラクター

영훈님 좋은 질문 해주셔서 감사합니다!!

테스트 결과를 보니 avg 27.66초, p95 45.37초에 실패율도 27%가 넘는 상황이네요. 질문 하나하나 짚어보겠습니다.

1. 현재 성능이 낮은 게 오히려 좋은 출발점입니다

지금 성능이 안 나온다는 건 "개선할 여지가 크다"는 뜻이에요. 이력서에서 중요한 건 절대적인 수치가 아니라 개선 폭입니다. avg 27초짜리 API를 200ms로 줄였다면, 그게 99% 이상 개선인 거고 면접관 입장에서 "이 사람이 병목을 찾아서 해결할 줄 아는구나"라고 판단할 수 있스빈다

지금 커넥션 풀 고갈 때문에 대기가 길어지는 거라고 추측하셨는데, 실제로 HikariCP 메트릭(active connections, pending threads, connection wait time)을 확인해보시면 근거가 생깁니다. Spring Boot Actuator의 hikaricp.connections 관련 메트릭을 통해 확인할 수 있어요. (https://docs.spring.io/spring-boot/reference/actuator/metrics.html)

2. 커넥션 풀 문제 해결 — 실무에서의 접근 방식

말씀하신 것처럼 커넥션 풀을 무한정 늘리는 건 해결책이 아닙니다. MySQL 서버가 감당할 수 있는 커넥션 수에도 한계가 있고, 커넥션이 많아지면 컨텍스트 스위칭 오버헤드도 커지거든요.

실무에서 가장 먼저 하는 건 커넥션 점유 시간 자체를 줄이는 걸 시도해보는 거에요! 교재 4주차에서 다뤘던 트랜잭션 범위 최적화가 대표적인 예시예요. 트랜잭션 안에서 외부 API 호출이나 불필요한 로직이 들어가 있으면 커넥션을 오래 잡고 있게 되니까, 그 지점을 분석해보는게 좋습니다.

순서로 보면 이렇습니다. 먼저 쿼리 자체를 빠르게 만들어서 커넥션 점유 시간을 줄이고(인덱스, 쿼리 최적화), 트랜잭션 범위를 좁혀서 불필요하게 커넥션을 잡고 있는 시간을 제거하고, 그래도 부족하면 캐싱으로 DB 접근 자체를 줄이고, 그 다음에야 커넥션 풀 사이즈 조정이나 인프라 스케일링을 고민합니다.

Kafka, Redis, MSA 같은 기술은 "부하 분산"이라기보다는 각각의 목적이 있어요. Redis는 DB 조회를 캐싱해서 커넥션 사용 자체를 줄여주는 역할이고, Kafka는 동기 처리를 비동기로 전환해서 요청 하나당 처리 시간을 줄이는 데 쓰입니다. MSA는 서비스 단위로 DB를 분리하면서 커넥션 풀 경합을 줄이는 효과가 있고요. 다만 이런 기술들은 도입 자체가 목적이 아니라, 구체적인 병목을 해결하기 위한 수단으로 쓸 때 의미가 있습니다.

3. VUS 수에 대한 걱정은 내려놓으셔도 됩니다

면접관이 VUS 300을 보고 "너무 적다"고 생각하진 않습니다. 면접관이 보는 건 동시 사용자 수가 아니라, 문제를 발견하고 해결한 과정이에요.

교재에서도 언급했듯이 TPS는 서비스의 비즈니스 요구사항에 따라 달라집니다. 내부 관리 시스템은 10 TPS면 충분하고, 대형 쇼핑몰은 1000 TPS 이상이 필요하죠. 중요한 건 "우리 서비스 기준으로 이 정도 트래픽이 예상되는데, 테스트해보니 병목이 여기서 발생했고, 이렇게 해결해서 목표 TPS를 달성했다"는 스토리입니다.

VUS 300에서 avg 27초가 나왔다는 건, 현재 상태에서 실질적인 처리량이 약 6 TPS밖에 안 된다는 뜻이에요(http_reqs 1093 / 약 180초). 여기서 인덱스 추가하고, 쿼리 최적화하고, 캐싱 넣어서 같은 VUS 300 조건에서 TPS를 100 이상으로 올렸다면 그게 대단한 개선 사례가 될 수 있을 것 같아요!

지금 생각하고 계신 인덱스 추가, 커넥션 풀 조정, 캐싱 도입 모두 방향은 맞습니다. 한 가지 제안드리자면, 한꺼번에 다 적용하지 말고 하나씩 적용하면서 각 단계별로 K6 결과를 기록해두세요. "인덱스만 추가했을 때 avg 27초 → 5초", "캐싱까지 적용했을 때 5초 → 500ms" 이런 식으로 단계별 개선 수치가 쌓이면 이력서에 쓸 때 훨씬 설득력 있는 스토리가 될 것 같습니다!

지금 상태가 오히려 좋은 개선 사례를 만들 수 있는 좋은 출발점이니까, 너무 걱정하지 마시고 하나씩 적용해가면서 수치를 만들어보세요. 실제 프로젝트에 적용해서 단계별 개선 수치를 이력서에 담아보시길 응원합니다!

communityai8509

안녕하세요, 인프런 AI 인턴입니다. 문영훈님.

k6 부하 테스트를 진행하시면서 성능 개선 사례를 이력서에 어떻게 적어야 할지 고민이 많으신 것 같습니다. 특히 현재 vus를 300으로 두었는데 성능이 기대에 미치지 못해 걱정이신 것 같네요.

성능 개선 방법 제안

커넥션 풀 사이즈 조정:
- 현재 커넥션 풀이 부족하여 대기 시간(레이턴시)이 증가하고 있는 것으로 보입니다. 커넥션 풀의 크기를 늘려서 동시 접속 요청을 처리할 수 있는 여력을 확보해보세요.
MySQL 인덱스 최적화:
- 인덱스를 통한 데이터베이스 최적화가 중요합니다. 실행 계획을 분석하여, 조회 쿼리가 효율적으로 처리될 수 있도록 인덱스를 구축하세요.
캐싱 도입:
- 자주 조회되는 데이터의 경우, 데이터베이스 직접 쿼리 대신 캐시를 사용하여 응답 시간을 줄일 수 있습니다. Redis와 같은 인메모리 데이터베이스를 고려해보세요.
부하 분산:
- 테스트가 특정 서버에 집중되고 있다면, 부하 분산을 위한 방법도 고려해보세요. 예를 들어, 더 많은 서버 인스턴스를 활용하여 부하를 분산할 수 있습니다.
성능 개선 후 측정:
- 성능 개선 전과 후의 지표를 명확히 기록해 두세요. 이는 이력서에 성능 개선 결과를 서술할 때 중요한 객관적 자료가 됩니다.

추가 자료

성능 테스트와 관련된 보다 구체적인 사례는 다음의 링크를 참조하시면 도움이 될 것입니다:

질문 제목: 백엔드 성능 테스트 최적화 방법
질문 제목: 성능 측정 및 지도 방법에 대해

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

tlsdlek119395

投稿した質問数

質問する