🤐TMI🤐
일단은 이 글을 작성하면서 먼저 반성하는 시간을 가질려고 합니다...
현재 백엔드개발자로 입사한 지 2년 6개월 가까이 됐는데...😱😱😱
서버가 터지고 이슈 해결이 된 지 어엿... 2년이 되어가는... 시점에서
(물론 개인 노트에 관련 내용은 적었지만) 지난 회고 때 분명히 꾸준히 하겠다고
다짐을 했었터라 혼나야 되긴 합니다.. 하하..🤣🤣🤣
TMI는 여기까지 하고 관련 이슈에 대해 얘기해보도록 하겠습니다!
(레거시적인 내용은 TMI일거라 최대한 삼가하겠습니당..ㅎ)
💩서버 다운💩
상용 프로젝트 서버구성에 대해 간단하게 설명드리자면, 4개의 어플리케이션이
존재하는데 각 모듈마다 서버를 나눠서 관리합니다.(부하방지)
사업이 확장됨에 따라 계속 늘어나는 환자 및 직원에 위치 측위 및 센서측정를 담당하는 도중에
(수천명의 환자 및 직원) Core API 모듈이 다운
📝원인은..?
크게 Redis Async 2가지 원인으로 볼 수 있다.
1. Redis
회사 레거시 코드(Core API 로직)은 Redis를 많이 사용한다. Core로직에서 많은 부분이 수행되야 하기 때문에 처리속도면에서 강점을 가지고, 데이터 유실에 비교적 안전한 (데이터 보존에도) 이점이 있기때문에 사용을 많이 하는데, 실제로 Redis를 사용하면서 많은 부분에서 루프문을 돌면서 레디스 커넥션맺는 부분이 있었다. 레디스는 싱글 쓰레드 기반이기 때문에... (Async편에서 이어집니다..)
2. Async
위에서 말씀드렸다시피 레디스는 싱글 쓰레드 기반이기 때문이고
레거시 코드(API)는 Async(비동기)로 처리가 되어있다.
I병원은 회사에 가장 규모가 큰 프로젝트 중 하나였다. 그래서 프로젝트
사이즈에 맞춰 서버 스펙 산정한다. 프로젝트가 확장됨에 따라 대용량 트래픽에
대한 처리에 문제가 생겼다. 코어로직은 비동기 처리를 하는 데, 초당 수십만 건에
Request가 오는 데 병렬처리로 수행되고 몇몇개의 Redis 핸들링 로직에서
아까 언급했던 Redis 루프문을 도는 데 처리를 못하고 커넥션 시간이 초과돼고 행이 걸려서
서버가 죽은 것이다.(Scouter 모니터링을 통한 정밀분석)
요약하자면
코어로직 비동기 처리(병렬구조) -> Redis에 상당한 부하(의존) -> 높은 트래픽으로 행걸려 서버 다운
이다.
🫡해결방안🫡
가장 쉬운 해결방안은 서버사양을 늘려서 해결하는 법 이다.
그렇지만, 그렇게 해결하는 방법은 추후에 규모있는 프로젝트 마다 서버사양을 높이는 건
최대한에 마진을 남겨서 이윤을 창출해야 하는 기업 입장에서는 있을 수 없다 생각한다.
그래서 어렵지만 솔루션 고도화를 통해 해결하였다.
고도화 과제를 참여했고 그때 정리했던 해결방안을 공유하고자 한다.
1. Core로직에 Async 삭제
- 병렬처리에서 -> 직렬처리로 변경
2. 처리방식을 효율적으로 개선
- 레디스 커넥션 최소화 (Redis 루프는 가벼운 로직이라 RDB에서 하도록 변경)
- 처리 방식을 효율적으로 개선(고도화 그자체..)
3. API Max Thread 증가
- 서버 부하 확인하면서 안전한 선에서 MaxThread 증가
💡마치며💡
이슈 발생일은 어림잡아 21년도 7월 금요일밤에 이슈가 터져서
새벽까지 스카우터로 분석하고 주말동안 엔지니어 분은 서버 모니터링 하시고
개발자는 고도화작업을 하여 정말 고생이 많았는데 돌이켜 생각해보면
대용량 트래픽을 경험하여 디버깅부터 시작해서 고도화, QA지원 등
최고의 값진 경험이라 생각하고 솔직히 말해서 레디스 루프쪽 로직은
복잡한 로직은 아니였지만 미치는 영향이 거대했다.
그 이후 코드를 짜는 데 좀 더 퀄리티 있는, 효율적인 로직을 구현할 수 있도록
많은 영향이 미친 거 같다. 정말 감사하다..!!
