(2) 스프링 부트로 마이크로서비스 구축

1. 서론

이번 포스팅에서는 2장인 스프링 부트로 마이크로서비스 구축에 대해 알아보도록 하겠습니다.

 

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

 

마이크로서비스 아키텍처를 구축할 때 프로젝트의 아키텍트는 아래 세 가지 일에 집중해야 합니다.

 

1. 비즈니스 문제의 분해
2. 서비스 세분화의 확정
3. 서비스 인터페이스의 정의

 

1) 비즈니스 문제의 분해

 

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

 

분해하는것은 말처럼 쉬운일이 아닙니다.

하지만, 아래와 같은 지침을 사용한다면 분해하는데에 있어 도움이 될 수 있습니다.

 

1. 비즈니스 문제를 기술하고 그 문제를 기술하는 데 사용된 명사에 주목 : 문제 기술에 자주 반복되는 명사로 논리적인 영역이 정해집니다.
2. 동사에 주목 : 문제 기술의 동사를 본다면 행위를 명확히 알 수 있습니다.
3. 데이터 응집성을 찾아라 : 서로 연관성이 높은 데이터 부분들을 찾아 마이크로서비스가 자기 데이터를 완전히 소유하도록 해야 합니다.

 

아래는 EagleEye의 모놀리식 서비스의 그림입니다.

 

 

이를 분해를 한다면 아래와 같은 데이터 모델이 나옵니다.

 

 

 

 

2) 서비스 세분화의 확정

 

위 데이터 모델을 본다면 조직, 계약, 자산, 라이선스로 4개의 마이크로서비스가 나올것을 예상할 수 있습니다.

 

그렇다면, 위 4개의 서비스는 서로 독립적으로 빌드하고 배포할 수 있어야 합니다.

 

하지만, 데이터 모델에서 서비스를 추출하는 일은 쉬운일이 아닙니다.

이유는, 서비스가 접근하는 실제 데이터베이스 테이블을 서비스에 따라 정리하고 각 서비스가 특정 도메인의 테이블만 액세스하도록 하는 등의 부가적인 일들이 동반되기 때문입니다.

 

아래는 위 데이터 모델을 기반으로 마이크로서비스로 분해했을때의 전체적인 그림입니다.

 

 

 

마이크로 서비스 아키텍처를 구축 시 세분화는 아래와 같은 개념을 이용할 수 있습니다.

 

1. 큰 마이크로서비스에서 시작해 작게 리팩토링
2. 서비스간 교류하는 방식에 먼저 집중
3. 문제 영역에 대한 이해가 깊어짐에 따라 서비스 책임도 계속 변함.

 

3) 서비스 인터페이스의 정의

 

서비스 인터페이스는 마이크로 서비스가 대화하는 방식을 정의하는 것입니다.

 

서비스 인터페이스를 설계할땐, 아래와 같은 지침을 사용할 수 있습니다.

 

1. REST 철학을 수용
2. URI를 사용해 의도를 전달
3. 요청과 응답에 JSON을 사용
4. HTTP 상태코드 결과를 전달

 

 

반응형

 

 

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

 

마이크로서비스가 만능은 아닙니다. 오히려 마이크로서비스를 적용하는것이 독이 될때가 있습니다.

 

아래는 마이크로서비스를 적용하지 않아야하는 할 때 입니다.

 

1. 분산 시스템 구축의 복잡성
2. 가상 서버/컨테이너의 스프롤
3. 어플리케이션 유형
4. 데이터 변환과 일관성

 

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

 

마이크로서비스는 모놀리식에 비해 복잡성이 증가하게 됩니다.

 

때문에, 마이크로서비스에서 필요한 자동화와 운영작업에 투자할 의사가 없는 조직이라면 적용하지 않는데 낫습니다.

 

 

2) 가상 서버 / 컨테이너의 스프롤

 

마이크로 서비스는 클라우드 조합으로 많이 사용합니다.

 

클라우드에서 서비스들을 실행하는데 드는 비용은 저렴하지만 서버를 관리하고 모니터링하는 운영작업은 엄청나게 복잡해질수 있습니다.

 

 

3) 어플리케이션 유형

 

소수 사용자를 위한 어플리케이션을 개발할 때 마이크로서비스와 같은 분산 모델로 구축하는것은 더욱 복잡성을 증대시키며, 오버 스펙입니다.

 

 

4) 데이터 변환과 일관성

 

마이크로서비스 환경에서는 데이터를 변환하고 취합하는 작업이 분산환경으로 인해 어려울 수 있습니다.

 

또한, 각 서비스는 분리가 되어있어 업데이트한 데이터가 즉시 나타나지 않을 수 도 있습니다.

 

4. 개발자 이야기: 스프링 부트와 자바로 마이크로서비스 생성

마이크로서비스에서 구현단계에서는 일관된 방식으로 코드가 배치되도록 하는 것이 중요합니다.

 

아래는 간단히 위 EagleEye의 라이선스 서비스의 골격인 프로젝트 예제입니다.

 

https://github.com/klimtever/spmia-chapter2

 

5. 데브옵스 이야기: 혹독한 런타임 구축

 

마이크로서비스는 데브옵스 관점에서 관리할 프로젝트들이 늘어 힘들어 집니다.

 

때문에, 데브옵스 관점에서 아래 4가지 원칙을 사용하여 빌드 배포에 대해서 일반화를 시켜야합니다.

 

1. 서비스 어셈블리
2. 서비스 부트스트래핑
3. 서비스 등록 및 디스커버리
4. 서비스 모니터링

 

1) 서비스 어셈블리

 

서비스 어셈블리란 일관된 구축, 패키징 및 배포하는 과정을 의미합니다.

 

아래는 서비스 어셈블리를 도식화한 그림입니다.

 

 

 

기존에는 웹서버 사용시 외부 톰캣을 이용하기 때문에 스프링 버전과 톰캣버전등의 구성편차가 어쩔수 없이 존재했습니다.

하지만, 스프링 부트에서부터는 내장 톰캣이 있어 단일로 소스와 웹서버를 관리 및 배포가 가능해졌습니다.

 

 

2) 서비스 부트스트래핑

 

서비스 부트스트래핑은 마이크로서비스가 처음 가동할 때 시작하며 어플리케이션 구성 정보를 로드합니다.

 

아래는 서비스 부트스트래핑을 도식화한 그림입니다.

 

 

일반적으로, 구성 정보는 구조가 단순하며, 조회는 자주 있지만 변경은 자주 없는것이 특징입니다.

 

때문에, 구성 정보를 저장하기 위해 별도의 데이터베이스를 이용하는것은 오버스펙이 될 수 있습니다.

 

스프링 클라우드에서는 이를 위해 컨피그 서버라는 것을 제공하고 있습니다.

 

 

3) 서비스 등록 및 디스커버리

 

마이크로서비스는 위치 투명성을 가져야 합니다.

 

위치 투명성을 제공하기 위해서는 서비스 인스턴스들을 관리하고 자유롭게 추가 삭제가 되어야 합니다.

 

아래는 이러한 서비스 등록과 관리를 하는것을 도식화한 그림입니다.

 

 

그림에서 보는것과 같이 서비스 디스커버리 에이전트는 각 서비스 인스턴스들을 관리하며,

서비스 인스턴스는 시작 시 이 에이전트에게 자신을 등록시킵니다.

 

서비스 디스커버리는 URL 을 통해 서비스 인스턴스들의 그룹을 만들며, 클라이언트는 이 URL을 통해 서비스를 제공받을 수 있습니다.

 

 

4) 서비스 모니터링

 

서비스 인스턴스 중에 장애가 있는 것들이 있고, 클라이언트는 그로인해 응답을 받지 못할 수 있습니다.

때문에, 서비스 디스커버리는 각 서비스 인스턴스들을 모니터링 해야합니다.

 

아래는 서비스 모니터링을 도식화한 그림입니다.

 

 

그림에서 보는것처럼 서비스 디스커버리는 장애가 난 서비스 인스턴스를 자신의 라우팅 테이블에서 제거하여

클라이언트의 요청이 해당 인스턴스에 가지 않도록 합니다.

 

이러한 상태 관리 모니터링은 스프링에서 제공하는 스프링 액추에이터를 사용할 수 있습니다.

 

스프링 액추에이터는 기본적으로 /actuator URL 엔드포인트를 통해 상태를 확인 할 수 있습니다.

 

아래는 /actuator/health URL을 통해 위 4번 예제의 상태를 확인한 그림입니다.

 

 

6. 마무리

이번 포스팅에서는 스프링 부트로 마이크로서비스 구축에 대해 알아보았습니다.

다음에는 스프링 클라우드 컨피그 서버로 구성 관리에 대해 포스팅하겠습니다.