마이크로 서비스 아키텍처: 개념

xellos·2022년 6월 18일
0

MSA

목록 보기
2/5

Intro

실제 소프트웨어 개발은 정의와 실행의 선형 과정이 아니라 개발팀이 당면한 문제를 제대로 이해하기까지 고객과 소통하고 고객에게 배우며 전달하는 활동을 반복하는 진화과정이다.

1) 폭포수 개발 방법의 단점

전통적인 폭포수 개발 방법론을 사용하기 어려워진 것은 이들 프로젝트의 소프트웨어 산출물이 가진 세분화 정도에 따라 다음의 단점이 발생하기 때문이다.

강한 결합

앱 컴포넌트를 조금만 수정해도 그 앱의 다른 부분을 깨뜨리거나 새로운 버그를 생산할 가능성이 매우 높다.

누설

테이터 사이에 명확한 경계가 있지만 한 영역에 속한 팀이 다른 팀의 데이터에 직접적으로 접근하고 싶은 유혹을 자주 받는다. 다른 영역의 데이터에 쉽게 접근하면 보이지 않는 의존성이 생기고 컴포넌트 내부 데이터 구조에 대한 세부 구현이 앱 전체에 유출될 수 있다.

모놀리식

앱의 코드를 조금만 변경해도 비용이 많이들며 오랜 시간이 소요된다.


2) MSA의 접근법

마이크로서비스 기반 아키텍처는 기능을 제공하는데 다른 접근법을 취한다.

제한

마이크로서비스는 하나의 책임 집합을 가지며 범위가 좁다.

느슨한 결합

마이크로서비스 기반 애플리케이션은 작은 서비스 집합이며, HTTP와 REST 처럼 비독점적 호출 프로토콜을 사용하는 구현기술에 중립적인 인터페이스로 소통한다.

추상화

마이크로서비스가 소유한 데이터는 해당 서비스만 수정할 수 있다.

독립적

배포독립성을 가지며, 모놀리식보다 변경사항을 쉽게 분리하고 테스트할 수 있다.


3) 클라우드에 MSA의 특징

클라우드에 기반을 둔 개발에 왜 이러한 마이크로서비스 아키텍처의 특성들이 중요할까? 클라우드 기반 애플리케이션은 일반적으로 다음 특징이 있다.

  • 사용자층이 다양하며 대규모다.
  • 상당한 작동시간이 요구된다.
  • 볼륨이 균일하지 않다.

1. 아키텍트의 이야기: 마이크로서비스 아키텍처 설계

소프트웨어 프로젝트에서 아키텍처 역할은 해결해야할 문제의 동작 모델을 제공하는 것이다. 또 앱 코드가 서로 들어맞도록 코드를 작성하는 개발자를 위한 발판도 제공해야 할 것이다.
1. 비즈니스 문제의 분해
2. 서비스 세분화의 확정
3. 서비스 인터페이스의 정의

1) 비즈니스 문제의 이해

마이크로서비스에서 아키텍트는 비즈니스 문제를 각 활동 영역을 대표하는 덩이로 분해하고 비즈니스 영역의 특정 부분과 연관된 비즈니스 규칙과 데이터 로직을 이 덩이 안에 캡슐화한다.

마이크로서비스가 단일 트랜잭션을 수행하기 위한 모든 비즈니스 규칙을 캡슐화하기 원하더라도 항상 실현 가능한 것은 아니다. 한 트랜잭션의 완료를 위해 비즈니스 영역의 다양한 부분과 동작하는 마이크로서비스가 필요한 상황을 자주 겪는다.

2개의 다른 비즈니스 트랜잭션 부분이 교류하는 방식이 일반적으로 마이크로서비스의 서비스 인터페이스가 된다. 비즈니스 영역 분리는 이분법적인 과학이라기보다는 예술에 가깝다. 따라서 비즈니스 문제를 인식하고 마이크로서비스 후보로 분해하는데 다음 지침을 사용해보자.

비즈니스 문제를 기술하고 그 문제를 기술하는데 사용된 명사에 주목하자

문제를 기술하는데 동일한 명사가 반복해서 사용되면 대개 핵심 비즈니스 영역과 마이크로서비스로 만들 기회가 드러난다.

동사에 주목하자


데이터 응잡성을 찾자

마이크로서비스는 자기 데이터를 완전히 소유해야 한다.


2) 서비스 세분화의 과정

각 서비스는 자기 영역의 모든 데이터를 소유한다. 이는 모든 서비스가 자기 DB를 보유한다는 것이 아니라 해당 영역을 소유하는 서비스만 그 영역의 데이터베이스에 접근할 수 있다는 의미이다. 마이크로서비스 아키텍처를 구축할 때 세분화 문제는 중요하지만 다음 개념을 사용해 올바른 해결책을 구할 수 있다.

개념

  1. 큰 마이크로서비스에서 시작해 작게 리팩토링하는 것이 더 낫다: 문제 영역을 한 번에 작은 서비스로 분해하는 것은 마이크로서비스가 그저 단순한 데이터 서비스로 전략하기 쉽다.
  2. 서비스간 교류하는 방식에 먼저 집중한다: 이는 문제 영역에 대한 큰 단위의 인터페이스를 만드는데 도움이 된다.
  3. 문제 영역에 대한 이해가 깊어짐에 따라 서비스 책임도 계속 변한다: 마이크로서비스는 단일 서비스에서 시작하여 여러 서비스로 분화하며 성장하는데, 원래 서비스는 새로운 서비스들을 조율하고 다른 부분에서 새 서비스의 기능들을 캡슐화한다.

나쁜 서비스의 징후

  1. 책임이 너무 많은 서비스
  2. 많은 테이들의 데이터를 관리하는 서비스
  3. 과다한 데이터베이스

3) 서비스 사이의 대화: 서비스 인터페이스

아키텍트가 제공할 마지막 부분은 애플리케이션의 마이크로서비스가 대화하는 방식을 정의하는 것이다. 일반적으로 서비스 인터페이스 설계를 고려할 때 다음 지침을 사용할 수 있다.

REST 철학을 수용하자

서비스에 대한 REST 방식은 서비스의 호출 프로토콜로 HTTP를 수용하고 표준 HTTP 동사를 사용하는 것이다.

URL을 사용해 의도를 전달하자


요청과 응답에 JSON을 사용하자


HTTP 상태코드로 결과를 전달하자


2. 마이크로서비스를 사용하지 않아야 할 때

1) 분산 시스템 구축의 복잡성

마이크로서비스는 잘게 나뉘고 분산되어 있어 모놀리식 앱에 없던 복잡성을 가져온다. 마이크로서비스 아키텍처에는 높은 수준의 운영 성숙도가 필요하다. 따라서 고도로 분산된 앱을 성공시키는데 필요한 자동화화 운영작업에 투자할 의사가 없는 조직이라면 고려하지 않는 것이 좋다.

2) 서버 스프롤

마이크로서비스의 가장 일반적인 배포 모델 중 하나는 한 서버에 하나의 마이크로서비스 인터페이스를 배포하는 것이다. 대규모 마이크로서비스 기반 애플리케이션의 운영 환경에서만 구축 및 관리가 필요한 서버나 컨테이너가 50 ~ 100개 있을 수 있다. 클라우드에서 이들 서비스를 실행하는데 드는 비용은 저렴하더라도 서버를 관리하고 모니터링 운영 작업은 엄청나게 복잡해질 수 있다.

3) 애플리케이션 유형

부서 수준의 소형 앱이나 소수 사용자를 위한 앱을 개발할 때 마이크로서비스와 같은 분산 모델로 구축한다면 구축에 따른 복잡성이 얻게 될 가치보다 더 클 수 있다.

4) 데이터 변환 일관성

마이크로서비스를 검토할 때 서비스의 데이터 사용 패턴과 서비스 사용 패턴과 서비스 소비자가 어떻게 서비스를 사용하는지 고민해야 한다. 마이크로서비스는 적은 수의 테이블을 둘러싸고 추상화하며, 저장소에 단순한 작업을 수행하는 메커니즘으로도 잘 동작한다. 앱이 여러 데이터소스에서 복잡한 데이터를 취합하고 변환해야 할 경우 마이크로서비스의 분산된 특성 때문에 작업이 어려워진다. 마이크로서비스느 변함없이 과도한 책임을 떠안고 성능 문제에도 취약해질 것이다.


3. 데브옵스 이야기

데브옵스 엔지니어에게 마이크로서비스 설계란 양산(실운영) 이후의 서비스 관리에 관한 설계다. 모드 작성은 흔히 쉬운 부분에 속한다. 계속 동작하게 만드는 것이 어렵다. 여기에서는 다음 네가지 원칙으로 마이크로서비스 개발을 시작하고 실행해볼 것이다.
1. 마이크로서비스는 단일 소프트웨어 산출물을 사용해 여러 서비스 인스턴스를 시작하거나 제거할 수 있도록 자체 완비형이며 독립적으로 배포가 가능해야 한다.
2. 마이크로서비스는 구성 가능해야 한다. 서십스 인스턴스가 시작될 때 구성에 필요한 데이터를 중앙에서 읽어 들이거나 환경 변수로 전달된 구성 정보를 받아야 한다. 서비스를 구성하는데 사람의 개입은 필요하지 않다.
3. 마이크로서비스 인스턴스는 클라이언트가 위치를 알지 못하도록 투명해야 한다. 그 대신 물리적인 위치를 알지 못하더라도 앱이 알 수 있도록 서비스 디스커버리 에이전트와 통신해야 한다.
4. 마이크로서비스는 자시의 상태를 전달해야 한다. 이는 클라우드 아키텍처에서 매우 중요한 부분이다. 마이크로서비스 인스턴스들은 고장날 수 있으며 클라이언트는 잘못된 서비스 인스턴스를 피해 라우팅 해야한다.

데브옵스 관점에서 마이크로서비스와 관련된 운영상의 요구사항을 해결하고 이러한 네가지 원칙을 마이크로서비스를 빌드하고 환경에 배포할 때마다 발생하는 표준 수명주기 이벤트로 변환해야 한다.

서비스 어셈블리

동일한 서비스 코드와 런타임을 정확히 같은 방식으로 배포하기 위해 반복성과 일관성을 보장하는 서비스 패키징과 배포 방식은 무엇인가?

서비스 부트스트래핑

사람이 개입하지 않아도 모든 환경에 마이크로서비스 인스턴스를 신속하게 시작하고 배포하기 위해 앱과 환경별 구성 코드를 런타임 코드와 분리하는 방법은 무엇인가?

서비스 등록 및 디스커버리

새로운 마이크로서비스 인스턴스가 배포될 때 다른 애플리케이션 클라이언트가 발견할 수 있게 만드는 방법은 무엇인가?

서비스 모니터링

마이크로서비스 환경에서 매우 높은 가용성을 요구하기 때문에 동일 서비스를 여러 인스턴스로 실행하는 것은 일반적이다. 데브옵스 관점에서 인스턴스를 모니터링하고 고장을 회피하는 라우팅과 비정상 서비스 인스턴스를 제거하는지 확인해야 한다.

1) 서비스 어셈블리: MSA의 패키징과 배포


2) 서비스 부트스트래핑: MSA의 구성 관리


3) 서비스 등록과 디스커버리: 클라이언트가 MSA와 통신하는 방법


4) 마이크로서비스의 상태 전달


모든 관점에서

1) 아키텍트

비스니스 문제의 실제 윤곽을 잡는다. 처음부터 잘게 나뉜 많은 서비스에서 시작하는 것보다 굵게 나뉜 마이크로서비스에서 시작해서 작은 서비스로 리팩토링하면 더 낫다는 것을 기억하자


2) 소프트웨서 엔지니어

서비스가 작다는 사실이 사실 좋은 설계 원칙을 포기하라는 것은 아니다. 서비스 안의 각 계층이 개별 책임을 맞는 계층적 서비스를 구축하는데 집중한다.


3) 데브옵스 엔지니어

서비스는 외부와 단절된 것이 아니다. 서비스 수명 주기를 일찍 수립하자. 데브옵스 관점에서는 서비스 빌드와 배포를 자동화하는 방법뿐 아니라 서비스 상태를 모니터링하고 문제가 발생할 때 대응하는 방법에도 집중해야 한다.

0개의 댓글