[회고] 응답에 대한 처리 속도 개선 방안은 뭐가 있을까?

필자가 다니고 있는 회사는 요즘 큰 문제점(?)을 가지고 있다. 

트래픽이 증가하면서 예기치 못한 장애가 발생하면서 현재 작동하고 있는 애플리케이션에 대한 튜닝 작업을 해야하는 것이다. 

제가 다니고 있는 회사에 있는 DevOps 엔지니어 분은 우선 해결책으로 현재 데이터베이스의 성능이 좋은 걸 쓰고 있으니 애플리케이션이 모든 Request를 받을 수 있게 증설하면 되지 않을까? 라는 것으로 시도하여 진행하였습니다.

 

확실히 이전보다 증설하면서 Request 처리량과 500 에러를 많이 줄일 수 있었다. 

하지만 근본적인 이유는 아니였다. 

 

필자 또한 같이 고민해보았다. 무엇이 문제였을까?

DevOps 엔지니어 분께서 추가적으로 현재 애플리케이션이 제대로된 퍼포먼스를 보여주지 못하고 있다고 했다. 

 

그래서 저는 이러한 바탕으로 가설을 작성하고 시행하려고 했습니다.

 

• 쿼리량을 볼 수 있는 모니터링이 있는데 거기서 COMMIT 량이 많다는 것
• 데이터베이스에 저장되어 있는 값이지만 변동이 거의 없는 테이블에 대해서 조회를 하는 api 에 대한 캐싱 처리를 하지 않는다는 것

이렇게 두개의 가설로 시험을 시작하였습니다.

 

우선 nGrinder로 TPS, MTT에 대한 추이를 보는 걸로 시작했습니다.

 

 

진행방식과 환경 구성은 다음과 같습니다.

 

진행방식
유저수를 1 -> 2 -> 4 -> 8 -> 16 -> 32 -> 64 -> 128 -> 252  순으로 늘리는 과정을 가졌습니다.

환경 구성
uwsgi의 process 갯수는 4, thread 갯수는 2로 설정했습니다. 그리고 애플리케이션은 2개를 띄웠습니다.

조회 방식은 하나의 테이블에 대한 타입을 in절로 조회하는 api에 대해서 테스트를 진행했습니다.

 

실제값이 아닌 비율로 설정해서 나타내었습니다.

 

1. 트랜잭션 O + 캐싱 X

유저 수	트랜잭션 O + 캐싱 x
	TPS(초당 처리 량)	MTT(평균 처리 시간)	ERR RATE
1	1.5	7	0
2	3	7	0
4	6	7	0
8	9	8	0
16	15	11	0
32	15	20	0
64	15	41	0
128	15	85	0
252	14	148	86.2

 

 

2. 트랜잭션 O + 캐싱 O

유저수	트랜잭션 O + 캐싱 O
	TPS	MTT	ERR RATE
1	2	5	0
2	4	5	0
4	7	6	0
8	12	6	0
16	22	7	0
32	25	12	0
64	25	25	0
128	27	47	4.7
252	27	81	73.5

 

3. 트랜잭션 X + 캐싱 O

유저수	트랜잭션 X + 캐싱 O
	TPS	MTT	ERR RATE
1	3	3	0.1
2	6	3	0
4	13	3	0
8	28	2	0
32	65	4	0
64	72	9	0

 

 

4. 비교 분석

	1번 : 2번	1번 : 3번
TPS	1: 1.61	1: 4.58
MTT	1.62: 1	4.58: 1

 

 

4-1. 캐싱으로 얻을 수 있는 점

응답에 대한 캐싱을 적용했을 때 이전에 비해 1.6배정도의 처리량을 보여주고 이전보다 5/8로 응답처리시간이 줄어든다.

 

4-2. 캐싱과 불필요한 트랜잭션을 제거 했을 때

응답 캐싱과 필요없는 트랜잭션을 제거했을 때에는 이전보다 4.58배의 처리량을 보여주고 처리속도는 그것에 대하여 반비례를 보여준다.

 

 

 

5. 해결방안

• 당장 트랜잭션을 제거하기에는 검토할 부분이 많으므로 우선 캐싱을 적용할 수 있는 부분은 적용을 하여 요청에 대한 처리량 증가와 처리속도 감소의 이점을 보자
• 트랜잭션에 대한 제거는 검토를 하면서 빠른 시일 내에 적용을 하면 많은 이점을 볼 수 있을 것이다.

비교분석에서 나온 수치라면 인스턴스 100대 띄울 양을 25대 보다 적은 양으로 처리를 할 수 있다는 것을 의미한다.