SignIn Spike 테스트 보고서

[junha-ahn]

Description

	0.0001%	0.001%	인터파크 기준
User Per Minute	20	200	20만

테스트 요약

1. 100만건 데이터 단일 컬럼에 대한 인덱스 추가 후 Slow Query 개선
2. 암호화 CPU 성능 이슈: CPU 코어수 증가 및 암호화 난이도 조절에 따른 변화 관찰 (코어 2배 증가로 Latency 40% 개선)

Enviroment

• Backend Commit: 9e195b8
• Infra Commit: dbcc8ef6188eebb0449b2f1adb494780292a11a0
• Time range: from=1696601556172&to=1696601694289

테이블명	데이터 수
User	100만

NodeGroup	NodeType	Running Pods
Ingress	[t3.small]	Nginx Ingress 팟 1대
Backend	[t3.small, t3.small, t2.small, t2.small]	백엔드 1대 (기타 모니터링 등)

Thresholds

thresholds: {
  http_req_failed: ['rate<0.01'], // http errors should be less than 1%
  http_req_duration: ['p(95)<300'], // 95% of requests should be below 300ms
}

100 ms는 통신시간

Report

K6 Report

• K6 (Native Histogram): ${dashboard}/d/a3b2aaa8-bb66-4008-a1d8-16c49afedbf0/k6-prometheus-native-histograms?&orgId=1&refresh=10s&from=1696601556172&to=1696601694289&var-DS_PROMETHEUS=prometheus&var-testid=signinTest.js&var-quantile=0.95

Resource Report

• Cluster : ${dashboard}/d/4b545447f/1-kubernetes-all-in-one-cluster-monitoring-kr??&orgId=1&refresh=10s&from=1696601556172&to=1696601694289&var-datasource=default&var-cluster=&var-namespace=default

ip-10-0-78-58.ap-northeast-2.compute.internal 는 Backend Pod 실행중 노드

Nginx Report

• Official NGINX : ${dashboard}/d/nginx/nginx-ingress-controller?&orgId=1&refresh=10s&from=1696601556172&to=1696601694289
• Request Handling Performance : ${dashboard}/d/4GFbkOsZk/request-handling-performance?&orgId=1&refresh=10s&from=1696601556172&to=1696601694289

Spring Report

• Official SPRING: ${dashboard}/d/OS7-NUiGz/spring-boot-statistics?&orgId=1&refresh=10s&from=1696601556172&to=1696601694289
  Spring Http: ${dashboard}/d/hKW8gvD4z/spring-http?&orgId=1&refresh=10s&from=1696601556172&to=1696601694289

nginx, network 이슈보다는 스프링 앱 자체 지연에 가까운것을 확인 가능

MySQL Report

• Link: ${dashboard}/d/549c2bf8936f7767ea6ac47c47b00f2a/mysql-exporter?&orgId=1&refresh=10s&from=1696601556172&to=1696601694289

1000ms 이상은 Slow Query

[junha-ahn]

병목 지점 분석

원인

Email에 의한 조회의 슬로우 쿼리 발생로 추정 (MySQL Slow Query 로그에 의해 추정중)

rds.tf

SQL 분석

# Hibernate: select u1_0.id,u1_0.created_at,u1_0.email,u1_0.name,u1_0.pw,u1_0.role,u1_0.updated_at from user u1_0 where u1_0.email=?

SELECT * FROM user WHERE email=?

• 애플리케이션이 생성하는 쿼리
• spring.jpa.properties.hibernate.show_sql=true 옵션으로 확인

analyze table user; # 통계 최신화

select table_schema, table_name, table_rows,
    round(data_length/(1024*1024),2) as 'data_size(mb)',
    round(index_length/(1024*1024),2) as 'index_size(mb)'
from   information_schema.tables
where TABLE_SCHEMA="ticketingdb" and TABLE_NAME = "user" 
group by table_name 
order by data_length desc 
limit 100;

TABLE_SCHEMA	TABLE_NAME	TABLE_ROWS	data_size(mb)	index_size(mb)
ticketingdb	user	991600	145.66	0.00

EXPLAIN select * from user where email = "K6-100000@email.com"
EXPLAIN ANALYZE select * from user where email = "K6-100000@email.com";

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	user	null	ALL	null	null	null	null	991913	10	"Using where"

EXPLAIN ANALYZE
-> Filter: (user.email = 'K6-100000@email.com') (cost=101170 rows=99191) (actual time=92.4..1779 rows=1 loops=1) -> Table scan on user (cost=101170 rows=991913) (actual time=0.121..1607 rows=1e+6 loops=1)

MySQL 8.0 최신 기능

개선방법: Email 인덱스 생성

TABLE_SCHEMA	TABLE_NAME	TABLE_ROWS	data_size(mb)	index_size(mb)
ticketingdb	user	990675	145.66	32.58

32 MB 증가

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	user	null	ref	email_index	email_index	1022	const	1	100	null

EXPLAIN
-> Index lookup on user using email_index (email='K6-100000@email.com') (cost=0.794 rows=1) (actual time=0.0309..0.0324 rows=1 loops=1)

개선 이후 동일 테스트 Report

• Time Range: &from=1696758624101&to=1696758747821

• 10s => 1s

Slow Query 미발생

Latency 기준 성능 10배 개선

• 다만 아직 300ms 기준을 통과하지 못했다.
• 추가 원인 분석이 필요
• 대시보드에서 특이사항을 발견할 수 없음으로, 테스트 데이터를 더 증가시켜본다.
• 0.0001% => 0.001% 테스트 진행

[junha-ahn]

병목 지점 분석

	0.0001%	0.001%(현재진행)	인터파크 기준
동시접속자 per minute	20	200	20만

• 테스트 데이터 생성 목적으로 0.001% 테스트 진행
• Time Range: from=1696759289298&to=1696759423588

원인

Resouce Report > CPU

Spring Rpoert > Load Average

암호화에 따른 CPU 리소스 성능 문제로 추정

• 회원가입/로그인 중 사용하는 암호화는 CPU sensitive 작업이다.

[ CPU 성능 분석 방법론 미비 ] CPU 암호화 연관성. 즉 1개 단위작업(=1 request)에 어느정도의CPU 자원을 현재 사용 중인지는 분석하지 못한 한계점이 있다.

개선방법

• CPU 성능 증가
  • CPU 코어 수 증가 (또는 현재 1개의 Pod을 더 많은 노드에 여러개의 Pod으로 분산)
  • 하나의 CPU 단순 성능 증가
• 암호화 난이도 감소
  • 스프링 앱 내부 암호화 클래스의 strength 인자 조절

참고

• kor-law-for-dev
• BCrypt 동작원리 파헤치기(BCryptPasswordEncoder)
• https://shanepark.tistory.com/427

개선사항: Pod 개수 증가

가장 단순하게 CPU 코어 수 증가 효과를 보기 위해 Pod 개수 1개 => 2개

❯ kubectl get pod                                              
NAME                                                    READY   STATUS    RESTARTS   AGE
development-ingress-nginx-controller-677b46dc9d-pxw5s   1/1     Running   0          2d2h
development-ticketing-application-bf9455b5f-pw4d7       1/1     Running   0          2d20h
development-ticketing-application-bf9455b5f-wpcp6       1/1     Running   0          87s

• Time range: from=1696762976174&to=1696763104767

물런 여러번의 테스트를 통해 평균값 비교를 하는 등 더 엄밀한 측정 방법이 있겠지만, 그럼에도 기존 P(95)=10s에서 6s로 성능 증가를 확인했다.

기존처럼 20VU(0.0001% 테스트)로 진행했을 경우도 마찬가지로 성능 증가를 확인 가능하다

• 기존: P(95)=1.3s
• Pod증가 이후: 680ms

정확히 50% Latency 개선이 아닌 것은 Nginx 로드밸런싱 관련 이슈로 추정한다 (매번 정확히 Idle Pod에 요청을 날리는게 아니기때문에)

개선사항: 암호화 난이도 조절

• 더 자세한 정보는 암호화 난이도 조절 #107

Log Rounds	response time
4	10ms
6	12ms
8	26ms
10 (기본난이도)	75ms
15	2s
20	1m 8s

로컬 환경에서 난이도에 따라 어느정도의 시간이 평균적으로 소요되는지 계산

만약 난이도를 10에서 낮춘다면 대략 어느정도의 시간을 감소시킬 수 있는지 확인하였다.

round수는 많을 수록 좋지만 시스템에 지장을 주지 않는선에서 round수를 지정하라고한다.
Log Round 를 먼저 정하지말고 서버에서 encode에 어느정도 걸리는지를 확인하고 250ms 에 비슷하게 맞추라고 조언하고있다

즉 난이도의 조절로 Latency 조절이 가능하며, 향후 Production 환경에서 개발할 경우 250ms를 목표로 난이도를 조절해야 한다.

• 현재 1개 POD에서 약 1s 소요되고 있기 때문에 300ms 목표를 위해 난이도를 4로 조정해야함을 예상한다.

현재 테스트 환경에서는 더 이상의 테스트는 진행 하지 않는다.