Microservice와 Spring Cloud

0. Software Architecture

Antifragile

ㄴ Auto Scaling: 리소스 사용량이나 조건에 따라 인스턴스나 리소스를 자동으로 확장/축소할 수 있는 개념

ㄴ Microservice: 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발하고 배포하고 운영할 수 있도록 세분화된 서비스

ㄴ Chaos engineering: 변동, 예견된 불확실성, 예견되지 않는 불확실성, 카오스 불확실성에서도 안정적인 서비스를 유지

ㄴ Continuous deployments: 지속적인 통합과 배포환경 구성

 

1. Cloud Native Architecture

- 확장 가능 아키텍쳐

ㄴ 시스템 수평적 확장

ㄴ확장된 서버로 시스템의 부하 분산, 가용성 보장

ㄴ 시스템 또는, 서비스 애플리케이션 단위의 패키지 (컨테이너 기반 패키지)

ㄴ 모니터링

 

- 탄력적 아키텍쳐

ㄴ 서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축

ㄴ 분할된 서비스 구조

ㄴ 무상태 통신 프로토콜

ㄴ 서비스의 추가와 삭제 자동으로 감지

ㄴ 변경된 서비스 요청에 따라 사용자 요청 처리 (동적 처리)

 

- 장애 격리

ㄴ 특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않음

 

2. Cloud Native Application

Cloud Native Architecture 에 의해 설계되고 구현되는 Application

CI/CD

ㄴ 지속적 통합, CI(Continuous Integration)

    - 통합 서버, 소스 관리, 빌드 도구, 테스트 도구

    - ex) Jenkins, Team CI, Travis CI

ㄴ 지속적 배포

    - Continuous Delivery

    - Continuous Deployment

    - Pipe line

- 카나리 배포와 블루그린 배포

DevOps

ㄴ 자주 테스트하고, 피드백받고, 업데이트하는 과정을 거쳐 전체 개발일정이 완료될때 까지 지속적으로 끊임없이 진행해 가는 것

ㄴ Cloud Native Application은 데브옵스 환경에 맞춰서 서비스의 구조를 작은 단위로 분할할 수 있게 함으로써 통합, 테스트, 배포를 자주할 수 있는 구조가 될 수 있다.

 

Container 가상화

공통적 라이브러리나 리소스 --> 공유해서 사용

컨테이너 각자 필요한 부분 --> 독립적 영역에 실행

하드웨어 가상화보다 더 적은 리소스, 가볍고 빠른 운영

 

3. 12Factors

Cloud Native Application 을 개발하거나 서비스를 운영할때 고려해야되는 항목을 정리

Cloud 서비스 시에 발생했던 문제점과 개선점, 시행착오들을 바탕으로 가이드라인을 만듬

 

1. 코드 통합

• 형상 관리를 위해 코드를 한 곳에서 배포하는 것이 주 목적

2. 종속성 배제

• 각 Micro Service는 자체 종속성을 가지고 패키징 되어있음, 전체 시스템에 영향을 주지않는 형태에서 변경 되어야 함

3. 환경설정의 외부 관리

• 코드의 외부에서 관리 도구를 통해 Micro Service에 필요한 작업들을 구성할 수 있어야함

4. 백업 서비스의 분리

• 응용프로그램 자체에서 필요한 백업 서비스를 분리하게 됨으로서 서로 상호가능한 서비스 자체를 종속성 없는 상태에서 작업 가능

5. 개발 환경과 테스트 운영 환경의 분리

• 빌드,릴리즈,실행환경을 분리
• 개발 서버에서 만들어진 코드 배포 하기위해 실행단계 까지 옮기는 환경을 엄격하게 관리

6. 상태관리

• 프로세스 각각의 Micro Service들은 실행되는 서비스와 분리된 채, 프로세스에서 운영가능해야 함(독립성과 일치)

7. 포트 바인딩

• 다른 Micro Service와 격리를 위해 각각의 Micro Service는 자체 포트에서 노출되는 인터페이스 및 자체에 포함되는 기능이 있어야 함

8. 동시성

• 하나의 서비스가 여러가지 인스턴스에 동일한 형태로 복사되면서 운영됨으로서 부하 분산이 가능

9. 서비스의 올바른 상태 유지

• 서비스의 인스턴스 자체가 삭제가 가능 하며 확장성을 높이고 정상적으로 종료 될 수 있는 환경이 되어야 함

10. 개발과 production단계 구분

• 환경자체를 최대한 다른 쪽에 있는 작업과 중복되지 않고 종속되지 않는 상태로서 서비스를 유지할 수 있어야

11. Log의 분리

• Log를 출력시키는 Logic은 기존에 있었던 Application Logic과 분리 되어서 Application 자체가 실행되지 않는 상태라 해도 Logging만은 정상적으로 작동해야 함

12. 관리 프로세스

• 현재 운영되고 있는 모든 Micro Service들이 어떤 상태이며 어떤 리소스로 구성되어있는지 파악하기 위해 관리 도구가 필요
• 이러한 작업에는 리포팅할 수 있는 기술이 포함되어 있어야 하고 데이터 정리 및 데이터를 분석하는 기능이 포함될 수 있음

 

4. Monolithic vs Microservice

Monolith Architecture

ㄴ Application을 개발함에 있어 모든 요소들을 하나의 거대한 Software안에서 전부 포함시켜 개발하는 방법

ㄴ 따라서 Application을 구성하는 서비스들 간 의존성을 가짐
이는 즉, 시스템 일부만 수정을 하여도 전체 시스템을 다시 패키징 하고 빌드-테스트-배포 해야하는 과정을 거쳐야함

 

Microservice Architecture

ㄴ Application을 구성하는 구성 요소 및 Service를 분리하여 운영하는 방식

ㄴ 유지보수 및 변경사항이 적용이 쉬워짐
변경이 필요할 때 필요한 부분만 변경하게 되고 다른 Service에 영향을 끼치지 않고 독립적으로 Service 가능

--> Application 자체가 down 되는 현상 방지

ㄴ 각각의 Service들은 최소화된 중앙집중된 관리만 필요하고 서로 다른 언어 및 서로 다른 Database를 사용가능 하기 까지도 함

ㄴ 각각의 Sevice들은 제공해야하는 Service를 restAPI를 통해서 제공 가능 및 다른 Micro Service들과 통신 가능

 

Trend

Application 개발 시 Smart Device도 고려해야 함

Web Browser 뿐 아니라 스마트 워치,스마트 폰,태블릿,노트북과 같은 Device들도 고려 해야 함

--> 사용자가 요청하는 형태로 응답이 가능 해야 한다는 뜻

--> 이를 위해 RestAPI 사용

 

5. Microservice 특징

ㄴ challenges: 개발 방식 및 패러다임을 상당히 바꾸어야 함

ㄴ small Well chosen Deployable Units: 독립적으로 개발 가능한 형태의 작은 서비스

ㄴ Bounded Context: 각각의 서비스들은 어플리케이션을 구성하고 있는 전체 도메인의 지식에 따라 서비스 경계를 잘 구분 해야 경계로 인해 하나의 서비스가 여러개, 여러개가 단일화 될 수 있음

ㄴ Restful: 상태에 대해서 restapi로 통신 json포맷 이용 서버의 리소스 및 상태 표시에 최적화

ㄴ Configuration managment: 마이크로 서비스들이 갖고 있는 설정 및 환경 정보는 코드 내에 갖고 있지 않고 외부에 시스템을 통해 관리

ㄴ Cloud enabled: 클라우드 네이티브 기술을 최대한 활용

ㄴ Dynamic scale up and down

ㄴ CI/CD

ㄴ Visibility: 마이크로서비스 기술들은 시각화 할 수 있는 관리도구 들을 가지고 있어야 함

 

6. 무조건 Microservice Application만 사용해야 하는가

처한 환경 및 기존 Application에서 MSA로 전환 혹은 Application개발 시,생기는 이익에 대하여 생각을 해야 합니다

ㄴ Multiple Rates of Change(다양한 변화율): 변화로 인해 생기는 이익이 어느 정도 이상이 되어야 Micro Service Application으로 전환을 할 것인지 봐야함

ㄴ Independent Life Cycles(독립 라이프 사이클): Application을 구성하고 있는 각각의 서비스들이 독립적으로 개발되고 운영될 수 있도록 서비스 경계가 잘 만들어져 있는가?

ㄴ Independent Scalability(독립적인 확장성): 유지 보수 및 확장성에 대처가 가능한지 확인

ㄴ Isolated Failure(격리된 오류): 오류를 격리시킬 수 있는지 오류가 독립적인지

ㄴ  Simplify Interactions with External Dependencies(외부 종속성과 상호 작용을 단순화): 서비스간의 종속성을 최소화하고 응집력을 높일 수 있도록 서비스 경계가 잘 구분되어 있는 가를 고려

ㄴ  Polyglot Technology(다국어 기술): 여러가지 프로그래밍 언어,스토리지 기술을 지원 할 수 있는지 확인

 

7. SOA와 MSA 차이

SOA (Service Oriented Architecture)

MSA(Microservice Architecture)

 

공통

ㄴ 서비스 단위로 개발

차이

ㄴ SOA는 하나의 서비스가 다른 서비스에서 재사용하게 만드는 특징 --> 비용 절감

ㄴ MSA는 서비스를 서로 공유하는게 아니고 각각 독립적으로 실행되는 것을 지향 --> 서비스 간 결합도를 낮추어 능동 대응

ㄴ SOA는 ESB, SOAP 등 여러 미들웨어를 통해 서로 통신

ㄴ MSA는 RESTful API를 통해 통신

 

8. RESTful API

ㄴ REST를 기반으로 만들어진 API

 

REST(Representational State Transfer)

ㄴ 해당 자원의 상태를 주고받는 모든 것

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

CRUD Operation

ㄴ Create : 데이터 생성(POST)
ㄴ Read : 데이터 조회(GET)
ㄴ Update : 데이터 수정(PUT, PATCH)
ㄴ Delete : 데이터 삭제(DELETE)