1. 왜 RabbitMQ와 Kafka를 둘 다 썼나요?
이는 각 메시징 시스템의 특성과 용도가 다르기 때문입니다. Config 서버는 설정 정보의 변경 알림이라는 단순하고 빈번하지 않은 메시지 전달에 적합한 RabbitMQ를 사용했습니다. 반면 Feed 서비스는 이벤트 소싱 아키텍처를 채택하여 대량의 사용자 활동 이벤트와 좋아요/북마크 정보를 처리하고 필요시 재생해야 했기 때문에 Kafka를 선택했습니다.
Kafka는 대용량 데이터 처리, 이벤트 로그 저장, 배치 처리, 데이터 복구 등에 최적화되어 있고, RabbitMQ는 간단한 메시지 라우팅과 빠른 응답이 필요한 경우에 유리합니다. 각 서비스의 요구사항에 맞게 적절한 도구를 선택했습니다.
2. Config 정보를 Git 과 같은 외부 저장소에 올리면 보안 위험은 없나요?
외부 저장소를 Private로 관리하고 있어서 큰 걱정은 없습니다. 하지만 추후 Spring Cloud Config 서버의 암호화/복호화를 진행할 예정입니다.
3. 추천 기능에 있어서 유저의 피드 읽음 처리, 유저별 해시태그 선호도는 DB 부담이 엄청날 데 어떻게 처리하셨나요?
DB 부담을 줄이기 위해 여러 전략을 구현했습니다:
- 피드 읽음 처리:
- 시간 기반 파티셔닝을 적용해 테이블을 월별로 분할
- 90일 이전 데이터는 자동 삭제되는 스케줄러 구현
- 읽음 처리는 비동기로 처리하여 사용자 경험에 영향을 주지 않도록 함
- 해시태그 선호도:
- 사용자 ID 기반 파티셔닝으로 데이터 분산
- 점수 감쇠 시스템을 도입하여 낮은 선호도(0.1 이하) 데이터 자동 제거
- 각 사용자별 상위 20개 해시태그만 보존하는 정책 적용
- 90일 이상 비활성 사용자의 선호도 데이터 정리
4. 프로젝트 하면서 가장 어려웠던 점
5. 피드 서비스가 사용자, 상품 서비스와 어떻게 통신하는지, 그리고 왜 그 방식을 선택했나요?
피드 서비스는 Feign Client를 활용하여 Rest API로 다른 서비스와 통신합니다. 그래야 MSA의 취지에 맞다고 생각하였습니다.
6. 여러 서비스 인스턴스 간에 요청을 어떻게 분산하나요?
요청 분산은 다층적으로 구현했습니다:
- API Gateway(Spring Cloud Gateway) 사용으로 라우팅 및 로드 밸런싱
- Eureka 서비스 디스커버리로 동적 서비스 등록 및 검색
- Kafka 컨슈머 그룹을 통한 이벤트 처리 부하 분산