Just Do IT!

[SODA] 프로젝트 마지막 회고 본문

프로젝트/SODA 프로젝트

[SODA] 프로젝트 마지막 회고

MOON달 2025. 6. 20. 17:33
728x90
반응형

캠프가 끝난 뒤 계속 이어졌던 SODA 프로젝트가 어제로 끝이 났다.

캠프가 5/16에 끝났고 어제가 6/19....거의 한 달 가량을 더 진행했다.

사실 중간중간 개인 일정이 좀 있었어서 캠프 때처럼 풀로 진행하진 않았지만 그래도 유의미한 성과가 있어서 다행이다.

 

 

 

 

 

 

 

부하 테스트 진행

 

테스트 환경 ec2, RDS 세팅 → 더미데이터삽입 → 스크립트 작성 → 부하테스트 → 성능 개선(쿼리최적화/튜닝, 레디스 적용, 서버 scale-out 등) → 부하테스트 → 성능 개선 (반복)

 

이 순서대로 부하 테스트를 진행했다.

사실 나는 이렇게 부하 테스드, 성능 개선하는 경험이 이번이 처음이 많이 배웠다.

 

테스트 하기 위해 새로운 서버를 세팅하고, 더미 데이터도 엄청나게 많이 넣었다.

 

테스트 환경 세팅과 더미 데이터 세팅은 다른 팀원들이 해주어서 나는 내가 맡은 API의 성능 개선에 대해 공부하기만 하면 그만이었다. 그래서 추후에 내가 처음부터 해보고 싶다는 생각이 든다.

 

여튼 부하테스트 시나리오대로 진행하였고, 병목 지점 확인 후에 각자 맡은 API 성능 개선을 진행했다.

 

 

 

 

 

 

 

성능 개선

 

일단 내가 맡은 API는 두 가지였다.

  • 사용자 대시보드 - 최근 질문 목록 조회 API
  • 특정 프로젝트의 질문 목록 조회 API

 

성능 개선이라는 걸 처음 해봐서 이것저것 많이 검색해봤다. 검색 결과대로 진행하지는 않았지만..ㅎ

 

첫번째로 최근 질문 목록 조회 API 성능 개선을 진행했다.

  1. API 속도 측정
  2. 로그 보고 분석
  3. 단계별 시간 측정

이 단계를 거쳐서 어디를 개선할지 확인했고, 3번째 순서에서 stopwatch를 통해 각 단계별 시간을 측정했다.

그 이후에 쿼리 최적화를 진행했다.

 

https://daydream-sy.tistory.com/403

 

[MySQL] EXPLAIN 사용하기

EXPLAIN이란?실행 계획DB 서버가 어떤 쿼리를 실행할 것인가 알고 싶을 때 사용하는 명령어DB에는 옵티마이저라는 엔진이 존재하는데, 가장 효율적인 방법으로 SQL을 수행할 최적의 처리 경로를 생

daydream-sy.tistory.com

 

https://daydream-sy.tistory.com/404

 

[SODA] 최근 질문 목록 조회 API 성능 개선하기

성능 개선 전 로그 분석최근 질문 목록 조회 (/articles/my) API 실행 시 로그를 파악하면 아래의 기능들이 있었다.인증 및 사용자 정보 조회JWT 인증 후 auth_id 기반으로 Member 조회비교적 빠름질문 목

daydream-sy.tistory.com

 

자세한 건 이 글에 적어두었다.

아무튼, EXPLAIN, 쿼리 최적화 등등 처음 해본게 너무 많았다.

 

그리고 블로그 글로 작성하지 않은 두 번째 API 성능 개선.

근데 이건 정말 이상했던 게, 혼자서 로그 찍어봤을 떄는 있지도 않은 부분이 조회되면서 N+1 문제가 두번 발생했었는데 귀신같이 해결하고 PR 올리니까 다른 팀원이 해봤을 때는 전혀 조회되지 않았다.

참 이상한 일이었다. 덕분에 이틀 날렸다 ㅋㅋㅋㅋㅋㅋ

 

두 번째 API는 N+1 문제가 발생해서 @BatchSize 추가하였고 마찬가지로 쿼리 최적화를 해주었다.

 

여튼 이 두가지 API 성능 개선하는데 시간이 꽤나 걸렸다.

중간중간 공부해야 할 부분이 많아서 그런가...그래도 두번째 API 성능 최적화는 첫 번째보다는 빨랐다.

 

아래는 내가 작성한 PR들.

자세히 섰고, 노션에 더 자세히 작성했어서 이력서랑 포토폴리오 작성할 때 보고 작성하면 좋을 것 같다.

 

https://github.com/Kernel360/KDEV4-SODA-BE/pull/347

 

[Perform] 최근 질문 목록 조회 API 성능 개선 by seoyeon-jung · Pull Request #347 · Kernel360/KDEV4-SODA-BE

요약 최근 질문 목록 조회 API 성능 개선 연관 이슈 #345 확인 사항 1. Article에 복합 인덱스 추가 복합 인덱스 사용 이유 index ⇒ 데이터 조회의 성능 향상을 위해 사용 상위 인덱스 값에 대한 하위

github.com

https://github.com/Kernel360/KDEV4-SODA-BE/pull/351

 

[Perform] 특정 프로젝트의 질문 목록 조회 API 성능 개선 by seoyeon-jung · Pull Request #351 · Kernel360/KDEV4-

요약 MemberProject 조회 성능 개선 Child Article 및 Vote 조회 N+1 문제 해 연관 이슈 #346 close #346 개선 사항 1. N+1 문제 해결 @BatchSize 설정 childArticles 조회 시 N+1 문제가 발생하고 있어서 childArticles 컬럼에

github.com

 

 

 

 

 

 

 

 

Redis 세팅

 

한 번 각자 맡은 부분 성능 개선 한 뒤에 다시 부하테스트를 했었다.

그리고 로드밸런서에 인스턴스 1개 추가를 했고, scale-out 전략 적용 뒤 세 번째 부하테스트를 했다.

이 과정은 다른 팀원이 진행했어서 3차 부하 테스트 결과를 기다렸다.

 

3차 부하 테스트 이후 레디스를 통해 스프링의 CPU 부담을 줄이는 방법으로 결정했다.

 

그리고 Redis 세팅하고 각자 필요한 부분에 적용해주었다.

 

https://github.com/Kernel360/KDEV4-SODA-BE/pull/360

 

[Perform] 사용자 대시보드의 최근 질문 목록 조회 API Redis 캐싱 적용 by seoyeon-jung · Pull Request #360 ·

요약 사용자 대시보드의 최근 질문 목록 조회 API Redis 캐싱 적용 연관 이슈 Close #356 확인사항 1. util 패키지 생성 후 CacheKeyHelper 추가 정렬 키를 일관되게 생성하기 위한 helper class 생성 2. ArticleCache

github.com

 

내가 작성한 PR.

 

PR 작성한 뒤에도 코드 수정한 부분이 좀 있다.

캐싱하고 무효화하고...이건 그래도 초반 성능 개선할 때보다는 빨리 끝냈다.

 

이렇게 진행하면서 API 속도가 확실히 빨라진 걸 확인했다.

그래서 여기까지 하기로 하고, 깃허브 리드미까지 완벽히 수정한 뒤에 헤어졌다.

 

 

 

 

 

 

 

성능 개선 결과

깃허브 리드미 캡처

 

리드미에 작성한 부분을 캡처해왔다.

결과는 위에 적힌대로 상당히 API 성능이 개선된 걸 확인할 수 있다.

 

짧다면 짧고 길다면 긴 한 달이었지만 캠프 진행할 때보다 더 많은 걸 배운 것 같아서 뿌듯하긴 하다.

이제 이걸 토대로 조금 더 공부를 해야겠지만, 그래도 저번 프로젝트보다 성장했다는 걸 느낀다.

 

 

 

 

 

 

 


어제 끝나고 바로 회고글을 작성하려 했는데 그냥 오늘 작성한다 ㅋㅋㅋ

진행하면서 팀원들을 친구들보다 더 자주 봤던 것 같은데, 그래도 좋은 팀원들이라 캠프 이후에도 잘 진행했던 것 같다.

이제는 진짜로 이력서랑 포토폴리오에 이 과정들을 추가하고 취업 준비를 열심히 해야겠다.

728x90