1. Spring Microservice 개요

1. 모놀리식아키텍처(monolithic) vs 마이크로서비스(microservice)

• 모놀리식아키텍처(monolithic)
  • UI, 비즈니스 로직, 데이터베이스 엑세스 로직 모두가 하나의 산출물로 패키징됨.
  • 작은 변경에도 애플리케이션 전체를 다시 빌드, 테스트 및 배포해야함.
    애플리케이션이 커질 수록 비용 증가.
• 마이크로서비스(microservice)
  • 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해, 조합해서 솔루션을 제공.
  • 각 팀마다 코드와 인프라스트럭처(앱 서버 및 데이터베이스)가 독립적. 독립적 빌드, 테스트, 배포 가능.
  • 데이터 교환을 위해 HTTP, JSON 같은 경량 통신 프로토콜 사용.
  • 다양한 언어와 기술로 애플리케이션 구축 가능

2. 스프링 부트 및 스프링 클라우드

• 스프링 부트 
  • 스프링의 핵심 기능을 수용하지만 많은 엔터프라이즈 기능 제거하고 대신 자바 기반의 REST 지향 마이크로서비스 프레임워크 제공
  • REST 마이크로서비스 빠르게 구축
• 스프링 클라우드
  • 사설 및 공용 클라우드에 마이크로서비스를 쉽게 운영하고 배포할 수 있는 기술

 

3. 마이크로서비스 필요성

• 애플리케이션 복잡성 증가
• 고객은 제품의 빠른 출시를 원함
• 트랜잭션 양과 유입 시점 예측이 어려움. 신속한 확장 및 축소 필요
• 고객은 애플리케이션을 항상 사용할 수 있길 기대함 (회복성)

 

4. 마이크로서비스 특징

• 유연성(flexible)
  • 새로운 기능을 신속하게 제공하도록 분리된 서비스를 구성하고 재배치 가능.
• 회복성(resilient)
  • 실패는 애플리케이션의 작은 부분에 국한되어 애플리케이션 전체 장애로 확대되기 전에 억제됨
• 확장성(scalable)
  • 분리된 서비스를 여러 서버에 수평적으로 쉽게 분산할 수 있어 기능 및 서비스를 적절히 확장할 수 있음

 

5. 클라우드 기반 마이크로서비스

• 간소화된 인프라스트럭처 관리
• 엄청난 수평 확장성
• 지리적 분산을 이용한 높은 중복성

 

6. 견고한 마이크로서비스 작성을 위한 주제

• 적정 크기
• 위치 투명성
• 회복성
• 반복성
• 확장성

 

7. 위 주제에 대한 패턴 기반 접근 방법

• 핵심 개발 패턴
  • 서비스 세분성 : 적정 수준의 책임을 갖게 하는 방법
  • 통신 프로토콜 : 데이터 교환을 위해 어떤 프로토콜 사용? (JSON)
  • 인터페이스 설계 : 서비스 호출에 사용하는 인터페이스 설계
  • 서비스 간 이벤트 프로세싱 : 하드 코딩된 의존성 최소화하고 회복성을 높이기 위해 마이크로서비스를 분리하는 방법
• 라우팅 패턴
  • 서비스의 물리적 IP 주소를 추상화하고 서비스 호출에 대한 단일 진입점 제공
  • 모든 서비스 호출에 대한 일관된 보안과 콘텐츠 정책 보장
  • 서비스 디스커버리
    • 서비스의 물리적 위치를 추상화
    • 인스턴스 추가 및 제거
  • 서비스 라우팅
    • 보안정책과 라우팅 규칙을 차별없이 적용하기 위한 단일 진입점 제공
• 회복성 패턴
  • 클라이언트 측 부하 분산 (client-side load balancing)
    • 서비스 디스커버리에서 검색한 마이크로서비스 엔드포인트를 캐시
  • 회로 차단기 (circuit breakers pattern)
    • 서비스 클라이언트가 실패한 서비스를 반복적으로 호출하지 않게 함
  • 폴백 패턴 (fallback pattern)
    • 클라이언트가 호출 실패 시 대체 경로
  • 벌크헤드 패턴(bulkhead pattern)
    • 오작동하는 서비스 구분
• 보안 패턴
  • 인증(authentication)
  • 인가(authorization)
  • 자격 증명 관리(credential management)와 전파(propagation)
• 로깅 및 추적 패턴
  • 마이크로서비스의 단점 : 디버깅과 추적이 훨씬 더 어려움
  • 로그 상관관계 (log correlation)
    • 단일 트랜잭션과 연관된 로그 항목을 연결
  • 로그 수집 (log aggregation)
  • 마이크로서비스 추적 (microservice tracing)
    • 클라이언트 트랜잭션 흐름을 시각화
• 빌드 및 배포 패턴
  • 마이크로서비스의 각 인스턴스가 모두 동일해야함
  • 인프라스트럭처 구성을 빌드 배포 프로세스에 통합
  • 목표는 스테이지 또는 운영 환경처럼 상위 환경에 도달하기 전에 최대한 빨리 구성 편차를 과감하게 노출하고 근절하는 것
  • 빌드 및 배포 파이프라인
    • 원클릭 빌드와 배포를 강조하는 반복 가능한 빌드 및 배포 프로세스
  • 코드형 인프라스트럭처 (infrastructure as code)
    • 실행하고 관리할 수 있는 코드로 서비스 프로비저닝을 처리
  • 불변 서버 (immutable servers)
    • 이미지가 생성되어 배포되는 순간 개발자나 시스템 관리자가 서버를 수정할 수 없음
  • 피닉스 서버 (phoenix servers)
    • 지속적 통합 프로세스 일부로, 실제 서버는 지속적으로 파괴되므로 새로운 서버들은 시작되고 파괴됨

 

8. 스프링 클라우드

• 스프링 부트
  • 마이크로서비스 구현에 필요한 핵심 기술
  • 주요 작업을 단순화
• 스프링 클라우드 컨피그
  • 애플리케이션 구성 데이터 관리를 중앙 집중식 서비스로 담당하고 애플리케이션 데이터를 마이크로서비스와 완전히 분리
• 서비스 디스커버리
  • 서비스를 사용하는 클라이언트에 서버가 배포된 물리적 위치(IP 주소나 서버 이름)를 추상화
  • 서비스 소비자는 물리적 위치보다 논리적 이름을 사용해 서버의 비즈니스 로직을 호출함
  • 서비스 인스턴스가 시작하고 종료할 때 등록과 말소 처리
• 넥플릭스 히스트릭스와 리본 (Hystrix, Ribbon)
  • 넥플릭스 히스트릭스 라이브러리를 사용하면 회로 차단기 (circuit breaker)와 벌크헤드 (bulkhead) 같은 서비스 클라이언트 회복성 패턴을 신속 구현 가능
  • 넥플릭스 리본 프로젝트는 유레카 같은 서비스 디스커버리 에이전트를 단순하게 통합할 뿐 아니라 서비스 소비자가 서비스 호출에 대한 클라이언트 측 부하 분산 기능도 제공
• 넷플릭스 주울 (Zuul)
  • 서비스 라우팅 기능 제공
  • 서비스 요청을 대리(proxy)해서 마이크로서비스에 대한 모든 호출이 한곳을 통해 대상 서비스에 도달하게하는 서비스 게이트웨이
  • 보안 인가 및 인증, 콘텐츠 필터링, 라우팅 규칙 등 표준 서비스 정책 시행 가능
• 스프링 클라우드 스트림 (Spring Cloud Stream)
  • 경량 메시지 프로세싱을 쉽게 통합
• 스프링 클라우드 슬루스 (Spring Cloud Sleuth)
  • 애플리케이션 안에서 사용되는 HTTP 호출과 메시지 채널 (RabbitMQ, Kafka)에 고유 추적 식별자를 통합할 수 있음
  • 여러 서비스를 순회하는 트랜잭션을 추적. 추적 ID는 마이크로서비스에서 생성하는 모든 로그에 자동으로 추가됨.
• 스프링 클라우드 시큐리티(Spring Cloud Security)
  • 인증 및 인가 프레임워크
  • 토큰 기반, JWT 지원
• 프로비저닝 (Provisioning)
  • '빌드와 배포' 파이프라인 구현
  • 빌드 도구용 Travis CI와 최종 서버 이미지를 만들기 위한 도커를 사용
  • 빌드한 도커 컨테이너들을 배포하기 위해 아마존 클라우드에 배포