성장을 꾸준히 기록하는 공간

당근마켓도 100만 MAU 뜨고 나서야 MSA를 도입했다는거 보면, 사실 그정도 규모 이하는 모놀리식으로 충분하다는 소리다.​도대체 왜 이렇게 MSA에 목메이게 되었는가..​이길 수 없다면 합류해라​나도 MSA하겠다​​이거말고 진짜 MSA를 결심한 이유원래 C++로 이뤄진 게임 서버와 통신하기 위해 Kafka를 사용했었다.   매칭 결과나 전적 결과를 저장하기 위해서라도 전달 과정에서 최소 한번은 디스크에 기록되어야 했다.​1. 매치메이킹의 결과를 받아서 게임 서버에 방을 생성2. 게임이 끝나면 그 결과를 다시 웹서버로 전달 대충 목적인데 닭 잡는데 소 칼 쓰는 느낌이다. 그래서 kafka를 좀 더 효율적으로 쓰기 위해서 고도화를 고민해봤다. ​일단 Redis를 이용하던 매치메이킹 기능이 스케줄러로 동작..

원래는 이벤트 소싱으로 도메인을 먼저 관리하고, CQRS 패턴을 이용해서 Command와 Query를 분리하면서 책임을 명확히 하는 식으로 단점을 보완하는게 맞다.​본 프로젝트는 이와 다르게, 전적 통계를 위해 CQRS 패턴을 먼저 구현해서 Axon Server 없이 Kafka만을 이용해서 게임이 끝날때의 전적 종료 이벤트를 받아 작업했다. ​그러다가 member 서비스에서 사용자 데이터를 관리하는데 있어서 전적 결과에 따른 실력 점수(Elo, MMR 등)의 변동은 비즈니스적으로 정합성 관리가 중요하다고 판단했다. ​따라서 인과는 좀 다르지만 뒤늦게 이벤트 소싱을 통해 사용자 정보를 관리하게 되었다. ​아직 사용자 서비스에 대한 CQRS는 구현되지 않았고, 전적 쿼리 서비스와 전적 서비스간의 이벤트 처리..

MSA로의 마이그레이션 과정에서 느낀 경험과 이론으로 봤을때, 최대 단점은 역시 어려움이 꼽힌다고 생각한다.  그러면 MSA 아키텍처가 왜 어려울까?1. 도메인 분해를 위한 설계의 어려움2. 마이크로서비스간의 통신(IPC)의 어려움3. 분산 환경에서의 트랜잭션 관리의 어려움 지극히 주관적인 의견이지만 일부는 모두가 동의할 것이라 믿는다.. 나만 어려운게 아니길   그중에서 기존 모놀리식 아키텍처를 도메인별로 잘게 나누어 분해하는 과정이 시작부터 우리들의 발목을 잡게 된다.  처음 접하는 사람들 입장에서 생각해보자.  그래 알겠어 각 서비스별로 쪼개서 만들면 되는거. 근데 무슨 기준으로 마이크로서비스를 나누는거지?  도메인 주도 설계(DDD)도메인 주도 설계는 비즈니스 도메인을 중심으로 설계해서 문제를 해..

기존의 Flask로 간단하게 구현한 프로토타입 백엔드는 Http 통신으로 계정과 게임 데이터를 불러오거나, 환율 혹은 공지사항, 이벤트 등의 실시간 변동 사항을 적용하는 시스템을 구현했었다.그러나 점점 볼륨이 커지니까 관리하기가 어려웠고, 공부중인 기술과 아키텍처의 경험도 얻을 겸 MSA로 마이그레이션을 시도했다. k8s로 인기를 얻게된 MSA는 굉장히 어렵고 복잡한 구조로 이해하기 위한 제반 지식이 필요하지만, 나의 경험을 녹아내기 위해 필요한 개념들만 간략하게 소개하면서 진행하겠다.​​MSA(Mircro Service Architecture)란?https://kr.tmaxsoft.com/info/storyTView.do?seq=345작고, 독립적으로 배포가 가능한 각각의 기능을 수행하는 서비스(mir..

마이크로 서비스 아키텍처(MSA)는 하나의 모놀리식 아키텍처에서 각 도메인별로 분해하여 비즈니스에 따른 유연한 대응을 목적으로 한다.​구조는 복잡해져도, 기술만을 중요시하지 않고 도메인을 신경써야하는 요즘 시대에 걸맞는다고 볼 수 있어서 시장의 대세로 자리잡았다. ​그런 MSA의 단점으로 꼽히는 문제점들이 있고, 각 서비스들은 이 문제를 어떤 방식으로 해결하는가? 가 중요해졌다. ​ 예를 들자면​여러 마이크로 서비스들이 어디 있는지 어떻게 찾아야 하는가?각 서비스는 어떻게 통신하는가?보안적 요소나 속도 제한처럼 서비스의 접근을 어떻게 제어하는가?문제 상황 발생시, 개별 서비스가 응답하지 않으면 비즈니스를 어떻게 처리할건가?​​이런 복잡한 문제점들을 해결하기 위해 Spring Cloud에서 여러 서비스를 ..