exp015_Nginx 적용 여부에 따른 게시글 생성 요청 성공률 변화 관찰

들어가기

Postgres DB insert 실험을 진행중이다. 30,000개 데이터 생성 시도 중 성공 갯수는 약 12,500개로 생성 성공율은 약 42% 이상 도달하지 못하고 있는 상황이다.

이에 대해 현업 시니어 멘토님과 대화를 나눴는데, Connection Pool이 성능 개선에 큰 영향이 없을 것이라는 이야기를 해주셨다. 그 이유는 Connection Pool이 머신의 CPU, Memory의 크기에 따라 영향력이 달라지기에, 우리 머신의 성능으로는 유의미한 개선 효과를 얻기 힘들기 때문이다. 한 DB 인스턴스에서 사용 가능한 connection pool은 많아야 30개 즈음이라고 현업에서는 이야기한다고 한다.

Connection Pool 문제가 아니면 왜 게시글 생성 성공률이 42%에 불과할까.

지금 시스템의 가용성이 떨어지는 원인을 다시 한번 생각해보았다. VUser 3,000명에 insert가 약 12,500회를 기점으로 에러가 발생한다. 에러 상황 발생 시 웹서버의 CPU는 10.5,%, DB CPU는 10.2% 사용중이다. 리소스 쪽은 비교적 평온한 상황이라는 말이다. insert는 30,000개나 들어가고 있는데 왜 웹서버와 DB는 놀고있을까 생각해보니, 혹시 이런 상황이 아닐까 생각했다.

만약 요청이 많은데 요청을 제대로 처리하지 못하고 있는 상황이라면 어떨까? 웹서버로 도달하기 전에 병목지점이 있다면 지금 상황을 설명할 수 있게 된다. 그렇다면 이 요청들을 어떻게하면 잘 처리해줄 수 있을까?

생각하던 중 Nginx가 생각났다. Nginx가 요청을 잘 처리해준다는 이야기를 어디서 들어본 적이 있다. 아파치의 C10K 문제도 해결해준다는데, 지금 내가 처한 문제도 비슷한 문제가 아닐까? 게다가 현재 시스템은 DB-어플리케이션 서버 2레이어 구조로 구성되어 있는데, 여기에 웹 서버가 추가된 3 레이어 구조가 최근에는 표준으로 받아들여진다는 점에서 Nginx를 도입해도 좋을 것이라는 생각이 들었다.

그래서 곧바로 실험에 옮기기로 했다.

Title

exp015_NGinx 적용 여부에 따른 게시글 생성 요청 성공률 변화 관찰

Research Question

• Nginx를 도입하면 게시글 생성 성공율을 높일 수 있을까?

Summary

• 게시글 생성 요청 30000개 중 성공률이 약 42%을 넘지못하는 상황
• 서버 부하 문제라고 판단하여 이를 해결하기 위해 Nginx를 도입
• 게시글 생성 성공율은 0.5% 증가했지만 유의미한 증가폭이라고 보기 어렵다. 리소스 사용률도 웹서버 CPU 15.5%, DB CPU 11.3%로 이전과 큰 차이가 없었음

Background Information

• 부하 테스트 툴 nGrinder을 활용하여 경매 래플 어플리케이션 시스템의 서버 부하 테스트 진행중인 상황

Procedures

요청할 URL을 기존 3000포트를 생략한 url(80번 포트)로 지정해주었다. 왜냐하면 Nginx를 거쳐서 요청을 하고 싶기 때문이다.

Data Recording & Analysis

test-pyramid-20230306-001

또 1240명에서 멈췄다.

현재 실험 : 20230306-001

• Vuser : 3000
• Run count : 10
• Total request : 30000
• Ramp-up : True
• 테스트 시작 전 DB 데이터 개수 : 0
• 테스트 완료 후 DB 데이터 개수 : 12662
• 테스트 중 생성 데이터 개수 : 12662
• 데이터 생성 성공율 : 42.2%

비교 실험 : 20230303-001

• Vuser : 3000
• Run count : 10
• Total request : 30000
• Ramp-up : True
• 테스트 중 생성 데이터 수 : 12513
• 데이터 생성 성공율 : 41.7%

Nginx를 적용해시 생성 성공율은 0.5% 증가했지만 유의미한 증가폭이라고 보기 어렵다. 리소스 사용률도 웹서버 CPU 15.5%, DB CPU 11.3%로 이전과 큰 차이가 없었다.

test-pyramid-20230306-002

팀원들과 이야기하다가 로그 이야기가 나왔는데, 로그가 생각보다 리소스를 많이 잡아먹는다는 이야기를 해주셨다. 현재 리소스는 웹서버, DB 모두 16% 미만으로 사용하고 있기 때문에 리소스 문제는 아닐 것으로 추측되지만, 혹시 모르니 한번 로그를 지워보고 테스트를 해보기로 했다.

bids.controller

  @Post()
  create(@Body() bid) {
    // this.createBidCount++;
    // this.logger.log(`${this.createBidCount}번째 입찰 등록`)
    return this.bidsService.create(bid);
  }

현재 실험 : 20230306-002

• Vuser : 3000
• Run count : 10
• Total request : 30000
• Ramp-up : True
• 테스트 시작 전 DB 데이터 개수 : 12662
• 테스트 완료 후 DB 데이터 개수 : 25392
• 테스트 중 생성 데이터 개수 : 12730
• 데이터 생성 성공률 : 42.4%

데이터 생성 성공률은 로거 제거하기 전인 42.2% 대비 0.2% 상승한 42.4%다. 우연일 수도 있고 진짜 성능이 개선된 것일 수도 있다. 하지만 0.2%는 사실상 큰 차이가 없다.

결국 로그 제거 방식도 성능 개선에 효과가 없다.

Discussion

Conclusion

• 게시글 생성 요청 30000개 중 성공률이 약 42%을 넘지못하는 상황
• 서버 부하 문제라고 판단하여 이를 해결하기 위해 Nginx를 도입
• 게시글 생성 성공율은 0.5% 증가했지만 유의미한 증가폭이라고 보기 어렵다. 리소스 사용률도 웹서버 CPU 15.5%, DB CPU 11.3%로 이전과 큰 차이가 없었음

Reference

Appendix

test-pyramid-20230306-001

test-pyramid-20230306-002