안녕하세요. 트러블슈팅 전반부 발표를 맡게된 이종원이라고 합니다.

각자 겪은 트러블슈팅을 문제, 해결과정, 결론의 3단계를 거치면서 발표를 진행하게 됩니다.

첫 시작으로 대규모 알림 시스템 성능 개선 과정 부터 발표를 시작하겠습니다.

이번 프로젝트에 팔로우한 유저 전원에 대해 알람을 보내야 하는 과정이 필요했습니다. 만약 10,000명이면 전10,000명 전원에게 알람을 전송해야하는데, 이때 동시 전송 시 대규모 병목 현상이 예상되었고

또한 단순 반복문 시, DB조회와 알람 객체 생성과정엫서 응답 시간이 급증하고 시스템 장애 발생이 우려되어습니다.

이 점이 크게 문제가 된다고 판단되었습니다. 왜냐하면 알람은 연성 실시간 처리가 필요한 시스템이라, 실시간에 빠르게 보낼수록 좋은데, 병목으로 느려지면 유저 경험에 안 좋을 것이라 판단되었습니다.

이 문제를 해결하기 위해 로직을 살펴보았습니다. 그 결과 알람 발생자, 장소 등 공통되는 데이터가 반복적으로 DB에서 조회하는 로직을 발견했습니다. 이 부분을 해결하기 위해 캐시를 도입해서 DB조회를 최소화하고 속도를 높였습니다 하지만 아직 애플리케이션 레벨에서 부하 문제가 여전히 존재했습니다.

해당 문제는 책”가상 면접 사례로 배우는 대규모 시스템”에서 답을 얻었습니다.

알람 서버와 알람 엔티티를 생성하고 메일 등으로 보내는 작업 서버로 분리시키고

알람 서버와 작업 서버간에 메시지큐로 순차적으로 처리하는 방식입니다.

해당 방식을 그대로 접목해서 캐시가 있는 빠른 경로와 캐시가 없는 느린 경로, 두 경로로 분리했고

느린 경로로 갈 때, 메시지큐를 통해 전송하는 식으로 했습니다.

그러나 여기서 문제가 하나 더 있었습니다.

현재 모듈 분리가 안된 단일 모듈 상태였습니다.

단일 모듈 상태에서 메시지큐를 거친 뒤에 작업 서비스로 향하는 것이나 바로 작업 서비스로 보내는 것이나 엇비슷하거나 오히려 전자가 속도가 조금 더 낮을 것이라고 판다되었습니다.

그렇다고 모듈을 분리해서 알람 서버와 작업서버를 분리하자니, 현재 EC2 인스턴스 상태의 메모리 상에서는 힘들 것이면서 동시에 시간이 부족해 진행하기 어렵다고 판단되었습니다.

하지만 캐시 유무에 따른 서비스 분기 로직은 이점이 상당하다고 판단되어서 해당 로직을 분리한 상태를 유지하였습니다.