Monolitihc이란 기존에 사용하던 방식으로,
한 서비스 안에 모든 기능을 유기적으로 연결시켜 운영하는 방식입니다.
MSA는 Monolithic방식과 다르게 서비스를 나누고 기능을 분리하여 하나의 어플리케이션으로 합쳐서 운영하는 방식입니다.
MSA환경에서 실제 개발을 해보면서 느낀점은,
MSA 환경이여서 얻는 이점도 많았지만,
장점만 존재하진 않았고, 불편한 점들도 상당히 있었습니다.
약간 주관적이겠지만 제가 생각하는 장단점입니다.
유연한 서비스 관리
각 서비스를 유연하게 배포할 수 있어서 실제 상황에서 소스를 롤백하거나, 또한 확장하기에 좋습니다.
책임 분리 및 장애 범위 축소
서비스의 책임이 분리되어서, 대량 데이터 조회 서비스와
핵심 로직 서비스를 분리하는 방식으로 사용도 가능하여서,
장애가 일어나도 커다란 피해가 없을 수 있습니다.
편리한 관리도구
elk 스택을 활용한 로그조회나, grafana를 통한 시각화 자료등이 각 서비스 마다 이루어져 있기에,
분석이나 해결방안을 도출하는데 많은 도움이 되었습니다.
편리한 기능개발
신규 기능을 개발하기에 해당 서비스에 미치는 영향도를 고려하기 더 쉽고,
특정 서비스의 구성을 바꿀 수 있기에 다양한 시도를 하기 좋습니다.
초기 서비스를 갖추는데 많은 시간과 인력이 필요합니다.
서비스를 설계에 따라 나누고, gateway, discovery, 등등 필요로 하는 서비스뿐 아니라,
배포화 도구, 모니터링 도구 등…
그 구현 난이도 또한 어렵습니다.
특정 소스 테스트 및 디버깅 난이도 상승
여러 서비스끼리 서로 api를 주고받는 경우,
어디 서비스에서 어떤 문제가 있는지 찾기 더 어려워질 수 있습니다.
또한 테스트하려면 여러 서비스를 동시에 돌려서 테스트 해야하는데 이것도 번거롭습니다.
난잡한 코드관리
JPA를 사용하는데 컬럼이 추가된다거나 하는 경우 해당 Entity를 사용하는 모든 서비스를 찾아서 업데이트를 해줘야하고,
혹은 새로운 기준코드가 생겨도 enum을 사용할 경우 마찬가지로 해당 모든 서비스를 찾아서 코드를 업데이트 해줘야 합니다.
뿐만 아니라 개발자의 수가 많아지고 프로젝트가 커질수록 여러 서비스에 같은 로직이 구현되어 있을 가능성도 점점 커집니다.
적다보니 단점도 많이 적었지만, MSA는 얻는 이점도 크고 확실한 아키텍처라고 생각합니다.
하지만 기술적으로나, 관리적으로 보았을 때 무조건적으로 MSA를 사용하는 것이 좋다 보단,
서비스의 규모나 특징을 생각하고 선택하는 것이 더 좋다 생각합니다.
MSA에 정해진 구조는 없지만, 이정도의 틀은 유효하다 생각합니다.
Client에게 요청을 바든 지점입니다.
Service Router를 통해 API요청을 각 서비스에 보내주고,
간단한 보안, 인증을 수행합니다.
Service Mesh란 Micro Service내의 내부 통신을 의미합니다.
Service Discovery (Eureke)
Service들을 등록하고, 각 Service들의 위치(IP주소,Port번호),
인스턴스 갯수 및 상황등을 파악하여 주는 서비스입니다.
Load Balancer (Ribbon)
서비스가 분산된 형태로 존재할 때 알맞는 Instance에 요청을 보내주도록 도와줍니다.
Config Store
공통된 설정파일(DB 정보나, Network 설정 등..)을 저장해두고 필요로 하는 서비스에게 보내줍니다.
Circuit Breaker
원격 접속의 실패율이 임계치를 넘을 경우,
접속을 차단해주는 시스템입니다.
전체 서비스의 모니터링과 진단 기능을 가집니다.
elastic Search같은 도구들을 이용합니다.