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

성공적인 마이크로 서비스 개발을 위한 세가지 역할

1. 아키텍트
2. 소프트웨어 개발자
3. 데브옵스 엔지니어

 

1. 아키텍트 역할 : 마이크로서비스 아키텍처 설계

• 비즈니스 문제의 분해
  • 비즈니스 문제를 각 활동 영역을 대표하는 덩이들로 분해
  • 비즈니스 문제 기술 후 주요 명사를 물리적 데이터 모델의 테이블로 매핑
    예)조직, 라이선스, 계약, 자산
• 서비스 세분화의 확정
  • 단순화한 데이터 모델을 근거로 서로 독립적 빌드 배포 가능한 자체 완비형 유닛을 추출
  • 데이터베이스 테이블을 서비스에 따라 정리하고 각 서비스가 특정 도메인의 테이블만 액세스할 수 있어야 함
• 서비스 인터페이스
  • 애플리케이션의 마이크로서비스가 대화하는 방식을 정의
  • REST, URL, JSON, HTTP 상태 코드

2. 개발자 역할 : 스프링 부트와 자바로 마이크로서비스 생성

• 기본 골격 프로젝트로 생성
  • 기본 디렉터리 구조 생성
  • pom.xml 작성
• Bootstrap 클래스 작성
  • @SpringBootApplication 클래스 작성
• 스프링 부트 컨트롤러 작성
  • 서비스의 엔드포인트를 노출하고 유입되는 HTTP 요청 데이터를 이 요청을 처리할 자바 메서드와 매핑

 

3. 데브옵스 역할 : 양산(실운영) 이후의 서비스 관리에 관한 설계

• 데브옵스 네가지 원칙
  • 자체 완비형(self-contained)이며 독립적으로 배포 가능(independency deployable)
  • 구성 가능(configurable)
  • 투명해야함(transparent)
  • 상태(health) 전달
• 네 가지 원칙은 다음 운영상의 수명 주기 단계로 대응됨
  • 서비스 어셈블리 (service assembly)
    • 일관된 구축, 패키징 및 배포하는 과정
    • 여러 인스턴스를 신속하게 배포하기 위해 필요한 의존성을 모두 담은 단일 산출물로 패키징 후 배포
    • 내장형 런타임 엔진을 포함한 단일 산출물로 배포하여 구성 편차 문제를 상당 부분 제거 가능
  • 서비스 부트스트래핑 (service bootstrapping)
    • 마이크로서비스가 처음 가동할 때 시작하며 애플리케이션 구성 정보를 로드
    • 서비스 외부 데이터 저장소에 구성 정보 데이터를 저장
    • 단순한 키-값 데이터 저장소를 사용
  • 서비스 등록 및 디스커버리 (service registration/discovery)
    • 소비자 관점에서 마이크로서비스는 위치 투명성을 가져야 함.
      클라우드 기반 환경에서 서버는 일시적(ephemeral)이기 때문.
    • 마이크로서비스 인스턴스는 제3자 에이전트에 스스로 등록해야 함.
      이 과정을 서비스 디스커버리라고 한다.
    • 인스턴스의 물리적인 IP 주소 또는 도메인 주소와 애플리케이션이 서비스 검색에 사용할 논리적인 서비스 이름, 이 두 가지 정보를 에이전트에 전달
    • 서비스 클라이언트는 디스커버리 에이전트와 통신해 서비스 위치를 찾을 수 있음
  • 서비스 모니터링 (service monitoring)
    • 서비스 디스커버리 에이전트는 등록된 각 서비스 상태를 모니터링
    • 해당 서비스가 가용한지 확인하기 위해 상태 확인 인터페이스(health check interface)를 계속 모니터링하고 핑(ping) 날림
    • 문제있는 인스턴스를 발견하면 정지시키거나 새로운 서비스를 추가하는 등 조치 취함
    • 상태 확인 인터페이스를 만드는 가장 단순한 방법은 JSON 페이로드와 HTTP 상태코드를 반환하는 HTTP 엔드포인트를 노출하는 것
    • 스프링부트의 스프링 액추에이터(Spring Actuator) 모듈은 이러한 엔드포인트 제공

 

 

※ 마이크로서비스를 사용하지 않아야 하는 경우

• 분산 시스템은 복잡성이 높음.
  따라서 높은 운영 성숙도를 갖출 투자가 되어있지 않다면 마이크로서비스를 고려하지 말것.
• 마이크로서비스 기반 애플리케이션은 구축 및 관리가 필요한 서버나 컨테이너가 50~100개 있을 수 있음.
  따라서 클라우드에서 이들 서비스를 실행하는 데 드는 비용은 저렴하더라도 서버를 관리하고 모니터링하는 운영 작업은 엄청나게 복잡해질 수 있음.
  
• 소형 애플리케이션이나 소수 사용자를 위한 애플리케이션 개발 시 마이크로서비스와 같은 분산 모델로 구축한다면, 얻게될 가치보다 구축에 따른 복잡성이 더 클 수 있음.
• 여러 데이터 소스에서 복잡한 데이터를 취합하고 변환해야 할 경우 마이크로서비스의 분산적 특성 때문에 작업이 어려워짐.
• 마이크로서비스 사이에 트랜잭션을 처리하는 표준이 없어, 트랜잭션 관리가 필요하다면 직접 만들어야 함.