MSA, 마이크로 서비스 아키텍처

넷플릭스, 배달의 민족, 쿠팡 그리고 11번가. 이 유명한 서비스들의 공통점이 있습니다.

바로 대규모 서비스라는점. 그리고 마이크로 서비스 아키텍처(MSA)를 도입했다는 점입니다.

 

오늘 이 MSA에 대해 공부한 내용을 공유해보도록 하겠습니다.

 

그렇다면 과거로 돌아가 이 기업들이 MSA의 이전에는 어떤 아키텍처를 사용하였는지 부터 시작하도록 하겠습니다.

 

모놀리식 아키텍처

모놀리식 아키텍처는 여러 기능들이 하나의 애플리케이션에 뭉쳐있는 서비스 입니다. 기능들을 단 하나의 코드베이스로 개발하고 배포 시 단일 데이터베이스를 사용합니다. 초기에는 개발 속도도 빠르고 배포하기도 쉽고 기능을 붙이기도 쉽습니다. 하지만 이 한 애플리케이션에 기능을 점점 붙여갈수록. 즉, 대규모 서비스가 되어갈수록 문제점이 들어나는데요.

 

모놀리식 아키텍처 단점

1) 장애 발생 시 취약하다.

기능들이 한 애플리케이션에 엮여 있어 시스템 일부분에 장애 발생시 모든 서비스가 죽어버린다.

2) 새로운 기술 스택 도입이 어렵다.

 예를 들어 자바 진영으로 개발된 한 애플리케이션에서 일부 기능만을 파이썬으로 개발 할 수 없다.

3) 유지보수가 어렵다.

규모가 커지고 기능들도 많아진다면 여러 서비스들이 하나의 애플리케이션으로 뭉쳐있기 때문에 서비스를 유지보수 하기 힘들다.

4) 배포 시 오래걸린다.

서비스가 커지면 배포 파일 크기도 어마어마해져 배포에 오랜시간 소요될 수 있다.

5) 일부 기능만 스케일아웃 불가능하다.

만약 여러분들이 80%할인 행사를 해서 트래픽을 대응해야 하는 서버개발자의 입장이라고 생각해봅시다. 주문기능에 트랙픽이 엄청 몰릴거기 때문에 주문 기능에 대한 서버만 3개로 늘리면 되는데, 안타깝게도 모노리식 아키텍처는 자체가 한 애플리케이션이기 때문에 오른쪽그림처럼 통째로 3개로 늘려야 합니다. 그래서 다른 기능은 늘릴 필요도 없는데 늘리면서 자원낭비를 하게 됩니다.

 

이러한 단점들 때문에 나온것이 바로 마이크로 서비스 아키텍처, 즉 MSA입니다.🙌

 

마이크로 서비스 아키텍처

MSA는 기존에 여러 기능들로 뭉친 애플리케이션을 쪼개서 각각을 작고 독립적으로 배포가능한 하나의 서비스로 만드는 것입니다. 그리고 이 서비스간은 API로 통신하게 됩니다.

 

마이크로 서비스 아키텍처 장점

1. 장애 발생시 전체 서비스에 영향을 끼치지 않는다.

여러 각각의 서비스들로 쪼개져 있어 느슨하게 연결돼 있기 때문에 시스템 일부분에 장애가 전체 서비스에 영향을 끼치지 않습니다.

2. 유지보수 하기 좋다.

기능별로 서비스가 나눠져 있어 크기가 작아 애플리케이션 시동시간도 짧고 배포도 빠르게 가능합니다. 만약 주문기능을 업데이트해서 버전2를 만들고 싶다고 할 때, 각 서비스는 독립적으로 배포가 가능하기 때문에 주문기능만을 업데이트하기 위해 어마어마한 전체서비스를 다시 배포하는 것이 아니라 주문 기능 유지보수 후에 주문 서비스 하나만 다시 배포를 하면 됩니다.

3. 원하는 서비스만 스케일 아웃 가능

아까 모놀리식 아키텍처에서는 주문 기능에 대한 서버만 늘릴 수 없었는데, MSA에서는 독립적으로 배포가 가능하기 때문에 주문 서비스만 스케일 아웃할 수 있습니다.

4. 새로운 기술 스택 도입할 수 있다.

마찬가지로 독립적인 서비스이므로 각 서비스에 특화된 기슬 스택을 선택하여 개발, 배포할 수 있습니다.

 

마이크로 서비스 아키텍처 패턴 몇가지

1. API Gateway

한 application이 300개의 서비스로 이루어져 있다고 할 때, 사용자가 이 300개의 서비스를 직접 호출하며 통신한다면, 이 많은 서비스의 api를 기억하고 알맞게 호출해줘야 하고, 또한 매 서비스마다 인증/인가를 해줘야 하기 때문에 번거롭고, 내부 구조가 노출되어 보안에 취약한 문제점이 있습니다.

따라서 중간 매개체인 API Gateway를 만드는데, 이 게이트웨이는 모든 서비스의 ip주소와 포트번호를 알고있어 프론트에서 이 게이트웨이와만 통신하면, 이 게이트웨이가 원하는 서비스로 데려다 줍니다. 또한 인증/인가 처리를 여러 서비스에서 중복적으로 하는 것이 아니라 게이트웨이에서 출입문 통과하듯이 한 번에 해줍니다. 또한 외부에서는 게이트웨이와만 통신하면 되기 떄문에 내부 구조를 들어낼 필요가 없어 보안에도 좋습니다. 

 

2. service mesh

사용자가 네트워크 외부에서 서비스들로 들어오는 부분에서 게이트웨이가 교통관리를 해줬다면 서비스들 간에도 교통정리가 필요한데요. 이를 담당하는 것이 service mesh입니다. 네트워크 내부에서 서비스들간의 검색, 라우팅, 로드밸런싱, 보안등의 기능을 담당합니다. 예시로 Istio, AWS app mesh가 있습니다.

 

3. 메시지큐를 활용한 비동기 통신 패턴

MSA는 여러 서비스들간 네트워킹을 할 때 메시지큐를 활용한 비동기 통신 패턴을 많이 사용합니다. 이 메시지큐의 예로 그 유명한 아파치 카프카가 있습니다. 먼저 메세지큐를 사용하지 않는 경우를 보도록 하겠습니다.

Msa는 한 트랙잭션이 여러 서비스간의 통신을 통해 작동하는데 위 그림처럼 여러 서비스들을 하나의 트랜잭션에 강하게 묶어버리면 장애 발생 시 트랜잭션이 깨져 버려 요청을 보존할 수 없고 연결된 서비스에도 문제가 생깁니다.

따라서 메시지큐를 활용해 트랜잭션을 분리해 서비스 안정성를 높입니다. 이처럼 메시지큐에 요청를 넣고 가져다쓰는 방식을 사용하면 보낸쪽의 서버는 요청 이벤트를 생성만 해주면 끝이기 때문에 받는쪽의 서버가 고장나도 영향을 받지 않습니다. 또한 메시지큐내에 요청이 보존되어 요청 손실 없이! 다시 받는쪽의 서버가 정상이 되면 그 요청을 받아가 정상적으로 처리할 수 있습니다.

 

4. 배포

마이크로서비스는 수백개의 서비스로 이루어져 있어 이를 관리하기 위해 도커 같은 컨테이너 기술과 함께 사용합니다. 또한 컨테이너 자체도 소규모가 아니기 때문에 그 많은 컨테이너를 어떤 서버에 배포 해줘야 할지에 대한 문제가 생깁니다. 따라서 서버를 컨테이너를 어떤 서버에 배치해야 하는지 스케줄링 하는 쿠버네티스을 사용하기도 합니다.

 

지금까지 MSA의 장점과 특징들을 좀 알아봤는데요🤔. 그렇다면 이 좋은 msa를 무조건 도입해야 하는걸까요?

 

당연히 아닙니다. 방금 구축환경을 좀 만 봐도 아시겠지만 매우 복잡하고 어렵습니다. 저는 msa의 단점을 공부하면서 “왕관을 쓰려는자! 무게를 견뎌라” 라는말이 떠올랐는데요, 견뎌야 하는 무게가 무엇인지 아래 설명 드리도록 하겠습니다.

 

마이크로 서비스 아키텍처 단점

1. 통합 오류추적 모니터링 필수

오류가 발생시 어떤 서비스에서 난 건지 찾을 수 있어야 하는데, 서비스간 연계가 복잡해서 찾기어렵고, 하나 하나 범인이 누구인지 확인하기에는 무리가 있습니다. 따라서 통합 오류추적 모니터링을 필수로 구축해야 합니다.

2. 어렵고 복잡하다.

여러 서비스가 분산된 환경이기 때문에 당연히 복잡성이 증가하고 그에 따른 추가설계가 필요합니다. 그리고 서비스간 어떻게 연결할지의 약속인 API통신 설계가 필요하고 각 서비스가 잘 연결되는지도 확인해주어야 합니다.

3. 데이터 트랜잭션 유지가 어렵다.

모놀리식에서는 하나의 데이터베이서를 쓰기 때문에 단일 트랜잭션을 통해 데이터 정합성을 유지하면 됐지만 msa는 서비스마다 db도 다르고 한 트랙잭션이 여러 서비스간의 통신을 통해 작동하기 때문에 각 연결된 DB의 정합성, 데이터 트랜잭션을 유지하는 것이 어렵습니다.

 

따라서 무조건 MSA를 쓴다고 좋은 것이 아니기 때문에 위에 말씀드렸던 MSA의 장점들이 꼭 필요한 서비스인지, 그 무게를 감당할 수 있는지! 잘 생각해 보시고 도입하시면 좋을 것 같습니다.

 

감사합니다.