서두
예전에 포스팅한 글을 보면 "다른 언어를 복합적으로 사용할 때 어떤 장점이 있을까?", "DB 사용은 어떻게 하지?"에 대한 궁금증이 있었다.
👉 여기서 확인
Python은 빠른 개발과 넓은 범용성이라는 장점을 가지고 있지만, 실행 속도가 느린 단점이 있다. 인터프리터 언어의 단점이라고도 할 수 있다. 그래서 같은 프로젝트 안에 다른 가상환경을 구축하여 연산이 필요한 곳은 C를 사용하는 방식으로 각 언어의 장점을 살려 하나의 서비스를 구성하면 어떨까? 에 대한 생각이 있었고, 그러한 방식을 MSA라고 불린다고 한다. 물론 말처럼 단순하지 않고 생각해야할 변수들이 많을 것이기 때문에 공부해보자.
MSA
MSA 탄생 배경
Micro Service Architecture의 약자이며 하나의 앱에서 모든 것을 처리하는 것이 아닌, 서비스별로 나누어 독립적인 배포를 하는 방식이다. 하나의 앱에서 모든 처리가 이루어지던 기존 방식과 달리 사용 언어, DB 등 기술 스텍이 다양한 MSA를 상황에 맞게 판단하여 사용할 수 있다.
MSA 이전에는 어떤 방식의 배포가 이루어졌을까?
이전에는 대부분이 Monolithic Architecture를 사용했다. Monolithic이란 모든 서비스가 하나의 앱 안에서 처리되는 아키텍쳐를 말한다. 즉, 개발툴부터 테스트 및 배포까지 하나의 앱 안에서 수행하기 때문에 아키텍쳐가 복잡하지 않고, 개발 환경 설정이 간단하다. 이러한 특징 때문에 운영 관리 측면은 비교적 용이하지만 서비스가 커질수록 단점 또한 존재한다.
빌드/테스트 시간 증가
작은 수정에도 시스템 전체를 빌드해야 하며, 테스트 시간도 길어진다. 요즘처럼 CI/CD가 강조되는 시점에서는 큰 문제가 될 수 있다.
하나의 서비스가 모든 서비스에 영향
이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 된다면 다른 모든 서비스 역시 마비 되는 상황이 오게 된다. 부분적 서비스 수정이 힘들고, 장애 발생 부분을 파악하고 배포하는 데 많은 시간이 소비된다.
위와 같은 문제점을 보완하기 위해 나온 방식이 MSA다.
MSA 특징
기존에 사용하던 Monolithic Architecture는 각 컴포넌트가 함수로 호출되는 방식을 사용한다. 하지만 MSA는 서비스가 각 하나의 컴포넌트로 구성되어 API로 통신한다. 때문에, 내부 구현 로직, 사용된 언어, DB, 아키텍쳐 등 기술적인 부분은 API에 의해 가려진다.
물론 장점만 있는 것은 아니다. Monolithic Architecture가 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만 MSA의 경우 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리며, 서비스 분산으로 인해 내부 시스템 통신을 어떻게 가져갈 지 표준 정의가 되어 있어야 한다.
MSA는 다음과 같은 특징들을 가지고 있다.
독립된 서버
함수가 아닌 End-Point로 통신하므로, 각 서비스는 독립된 서버로 상호 의존성이 없기 때문에 독립된 배포를 하게 된다. 독립된 서비스 개발로 인해 부분 확장 또한 가능하며, 지속적인 배포(CD)도 Monolithic Architecture에 비해 가볍게 할 수 있다. 또한, 각 서비스마다 부하에 따른 개별 Scale-out이 가능하다. 이벤트를 진행할 때 특정 시간대에 트래픽이 증가한다면 해당 서버만 확장 해주면 해결할 수 있다.
데이터 분리
데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용한다. DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 된다. 데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트렌젝션으로 묶을 수 없는 문제가 발생하기도 한다.
API Gateway
MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없다. 이때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다. 또한 거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화 시켜준다. 그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행한다.
<참고한 이응호 과장님의 정리>
MSA는 복잡한 웹 시스템에 맞춰 개발된 API기반의 서비스 지향적 아키텍처 스타일입니다. MSA가 유행을 하고 있지만 꼭 정답은 아니고, 업무나 비즈니스 특징에 따라 적절한 아키텍처가 선택됩니다. 근래의 아키텍처 모델은 시스템에 대한 설계뿐만 아니라 팀의 구조나 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 매우 크며, 때문에 거시적인 관점에서 고려할 필요가 있습니다.
MSA가 필요하다고 해도 꼭 시작을 MSA로 해야 하는 것은 아닙니다. MSA가 서비스의 재사용 성, 유연한 아키텍처구조, 대용량 웹 서비스에 적합한 구조 등 많은 장점을 가지고 있지만 개개인의 높은 숙련도가 필요한 편입니다. MSA를 구축한 많은 기업들이 시작은 모노리틱 시스템으로 시작하여 팀원들의 숙련도를 높이고 피드백을 통해 시스템을 발전 시키는 과정에서 MSA로 전환한 사례들도 있습니다. 프로젝트의 목적이나 팀의 상황에 맞는 유연한 선택이 필요합니다.
글을 마치며
MSA를 공부해보니 같은 서비스를 제공하지만 뛰어난 성능과 빠른 유지보수가 가능하다는 점에서 단점보다 장점이 많은 아키텍쳐라고 생각했다. 그만큼 높은 개개인의 기술력을 필요로 한다는 제약이 있다. 특히 분리된 DB를 사용하며 어떻게 트랜잭션을 유지할 지에 대한 고민에 집중해야 할 것 같다.
아직 부족한 점이 많기 때문에 신경쓰지 못하고 코드를 작성하는 부분이 많다. 요즘 "널널한 개발자"라는 유튜브 강의를 종종 본다. 최근에 본 영상인데, 나만 뒤쳐져 있는 개발자라고 느꼈을 때, 우울함을 자극으로 바꾸고 꾸준하게 노력한다면 어느 순간 극복할 것이라고 말씀하셨다. 언젠가 나 또한 꾸준히 공부하다 보면 실행만 되는 코드가 아닌 성능을 향상시키는 코드를 작성하며 거시적인 관점에서 바라볼 수 있는 개발자가 될 수 있을거라 믿는다.
참고
[CI/CD] CI/CD란? - 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 기본개념
