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

 

마이크로서비스 아키텍처란?

마이크로서비스 아키텍처((Microservice Architecture)는 하나의 큰 애플리케이션을 비즈니스 단위의 여러 개의 작은 서비스로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말합니다. 서비스의 전체 사이클은 몇 가지 단일 기능 모듈들의 합으로 이루어지며, 해당 모듈들은 개별적으로 배포되고 운영됩니다. 일반적으로 DevOps 에자일 방식으로 개발하고 배포합니다. 각 기능들은 독립적인 자동화 서비스(마이크로서비스)로서 개별 서버를 갖고 있게 됩니다. 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성하게 됩니다.

 

MSA의 등장 배경

기존 Monolithic Architecture의 한계

• 부분 장애가 전체 서비스의 장애로 확대될 수 있음
• 전체 시스템 구조 파악이 어려움
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트 등) 파악이 힘듦
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(sacle-out) 하기 어려움

 

 

MSA의 특징

① 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공한다.
② 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 담당한다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.
③ 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
④ 애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
⑤ 작고 독립적이며 분산된 마이크로서비스를 사용해 조직은 명확히 정의된 책임 영역을 담당하는 소규모 팀을 보유할 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.

 

MSA의 목적

마이크로서비스를 달성하기 위해서는 많은 노력과 비용이 수반된다. 따라서 MSA를 적용하고자 할 경우 명확한 목적을 갖고 적용을 고려해 보아야 한다.
1) 마이크로서비스 아키텍처를 통해 달성하고자 하는 목표는 무엇인가?
명백한 목표 예를 들어 기존 대비 1.5배 빠른 성능, 이벤트에도 중단되지 않는 가용성 높은 서비스 등 결과를 기준으로 설명할 수 있어야 하며, 시스템의 end-user에게 이점을 제공하는 방식으로 설명될 수 있어야 한다.
2) 마이크로 서비스 사용에 대한 대안을 고려했습니까?
마이크로서비스가 제공하는 것과 동일한 이점을 얻을 수 있는 다른 많은 방법이 있다. 때로는 MSA를 고려하지 않고도 적용 가능한 방법이 다양하게 존재하므로, 이에 대한 고려를 선행한 후 MSA를 선택하는 것이 좋다.

 

 

 

MSA 장점

1. 배포

- 서비스별 개별 배포가 가능합니다.(배포시 전체 서비스의 중단이 없습니다.)

- 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능합니다.

 

2. 확장

- 특정 서비스에 대한 확장성(scale-out)이 유리합니다.

- 클라우드 기반 서비스 사용에 적합합니다.

 

3. 장애

- 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.

- 부분적으로 발생하는 장애에 대한 격리가 수월합니다.

 

4. 그 외

- 새로운 기술을 적용하기 유연합니다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)

- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

 

MSA 단점

1. 설계의 어려움

- MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야합니다.

 

2. 성능

- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재합니다.

 

3. 테스트/데이터 트랜잭션

- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.
- 통합 테스트가 어렵습니다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않습니다.

 

4. 데이터 관리

- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.

- 데이터를 관리하기 어렵습니다.

 

 

---

응답하라 추억시대에서 MSA를 도입한 이유

: 서비스의 가용성, 지속성 (채팅방 서버의 안전한 구현)

응답하라 추억시대에서 MSA를 도입하며 DB를 5개로 분리한 이유

: 서비스의 결합도가 낮아지면 가용성이 올라가기 때문이다.

응답하라 추억시대의 MSA가 더 궁금합니다! 

- 저희는 현재 비즈니스 로직 별로 Users, Posts, Threads, Admin, Chat으로 서비스를 나누었습니다.

- 서비스별로 각각 다른 포트를 갖는 서버를 갖습니다.

- DB역시 서비스별로 분리하였으며 Chat은 MongoDB 나머지 서비스는 MySQL을 사용합니다.

- 4대의 MySQL로 나누어 서로 통신을 통해 다른 서비스의 DB에 접근할 수 있습니다.

- 서비스별로 분리한 DB의 인바운드 규칙은 현재 화이트리스트 방식으로 허용한 ip만 접근할 수 있습니다. 

 

참고 자료 : 

https://library.gabia.com/contents/infrahosting/9154/

https://waspro.tistory.com/429

https://hahahoho5915.tistory.com/71

https://aws.amazon.com/ko/compare/the-difference-between-monolithic-and-microservices-architecture/