MSA (Micro Service Architecture) 란

1. MSA 란?


대규모 서비스에서 많이 사용되는 MSA 가 무엇일까? 말 그대로 풀이해보면 작은 서비스로 이루어진 구조이다. 작은 서비스로 이루어진 구조는 또 무엇일까?

MSA 는 SOA (Service Oriented Architecture) 라는 구조의 작은? 의미라고도 한다.

SOA 는 기업 (Enterprise) 단위에서 사용되었던 서비스 기반으로 이루어진 소프트웨어 구조이다. MSA 는 SOA 개념을 기반으로 대규모, 대용량 서비스를 이용하기 위한 SOA 보다는 조금 가벼운 구조라고 볼 수 있다.

MSA 는 작은 서비스로 이루어진 구조라고 하였다. 이 개념이 낯선 이유는 무엇일까? 그 이유는 가까이에서 찾을 수 있다. 아직도 많이 사용하는 웹 서비스 개발 구조를 보자. 하나의 프로젝트를 생성하고 그 프로젝트 안에 기능 A, 기능 B, 기능 …, 을 둔다. 또한 하나의 프로젝트에는 하나의 DB 가 연결되어 있으며, WAS 역시 하나로 구성되어 있다. 익숙한 이 구조를 모놀리틱 구조 (Monolithic Architecture) 라고 한다.

모놀리틱 구조 (Monolithic Architecture)

그러면 기존의 잘 사용하던 모놀리틱 구조를 왜 굳이 MSA 를 도입하려하고 또 이미 사용하는 기업들이 많은 걸까? 모놀리틱 구조의 단점을 보면 알 수 있다. 모놀리틱 구조는 하나의 프로젝트 안에 여러 기능(서비스) 가 들어가 있다고 했다. 만약 여기서 자주 배포되는 프로젝트의 경우는 어떻게 될까? 서비스 A 에서 코드를 조금 수정했다고 해보자 모놀리틱 구조의 경우 프로젝트 전체를 다시 배포해야 된다. 즉, 뭘 해도 전체를 다시 시작해야 된다는 것이다.

또한 여러 서비스들이 서로 간의 Dependency 가 높을 수 있기 때문에 서비스 A 의 기능을 변경할 경우 어떤 서비스에 영향을 미칠수도 있다. 같은 이유로 어느 한 서비스에 새로운 버전의 기능 및 다른 구조를 적용하기도 어려워지며, 서비스의 확장면에도 다른 서비스들과의 Dependency 를 고려해야하기 때문에 어렵다는 단점이있다.

이러한 모놀리틱 구조의 단점들을 해결하고자 사용되는 것이 MSA 구조이다. 위에 모놀리틱 구조의 그림과는 조금 다른 구조이다.

MSA 구조 (Micro Service Architecture)



2. MSA 장단점


MSA 는 하나의 서비스를 최소의 기능만을 수행하는 단위로 나누고 이에 연결되는 DB, WAS 를 각각 하나씩 두는 여러개의 프로젝트로 이루어진 구조이다. 그러면 MSA 는 어떤 장점들이 있으며 또 어떤 단점들이 있을까. MSA 의 장점은 모놀리틱 구조의 단점의 반대되는 내용이 많다.

첫쨰, 배포 시간 단축. 하나의 서비스는 최소한의 단위로 이루어져 있다. 그러면 당연히 사이즈도 그에맞게 작다. 즉, 빌드할 내용이 적으니 빌드의 속도도 빠르다. 빌드가 빠르면 배포 또한 오래걸리지 않는다.

둘쨰, 하나의 기술에 얽매이지 않는다. 각각의 서비스는 서로 다른 프로그래밍 언어로 구성해도 되고 아니면 서로 다른 구조를 사용해도 된다. 이를 일컬어 폴리글랏 구조라고 한다. MSA 에서는 이러한 점이 다른 서비스에 영향을 미치지 않는다. 왜냐하면 서비스들 각각이 상대 서비스의 내부 구조를 알지도 못할 뿐더러 알필요도 없기 때문이다.

  • “폴리글랏 (Polyglot) : 서로 다른 프로그래밍 언어와 기술을 사용한 구조”

셋쨰, 확장성. 모놀리틱 구조에서는 서버 과부하에 따른 서비스 확장시에 하나의 프로젝트를 여러개 생성하여 L4 스위치를 이용해 로드 밸런싱을 구성한다. 하지만 MSA 에서는 다르다. 서비스 A 에 많은 과부하가 있으면 서비스 A 만 여러개로 구성하면 된다. 로드 밸런싱 구성은 나중에 Ribbon 이라는 기술을 사용하여 Client 쪽에서 구성할 수 있고 기존의 L4 스위치를 이용해서 구성해도 된다.

이외에도 여러가지 장점이 있지만 위 세가지는 여러 블로그, 책 등에서 나오는 대표적인 장점들이다. MSA 는 장점만 있는 것일까? 물론 단점도 존재한다. MSA 의 단점은 반대로 모놀리틱 구조의 장점이 될 수도 있다.

첫째, 통합 테스트의 어려움 모놀리틱 구조에서는 하나의 프로젝트에 전체 서비스가 들어가 있기 때문에 해당 프로젝트 내에서 테스트 코드를 작성해서 테스트를 쉽게 할 수 있다. 반면에 MSA 구조에서는 서비스가 각각 개별로 존재하기 때문에 프로젝트 전체의 통합 테스트를 하기가 어려운 부분이 있다.

둘째, 성능 모놀리틱 구조는 서비스들이 한 프로젝트 안에 있으므로 서로 Function 또는 Method 를 호출해서 참조할 수 있다. 반면에 MSA 는 분리된 서비스 구조이기 때문에 REST, Message 등의 기술로 내용을 주고 받아야한다. 집 앞에 있는 가게에 가서 직접 물건을 사오는 것과 집 앞에 있는데 굳이 배달을 이용해서 배달 지연등등의 상황을 고려해가며 물건을 받는 것의 차이일까?

셋쨰, 트랜잭션 관리 MSA 는 각각 서비스들을 호출해가며 트랜잭션을 진행한다.

MSA 구조의 트랜잭션

위 그림에서 보면 서비스 A -> 서비스 B 로 가는 트랜잭션 A 가 있고, 서비스 C 에서 서비스 B 로 가는 트랜잭션 B 가 있다. 각각의 트랜잭션은 서로 별개의 트랜잭션이기 때문에 이를 관리해하는데 어려움이 있다. 보통 모놀리틱 구조에서는 하나의 데이터의 이동을 따라 하나의 트랜잭션으로 구성되기 때문에 관리가 쉽지만 MSA 구조에서는 그렇지 않다. 이를 해결하기 위해 보상 트랜잭션, 분산 트랜잭션등의 기술이 있다.



3. MSA 구성


MSA 는 어떻게 구성되어 있을까? 여러 글을 봤지만 딱 이거다! 라고 내린 정의된 구성은 없었다. 다만 어느정도 중복되는 개념은 있었다.

모놀리틱 구조의 팀구성

  • Gateway 영역
    하위 항목으로 Security 를 가지고 있다. Security 는 인증 & 인가 역할을 수행하며 Gateway 에서는 인증 & 인가 내용을 바탕으로 맞는 서비스를 호출 또는 접근 불가 동작을 수행한다.

  • Discovery 영역
    MSA 에 구성된 서비스들을 등록한다. 등록된 서비스들은 Health Check 및 다른 서비스의 호출 요청에 원하는 서비스를 찾는데 도움을 준다.

  • CI/CD 영역
    서비스의 지속적인 배포 및 통합을 관리한다.

  • Testing 영역
    서비스 각각의 테스트 또는 전체적인 테스트를 관리 및 실행한다.

  • Communication 영역
    서비스들간의 통신처리를 담당한다. 통신 처리는 AMQP 와 같은 메세지 프로토콜이 될수도있고 JSON 을 사용하는 REST 방식일 수도있다.

  • Observing 영역
    서비스들 각각의 모니터링을 담당한다.

MSA 구성을 간단하게 작성해 보았다. 다시 말하지만 MSA 구성에는 정답이 없으며 나또한 많이 사용되는 부분을 참고하여 작성한 것이다.

MSA 구성 관련해서는 가트너에서 언급한 구성도 있고, microservice.io 라고 Chris Richardson 이라는 분이 운영하는 페이지에서도 확인 가능하다. 그외에도 검색을 통해 여러 사람들이 다양하게 구성한 MSA 구조를 볼 수 있다. 여러 곳을 참고하여 자신이 운영할 서비스에 맞는 구조를 구성하도록 하자.



4. MSA 도입


이렇게 보면 하루빨리 MSA 구조를 도입해야만 할 것 같다. 하지만 또 무조건적인건 아니다. 모놀리틱 구조는 절대 나쁜 구조가 아니다. 그렇다고 MSA 구조 또한 절대 좋은 구조가 아니다. 서로 다른 구조라고 보는게 맞는것 같다. 예를들어 크지 않은 경량 서비스의 경우에는 오히려 모놀리틱 구조가 유용할 수 있다. 이는 성능 상의 이점을 가져올수도 있기 때문이다.

개인적으로는 MSA 는 모놀리틱 구조와 같이 어울리는 것 같기도하다. MSA 의 작은 서비스 단위 하나가 모놀리틱 구조로 설계 될 수도 있지 않은가?

MSA 구조는 팀의 구성 또한 중요하다. 모놀리틱 구조의 팀 구성을 보면 대부분 기획/개발/디자인/운영 등으로 이루어져 있다.

모놀리틱 구조의 팀구성

반면에 MSA 구조의 팀 구성은 각각의 서비스에 7~10 명 정도의 인원으로 구성되며, 그 안에서 기획/개발/디자인/운영으로 이루어진다. 최종적으로 이러한 소규모의 인원으로 구성된 팀이 하나의 서비스를 담당하며 그 팀들이 여러개로 구성되어 있다.

MSA 구조의 팀구성

물론 이게 정답은 아닐 것이다. 대규모 인원으로 이루어진 하나의 팀으로 MSA 를 진행할 수도 있고 소규모의 인원으로 구성된 여러개의 팀으로 모놀리틱 구조를 진행 할 수도 있다. 하지만 위에 나온 그림들은 각 소프트웨어 구조에 그나마? 최적화된 구성이 아닐까 싶다.



5. 끝


낯선 내용은 언제나 처음이 어렵다. 하지만 찬찬히 하나씩 적용해가며 이해하면 또 금방이다. 스마트폰 보급으로 인터넷 사용률이 증가하고 있는 세상에서 어떠한 서비스던지 많은 사용량을 기록할 수도 있다. 무조건적으로 보류할만한 내용은 아니다. 자신이 개발한 서비스 또는 팀이 개발한 서비스가 커질것이라고 믿고 MSA 를 공부해보자!

태그:

카테고리:

업데이트:

댓글남기기