스프링 부트로

마이크로서비스 구축

박영준

Spring Microservices in Action

Chapter 2

핵심 내용

  • 마이크로서비스의 주요 특징
  • 마이크로서비스를 클라우드 아키텍처에 적용하는 방법
  • 비즈니스 영역(domain)을 마이크로서비스로 분해
  • 스프링 부트로 간단한 마이크로서비스 구현
  • 마이크로서비스 기반 애플리케이션 구축에 대한 관점

  • 마이크로서비스를 사용하면 안되는 상황

소프트웨어 개발이란...

개발 팀이 당면한 문제를 제대로 이해하기 까지

고객과 소통하고 고객에게 배우며 전달하는 활동을 반복하는 진화 과정

전통적인 폭포수 개발 방법 적용의 어려움

  • 강한 결합(tightly coupled) : 비즈니스 로직 호출이 프로그래밍 언어 수준에서 이루어짐. 코드를 조금만 수정해도 다른 부분을 깨트리거나 새로운 버그를 생산할 가능성이 높음
  • 누설(leaky) : 다른 영역의 데이터에 쉽게 접근하면 보이지 않는 의존성이 생김. DB 테이블 하나만 변경해도 엄청난 코드 수정과 회귀 테스트가 필요할 수 있음
  • 모놀리식(monolithic) : 애플리케이션 코드를 조금만 변경해도 컴파일, 빌드, 배포에 많은 비용과 시간이 소요된다. 변경 사항이 많으면 제 시간에 하기는 거의 불가능하다.

마이크로서비스 아키텍처의 특징

  • 제한(constrained) : 마이크로서비스는 하나의 책임 집합을 가지며 범위가 좁다.
  • 느슨한 결합(loosely coupled) : 마이크로서비스는 작은 서비스들의 집합이며 HTTP와 REST처럼 구현 기술에 중립적인 인터페이스로 서로 소통한다.
  • 추상화(abstract) : 마이크로서비스는 자신의 데이터 구조 및 소스를 완전히 소유한다. 서비스가 소유한 데이터는 해당 서비스를 통해서만 접근할 수 있다.
  • 독립적(independent) : 마이크로서비스는 서로 독립적으로 컴파일하고 배포할 수 있다. 변경사항을 쉽게 분리하고 테스트 할 수 있다.

클라우드 기반 애플리케이션의 특징

  • 대규모 사용자층 : 사용자마다 서로 다른 기능을 신속하게 제공받길 원한다. MSA를 이용하면 다양한 사용자의 요구를 신속하게 제공할 수 있다.
  • 상당한 작동 시간(uptime)이 요구됨: MSA의 분산적인 특성 때문에 전체 애플리케이션을 중단하지 않고도 장애를 더 쉽게 격리할 수 있다. 이로인해 uptime이 올라간다.
  • 볼륨이 균일하지 않음 : 일정한 사용 패턴이 없다. MSA는 독립적으로 배포 가능한 컴포넌트로 분리되어있기 때문에 부하에 따라 서버를 수평 확장하기 쉽다.

(MSA가 클라우드에 적합한 이유)

MSA를 보는 3가지 관점

  • 아키텍트 : 큰 그림을 바라보고 애플리케이션을 개별 서비스로 분해하는 방법과 마이크로서비스의 상호 작용 방법을 이해해야 한다.
  • 소프트웨어 개발자 : 마이크로서비스를 제공하기 위해 프로그래밍 언어와 해당 언어용 개발 프레임워크의 사용 방법을 자세히 이해해야 한다.
  • 데브옵스 엔지니어 : 운영 환경 및 비운영 환경에서 서비스 배포와 관리 방법 정보를 제공한다. 모든 환경에서 일관성과 반복성을 제공해야 한다.

Index

2.1 마이크로서비스 아키텍처 설계 (아키텍트)

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

2.3 스프링 부트와 자바로 마이크로서비스 생성 (개발자)

2.4 혹독한 런타임 구축 (데브옵스)

2.5 모든 관점에서

2.1 마이크로서비스 아키텍처 설계

아키텍트 관점

마이크로서비스를 구축하는 아키텍트의 역할

1. 비즈니스 문제의 분해

2. 서비스 세분화의 확정

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

비즈니스 문제의 분해

  • 아키텍트는 비즈니스 문제를 각 활동 영역을 대표하는 덩이들로 분해한다.

  • 비즈니스 규칙과 데이터 로직을 이 덩이들 안에 캡슐화 한다.

  • 데이터 영역이 서로 어울리지 않는다면 마이크로서비스들의 서비스 경계를 나눈다.

마이크로서비스 분해를 위한 지침

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

2. 동사에 주목하라

3. 데이터 응집성을 찾아라

  • 계약, 라이선스, 자산 등등..
  • 조회하다, 업데이트하다 등등..
  • 서로 연관성이 높은 데이터 부분들을 찾는다.
  • 마이크로서비스는 자기 데이터를 완전히 소유해야 한다.

EagleEye 애플리케이션 예제

  • 전통적인 모놀리식 웹 애플리케이션
  • 사용자와 인터뷰하여 업무를 이해한다.

EagleEye 애플리케이션 예제

조직

라이선스

계약

자산

단순화된 EagleEye 데이터 모델

서비스 세분화 확정

  • 독립적으로 빌드하고 배포할 수 있는 자체 완비형 유닛을 추출한다.
  • 관련된 애플리케이션 코드와 데이터 모델을 한곳에 묶어 개별 조각으로 나눈다.
  • 적정 수준으로 잘게 나뉘었는지 확신하는데 어려움이 있을 수 있다.

서비스를 올바르게 세분화 하기

1. 큰 마이크로서비스에서 시작해 작게 리팩토링하는 것이 더 낫다.

2. 서비스간 교류하는 방식에 먼저 집중한다.

3. 문제 영역에 대한 이해가 깊어짐에 따라 서비스의 책임도 계속 변한다.

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

1. REST 철학을 수용하라

2. URI를 사용해 의도를 전달하라

3. 요청과 응답에 JSON을 사용하라

4. HTTP 상태 코드로 결과를 전달하라

  • 서비스 호출 프로토콜로 HTTP 사용하기
  • 표준 HTTP 메서드 (GET, PUT, POST, DELETE)를 사용하기
  • URI는 문제 영역에 존재하는 다양한 자원을 기술하고 관계에 대한 기본 매커니즘을 제공해야 한다.
  • JSON은 초경량 데이터 직렬화 프로토콜이며 XML보다 사용하기 쉽다.
  • HTTP 표준 응답 코드를 사용하여 모든 서비스에 일관되게 사용해야 한다.

2.2 마이크로서비스를 사용하지

않아야 할 때

분산 시스템 구축의 복잡성

  • 마이크로서비스는 분산되어 있기 때문에 모놀리식에는 없는 복잡성이 있다.

 

  • 마이크로서비스 아키텍처는 높은 수준의 운영 성숙도가 필요하다.

 

  • 고도로 분산된 시스템의 자동화와 운영 작업에 투자할 의사가 없는 조직이라면 마이크로서비스를 고려하지 않는 것이 좋다.

서버 스프롤(server sprawl)

  • 마이크로서비스의 일반적인 배포 모델은 한 서버에 한 인스턴스

  • 대규모 마이크로서비스의 경우50 ~ 100개의 인스턴스가 필요할 수 있다.

  • 마이크로서비스를 도입 했을때의 이득보다 수 많은 서버를 관리하고 모니터링하는 비용으로 인한 손실이 더 많지는 않은지 따져보아야 한다.

애플리케이션 유형

  • 소형 애플리케이션이나 소수 자용자를 위한 애플리케이션을 마이크로서비스와 같은 분산 모델로 구축한다면 구축에 따른 복잡성이 얻게될 가치보다 더 클 수 있다.

데이터 변환과 일관성

  • 애플리케이션이 여러 데이터 소스에서 복잡한 데이터를 취합하고 변환해야할 경우 마이크로서비스의 분산된 특성 때문에 작업이 어려워진다.

  • 마이크로서비스 사이에는 트랜잭션을 처리하는 표준이 없다. 필요하다면 직접 만들어야 한다.

  • 마이크로서스는 메시지를 사용해 서로 통신하기 때문에 데이터 업데이트시 지연시간(latency)이 발생할 수 있다.

2.3 스프링 부트와 자바로

마이크로서비스 생성

개발자 관점

REST의 이해

  • 서비스 호출 프로토콜로 HTTP 사용

  • 서비스 행동 양식을 HTTP 표준 동사에 매핑

    • POST, GET, PUT, DELETE >>> CRUD

  • 데이터 직렬화 포멧으로 JSON 사용

  • HTTP 상태 코드를 사용해 호출 상태 전달

2.4 혹독한 런타임 구축

데브옵스 관점

마이크로서비스 런타임 구축을 위한 4가지 원칙

  • 자체 완비형이며 독립적으로 배포 가능해야 한다.

  • 구성 가능해야 한다.(configurable)

  • 클라이언트가 위치를 알지 못하도록 투명해야 한다.

  • 자기 자신의 상태(health)를 전달해야 한다.

마이크로서비스 라이프 사이클

  • 서비스 어셈블리 : 서비스 패키징과 배포

  • 서비스 부트스트래핑 : 환경별 구성정보를 읽어 서비스 시작

  • 서비스 등록 & 디스커버리 : 서비스를 디스커버리 에이전트에 등록

  • 서비스 모니터링 : 인스턴스 모니터링 및 비정상 인스턴스 제거

12요소 애플리케이션

  • Heroku가 제시한 12 요소 애플리케이션 방법론

  • 클라우드 환경에서 운영 가능한 가장 현대적인 애플리케이션에서 기대할 수 있는 특징을 기술한 방법론

서비스 어셈블리 : 서비스 패키징 및 배포

  • 여러 인스턴스를 신속하게 배포할 수 있어야 한다.

  • 필요한 의존성을 모두 담아 단일 산출물로 패키징하고 설치될 수 있어야 한다.

  • 내장형 런타임 엔진을 포함한 단일 산출물로 배포해야 한다.

서비스 부트스트래핑 : 구성 관리

  • 서비스가 처음 가동할 때 중앙 저장소에서 구성 정보를 로드

  • 구성 정보는 단순한 키-값 이기 때문에 RDB를 사용하는 것은 과도하다.

서비스 등록과 디스커버리

  • 클라우드 환경에서 서버는 일시적

  • 클라우드 기반 서비스는 완전히 새로운 IP를 할당받아 신속히 시작되고 제거될 수 있다.

  • 마이크로서비스 인스턴스는 제3자 에이전트에 스스로 등록해야 한다.

  • 상태 확인을 하는데 필요한 URL을 등록하기도 한다.

  • 클라이언트는 디스커버리 에이전트와 통신해 서비스의 위치를 찾는다.

마이크로 서비스 상태 전달

  • 서비스 디스커버리 에이전트는 등록된 각 상태를 모니터링

  • 고장난 서비스는 호출되지 않도록 라우팅 테이블에서 문제가 된 서비스 인스턴스를 제거

  • 스프링 부트를 사용하면 actuator 모듈을 추가하여 헬스 체크 URL을 쉽게 구축할 수 있다.

2.5 모든 관점에서

역할 관점별 핵심

  • 비즈니스 문제의 실제 윤곽 잡기

  • 큰 서비스에서 작은 서비스로 리팩토링 하는게 낫다는 것을 기억하기

아키텍트

소프트웨어 엔지니어

데브옵스 엔지니어

  • 개별 책임을 갖는 계층적 서비스를 구축하는데 집중하기

  • 완전히 독립적인 마이크로서비스를 지향하기

  • 서비스의 라이프 사이클을 일찍 수립하기

  • 빌드와 배포 자동화하기

  • 서비스 상태를 모니터링하고 문제 발생시 대응하는 방법에도 집중하기

Summary

Summary

  • 아키텍트, 개발자, 데브옵스 관점을 통합해야 한다.
  • 마이크로서비스도 장단점이 있다. 모든 서비스가 마이크로서비스일 필요는 없다.
  • 마이크로서비스는 작고, 자체 완비형이고 분산된 것이다.
  • REST 설계 방식과 JSON을 사용해 마이크로서비스를 구축한다.
  • 마이크로서비스의 패키징, 배포, 모니터링은 중요하다.
Made with Slides.com