프로젝트/FitTrip

FitTrip 프로젝트는 MSA 구조에서 EDA를 적용한 프로젝트입니다.즉 서비스가 여러 개로 나눠진 분산 시스템 구조입니다.이러한 분산 시스템 구조에서는 데이터의 일관성을 확보하기가 상대적으로 어렵습니다.발행되지 않아야 하는 메시지가 발행되거나, 발행되어야 하는 메시지가 발행되지 않고 누락되기도 합니다. 이번 글에서는 간단한 예시와 함께, 흔히 볼 수 있는 메시지 발행, 처리 방식들의 문제점들을 짚어보려고 합니다.또한 이 문제점들을 해결하는 방법 중 하나인 Transactional Outbox Pattern을 소개하고 FitTrip 프로젝트에 적용한 과정에 대해 얘기하려 합니다. 분산 시스템에서 데이터를 전달하는 방법은 아래 글을 참고해주시면 감사하겠습니다.https://an-jjin.tistory.c..

서론이번 글에서는 유저의 실시간 온/오프 상태 처리 기능(https://an-jjin.tistory.com/44)을 구현하면서 겪었던 이슈 중 세 번째 이슈에 대해 다루겠습니다. 개발을 진행하면서 처음 구현한 로직에서 최종 로직까지의 개선 과정을 설명해 보려고 합니다.문제 상황채팅 서비스에서 유저의 웹소켓 연결 상태를 파악하여 해당 유저가 온라인인지 오프라인인지 지정하는 기능을 구현했습니다.해당 유저를 A라고 지칭하겠습니다. 유저 A의 온라인/오프라인 이벤트 데이터를 카프카의 특정 토픽으로 전송하고, 다른 채팅 서비스들이 이를 받아와 유저 A가 속한 서버(단체 채팅방)와 DM방에 있는 유저들에게 브로드캐스팅합니다.카프카에 보내는 이유는 이유는 채팅 서비스의 스케일 아웃을 고려했기 때문입니다.(관련 포스팅..

서론유저의 편의성을 위해 유저의 온라인, 온프라인 상태의 실시간 변경에 대해 처리를 하는 기능을 구현했습니다.전체적인 로직은 아래와 같습니다.로직 설계사용자의 온라인 상태와 오프라인 상태에 대한 기준은 웹소켓 연결로 결정했습니다.예를 들어 웹소켓으로 사용자가 채팅 서비스에 연결이 되어 있는 경우 온라인 상태로 웹소켓 연결이 끊기면 오프라인 상태라고 지정했습니다.서비스 간 비동기 처리가 가능한 부분은 카프카를 사용하여 데이터를 전송했습니다.서비스 간 동기 처리가 필요한 부분은 openfeign을 사용하여 처리했습니다.온라인 상태 처리 로직1. 사용자와 채팅 서비스가 웹소켓으로 연결되면 채팅 서비스에서는 해당 유저의 id값과 웹소켓 세션 id값을 가져옵니다.2. 채팅 서비스는 카프카를 통해 상태관리 서비스로..

서론유저의 편의성을 위해 입장한 서버에서의 마지막 채널 위치를 기억하여 다시 해당 서버로 입장 시 마지막 채널 위치를 기반으로 페이지를 보여주기 위한 기능을 구현했습니다. 전체적인 로직은 아래와 같습니다.로직 설계1. 채널 조회 시 각 서비스는 채널을 조회한 유저의 id값과 조회한 채널 id값을 카프카를 통해 상태관리로 전송텍스트 채널 조회는 채팅 서비스로 포럼 채널 조회는 커뮤니티 서비스로 음성 채널 조회는 시그널링 서비스로 요청이 갑니다.요청을 받은 각 서비스들은 채널을 조회한 해당 유저의 id값과 조회한 채널 id값을 카프카를 통해 상태관리로 전송합니다.상태관리 서비스는 유저가 입장한 서버에서의 마지막 채널 위치를 관리합니다.서버 생성 또는 서버로 유저가 처음 입장 시 커뮤니티가 상태관리로 유저 i..