마이그레이션 전 소스코드
※실제 코드는 아니지만, 구조는 동일했습니다.
@Service
@RequiredArgsConstructor
public class SignUpService {
private final NotiService notiService;
public void signUp() {
//회원가입 로직
...
...
//노티전송 로직
...
...
}
}
위에 코드에서 signUp() 안의 내용을 들여다 보면
1)회원가입
2)노티전송
두가지 역할을 하고있습니다.
한 서비스에 여러 로직이 함께 있는 경우 몇 가지 단점이 있습니다.
● 단일 책임 원칙 위반: 각 서비스는 특정 기능 또는 역할을 담당해야 한다는 원칙입니다.
● 유연성 감소 : 서비스가 다양한 역할을 수행하면 변경이 발생했을 때 다른 부분에도 영향을 미칠 수 있습니다.
● 확장성 문제 : 노티 로직이 비즈니스 로직과 결합되어 있으면, 노티 로직을 확장하기에 어려울수 있습니다.
● 유지보수 어려움 : 여러 기능이 한 곳에 모여있으면 코드를 이해하고 수정하기가 어려울 수 있습니다.
위와 같은 이유로 노티서비스를 아예 분리를 해볼까 합니다.
모듈 분리
기존에는 한 프로젝트 안에 노티서비스도 다 들어있었지만,
노티서비스를 한 프로젝트 단위로 빼서 새로 띄울 계획입니다.
우선 아래 사진은 노티서비스 프로젝트 내부 모듈로 쪼개논 모습입니다.
● module-core, module-database : 공통으로 쓰이는 코어부분과 데이터베이스 부분입니다.
● module-redis, module-rabbitmq : 공통으로 쓰이는 redis, rabbitmq 설정 및 세팅 소스코드 부분입니다.
● module-sms, module-mail : 실제로 쓰이는 sms 모듈과 mail 모듈을 분리해놓았습니다.
내부 통신
자 이제 기존 서비스도 떠있고, 노티 서비스도 떠있습니다.
각자 서비스가 잘 떠있으니, 기존 서비스에서 필요한 노티 서비스 API를 요청해오면 됩니다.
하지만 내부 통신 시 API 호출은 단점이 분명 존재합니다.
● 성능문제 : API호출은 네트워크 오버헤드와 대기 시간을 유발 할 수 잇습니다.
● 장애 전파 : 호출되는 서비스의 장애가 호출하는 서비스에 영향을 줄 수 있습니다.
여러 문제점이 있었습니다.
메세지큐 도입 (Rabbit MQ 사용함)
그래서 위와같은 단점을 보완하기 위해 메세지큐를 사용하기로 하였습니다.
메세지큐를 사용하면 좋은점이 많습니다.
● 비동기 통신 : 응답 대기 시간을 줄이고, 서비스 간의 결합도를 낮출 수 있습니다.
● 확장성 : 분산형 아키텍처를 지원함으로 서비스 확장에 용이합니다.
● 결함 격리/데이터 신뢰성 : 메세지를 큐에 보내고 다른 서비스에서 처리할 수 있으므로, 장애가 발생해도 메세지 유실이 되지않습니다.
1. 회원가입을 담당하는 로직입니다.
2. notiService.sendNoti(); => 노티 전송을 담당하는 로직입니다.
◆ notiSerivce.sendNoti() 내부로직은 아래 그림과같이 메세지를 담아 큐에 전송하는 로직이 전부입니다.
그 후 처리는 따로 띄어있는 노티프로젝트가 임무를 완수합니다.
[NotiService]
amqpTemplate.convertAndSend(); 를 통해 메시지를 담아 큐로 전송해줍니다.
위의 그림은 따로 띄어놓았던 노티서비스 프로젝트 안의 코드입니다.
@RabbitListener를 이용하여 큐안에 있는 메세지를 받아와서 처리를 해줍니다.
결론
이러한 구조에서는 회원가입 서비스와 노티 서비스가 서로 독립적으로 존재하며, 비동기적으로 통신합니다.
이를 통해 각 서비스는 서로의 내부 동작에 대해 알 필요가 없으며, 서비스 간의 결합도를 낮추고 확장성을 높일 수 있습니다.
또한 최종적으로 시스템 전체의 안정성과 성능을 향상 시킬수 있습니다.
