[MSA] Microservice Architecture란? - (2)

 

++ 이전 포스팅 링크 (눌러주세요 제발)

 

이전 포스팅에서는 클라우드 네이티브 기술에 대한 내용을 주로 다뤘다.

그 중 Cloud Native Application의 핵심 중 하나인 Microservice에 대해 언급했는데,

이번에는 해당 개념(Microservice Architecture) 에 대한 내용을 좀 더 자세히 다뤄보도록 하겠다.

 

 Monolithic vs MSA

 

그래서, MSA가 도데체 뭘까..?

요즘 채용 공고를 보면 심심찮게 해당 단어를 확인할 수 있을 것이다.

마이크로 라는 말이 들어간 것을 보아하니 작은 단위로 쪼개진 서비스 같은데.. 단어만 봐서는 분명하게 와닿지 않는다.

 

먼저 MSA등장 이전에 주를 차지하던 어플리케이션 구조와 비교하며 감을 잡아보자!

 

출처 : profisea

해당 그림처럼 Monolith 방식은 어플리케이션 개발에 필요한 모든 요소를 '하나의 소프트웨어'안에 포함시켜 개발하는 방식이다.

반면에 Microservice는 모든 요소가 큐브의 조각처럼 분리되어 구성되어 있다.

 

하나의 서비스를 예로 들어 살펴보자.

'나만의 스케줄러 어플리케이션'을 만든다고 할 때, 들어갈 기능은 다음과 같다.

• TODO 리스트
• Calendar
• 알림 기능

 

Monolithic 설계 구조의 경우, 해당 기능을 모두 하나로 합쳐 하나의 애플리케이션을 빌드하여 배포할 것이다.

만약, 알림 기능을 수정할 경우? 전체 애플리케이션을 다시 수정해서 빌드 배포해야 하는 번거로운 일이 생길 것이다.

(실제 필자의 경우, 코드 한줄을 바꾸기 위해 다시 빌드하여 jar파일을 배포하는 일이 빈번했는데, 코드를 바꾸는 시간보다 빌드 및 배포 시간이 더 길었다..^_ㅜ)

 

그림으로 구조를 좀 더 자세히 살펴보자, 

Monolithic 방식은 하나의 어플리케이션에서 서로 의존성을 가지고 패키징 되어 운영되기 때문에 유지 보수 측면에서 필자가 겪은 경험처럼 비효율적인 일이 발생할 수 있다.

 

Microservice Architecture의 경우 다음과 같이 정리할 수 있다.

• Monolithic과 상반되는 방식으로 모든 요소가 분리되어 구성되어있는 방식
• 유지 보수 측면에서 유리하다.
• 분리된 서비스가 다른 서비스에 영향을 주지 않아 독립적으로 개발 및 배포가 가능
• 각각 용도에 맞는 컨테이너들을 모아서 사용하는 서비스 개념

 

 Microservice Architecture

 

이제 어느정도 MSA에 대한 감이 조금 잡혔을거라 생각한다.

쉽게 생각하면 spring boot로 backend, frontend 다 때려넣고 한번에 빌드하는 방식 -> monolithic

backend 내부에서 서비스를 각각 독립적으로 분리해서 따로 빌드하고 배포하는 방식 -> MSA

라고 생각하면 된다.

 

물론 말이 쉽지 그만큼 MSA구조는 상당히 복잡하다. 왜?

가령 서비스가 1, 2, 3으로 나눠져 있다고 가정해보자.

유저A 가 서비스 1 (주문 이라고 할 때)에 요청을 보내 마지막 상품을 주문했다고 해보자.

이 때 다른 유저B 가 서비스 2 (장바구니 라고 할 때) 에 요청을 보내 같은 상품을 담아야 할 때,

이미 해당 상품이 품절이라면? 

 

각각의 서비스는 독립적으로 돌아가기 때문에 DB도 서로 다르게 가지고 있다. 유저A와 유저 B 모두에게 같은 상태의 상품 수량을 보여줘야 하므로 각각의 DB는 서로 최신상태로 늘 갱신되어 있어야 한다.

 

벌써부터 머리가 아프다.. 해당 내용은 포스팅을 진행하면서 차차 다룰 예정이니 벌써부터 포기하지 말길 바란다..!

 

마지막으로 MSA구조에 대한 그림을 참고하여 전체적인 구조를 살짝 찍먹해보자.

 

 MSA 표준 구성요소

 

 

간단하게(?) 흐름을 쭉 읽어보겠다. 

 

1. 클라이언트들의 요청은 API 게이트웨이로 수집된다.
   (A라는 서비스에 요청할래!)
2. 게이트웨이는 서비스 라우터에게 어디로 가야할지 질문한다.
   (어디 서비스로 가야하니?)
3. 서비스 디스커버리에게 필요한 마이크로서비스가 어디에 저장되어있는지 물어본다
   (서비스 어딨니?)
4. 서비스 위치를 받은 로드밸런서가 여러개로 분산된 서비스 중 어디로 보낼지 결정한다.
   (서비스 A의 여러 서버중에 어디가 제일 널널하니?)

일반적으로 마이크로 서비스 안에서 사용하는 환경설정 정보는
config store처럼 외부 시스템에 저장해서 사용한다.

 

 

완성된 어플리케이션은 배포를 위해
CI/CD 자동 기술을 사용한다.

 

 

 

서비스에서 DB에 요청하여 정보를 가져오고 갱신한다.

이 때 각 서비스에 연결된 DB들은 모두 같은 상태로 동기화 되어 있어야 한다.

 

메세징 처리 시스템을 통해 하나의 서비스와 다른 서비스가 연결될 수도 있다. (MOM)

 

 

마이크로 서비스의 모니터링과 진단 기능을 가지고 있다.

 

각각 서비스가 독립적이라 어디서 오류가 발생했는지 체크하기가 힘들어 지속적으로 로그 수집 및 모니터링이 필요하다

 

 

 

보기만 해도 어질어질하다. 너무 겁먹을 필요 없다! 다음 포스팅부터 각각의 구역을 하나씩 다뤄보며 전체적인 흐름을 익혀볼 예정이다. 필자와 함께 MSA를 차근차근 정복해보자! 

 

 

MicroService의 특징

 

• Challenges (기존의 패러다임을 바꿔야함)

 

• Small Well Chosen Deployable Units (작은 단위로 독립적으로 배포 가능)

 

• Bounded Context (서비스 경계 구분)

 

• RESTful (MSA의 서비스 인터페이스)
  독립적으로 구분된 서비스 사이의 통신 방식이다. 

 

• Configuration Management
  서비스들의 환경, 설정 정보를 하드코딩하지 않고 외부의 시스템으로 두어 관리한다.
  외부 API를 쓸 때 필요한 고정된 변수등을 의미한다.

 

• Cloud Enabled (cloud native 기술을 최대한 활용)

 

• Dynamic Scale Up And Scale Down (부하 분산을 동적으로 처리)
  할인 이벤트 등으로 사용자들이 몰릴 때, 관리자가 직접 수동으로 서버를 늘리지 않는다.
  자동으로 서버를 증설하고 한 서버에 몰리지 않도록 부하를 분산시키는 일도 동적으로 처리한다.

 

• CI/CD (자동화 배포 관리)
  젠킨스 등의 도구로 빌드 및 배포를 자동화한다.

 

• Visibility (마이크로 서비스를 시각화 하여 관리)
  독립적으로 구분된 서비스 사이의 통신이나 log를 모두 수집하여 시각화한다.
  관리자는 해당 시각화된 내용을 모니터링하여 지속적으로 어플리케이션 상태를 관리한다.

 

이전에 계속해서 다루던 MSA방식의 특징과 겹치는 부분도 많았을 것이다.

반복적으로 개념을 다룰 예정으로 억지로 암기하지 않아도 자연스레 와닿을 수 있도록 할 것이다.

 

개념을 쭉 다뤄보니 MSA구조를 실제로 어떻게 만들지에 대한 호기심이 생겼다!

필자의 경우 개념만 주구장창 파다보면 시들시들 흥미를 잃는 타입으로 다음 부터는 실습과 함께 MSA구조를 조금씩 구축해나갈 예정이다. 참고로 이전 포스팅에서도 언급했지만 모든 개념은 인프런의 강의를 토대로 재구성한 내용이다.

아직 20%정도 수강한 상태지만 퀄리티가 아주 상당하여 여러분들에게도 추천하고 싶다. (광고아님 내돈내산)

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

 

다음 포스팅은 Service Discovery를 다룰 예정이다.

 

조금 스포를 해보자면

수많은 독립된 서비스들을 어떻게 구분해서 클라이언트가 요청할 수 있을까? 그에 대한 해답을 다룬 내용이다.

 

참고

[강의]

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4