[MSA] MSA 개념 이해하기 (1)

최근 회사에서 MSA에 대한 이야기를 듣게 되었는데, MSA라는 개념을 들어본 적이 없어서 생소했다.

그런데 사실 아예 접하지 못한 개념은 아니었다는 것을 알게 되었는데

결론적으로 이야기하면 시스템, 서비스 분산에 대한 내용이었다.

 

MSA 하면 가장 유명한 회사가 있는데

넷플릭스에서 모놀리식 아키텍처(Monolithic Architecture)에서 마이크로서비스 아키텍처(Microservice Architecture)로 전환했다는 이야기를 많이 보게 되었다.

 

어째서 넷플릭스는 기존 아키텍처에서 MSA로 전환을 택하게 되었는지에 대한 내용들을 찾아보니 많은 내용들을 공감할 수 있었다. 여기서 기존 아키텍처는 Monolithic Architecture인데 어떤 문제점이 있어서 전환을 하게 되었는지 한번 확인해 보려고 한다.

---

Monolithic Architecture VS Microservice Architecture

모놀리식 아키텍처(Monolithic Architecture)

하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍처를 가질 때 이를 모놀리식 아키텍처

 

Monolithic Architecture는 하나의 애플리케이션에 모든 서비스 기능들이 집합해 있다고 보면 되는데

과거에 내가 개발해왔던 프로젝트들이 모놀리식 아키텍처라고 보면 될 것 같다.

장점

• 하나의 애플리케이션에 모든 서비스가 있기 때문에 개발, 빌드, 배포, 테스트가 용이하다.
• 초기의 소규모 프로젝트에 적합하다.
• 동일한 환경에서 개발되기 때문에 복잡하지 않다.

단점

• 어플리케이션의 규모가 커질수록 빌드, 배포 시간이 길어진다.
• 작은 수정사항이 생기더라도 전체를 빌드하고 배포해야 한다.
• 장애 발생시 전체 서비스 장애로 번질 가능성이 높다.

현재 개발자라면 Monolithic Architecture의 장단점을 공감할 거라고 생각한다.

MSA를 사용하려는 이유는 Monolithic Architecture의 단점 및 한계를 극복하기 위해서라고 보인다.

 

마이크로 서비스 아키텍처(Microservice Architecture)

하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처

 

기존에 하나의 애플리케이션에 모든 서비스 기능이 있었다면 MSA는 서비스들을 분산시켜 놓은 형태인 듯하다.

아래 사진을 보면 왼쪽은 MA, 오른쪽은 MSA인데 서비스뿐만 아니라 DB도 함께 분리하는 모습을 볼 수 있다.

Monolithic VS Microservice

왜 서비스와 DB를 분산시켜야 할까?

• 각 서비스가 독립적이다.
• 서비스별 배포가 가능하여 배포가 빠르고 전체 서비스 중단이 없다.
• 장애 발생 시 격리 및 복구가 쉽고 전체 서비스 장애로 번질 가능성이 적다.
• 서비스별 기능에 따라 언어, 프레임워크, 데이터베이스 등의 다른 기술들 적용이 가능하다.

운영 관점

기존에는 서비스들이 하나의 애플리케이션에 모여있기 때문에 배포 속도도 느리고 배포 한번 하려면 전체 서비스를 재기동해야 한다. 하지만 MSA에서는 서비스들이 분산되어 있어 특정 서비스만 배포하면 되기 때문에 배포가 빠르고 서비스 중단이 없다는 장점이 있다. 또 각 서비스는 독립적이기 때문에 장애 발생시 격리 및 복구가 쉽고, 장애가 전체 서비스로 번질 가능성이 현저히 줄어든다.

 

개발 관점

서비스별로 기능에 따라서 언어와 프레임워크, 데이터베이스 등의 기술들을 적용할 수 있다는 장점도 있다. 특정 서비스에 대한 업무 집중도도 향상되고 좀 더 효율적인 작업이 가능하다는 장점이 있다. 그리고 개발할 때 선행개발을 해야 진행할 수 있는 개발도 있지만 MSA에서는 서비스가 분리되어 있기 때문에 각각 개발을 진행하면 돼서 개발 속도도 빨라진다.

 

MSA의 장점들을 살펴봤는데 상당 부분 동의하는 부분이다.

특히나 특정 서비스 장애 발생 시 전체 서비스 장애로 이어지지 않는 점은 큰 메리트가 있다고 느껴진다.

MSA는 어떻게 운영할까?

현재 서비스를 운영 중인데 추가적으로 서비스가 계속 늘어난다고 생각해보자.

 

서비스별로 연계가 잘 되는지, 테스트는 어떻게 해야 되는지 등 고민할 거리가 많아진다.

트랜잭션 처리는 어떻게 할 건지, DB의 정합성 확인은 어떻게 할 건지 등에 대한 생각도 하지 않을 수 없다.

계속 늘어나는 서비스

그리고 계속 늘어나는 서비스의 관리는 어떻게 해야 되는지에 대한 의문도 들었다.

 

서비스가 많아지면 각각 URL도 그만큼 늘어나는 건가?

URL들은 어떻게 관리하고 호출하지?

Service Discovery

클라우드 환경의 MSA에서는 서비스가 필요에 따라 생성/소멸을 반복할 것이고, 운영하면서 서비스는 계속해서 늘어날 텐데 이를 관리하기 위한 무언가가 필요했다.

 

그래서 서비스를 등록하고 검색해주는 서비스 디스커버리(Service Discovery)가 필요했는데 넷플릭스에서 OSS로 공개한 유레카 서버(Eureka Server)가 해당 역할을 하고 있다.

 

정리하면 유레카 서버(Eureka Server)에서는 각 서비스들을 서비스의 ID값으로 매핑하여 관리하고 있는데 서비스들은 각각 자신의 정보를 디스커버리 서버에 등록(Service Registry)하고, 디스커버리 서버(Service Discovery)는 다른 서비스들의 정보를 조회(검색)한다.

 

서비스 디스커버리 서버를 통해 각 서비스들의 IP와 PORT를 모르더라도 서비스의 정보(ID)만 알면 서로 연계가 가능해지는 것이다.

MSA 구조

API Gateway

MSA에서는 모든 API 요청을 받는 API Gateway를 사용하는데 서비스 디스커버리 서버에서 서비스들을 매핑해주기 때문에 클라이언트는 API Gateway를 통해 모든 요청을 하더라도 각 서비스로 연계가 가능해진다.

---

정말 간단하게 MSA에 대해서 알아보았는데

각 기능별로 좀 더 자세히 공부를 해볼 예정이다😊

 

MSA에 대하여 (2) - API Gateway