[스프링 마이크로서비스 코딩 공작소] 1. 스프링, 클라우드와 만나다

1-1. 마이크로 서비스란?

• 모놀리식 아키텍처 (monolithic architecture) :
  • 배포 가능한 단 일 소프트웨어 산출물
  • UI 및 비즈니스 로직，데이터베이스 액세스 로직 모두가 하나의 애플리케이션 산출물로 패키징되고 애플리케이션 서버에 배포
• 마이크로서비스 아키텍처 
  • 대형 애플리케이션을 관리하기 쉽고 제한된 책임을 담당하는 컴포넌트로 분해
  • HTTP와 JSON(JavaScript Object Notation) 같은 경량 통신 프로토콜 사용

 

1-2. 스프링이란 무엇이고 마이크로서비스와 어떤 관련이 있을까?

• Java EE의 단점
  • EJB(Enterprise Java Beans) Container 기반의의 Java EE 개발은 제공하는 API를 상속 받아야만 했고 부가적인 코드를 작성해야 하는 등의 불편함스프링은 의존성 주입이라는 핵심 개념에 기반을 둔다.
  • 일반적인 자바 어플리케이션는 각 클래스가 어플리케이션의 다른 클래스와 명시적으로 링크된 클래스로 분해된다. 링크는 코드에서 클래스 생성자를 직접 호출하는 것이다. 이러한 외부링크는 깨지기 쉽고 사이드 이펙트가 크다.
• DI(Dependency Injection, 의존성 주입)과 IoC(Inversion of Control)을 통한 Java EE 단점 극복
  • DI : 객체를 클래스내에서 생성하는 것이 아니라, 주입 받겠다.
  • IoC : 객체의 생명 주기와 관계를 프로그래머가 아닌, 스프링 컨텍스트에게 맡기겠다.
  • 이를 통하여 의존성 약화, 테스트 코드 작성 용이, 객체 재사용성 증가, 가독성 증가의 효과
• 스프링 부트와 스프링 클라우드로의 진화
  • 스프링 개발팀은 많은 개발팀이 모놀리식 애플리케이션에서 이탈하여, 작고 분산되어 클라우드에 쉽게 배포 가능한 분산 모델로 이동
  • 기존 스프링 프레임워크는 복잡한 초기 설정, 높은 러닝 커브(learning curve), 가독성이 떨어지는 xml 기반의 bean 설정, 별도 WAS (ex. tomcat) 설정 등의 많은 단점이 존재
  • 스프링 개발팀은 단점을 보완하기 위하여, 스프링 부트와 스프링 클라우드라는 2 개의 프로젝트를 시작했다.
  • 스프링부트 : 많은 엔터프라이즈 기능을 제거하고, 단순한 어노테이션 기반의 REST MSA 신속 구축
  • 스프링 클라우드 : 사설 및 공용 클라우드에 MSA를 쉽게 운영 및 배포 가능. 역시 단순한 어노테이션 기반으로 이러한 기술을 쉽게 사용하고 배포할 수 있게 만듦.
  • 이 책 전반에 스프링 클라우드 기술이 사용됨

 

1-3 책의 목적

• 마이크로서비스 정의와 마이크로서비스 기반 애플리케이션을 구축할 때 설계 고려 사항
• 마이크로서비스 기반 애플리케이션을 사용하면 안 될 때
• 스프링 부트 프레임워크로 마이크로서비스를 구축하는 방법
• 마이크로 서비스 애플리케이션, 특히 클라우드 기반 애플리케이션을 위해 필수적인 핵심 작
  동 패턴
• 스프링 클라우드를 사용한 작동 패턴의 구현 방법
• 배운 것을 활용해 서비스를 내부에서 관리하는 사설 클라우드나 공용 클라우드 공급자에게
  배포할 수 있는 배포 파이프라인의 구축 방법

1-6 애플리케이션 구축 방식을 바꾸는 이유

• 복잡성이 증가했다 :
  • 내부의 여러 서비스와 데이터 베이스뿐만 아니라 인터넷으로 외부 서비스 제공자와도 통신해야 한다.
    전체 제품 의 릴리스를 기다리지 않고 새로운 기능이 몇 주나 며칠 안에 재빨리 릴리스되길 기대한다.
  • 유연성(flexible) 증진: 새로운 기능을 신속하게 제공하도록 분리된 서비스를 구성하고 재배치할 수 있다. 다른것과 동작하는 코드 단위가 작을수록 코드 변경에 따른 복잡성을 낮추고 코드배포를 테스트하는 시간도 줄어든다.
• 성능 및 확장성:
  • 트랜잭션 양과 유입 될 시점을 매우 예측하기 어렵다. 애플리케이션은 여러 서버로 신속히 확장한 후 확장이 필 요 없다면 다시 축소해야 한다.
  • 분리된 서비스를 여러 서버에 수평적으로 쉽게 분산할 수 있어 기능 및 서비 스를 적절히 확장할 수 있다. 애플리케이션의 모든 로직이 얽혀 있는 모놀리식 애플리케이 션은 한 부분이 병목점이 되더라도 전체를 확장해야 한다. 작은 서비스를 확장하는 것은 국지적이며 비용 효율이 더 높다.
• 회복성(resilient):
  • 실패는 애플리케이션 의 작은 부분에 국한되어 애플리케이션 전체 장애로 확대되기 전에 억제된다. 또 회복 불능 (unrecoverable) 에러가 발생했을 때도 애플리케이션이 원활하게 기능 저하될 수 있다.
• 작고(small) 단순하며(simple) 분리된(decoupled) 서비스
  = 확장 가능하고(scalable) 회복적이며 (resilient) 유연한(flexible) 애플리케이션

 

1-7. 클라우드란 정확히 무엇인가?

• 모든 소프트웨어 공급자가 클라우드를 쓰고 사용자의 플랫폼 모두 클라우드를 지원한다고 하지만，과장 광고를 없애면 클라우드 기반 컴퓨팅에는 다음 세 가지 기본 모델이 존재한다.
  • IaaS(Infrastructure as a Service)
  • PaaS(Platform as a Service)
  • SaaS(Software as a Service)
  • FaaS(Funcion as a Service) : 서버 관리할 필요가 없고 함수를 실행하는 데 필요한 컴퓨팅 작동 시간만큼 지불하면 된다.
  • CaaS(Container as a Service) :  모델에서 개발자는 도커처럼 클라우드 공급자에게 이식이 용이한 가상 컨테이너 로 마이크로서비스를 빌드하고 배포한다.
  • 10장에서 우리가 구축한 마이크로서비스를 아마존 ECS에 배포하는 방법을 살펴볼 것이다. 

• • 왜 클라우드와 마이크로서비스인가?
    
    • 물리적서버 : 용량을빠르게늘릴수없고여 러 물리적 서버로 마이크로서비스를 수평 확장히는 데 상당한 비용이 든다.
    • 가상 머신 이미지 : 실패 이벤트를 받을때 신속하게 마이크로서비스 인스턴스를 시작하고 종료할 수 있다는 것이다.
    • 가상 컨테이너 : 가상 머신안에서 실행되며 같은 가상 머신 이미지를 공유하는 완전 자립형 프로세스로 분리가 가능하다.
    • 간소화된 인프라스트럭처 관리: 간단한 API 호출로 새로운 서비스를 시작하고 정지할 수 있다. IaaS 클라우드 솔루션은 사용한 인프라 비용만 지불하면 된다.
    • 엄청난 수평확장성 : 인스턴스를신속하 고 간결하게 시작할 수 있다. 이 기능을 이용해 서비스를 재빨리 확장하고 오작동하거나 고장난 서버를 우회할 수 있다.
    • 지리적 분산을 이용한 높은 중복성: IaaS 공급자는 필요에 따라 다수의 데이터센터를 보유한다. IaaS 클라우드 공급자가 마이크로서비스를 배포하면 데이터센터의 클러스터보다 더 높은 수준의 중복성을 얻을 수 있다.
  • PaaS기반 마이크로서비스를 사용하지 않는 이유
    • 책에서는 laaS 기반으로 마이 크로서비스를 구축하는 데 중점을 두기로 했다.
    • 아마존과 클라우드 파운드리(Cloud Foundry), 허로쿠(Heroku)에서는 하부 애플리케이션 컨테이너를 알지 못해도 웹 인터페이스와API를 제공해 애플리케이션을 WAR나 JAR 파일로 배포가 가능하다.
    • 반면 laaS 방식에서는 일은 더 많지만 여러 클라우드 공급자에게 이식할 수 있어 유연성이 증대된다.

1.9 마이크로서비스는 코드 작성 이상을 의미

 

• 견고한 서비스를 작성하는 주제들
  • 적정크기 : 과도한 책임을 맡지않도록 서비스가 적절한 크기가 되면 변경에 유연하고, 장애를 줄일 수 있다.
  • 위치 투명성: 인스턴스가 재빨리 시작하고 종료될 때 서비스 호출에 대한 물리적 상세 정보를 관리할 수 있는 방법은 무엇인가?
  • 회복성: 장애가 발생한 서비스를 우회하고 ‘빨리 실패’하는 방법을 사용해 어떻게 무결성을 유지할 것인가?
  • 반복성: 새로운 서비스 인스턴스가 시작할 때마다 운영 환경의 다른 서비스 인스턴스 구성과 코드 베이스를 동일하게 만드는 방법은 무엇인가?
  • 확장성: 비동기 프로세싱과 이벤트를 사용해 서비스간 의존성을 최소화하고 마이크로서비 스를 원만하게 확장할 수 있는 방법은 무엇인가?
  • 이러한 질문에 답하기 위해 6가지 패턴을 다룰 것이다.
    • 핵심 개발 패턴(core development patterns)
    • 라우팅패턴
    • 클라이언트 회복성 패턴
    • 보안패턴
    • 로깅 및 추적 패턴
    • 빌드 및 배포 패턴
•  핵심 개발 패턴 : 
  • 서비스 세분성 : 비즈니스 영역을 분해해서 적정 수준의 책임을 갖게한다. 너무 굵게 나누면 유지보수, 변경이 어렵고 너무 잘게 나누면 어플리케이션의 전반적 복잡석이 증가되고, 아무런 로직도 없는 '멍청한' 추상화 계층으로 전락한다.
  • 통신 프로토콜 : JSON이 가장 이상적인 이유와 일반적으로 선택되는 이유
  • 인터페이스 설계 : 서비스 의도를 전달하도록 서비스 URL을 구조화하는 방법과 버전 관리하는 방법 (2장)
  • 서비스 간 이벤트 프로세싱 : 의존성을 최소화하고 회복성을 높이기 위해 마이크로 서비스를 분리하는 방법(8장)

• 라우팅 패턴(routing patterns) :
  • WAS의 위치를 발견하고 라우팅
  • 서비스 디스커버리 : 서비스 위치를 하드 코딩하지 않고, 탐색 가능하도록하고, 오작동하는 인스턴스를 인스턴스 풀에서 어떻게 제거해야할까? (4장에서 다룬다)
  • 서비스 라우팅 : 보안 정책과 라우팅 규칙을 인스턴스들에게 차별 없이 적용하고, 단일 진입점을 제공하는 방법은 무엇인가? (6장에서 다룬다)

• 클라이언트 회복성 패턴(client resiliency patterns)
  • 클라이언트 측 부하 분산(clieM-side load balancing): 호출이 안스턴스에 분산하도록 서비스 인스턴스의 위치를 캐싱하는 방법은 무엇인가?
  • 회로 차단기 패턴(circuit breakers pattern) :클라이언트가 고장 나거나 성능 문제가 있는 서비스를
    계속 호출하지 않게 하는 방법은 무엇인가?
  • 폴백 패턴(fallback pattern) :서비스 호출이 실패할 때 호출한 마이크로서비스가 아닌 다른 대체 수단을 어떻게 제공할 것인가?
  • 벌크헤드 패턴(bulkhead pattern): 마이크로서비스 애플리케이션은 작업을 수행하기 위해 여러
    분산 자원을 사용한다. 오작동하는 서비스 호출 하나가 나머지 애플리케이션에 부정적인 영 향을 미치지 않도록 이러한 호출을 구분하는 방법은 무엇인가?

• 보안 패턴(security patterns)
  • 인증 : 클라이언트가 자신이라는 것을 어떻게 알 수 있는가?
  • 인가 : 작업을 수행할 자격이 있는가?
  • 자격 증명 관리와 전파 : 한 트랜잭션과 관련된 여러 호출에서 자격 증명을 항상 제시하지 않아도 될 방법은 무엇인가? OAuth와 JWT 토큰 기반 보안 표준을 사용해 토큰을 얻는 방법을 살펴본다.

• 로깅 및 주적 패턴(logging and tracing patterns)
  • 로그 상관관계 : 단일 트랜잭션에 대해 여러 서비스 간 생성된 모든 로그를 연결하는 방법
  • 로그 수집 : 서비스에 생서된 모든 로그의 질으 ㅣ가능한 단일 데이터베이스로 취합하는 방법
  • 마이크로서비스 추적 : 트랜잭션과 연관된 모든 서비스에서 클라이언트 트랜잭션 흐름을 시각화하고 트랜잭션과 관련된 서비스의 성능 특성을 이해하는 방법

 

• 빌드 및 배포 패턴(build and deployment patterns)
  • 빌드 및 배포 파이프라인 : 원클릭 빛드와 반복 가능한 빌드 및 배포 프롯게스
  • 코드형 인프라스트럭처 : 소스 제어를 사용해 관리할 수 있는 코드로 서비스 프로비저닝을 처리하는 방법은 무엇인가?
  • 불변 서버(immutabie servers): 마이크로서비스 이미지를 생성하고 배포한 후 변경하지 못하게 하려면 어떻게 해야 하는가?
  • 피닉스서버(phoenix servers) : 서버가 오래 실행될수록 구성 편차가 발생할 가능성도 높아진다. 마이크로서비스를 실행하는 서버를 정기적으로 해체(종료)하고 불변 이미지를 재생성하려 면 어떻게 해야하는가?

 

1-10. 스프링 클라우드로 마이크로서비스 구축

스프링 클라우드는 이 프로젝트들을 스프링 어플리케이션에서 쉽게 설정하고 구성하게 만들어,코드를 작성하는 데 집중할 수 있게 되었다.

1.10.1 스프링 부트

스프링 부트는 마이크로서비스 구현에 필요한 핵심 기술이다. 스프링 부트로 REST 기반 마이크 로서비스를 구축하는 주요 작업을 단순화해 마이크로서비스를 상당히 쉽게 개발할 수 있다. 

1.10.2 스프링 클라우드 컨피그

스프링 클라우드 컨피그(Corfig)는 중앙 집중식 서비스로 애플리케이션 구성 데이터 관리를 담당 하고 애플리케이션 데이터(특히 환경별 구성 데이터)를 마이크로서비스와 완전히 분리한다. 따라서 마이크로서비스 인스턴스가 아무리 많더라도 항상 동일한 구성을 유지할 수 있다. 스프링 클라 우드 컨피그에는 고유한 관리 저장소가 있지만 다음 오픈 소스 프로젝트와도 통합된다.

• 깃(Git): 깃 기반 저장소 와 통합되어 애플리케이션의 구성 데이터를 저장소에서 읽어 올 수 있다.
• 콘설(Consul): 콘설(https://www,consul.io/)은 서비스 인스턴스를 서비스에 등록할 수 있는 오픈 소스 서비스 디스커버리 도구다. 서비스 클라이언트는 콘설에 서비스 위치를 물어볼 수 있다. 콘설에는 스프링 클라우드 컨피그가 애플리케이션 구성 데이터를 저장하는 데 사 용하는 키-값 저장소 기반 데이터베이스도 있다.
• 유레카(Eureka): 유레카(https://github.com/Netflix/eureka)는 콘설과 유사한 서비스 디스커 버리 기능을 제공하는 넷플릭스의 오픈 소스 프로젝트다. 유례카에도 스프링 클라우드 컨피그와 함께 사용될 수 있는 키-값 데이터베이스가 있다.

1.10.3 스프링 클라우드 서비스 디스커버리

서비스를 사용하는 클라이언트에 서버가 배포된 물리적 위치(IP 주소나서버 이름) 를추상화할수 있다.
서비스소비자는 물리적 위치보다 논리적 이름을 시용해 서버의 비즈니스 로직을 호출한다.
스프링 클라우드의 서비스 디스커버리는 서 비스 인스턴스가 시작하고 종료할 때 등록과 말소를 처리하며, 서비스 디스커버리 엔진의 구현을 위해 콘설과 유레카를 사용할 수 있다.

1.10.4 스프링 클라우드/넷플릭스 히스트릭스와 리본

• 히스트릭스 :  회로 차단기(circuit breaker)와 벌크헤드(bulkhead) 같은 서비스 클라이 언트의 회복성 패턴 구현
• 리본 프로젝트 : 유레카 같은 서비스 디스커버리 에이전트를 단순하게 통합할 뿐만 아 니라 서비스 소비자가 서비스 호출에 대한 클라이언트 측 부하 분산 기능도 제공

• 1.10.5 스프링 클라우드/넷플릭스 주울
  Zuul : 서비스 라우팅 기능을 제공하는 서비스 게이트웨이다. 보안 인가 및 인증, 콘텐츠 필터링, 라우팅 규칙 등 표준 서비스 정책을 시행할 수 있다.
• 1.10.6 스프링 클라우드 스트림 
  애플리케이션에서 발생되는 비동기 이벤트를 사용하는 영리한 마이크로 서비스를 구축 할 수 있고 RabbitMQ, Kafka
• 1.10.7 스프링 클라우드 슬루스
  HTTP호출과 메시지 채널(RabbitMQ, Kafka)에 고유 추적 식별자를 통합 할 수 있다.
  페이퍼트레일(Papertrail)같은 로그 수집용 기술 도구 및 집킨(Zipkin)같은 추적 도구와 결합할 떄 더 큰 빛을 발한다.
  • 페이퍼트레일 : 실시간으로 질의 가능한 데이터베이스로 수집하는 클라우드 기반 로깅 플랫폼이다.
  • 집킨 : 슬루스가 생성한 데이터를 사용해 단일 트랜잭션에 연관된 서비스의 호출 흐름을 시각화 할 수 있다.

1.10.8 스프링 클라우드 시큐리티

• 인증, 인가 프레임워크
• 토큰에 기반을 두며 인증 서버가 발행한 토큰으로 서비스는 서 로 통신한다. 호출받는 서비스 모두 HTTP 호출에서 전달된 토큰을 확인해 사용자 신원과 서비스 접근 권한을 검증한다.
• 스프링 클라우드 시큐리티는 자바스크립트 웹 토큰(JWT) 지원. JWT는 OAuth2 토큰의 생성 방식과 생성된 토큰의 디지털 서명(signing)에 대한표준을 제공한다.

1.10.9 프로비저닝

• 빌드와 배포 파이프라인 구성
• 빌드 : Travis CI
• 도커 : T서버 이미지를 만들기 위함
• 배포 : 아마존 클라우드