커널360 마지막 주 회고

 

2주간 최종 발표를 준비하며 정신 없이 지냈다.

하고싶은 건 많은데 정말 시간이 부족하다.

 

부트캠프가 1달만 더 길었다면... 어땠을까..

 

동시성 이슈 

최종 발표를 준비하며 트러블슈팅으로 어떤것을 발표할까 고민하던 중

부하테스트, 동시성 이슈에 대해 다뤄보고 싶다는 생각을 했다.

사실 부하테스트를 해보고 싶었는데

유의미한 결과를 낼 만큼 환경 구성하기엔 시간이 부족했다.

그래서 동시성 이슈로 트러블 슈팅을 준비했다.

 

Company Entity에 대해서 동시에 수정 요청이 들어올때

기존 방식은 무조건 후속 요청이 반영되는 구조였다.

먼저 요청을 보낸 사람은 수정 요청이 성공했다는 응답을 받았음에도

자신의 요청이 제대로 반영되지 않은 결과를 받게되는 구조였던 것이다.

그래서 Company Entity에 version 필드를 추가하여 이러한 동시성 이슈를 해결하였다.

 

분산 서버 환경에서의 REDIS 동기화 문제

1. 개발 서버와 운영 서버를 분리하였다.

2. 무중단 배포를 구현하기 위해 운영서버는 분산 서버 환경을 구축하였다.

위 2개를 구현하고 나니 운영서버에서 RefreshToken을 저장하는 REDIS가

서로 동기화 되고 있지 않아 문제가 발생할 수 있다는 점을 깨닫게 되었다.

 

이 문제를 해결하는 방법은 크게 3가지다

1. Redis용 서버를 하나 추가로 띄운다.

2. AWS Elastic Cache를 사용한다.

3. Master - slave 구조를 적용한다.

 

사실 적용하기 쉬운 건 1,2 번이지만

2가지 이유로 1,2번은 맘에 들지 않았다.

1번 이유 - network i/o 로 인한 시간 지연이 존재해 아쉬웠다.

2번이유 - 트러블 슈팅 발표 시에 "AWS 서비스에 의존하는 방식으로 해결했습니다! " 

라고 하고 싶진 않았다.

 

그래서 Master - slave 와 더불어 Sentinel도 도입하여 해당 문제를 해결하기로 결정하였다.

 

이 문제를 저녁 8시쯤 발견해서 집가는 길에 GPT 에게 엄청 질문했다.

구현 방식, 동작 과정, Read, Write 주 책임은 누가 가지고 있는지 등등..

 

그래서 다행스럽게도 한 3시간? 걸려서 구축한 것 같다.

그래서 바뀐 서버 아키텍처

조금 더 풍성?!? 해졌다. 

 

부하테스트

부하테스트를 위해 grafana, k6를 사용하여 진행해보았다.

근데 cpu 사용률, DB 커넥션 풀, 스프링 쓰레드 등 여러 정보를 가져오는 부분을 구현하지 못해서

부하 테스트를 해도 유의미한 결과를 가져오진 못했다.

일단 모니터링을 먼저 구축한 다음 부하테스트를 해봐야겠다는 깨달음도 얻었다.

추후 해볼 예정..

 

QA

최종 발표를 준비하며 나름 QA를 빡세게 진행했다.

(근데 빡세게 했는데도 최종 발표때 문제가 발생하긴 했따;;)

진짜 사소한 것 하나하나 다 체크해보았다.

QA는 정말 중요하지만 너무 귀찮은 것 같긴하다..