MSA 개념

반응형

 

마이크로서비스 개념이 나오게 된 배경

 

서비스 변경 빈도가 잦아지면서 변화된 비즈니스 환경에 민첩하게 대응할 수 있는 구조의 필요성이 높아지면서 그런 구조를 갖춘 아마존의 비즈니스 환경에 대한 관심을 갖게 되었다.

 

현재 아마존은 MSA 환경 덕분에 요구사항에 즉각적으로 대응할 수 있으며 그 서비스 변경 속도는 대략 11초 밖에 소요되지 않는다.

 

MSA에 가장 기본이 되는 개념은 클라우드 인프라이다.

물리서버는 인프라를 구축하는데 많은 비용과 시간을 투자해야 된다. 하지만 클라우드 인프라는 신규 또는 구축되어 있는 인프라를 구성을 빠르게 진행할 수 있다.

그리고 클라우드 인프라의 또다른 장점은 사용량에 따라 리소스 확보가 가능하다는 점이다.

 

서버의 리소스를 확장하는 방법에는 두가지가 있다. 수직 확장, 수평 확장이 있다.

수직 확장은 그 서버의 리소스를 확장하는 방식이고 수평 확장은 서버를 2개, 3개로 늘리는 방식이다.

 

관리자는 이벤트기간 동안 리소스 확보를 위해 수직, 수평 확장을 계획할 수 있다. 하지만 전체 서버를 확장할 경우 수직이든 수평이든 불필요한 리소스까지 같이 확장되어 비용적 부담이 커질 수 있다. 

 

보통 이벤트를 진행할 경우 특정 서비스에만 트래픽이 몰리고 그 외엔 평소와 크게 다르지 않을 것이다. 이 부분 때문에 마이크로서비스 개념이 나오기 시작했다. 

특정 서비스의 리소스만 수평 확장을 한다면 비용 절감이 가능하고 유지보수 역시 즉각적인 대응이 가능하다.

 

클라우드 인프라의 장점을 효율적으로 사용하려면 사용량이 몰리는 일부 기능의 리소스만 변경되게 하는 것이다.

일부 기능만 변경할 수 있도록 하려면 서버를 각 기능별로 쪼개서 구성해야 된다. 그걸 마이크로 서비스 아키텍처이다.

(Cloud Native Application = Microservice)

 

모노리스 시스템

애플리케이션이 한덩어리로 구성되어있고 단일 프로세스 실행임으로 한꺼번에 수정, 배포를 진행해야 되는 시스템 구조를 의미한다.

확장을 해야되면 전체가 확장되어야 함, 스케일아웃을 통해 전체를 확장할 수 있어 확장성과 탄력성은 보장받을 순 있으나 비용적으로 효율적이지 않다. (하나가 실패하면 모두 실패됨)

 

마이크로서비스 시스템

애플리케이션이 여러개의 서비스 조각으로 구성된 시스템 구조를 의미한다.

서비스가 독립적으로 기능을 제공하며 서비스별 저장소가 분리되어있으며 독립적으로 수정 및 배포, 확장이 가능하다. (하나의 서비스 실패는 전체 실패가 아님)

각 서비스는 개별 프로세스에서 실행되며 restful api 처럼 가벼운 수단을 사용해서 통신한다.

polyglot (폴리그럿)이 한 서비스 단위를 의미하며 각 폴리그럿은 각각 다른 언어와 다른 디비를 사용할 수 있다. 

 

마이크로서비스 성공을 위한 조건들

클라우드 적용 시 가장 이상적인 애플리케이션 유형이 마이크로서비스이며 비스니스 민첩성을 높이기 위해서는 기술 아키텍처 변화에 국한되지 않는 개발프로세스, 조직, 개발 문화의 동반적인 변화가 필요하다. 그러므로 마이크로서비스를 적용하는 것은 쉽지 않다.

아키텍처, 개발 문화, 조직 등 변화 뿐만 아니라 애플리케이션 설계 방식 역시 변화해야 된다.

데이터 일관성 문제가 발생하는데 과정이 아닌 결과적인 측면에서만 데이터 일관성을 보장하면 된다. 즉 데이터 중복은 발생할 수 있으며 결과적 일관성을 보장하는 방향으로 설계하면 된다.

 

또한 모든 과정을 API 기반으로 설계함으로 항상 단계별 실패에 대한 고민이 필요하며 반드시 실시간 모니터링 체계가 필요하다.

 

그럼 마이크로서비스는 과연 무조건 도입해야되는 만병통치약인가?

MSA는 마이크로서비스 기반 아키텍처이지만 말그대로 아키텍쳐임으로 상황에 따라 최선의 선택을 하면 되고 우선순위에 따라 선택과 집중이 필요하다.

 

MSA의 오해들이 있는데 컨테이너, 쿠버네이티스를 사용하면 MSA이다. 클라우드 인프라 위에는 무조건 마이크로서비스가 올라가야 된다 등등 MSA의 기본 베이스가 클라우드 환경은 맞지만 꼭 마이크로서비스가 아닌 모노리스를 올려도 된다.

 

마이크로서비스 성숙도

모노리스 시스템 -> 매크로서비스 -> 미니서비스 -> 마이크로서비스

형태로 애플리케이션을 진화시킬 수 있다.

 

매크로서비스 : 모놀리스 시스템 안에 각각의 영역을 API 화하여 언제든 서비스별 분리가 가능한 구조를 의미한다. (같은 디비 사용)

미니서비스 : 영역별로 서비스는 분리했으나 일부는 디비까지 분리된 하이브리드형 구조를 의미한다. 

마이크로서비스: 영역별 서비스와 디비 모두 분리된 구조를 의미한다.

 

-> 성능 면에선 모노리스 시스템보다 안 좋을 수 있다 왜냐하면 기능별 인스턴스를 쪼개놓았기 때문에 1개의 요청에 대한 처리를 위해선 각 서비스 서버에서 분산 트랜젝션처리 및 각 서버 별 네트워크와 보안적인 부분까지 여러가지에 대한 고민이 필요하다.

물론 요즘 네트워크이 좋아졌다고 하지만 네트워크 문제가 항상 발생하지 않는다고 단정 짓을 순 없기 때문에 성능 및 안정성이 중요한 시스템은 모노리스 서비스를 유지하는 게 좋을 수도 있다.

 

클라우드 인프라 도입과 애플리케이션 컨테이너화 만으로도 어느정도 확장성과 배포성, 탄력성을 보장받을 수 있기 때문에 결제 시스템은 굳이 마이크로서비스 아키텍쳐 구조를 선택하지 않아도 된다.

 

아키텍처란

아키텍처 특성 : 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성, 내고장성, 탄력성, 복구성, 성능, 배포성, 학습성

아키텍처 결정 : 제약조건, 개발자가 지켜야 하는 규칙

설계 원칙 : 아키텍처 결정을 만족시키는 가이드 라인

시스템 구조 : 아키텍처 결정 및 설계 원칙에 적합한 상위 수준의 시스템 구조를 정의

 

레이어드 아키텍처 스타일

- 표준 아키텍처이며 관심사를 분리하고 각 레이어별 역할을 격리한다. 

- 장점 : 익숙하고 단순하며 소규모, 비용이 적다.

 

파이프라인 아키텍처 스타일 

 - Bash,Zsh 등 유닉스 터미널 쉘 언어의 기초 원리

 - 장점 : 단방향이라 단순하고 조립이 가능하다.

마이크로커널 아키텍처 스타일 

 - 제품 기반 애플리케이션에 적합하며 코어 시스템과 플러그인 컴포넌트들로 구성되어 있다. ex) 이클립스, 젠킨스, 크롬 등등

 - 장점 : 단순하며 비용이 적다.

[작성 예정......]

서비스 기반 아키텍처 스타일 

이벤트 기반 아키텍처 스타일

공간 기반 아키텍처 스타일

오케스트레이션 기반 서비스 지향 아키텍처 스타일

마이크로서비스 아키텍처 스타일

 

 

[참고자료 및 강좌]

https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard

실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 - 인프런 | 강의

이 글은 인프런 강좌 실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 자료로 작성했습니다.