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가지를 추가했다.
- API first
- api를 구축함에 있어서 사용자측에서 어떤 형태로 사용할 것인지를 먼저 고려해야한다.
- Telemetry
- 모든 지표는 시각화하여 우리가 관리할 수 있어야한다.
- Authentication and authorization
- api를 사용함에 있어서 인증 작업은 필수다.
어플리케이션 개발 방법론
- Monolith
- 모든 업무 로직이 하나의 application 형태로 패키지 되어 있는 개발 방법
- 대부분 이전의 프로젝트들의 구성 상태
- Microservice Architeecture
- Sam Newman는 Small autonomous services that work together라 정의했다.
- http 통신을 이용하여 작은 규모의 여러 서비스들의 묶음
- 여러 서비스들의 묶음이 모여 하나의 어플리케이션을 구성하는 방법
- 비지니스를 위주로 구성되어야 하고 완전한 자동화된 배포와 테스트로 구성되어야 한다.
- MSA를 제안한 Martin Fowler는 각각의 서비스는 각자 다른 프로그래밍 언어와 각자 다른 데이터 베이스를 사용할 수 있어야한다.라고 정의
Microservice 란
-
특징
- 기존의 설계 방식과는 다른 설계 방식이 적용되어진다.
- 작은 단위의 서비스들로 구성되어 진다.
- 각각의 서비스들은 서로 결합될수도 분리되어질 수도 있다.
- 서로 상태에 대해 Restful API로 통신한다.
- 환경에 대한 설정 정보는 코드내에 가지지 않고 외부 시스템에서 관리한다.
- Cloud 시스템을 활용하여 시스템을 구성한다.
- 부하 분산에 대한 처리와 시스템의 Scale up/down을 동적으로 처리할 수 있어야한다.
- 배포, 테스트는 자동화 되어야한다.
- 모든 서비스는 시각화되어 모니터링할 수 있어야한다.
-
그렇다면 모든 서비스를 Microservice로 변경하는 것이 좋을것인가에 대한 고려사항
- 기존 개발 환경에서 변경되어지는데 어느정도의 비용이 사용될 것인가
- 현재 운용 중인 어플리케이션의 각각의 서비스들의 독립성을 갖고 있는가
- 각각의 서비스가 유지보수가 용이하게 작성된 프로그램인가
- 서비스의 오류사항이 각각의 서비스에 최소한의 영향을 주고 있는 프로그램인가
- 외부 종속성이 없는 프로그램인가
- 여러가지 프로그램 언어를 사용할 수 있도록 설계된 프로그램인가
SOA와 MSA의 차이점
-
공통점
MSA와 SOA(Service Oriented Architecture=서비스 지향 아키텍쳐)는 서비스를 지향한다는 점에서는 같다. -
차이점
- SOA : 서비스 재사용을 통한 비용의 절감을 주 목적
- MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하는 것을 주 목적
Microservice Architecture 표준 구성요소
MSA는 Gartner에서 발표한 넷플릭스, 트위터, 나이키 등의 회사에서 선택한 아키텍쳐의 형태를 시각화한 그림이다.
각 회사별 아키텍쳐가 다르게 존재할 수도 있고 해당 아키텍쳐를 참고하여 프로젝트 상황에 맞게 변경할 수도 있지만 우선 우리는 해당 그림의 형태로 구성요소에 대해 이해해보려한다.
- 먼저 맨 앞에 Mobile App, Brower App, Other Services와 같이 여러 client들의 요청을 받을 수 있다.
- 그 후 API Gateway를 통해 서비스 요청을 받게 된다.
- Service Router에 요청된 서비스를 찾아 달라고 하게 되고
- Service Router는 Service Discovery에 등록되어진 Service중 요청된 서비스를 찾아온다.
- 서비스의 위치를 알게되었으니 Load Balancing을 통해 생성되어진 컨테이너의 인스턴스들 중 요청이 가능한 인스턴스로 요청을 보내게된다.
- 각 인스턴스에서 설정에 대한 정보는 외부 Config Store에 저장되어진 내용을 가져다 사용한다.
- 자동화된 CI/CD 시스템을 통해 인스턴스들은 계속해서 배포되고 테스트된다.
- 각 분리되어진 서비스들의 데이터는 Backing Service를 통해 데이터의 통일성을 가질 수 있고 다른 서비스와도 결합되어질 수 있다.
- 위 서비스들은 모두 Telemetry를 통해 모니터링되어야 한다.
-
Service Mesh란
Service Mesh라는 것은 MSA를 적용한 시스템의 내부 통신을 말하고 각 서비스들에 대해 프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱 등 여러 기능을 제공해준다.
-
CNCF(Cloud Native Computing Foundation)
MSA를 구성하기 위해서는 다양한 제품들이 존재한다.
에 접속하여 클라우드 제품들을 카테고리별로 확인할 수 있고 개발자가 선택하여 application에 적용하여 사용할 수 있다.
Spring Cloud
Spring Cloud는 환경설정, 서비스 검색, 회복성 처리, 라우팅, 프록시 등의 서비스들을 모아놓은 하나의 프레임워크
- 환경설정 : Spring cloud Config Server
- 서비스의 등록과 위치 정보 : Eureka
- 로드 밸런스 : Spring Cloud Gateway(Spring 권장), Ribbon
- 서비스 간의 통신 : FeignClient
- 모니터링 : Zipkin, Netflix API gateway
- 장애복구 : Hystrix
