MSA 에 대해 알아보자

 

이번엔 MSA 에 대해 알아보려고 한다.

 

그간 개발자로 일을 하며 모놀로식으로 개발한 적도 있었지만 주로 MSA 환경에서 개발을 많이 했었다.

 

MSA 에 대해 어느정도 알고 있다고 생각했지만 정작 정의나 특징에 대해 제대로 알아본 적이 없었다.

 

누군가 MSA 가 뭐야로 시작해서 사용하는 이유, 구체적인 장단점 및 어떤 상황에서 이점이 있는 지 등을 물어본다면 말문이 막히게 될 것 같다.

 

때문에 이번 기회에 정리를 해보려고 한다.

 

---

 

 

MSA에 대해 설명하기 전에 먼저 Monolithic Architecture 에 대해 알아보자.

 

 

모놀로식 아키텍쳐는 모든 소프트웨어의 구성이 하나의 프로젝트, 하나의 아키텍쳐에 속해 있는 형태를 말한다.

 

MSA가 화제가 되기 전에는, 보통의 방식이 모놀로식이였다.

 

모놀로식은 개발과 관리가 한군데 모여있으니 좀 더 수월하다는 장점이 있으나, 시스템이 커지고 복잡해질 수록 그 한계가 드러나게 된다.

 

또한 작은 수정에도 전체를 다시 빌드하거나 배포해야 하기 때문에 서비스가 무거워지는 상황을 초래한다.

 

확장하게 될 경우에는 수직적으로, 전체 시스템의 부하를 감당하는 성능을 늘려야 한다.

 

부하에 따라 탄력적으로 대응하여 시스템의 성능을 높이기는 쉽지 않고, 반대로 부하가 감소 했을 때에 자원의 낭비를 막을 수 없다.

 

시간이 지나며 엔터프라이즈 시스템, 서비스의 규모가 점차 증가되며 클라우드 환경이 증가하는 추세로 MSA가 대두되고 있다.

 

 

 

 

 

 

Micro Service Archtecture

 

MSA는 어플리케이션의 기능을 모듈별로 개발 된 애플리케이션을 조합하여 배포하는 형식이다.

 

하나의 애플리케이션을 작은 애플리케이션으로 쪼개어 나누고 변경과 조합이 가능하다고 설명해도 될 것 같다.

 

각 애플리케이션이 구분되어 있기 때문에 수평적인 처리를 할 수 있다. ( 탄력성 )

 

예를 들어 특정 어플리케이션의 부하가 늘어났을 때 해당 어플리케이션을 스케일링하여 여러 대로 구성할 수도 있겠고, 해당 어플리케이션이 배포되는 물리적인 장비의 성능을 올릴 수도 있겠다.

 

반대로 부하가 감소 하였을 때는 스케일링을 통해 서버 수를 감소하게 하거나, 지속적으로 부하가 증가한 다른 어플리케이션과 물리적 장비를 변경 할 수도 있다. 

 

애플리케이션을 서비스에 따라 나누었기 때문에 작업을 분산하기에 좋다.

 

애플리케이션의 변경이 다른 애플리케이션에 침범되는 일이 없고, 애플리케이션을 하나의 작업으로 분류하여 각 개발자가 온전히 담당하도록 할 수 있다. ( 생산성 ) 

 

또한 변경이 있어도 각 애플리케이션 별로 빌드, 배포가 가능하기 때문에 시스템의 무게를 낮출 수 있다, 그렇기에 중간에 이슈가 발생해도 해당 애플리케이션만 수정하여 빠르게 이슈를 해결할 수 있다. ( 유지보수 )

 

애플리케이션 별로 기능구현에 필요한 다른 언어나 기술을 사용 할 수 있다.

 

 

하지만 단점도 존재한다.

 

한줄로 표현하자면 서비스가 작은 단위로 배포되어 있기 때문에 전체적인 관리가 힘들어진다.

 

이 관리란 모니터링, 트랜잭션, 테스트, 배포시 복잡도 등을 예로 들 수 있겠다.

 

분리된 애플리케이션의 서비스가 모여 비즈니스 로직이 처리 될 때 네트워크 장애, 데이터 불일치, 서비스 장애 등의 사유로 트랜잭션이 부분적으로만 성공할 때 시스템을 롤백해서 일관성을 유지하기가 어려워진다.

 

이럴 경우 실제 트랜잭션을 이용해서 롤백하는게 아닌 논리적인 개념으로 작업단위를 선정해 롤백을 처리 할 수 있다.

 

보상 트랜잭션 개념을 적용해 로직과 반대되는 개념을 적용해 롤백을 구현하는 것이다.

 

이러한 작업이 추가로 필요할 수 있기 때문에 , 로직의 복잡성이 증가 할 수 있다.

 

 

비즈니스가 정상적으로 동작하는 지에 대한 통합 테스트 시에도 문제가 생긴다.

 

MSA 환경에서 통합 테스트 코드를 작성하는 일은 모놀로식 환경에서 보다 훨씬 어렵다.

 

하나의 비즈니스 로직을 처리하기 위해 의존을 갖는 여러 애플리케이션들이 정상적으로 동작해야 하고,

 

각 애플리케이션이 계속 변화하는 개발환경에서는 이를 구현하기가 꽤나 힘들 수 있다.

 

사전적인 의미로만 알고 있을 때는 이것이 어느정도 인지 알지 못했지만 어느정도 규모가 있는 MSA 기반에서 통합테스트를 직접 구현해보니 정말 난해하다.

 

비즈니스 로직마다 실질적으로 구현하기가 힘든 경우가 꽤나 많이 발생한다. ( mock 객체를 구현하여 이미 성공적인 상황에서 테스트가 시작된다 )

 

연관되어 있는 비즈니스 때문에 각각의 비즈니스 별로 테스트 하기도 쉽지 않고, 다수의 상황에서 의미 있는 테스트를 구현하기가 쉽지 않다.

 

모든 상황에서의 문제를 걸러 줄 수 있는 테스트가 존재 할 수 는 없겠지만 그에 비해서도 유효성이 많이 떨어진다고 설명 할 수 있겠다.

 

도커나 쿠버를 이용해 유효한 테스트 환경을 만들어 줄 수 있겠지만 한번 구현한 환경에 변경이 있을 때마다 원활하게 적용하기도 쉽지 않고

 

무엇보다 손이 굉장히 많이 가서 시간을 많이 사용하게 된다. 개발하기에도 바빠죽겠는데 이런 테스트 환경 까지 구현하는 것은...

 

 

이제 다음은 배포 복잡도가 문제다.

 

애플리케이션을 분산시켰기 때문에 관리해야 할 애플리케이션의 수가 늘어나는데, 

 

각각의 애플리케이션이 개별 단위로 수정, 배포가 이뤄지기 때문에 각각의 파이프라인이 필요 할 수 있다.

 

이러한 관리 포인트가 늘어난다는 것은 그만큼 신경을 써야 할 곳이 많아진다는 의미이고,

 

모니터링과 배포, 관리를 위해 이에 대한 기능을 한 곳으로 통합하여 제어 할 서버가 필요해질 수 있다.

 

CI/CD 와 같은 지속적 통합, 관리 작업을 구현해야 할 수 도 있고, 원활한 배포를 위해 유레카 등을 구현하는 등 공수가 늘어나게 될 수 있다.

 

 

이러한 부분들이 시스템의 규모나 방식을 고려하여 모놀로식과 MSA를 선택해야 하는 이유다.

 

위에서 MSA 의 장점으로 서비스의 확장성, 기술의 다양성, 복원력과 빠른 개발 등을 이야기 했지만 이 것 또한 상황에 따라 변화 할 수 있다.

 

애플리케이션이 스케일링을 통해 자유로운 확장성을 가질 수 있다고 했지만 온전히 기능하는 스케일링을 구현하기에는 많은 비용이 들어간다.

 

애플리케이션 별로 다른 언어나 기술을 사용할 수 있지만 개발팀 팀별로는 물론, 개인마다도 차이가 천차만별이다.

 

다른 언어나 기술을 감당할 만큼 성숙하지 않은 개발팀이라면 이러한 부분은 오히려 기술의 부재나 운영 복잡성을 증가 시킬 수 있다.

 

당연하게도, 애플리케이션을 구현한 개발자와 유지보수 하는 개발자가 다를 수 있겠다.

 

나만해도 다른 사람이 Golang으로 개발해놓은 서버를 퇴사하면서 갑자기 내가 떠맡게 되는 상황이 온다면... 다른 언어 사용해보는 것은 나쁘지 않은 경험이지만... 그치만... 흑...

 

이러한 다양성이 오히려 확장이나 운영에 벽이 되어 버리는 것이다.

 

복원력의 경우도 다른 애플리케이션에서 이슈가 생겼을 때 해당 어플리케이션만 수정하면 된다고 했지만 어떻게 개발하느냐에 따라 그 이슈를 쉽게 찾지 못할 수도 있다.

 

문제가 있는 부분에서 예외가 바로 발생하는게 아닌 잘못 된 처리로 인해 전혀 다른 부분에서 문제를 일으킬 수도 있기 때문이다.

 

이런 상황을 막기 위해 각 의존성을 적절히 분리하고 엄격히 관리해야 한다.

 

빠른 개발의 경우 위에 서술한 단점들을 커버하느라 오히려 문제가 생길 수도 있다.

 

 

MSA 가 강조하는 것은 느슨한 결합과 최소한의 의존성이다. 

 

객체지향에서 강조하는 그것과 크게 다르지 않겠다. 

 

그러나 자바에서도 그렇듯 느슨한 결합과 의존성을 관리하기 위해선 사전 작업이 많이 필요하고 상황에 따라 신경 써야 할 부분도 많다.

 

 

쓰다보니 뭔가 MSA의 단점에 대해서만 알아본 것 같다.

 

MSA 가 모놀로식 아키텍쳐에 비해 효율적으로 구성할 수 있지만 그만큼 고려해야 할 것이 많다는 것을 말하고 싶었다.

 

MSA가 요즘 대두되는 이유는 엔터프라이즈 환경도 있겠지만, 클라우드 환경도 큰 몫을 하는 것 같다.

 

클라우드 환경을 구성해보면 알겠지만 결국 하나하나의 단위가 모두 돈과 직결된다.

 

애플리케이션을 작은 단위로 나누어 적재적소에 적절한 환경으로 분산하는 것 또한 개발자의 큰 역량인 것 같다.

 

기술의 숙련도, 언어에 대한 이해와 더불어 또 하나의 역량이다.

 

MSA가 요즘 각광받는다고 무조건 지향하면 안된다, 모놀로식이라고 무조건 지양 할 필요도 없다.

 

 

자. 이제 글을 다 적었으니 완료를 누르고 노트북을 닫고 집으로 간다.

 

언젠가 시간이 지나고 MSA의 장단점이 뭐야? 라고 물어보면 2시간 넘게 생각하고 공부하며 쓴 이 글을 전혀 생각나지 않고 

 

어...(3초) msa가 애플리케이션을 분리한건데....(3초 ) 장점은 수평적인 처리를 할 수 있고... 개발자가 작업 단위를 나누기 좋아서 생산성이.. 늘지 않을까?.. (3초 ) 단점은... 관리가 어렵다(?) ...

 

이딴식으로 대답 할 나의 모습이 벌써 눈에 선하다... 인생....

 

 

이것을 방지하기 위하여 키워드로 머리속에 넣어보자...

 

msa 란 ? 장점은 ? 

느슨한 결합, 적은 의존성 - 분리된 애플리케이션을 조합, 배포한다.

확장성 - 수평적 처리, 다양한 기술의 사용이 가능해진다. 

유지보수 - 애플리케이션에 변경이 있어도 각각 빌드, 배포가 가능하여 유지보수성이 증가한다.

생산성 - 하나의 애플리케이션을 하나의 작업으로 분류하여 생산성을 높일 수 있다.

 

 

 

단점은 ?

관리 - 모니터링, 테스트, 배포복잡도, 트랜잭션 

- 확장성을 위한 비용
- 기술의 다양성에 대한 기술 부재 , 운영 복잡도 증가
- 예외 발생 시를 위한 엄격한 의존 관리
- 위와 같은 관리를 하기 위핸 생산성 저하

 

 

??? : "msa 가 뭐야?"

 

"

분리된 애플리케이션을 조합, 배포해서 느슨한 결합과 적은 의존성을 가지게 할 수 있고 수평적 처리나 다양한 기술의 사용이 가능하도록 확장성을 가지고 있어.

각각 빌드 배포가 가능하여 유지보수가 쉽고 하나의 작업 단위로 분류하여 생산성을 높일 수 있지.

하지만 관리가 어려워. 모니터링과 통합테스트 시의 문제,  분리됨에 따라 변화된 애플리케이션들을 일관성있게 처리하고 관리할 수 있어야 하기에 배포복잡도가 증가하고 트랜잭션 시 어려움을 겪을 수 있어.

장점으로 말했던 확정성을 위한 비용이 필요하고 기술의 다양성이 오히려 기술부재나 운영복잡도를 늘릴 수 있지.

예외 발생 시를 위한 엄격한 의존 관리가 필요하고 위와 같은 관리를 위해 오히려 생산성이 저하 될 수도 있어.

알겠니!?!?!?!?!?!?!?!?!?

"

 

이 외에도 신경 쓸 것은 매우 많지만... 일단 여기까지 정리해보도록 하겠다

 

---

 

그냥 눈에 띄는 단어만 굵게 넣어봤는데 이게 생각보다 재미(?) 있다.. 뜬금 없이 그냥 눈에 띄는 대로 넣었는데 뭔가 잘 읽히는 느낌적인 느낌?! 네이버 웹툰 마술사 나 용사참수인 ( 같은 작가 )을 보면 이렇게 하길래 따라서 해봤다..

 

어쨋든... 

 

항상 바로 남이 물어보면 목소리로 말 할 수 있도록 노력해보자. 

 

이 글을 적으며 카페에서 혼잣말을 몇번이나 웅얼웅얼 했는지... 그래도 다음에 누가 물어보면 명확하게 기억이 안날 것 같다.

 

무한 반복...반복 밖엔 믿을 게 없다...