난이도 ⭐️⭐️⭐️
작성 날짜 2024.09.30
고민 내용
기존 아이쿠는 학교 프로젝트로 시작했기 때문에, 단순하게 모놀리식 구조로 구성되어 있었다.
기존 코드 : https://github.com/kyoona/AiKu_backend
아이템을 좀더 확장시켜서 진정한 프로덕트로 발전시켜보기 위해 기획도 확장했고, 이에 맞춰 기능 추가와 리팩토링도 진행하기로 했다.
그런데, 핵심이 되는 기능인 '실시간 위치 공유'가 서버에 많은 부담을 줄 것 같았다.
5초에 한 번씩 모든 사용자가 자신의 위치를 REST로 요청해야하고, 동시에 서버는 같은 그룹에 속한 모든 사용자에게 이것을 전달해야 했기 때문이다.
위치 공유 기능 때문에 서버가 다운되면, 다른 로직이 마비된다.
특히 약속 시작을 알리는 스케줄러가 서버 다운으로 초기화가 된다면, 복구 후에도 문제가 지속된다.
🤔
위치 공유 기능 때문에 모든 로직에 장애가 전파되는 것을 피하려면 어떻게 해야할까?
찾아보기
- 유튜브 자료 모음
분산 시스템에서 데이터를 전달하는 효율적인 방법
회원시스템 이벤트기반 아키텍처 구축하기
은행 최초 코어뱅킹 MSA 전환기
대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화
배달의민족 마이크로서비스 여행기
이벤트 스토밍 인 액션: 이벤트 스토밍 소개와 적용 방법
마이크로서비스, 어디까지 해봤니?
그래서 우리 팀이 알아보게 된 것이 서버를 분리하여 장애 전파를 방지할 수 있는 MSA(Micro Service Architecture)이다.
1. 이벤트 스토밍
기존의 서비스를 잘 분리하는 것이 우선 해야할 일이라고 생각했다.
이를 위해 도메인을 먼저 나누어야했고, Event-Storming의 필요성을 느꼈다.
다음의 블로그를 참고하였습니다!
https://custom-li.tistory.com/207
이벤트를 브레인 스토밍 하듯이 일단 마구 나열한다.
시간 순서에 맞도록 이벤트를 정렬한다.
이벤트에 의해 생성되는 정책을 도출한다.
해당 이벤트를 발생시키는 액터와 커맨드를 식별한다.(액터는 보통 사용자라 생략)
외부 시스템에 의존하는 로직이 있다면 추가한다.
이벤트나 커맨드가 사용하게되는 데이터를 찾아 어그리거트로 표기한다.
바운디드 컨텍스트의 경계를 찾는다.
자세히 확대하면 다음과 같다.
- 주황 : 이벤트
- 연분홍 : 정책
- 하늘 : 커맨드
- 노랑 : 어그리거트
- 핑크 : 외부 시스템
- 초록 : 정책(분기의 끝)
2. 바운디드 컨텍스트 분리
- 서로 연관된 어그리거트를 찾고 경계를 구분한다.
- 어그리거트 루트를 지정한다.
3. MSA 설계를 한다.
- 바운디드 컨택스트를 기준으로 서비스를 분리
- 비용과 효율을 고려하여 알림, 공통, 지도 총 세 가지의 역할을 하는 서버로 분리
- 아키텍처 구조상 필요한 Kafka와 Gateway 서버를 추가
- 코드 접근과 관리가 편리한 모노레포(멀티모듈) 방식을 채택
결론
이제 문제가 되었던 장애의 전파는 해결되었고,
희망적인 미래에 사용자가 몰리게 된다면 지도 서버만 Scale-Up 하는 방식으로 해결 가능하다!
아무래도 사이드 프로젝트이다 보니, 구조를 짤 때 비용 상의 문제를 고려하지 않을 수 없어 단일 장애 지점이 발생하고 있다는 것이 아쉽다.
그러나 모놀리식 구조만 작성하다 시야를 넓혀 여러 기술을 공부하고, 적용시킬 수 있는 좋은 기회가 된 것 같다!
안정적인 서비스를 제공하는 서버 개발자가 되고 싶다!
