Microservice와 SpringColud

Cloud Native Architecture란

• 확장 가능한 아키텍쳐
  • 수평적 확장에 유연
  • 확장된 서버로 시스템의 부하 분산
  • 서비스 단위의 패키지 (=컨테이너 기반)
  • 서비스 단위로 모니터링 가능
• 탄력적 아키텍쳐
  • CI/CD를 통해 서비스 생성-통합-배포의 자동화롴 비지니스 환경 변화에 대한 대응 시간 단축
  • 작게 분리되어진 분할된 서비스 구조(= 각각의 서비스는 서로의 영향력을 최소화 해야함)
  • 각각의 통신에 대해 서비스는 무상태를 유지
  • 각각의 서비스 관리를 자동화
• 장애 격리
  • 특정 서비스에 오류가 발생해도 다른 서비스에는 영향을 주지 않음

Cloud Native Application

Cloud Native Architecture에 의해 설계된 프로그램을 의미하며 구현 형태가 존재한다.

1. Microservice로 구현
   • 서비스들이 작은 단위로 구성되어진다.
2. 자동화된 CI/CD
   • CI(Continuous Integration 지속적인 통합)
     • 통합 서버, 소스 관리, 빌드, 테스트
     • Jenkins, Team CI, Travis CI
   • CD(Continuous Delivery, Continuous Deployment 지속적인 전달, 배포)
   • 자동화된 빌드,테스트,배포
3. DevOps
   • 시스템의 서버가 켜져있는 동안 2번의 과정을 무한 반복해준다.
4. Container
   • Cloud환경에 배포하며 컨테이너 가상화 기술(Dokcer)을 사용한다.

12 Factors

cloud native application을 구축함에 있어 고려해야할 12가지 항목
Heroku사에서 자신들의 Cloud 서비스 제공 경험을 바탕으로 cloud native application을 설계할 때 고려해야할 사항을 제시했다.

1. Code Base
   • application은 1개의 코드 베이스(=git)를 통해 운영되고 개발되어야 한다.
2. Dependency
   • 각 서비스들은 전체 시스템에 영향을 주지 않는 상태로 변경되어질 수 있어야한다.
3. Configuration
   • 코드 외부에서 설정 정보를 제어한다.
   • 각 서비스들은 설정정보를 공유할 수 있어야한다.
4. Linkable Backing Service
   • 백엔드 서비스는 자유롭게 사용하거나 분리할 수 있고 코드의 수정없이 변경될 수 있어야 한다.
     • 백엔드 서비스 : DB, Cache, SMTP 등
5. Stages of Creation(Build, Release, Run)
   • 각각의 서비스는 빌드, 배포, 실행을 모두 분리해야한다.
6. Stateless Processes
   • 각각의 서비스는 서로의 프로세스에 상태를 공유하지 않아야한다.
7. Port Binding
   • 각각의 서비스는 바인딩된 포트로 다른 application에서도 접근할 수 있도록 서비스를 제공한다.
8. Concurrency
   • 서비스는 수평으로 확장할 수 있어야하고 기능별로 분리된 서비스들은 동시에 실행될 수 있어야한다.
9. Disposability (일회성)
   • 서비스는 쉽게 삭제되며 또한 쉽게 추가될 수 있어야한다.
   • 서비스 상황에 따라 쉽게 Scale up/down이 가능해야한다.
10. Development & Production Parity
    • 개발환경과 실제 서비스 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 디자인되어야 한다.
11. Logs
    • 로그는 로컬에 저장하지 않는다.
    • 대신 별도의 로그 저장소를 사용하거나 모니터링 프로그램을 사용하여 관리한다.
12. Admin Processes For Eventual Processes
    • 현재 운영되고 있는 서비스들을 관리하기 위한 관리 도구가 있어야한다.

최근 추가된 3가지

Pivotal사에서 Cloud 서비스를 운영하면서 제시한 총 15가지 항목이며 기존 12 Factors에 3가지를 추가했다.

1. API first
   • api를 구축함에 있어서 사용자측에서 어떤 형태로 사용할 것인지를 먼저 고려해야한다.
2. Telemetry
   • 모든 지표는 시각화하여 우리가 관리할 수 있어야한다.
3. Authentication and authorization
   • api를 사용함에 있어서 인증 작업은 필수다.

어플리케이션 개발 방법론

1. Monolith
   • 모든 업무 로직이 하나의 application 형태로 패키지 되어 있는 개발 방법
   • 대부분 이전의 프로젝트들의 구성 상태
2. Microservice Architeecture
   • Sam Newman는 Small autonomous services that work together라 정의했다.
   • http 통신을 이용하여 작은 규모의 여러 서비스들의 묶음
   • 여러 서비스들의 묶음이 모여 하나의 어플리케이션을 구성하는 방법
   • 비지니스를 위주로 구성되어야 하고 완전한 자동화된 배포와 테스트로 구성되어야 한다.
   • MSA를 제안한 Martin Fowler는 각각의 서비스는 각자 다른 프로그래밍 언어와 각자 다른 데이터 베이스를 사용할 수 있어야한다.라고 정의

Microservice 란

• 특징

  1. 기존의 설계 방식과는 다른 설계 방식이 적용되어진다.
  2. 작은 단위의 서비스들로 구성되어 진다.
  3. 각각의 서비스들은 서로 결합될수도 분리되어질 수도 있다.
  4. 서로 상태에 대해 Restful API로 통신한다.
  5. 환경에 대한 설정 정보는 코드내에 가지지 않고 외부 시스템에서 관리한다.
  6. Cloud 시스템을 활용하여 시스템을 구성한다.
  7. 부하 분산에 대한 처리와 시스템의 Scale up/down을 동적으로 처리할 수 있어야한다.
  8. 배포, 테스트는 자동화 되어야한다.
  9. 모든 서비스는 시각화되어 모니터링할 수 있어야한다.

• 그렇다면 모든 서비스를 Microservice로 변경하는 것이 좋을것인가에 대한 고려사항

  1. 기존 개발 환경에서 변경되어지는데 어느정도의 비용이 사용될 것인가
  2. 현재 운용 중인 어플리케이션의 각각의 서비스들의 독립성을 갖고 있는가
  3. 각각의 서비스가 유지보수가 용이하게 작성된 프로그램인가
  4. 서비스의 오류사항이 각각의 서비스에 최소한의 영향을 주고 있는 프로그램인가
  5. 외부 종속성이 없는 프로그램인가
  6. 여러가지 프로그램 언어를 사용할 수 있도록 설계된 프로그램인가

SOA와 MSA의 차이점

• 공통점
  MSA와 SOA(Service Oriented Architecture=서비스 지향 아키텍쳐)는 서비스를 지향한다는 점에서는 같다.

• 차이점

  • SOA : 서비스 재사용을 통한 비용의 절감을 주 목적
  • MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하는 것을 주 목적

Microservice Architecture 표준 구성요소

MSA는 Gartner에서 발표한 넷플릭스, 트위터, 나이키 등의 회사에서 선택한 아키텍쳐의 형태를 시각화한 그림이다.

각 회사별 아키텍쳐가 다르게 존재할 수도 있고 해당 아키텍쳐를 참고하여 프로젝트 상황에 맞게 변경할 수도 있지만 우선 우리는 해당 그림의 형태로 구성요소에 대해 이해해보려한다.

1. 먼저 맨 앞에 Mobile App, Brower App, Other Services와 같이 여러 client들의 요청을 받을 수 있다.
2. 그 후 API Gateway를 통해 서비스 요청을 받게 된다.
3. Service Router에 요청된 서비스를 찾아 달라고 하게 되고
4. Service Router는 Service Discovery에 등록되어진 Service중 요청된 서비스를 찾아온다.
5. 서비스의 위치를 알게되었으니 Load Balancing을 통해 생성되어진 컨테이너의 인스턴스들 중 요청이 가능한 인스턴스로 요청을 보내게된다.
6. 각 인스턴스에서 설정에 대한 정보는 외부 Config Store에 저장되어진 내용을 가져다 사용한다.
7. 자동화된 CI/CD 시스템을 통해 인스턴스들은 계속해서 배포되고 테스트된다.
8. 각 분리되어진 서비스들의 데이터는 Backing Service를 통해 데이터의 통일성을 가질 수 있고 다른 서비스와도 결합되어질 수 있다.
9. 위 서비스들은 모두 Telemetry를 통해 모니터링되어야 한다.

• Service Mesh란

  Service Mesh라는 것은 MSA를 적용한 시스템의 내부 통신을 말하고 각 서비스들에 대해 프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱 등 여러 기능을 제공해준다.

• CNCF(Cloud Native Computing Foundation)

  MSA를 구성하기 위해서는 다양한 제품들이 존재한다.

  https://landscape.cncf.id

  에 접속하여 클라우드 제품들을 카테고리별로 확인할 수 있고 개발자가 선택하여 application에 적용하여 사용할 수 있다.

Spring Cloud

Spring Cloud는 환경설정, 서비스 검색, 회복성 처리, 라우팅, 프록시 등의 서비스들을 모아놓은 하나의 프레임워크

• 환경설정 : Spring cloud Config Server
• 서비스의 등록과 위치 정보 : Eureka
• 로드 밸런스 : Spring Cloud Gateway(Spring 권장), Ribbon
• 서비스 간의 통신 : FeignClient
• 모니터링 : Zipkin, Netflix API gateway
• 장애복구 : Hystrix

출처 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4