댕댕어디가 프로젝트/MSA

지금까지, 모놀리식 아키텍처를 MSA 아키텍처로 분리하고 연결하는 과정을 경험해봤습니다.하지만, 서비스가 분리되면서 생긴 트랙잭션 문제가 있는데요, 이를 해결하기 위해 어떤 방법들이 있는지 알아보겠습니다. 1. 분산 트랜잭션 문제이전 글에도 나왔던 상황인, '실시간 장소 방문 인증' 로직은 두개의 서비스가 분리되어 통신하면서 로직을 처리합니다. flow사용자 : 실시간 리뷰 작성 -> project-service : 실시간 리뷰 저장 -> region-service : 지역 방문 횟수 증가 하지만 지역 방문 횟수를 증가시키는 과정에서 장애(DB 연결 실패,저장 실패)가 발생한다면, 실시간 리뷰 저장은 롤백되지 않아, 실시간 리뷰 개수와 방문 횟수 사이에 원자성이 깨지게됩니다. 이를 해결하기 위해 2가지 ..

기존 모놀리식 아키텍처에서는 JWT 기반 인증을 진행했었습니다.서비스가 나뉜 지금도 각 서비스마다 시큐리티 필터를 거쳐 jwt 인증이 필요한데, 여기서 문제는 서비스마다 인증이 따로 된다는 점과 DB가 분리되어 인증에 필요한 유저 정보를 조회할 수가 없다는 점입니다. 이를 해결하기 위해 선택한 방법은, 각 서비스마다 인증 필터를 두는 것이 아닌 api gateway에서 pre filter로 인증/인가 작업을 진행하기로 결정하였습니다. 인증 서버까지 따로 분리하면 좋겠지만 아직은 MSA 아키텍처 전환 초기 셋팅이 완료되지 않아 이후에 분리할 예정이고, 현재는 project-service에서 인증 역할을 맡으려고 합니다. 목표 flow사용자 요청 -> api gateway - pre filter에서 jwt ..

이번에는 서비스간 동기 통신이 필요한 경우 어떻게 해결했는지 이야기해보려 합니다. 1. 문제 발생 : 동기 통신이 필요하게 된 계기region-service에는 모든 지역의 땅 주인 정보를 조회하는 API가 있습니다. 각 지역의 땅 주인 닉네임과 펫 정보를 함께 제공해야 하지만, 서비스 분리로 인해 DB가 나뉘면서 region-service DB에서는 최근 땅 주인들의 userId 정보만 조회할 수 있고, 해당 userId에 대한 추가 정보는 조회할 수 없습니다. 이를 해결하기 위해, 유저의 닉네임과 펫 정보를 project-service에 동기적으로 요청하기로 결정했습니다.  2. 동기 통신 구성 : Spring Cloud OpenFeignOpen Feign이란 ?선언적인 http 클라이언트 도구로, ..

이번 시간에는, 지역별 방문 횟수 증가 로직에 필요한 통신을 연결해 보겠습니다. 지역별 방문 횟수 증가 로직 : 유저가 A라는 지역의 A1 시설을 방문하면, 이를 인증하기 위해 실시간 리뷰를 작성하여 방문 횟수를 증가시킵니다. 이때, A 지역에서 방문 횟수가 가장 많은 유저가 땅의 주인이됩니다. service별 역할유저 실시간 리뷰 작성 요청 -> project-service 에서 실시간 리뷰 저장 -> region-service에서 방문 횟수 증가 및 새로운 땅의 주인 판별 통신이 필요한 부분projdect-service에서 실시간 리뷰를 저장한 후, 방문 횟수를 증가시키기 위해 region-service에 요청을 전달해야합니다. 1. Kafka 클러스터 구성kafka 클러스터 구성 과정에 대해서는 간..

project-service와 region-service 간에는 통신이 필요합니다. 그 중에서 이번에는 비동기 통신이 필요한 경우 어떻게 해결했는지 이야기해보려 합니다. 대표적인 예시에는 방문 횟수 증가 로직이 있습니다.: 유저가 A라는 지역의 A1 시설을 방문하면, 이를 인증하기 위해 실시간 리뷰를 작성하여 방문 횟수를 증가시킵니다. 이때, A 지역에서 방문 횟수가 가장 많은 유저가 땅의 주인이됩니다. 해당 로직을 service별로 역할을 나누어보면 다음과 같습니다. 유저 실시간 리뷰 작성 요청 -> project-service 에서 실시간 리뷰 저장 -> region-service에서 방문 횟수 증가 및 새로운 땅의 주인 판별위의 로직을 처리하기 위해서는 MSA 아키텍처에서는 서비스 간의 통신이 필요..

1. API Gateway란 ?마이크로서비스 아키텍처에서 클라이언트와 백엔드 서비스 간의 중간 계층 역할을 하는 서버입니다. API Gateway는 클라이언트 요청을 받아 여러 마이크로서비스로 라우팅하고, 요청에 대한 인증, 로깅, 트래픽 관리 등의 작업을 수행합니다. 2. API Gateway 라이브러리API Gateway 를 구현할 수 있는 라이브러리에는 Netflix Zuul과 Spring Cloud Gateway가 있습니다. 아래와 같이 두 라이브러리의 각 장단점이 있습니다. 특징Netflix ZuulSpring Cloud Gateway프로세싱 모델블로킹 방식비동기 및 논블로킹 방식성능고부하 환경에서 병목 가능성 있음고성능 및 확장성 제공설치 및 설정복잡할 수 있음간단하고 직관적지원 상태유지보수 ..

| 해당 글은, 문제 해결 경험을 기록하는 글이기 때문에, 개념 및 원리에 대해 구체적으로 설명하지 않습니다. 1. Service Discovery 패턴이란?MSA 서비스간 통신시, 각각 IP와 Port가 달라 매번 수동으로 관리해줘야 하는 불편함이 있으며, 이를 위해 각 서비스의 IP와 Port에 대해 저장하고 관리하는 것을 말합니다. 서비스의 IP와 Port는 Service Registry에 저장 및 관리됩니다. 2. 구현 방법구현 방법에는 아래 두가지 방법이 있습니다.  1) Client-Side Discovery Pattern서비스 클라이언트가 Service Registry에서 서비스의 위치를 찾아서 호출하는 방식 2) Server-Side Discovery Pattern호출되는 서비스 앞에 로드..

이번에 댕댕어디가 서비스를 MSA 아키텍처로 전환해보고자 합니다. 1. 댕댕어디가 서비스란 ?반려동물 동반 가능 장소 추천 서비스로, 반려동물 동반 가능한 장소를 검색할 수 있고 맞춤 추천 및 땅따먹기 기능을 통해 반려동물과의 새로운 재미를 즐길 수 있는 서비스입니다. LG 유플러스 부트캠프 과정에서 최종 프로젝트로 진행하게 되었고, 저는 팀장 및 백엔드 개발을 담당하게 되었습니다. 2. 기존의 아키텍처기존의 아키텍처는 모놀리식으로 구성되어있고, 별도로 알림 서버가 구성되어 있습니다. 알림서버만 따로 분리한 이유는 알림 생성에만 집중하고 FCM과 같은 외부 API로 인한 장애가 주요 기능에 미치지 못하게하기 위함입니다. 3. MSA 아키텍처로 전환하는 이유프로젝트를 진행하며 MSA 아키텍처의 필요성을 느..