MSA 총정리
Cloud Native Architecture - 2010 s ~ 부터 IT 시스템은 anti-fragile, cloud native architecture 형태로 관리되어 왔다.
(1). 확장 가능한 아키텍쳐
- 시스템의 수평적 확장에 유연하여 더 많은 사용자의 요청을 처리할 수 있다.
- 확장된 서버로 시스템의 부하를 분산하고, 가용성 ( availabilty ) 를 보장할 수 있다.
- scale-up : 하드 웨어의 사양을 높이는 것 ( CPU, 메모리의 사양을 업그레이드 하는 것 ), scale-out : 같은 사양의 서버 인스턴스를 여러 대 배치함으로써 동시에 더 많은 사용자의 요청을 처리할 수 있도록 하는 것.
- 일반적으로 이렇게 서버를 양적으로 늘리게 되면 하드웨어 비용이 증가하게 되겠지만, 클라우드 서비스를 제공하는 업체로부터 가상의 서버, 가상의 스토리지, 가상의 네트워크 등을 빌려서 사용함으로써 이러한 비용을 최소화 시켰다.
- Cloud Native 에서는 가상 서버의 기술이 핵심적으로 필요하다. 기존의 서버 가상화 방식과 더불어 컨테이너 방식의 가상화를 함께 사용한다.
- Cloud Native 에 구축된 가상 서버와 리소스들은 다양한 모니터링 도구를 이용해서 현재 사용되고 있는 시스템의 상황 및 리소스의 사용량 등을 확인 할 수 있다.
(2). 탄력적 아키텍처
- 애플리케이션을 구성하는 각 기능을 하나의 분리된 서비스로 개발하고 분리되어 개발되어 있는 서비스들을 통합하고 배포하기까지 걸리는 시간을 CI/CD 라는 자동화 파이프 라인을 통해서 처리함으로써 배포 환경에 적용되는 시간을 단축시킨다.
- 마이크로 서비스는 작게 분리된 독립적인 서비스이므로, 전체 애플리케이션을 구성하고 있는 도메인의 특성에 따라 서비스의 경계를 잘 구분하고 거기에 맞게 서비스를 개발해야 한다.
- 서로 분리되어 있는 서비스 간에 원활한 통신을 위해 각 서비스들은 종속성을 최소화 해야 하고, 상태를 갖지 않는 서비스를 제공하려고 노력해야 한다.
- 전체 애플리케이션을 구축하는 마이크로 서비스들은 배포될 때 자신들이 위치가 어디에 있는 지 등록을 해야 한다.
(3). 장애 격리 ( Fault isolation )
- 여러 개로 분리되어 개발되는 마이크로 서비스들은 하나의 독립적인 작은 단위의 애플리케이션과 같다. 따라서 하나의 마이크로 서비스에서 생기는 장애는 다른 쪽 서비스로의 영향을 최소화 할 수 있다.
- 특정 마이크로 서비스만 개선, 수정한 뒤 배포할 수 있기 때문에 다른 시스템에 영향을 주지 않게 된다.
Cloud Native Application - Cloud Native Architecture 방식으로 설계된 애플리케이션
(1). Microservices
(2). CI/CD : 마이크로 서비스로 개발된 서비스들은 CI/CD 에 의해 자동으로 통합되고, 빌드되고, 테스트되고, 배포된다.
CI ( Continuous Integration )
- 통합 서버, 소스 관리( SCM ), 빌드 도구, 테스트 도구
- ex ) Jenkins, Team CI, Travis CI ( Git 과 같은 형상 관리 시스템과 연동하여 사용하게 된다. )
- CI 시스템에 파이프 라인을 잘 연동하게 되면 개발자가 코드를 완성한 후 Git 에 commit 함과 동시에 빌드, 테스트를 실행하여 다른 쪽의 코드와 문제가 발생하는 지에 대한 여부를 확인할 수 있다.
- 하나의 애플리케이션이 여러 팀이나 여러 개발자들에 의해 개발하고 있는 경우, 결과물을 통합하기 위한 형상 관리를 뜻할 수도 있다.
- 통합된 코드를 빌드하고 테스트 하는 과정 자체를 의미하기도 한다.
CD ( Continuous Delivery, Continuous Deployment )
- Git 과 같은 소스 저장소에 업로드된 코드를 가지고 와서 패키지화된 형태의 결과물을 실행 환경에 어떻게 배포하는 지에 따라 달라진다.
- 패키지화된 결과물을 배포 환경에 수작업으로 배포하는 과정이 필요하다면 Continuous Delivery
- 운영자나 관리자의 개입 없이 배포 환경까지 완벽하게 자동화 되어있다면 Continuous Deployment
- 시스템의 완성된 결과물을 배포하기 위해 카나리 배포, 블루그린 배포와 같은 배포 전략이 존재한다.
CI/CD ( 배포 파이프라인, 지속적 통합 지속적 배포 ) 를 사용해야하는 이유
CNA 는 적게는 수 십개, 많게는 수 백개의 마이크로 서비스로 도메인이 분리되어 개발되는 경우가 일반적이다. 하나의 어플리케이션을 구성하는 서비스들을 일일히 빌드하고 테스트하고 서버에 배포하는 등의 작업을 수작업으로 한다면 시스템 자체의 복잡성을 떠나서 어플리케이션을 구성하고 있는 각각의 서비스들을 구성하고 배포하는 작업 자체가 하나의 커다란 업무이자 작업의 로드가 심하게 걸리는 부분이 된다. 그래서 이러한 마이크로 서비스들을 빌드하고 배포함에 있어서 자동화된 시스템을 구축하고 하나의 작업에서 다른 작업으로 연계되는 과정을 파이프 라인으로 연계 시켜놓게 된다면, 작은 변화 뿐 아니라, 전체적인 시스템의 업그레이드 작업 또한 빠르게 적용시킬 수 있다. CI/CD 라는 개념이 CNA 나 마이크로 서비스에서 새로 생겨난 개념은 아니지만, CNA 의 마이크로 서비스에서 활발하게 사용되고 빠질 수 없는 기술이 되었다.
(3). DevOps : 마이크로 서비스에 문제가 발생했을 경우 바로 바로 수정해서 댜시 배포하는 과정을 반복할 수 있는 형태, 처음 애플리케이션이 기획되고, 개발되고, 테스트되고, 배포되는 과정을 시스템이 종료될 때 까지 무한 반복 해줌으로써 고객이 원하는 최선의 애플리케이션을 만드는 데 목적을 두고있다.
(4). Containers : 하나의 애플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고, 사용하기 위해 컨테이너 가상화 기술을 사용한다.
- 가상화는 Cloud Navtive Architecture 의 핵심이다. 기존에 로컬 환경에서 운영하고 유지해야만 했던 시스템을 클라우드 환경으로 이전해서 적은 비용으로 탄력성 있는 시스템을 구축하게된 배경이 바로 컨테이너 가상화 기술이다.
- 컨테이너 가상화 기술은 기존의 하드웨어 가상화 또는 서버 가상화에 비해 적은 리소스를 사용하여 가상화 서비스를 구축할 수 있다.
- 전통적 방식의 개발 시스템은 하드웨어 위에 운영체제를 설치하고 애플리케이션을 운영한다.
- 가상 머신을 통한 개발 시스템은 운영체제 위에 Hyperviser 기술을 통한 가상 머신을 가동하게 된다. 이러한 가상 머신은 시스템이 가지고 있는 물리적인 하드웨어를 쪼개서 사용하는 개념으로 하나의 가상 머신은 독립적인 운영체제를 가질 수 있다. 즉, 하나의 가상 머신에 독립적인 애플리케이션을 운용할 수 있다. 그러나 가상 머신에서 작동되는 애플리케이션은 하드 웨어에 많은 부하를 주게 되고 시스템 확장에 한계가 존재한다.
- 컨테이너 가상화를 통한 개발 시스템은 운영체제 위해 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스를 작동시키고, 컨테이너 가상화에서는 공통적인 라이브러리나 리소스를 공유해서 사용한다. 각자 필요한 부분들만 독립적인 영역에 실행할 수 있는 구조이다. 따라서 기존의 하드웨어 기술보다 적은 리소스를 사용하게 된다.
Cloud Native Application 을 구축하기 위해 고려되는 12 Factors
12 factors
Base Code : 자체 레포지토리에 저장된 각 마이크로 서비스들에 대한 단일 코드 베이스를 뜻한다. 버전을 제어하기 위한 목적이고, 형상 관리를 위해 코드를 한 곳에서 배포하는 것이 주 목적이다. 결국 배포하기 위해서 코드의 통일적인 관리가 필요햐기 때문에 매우 중요한 항목이다.
Dependency Isolation : 각 마이크로 서비스는 자체 종속성을 가지고 패키지되어 있기 때문에 전체 시스템에 영향을 주지 않은 상태에서 변경되고 내용을 수정할 수 있어야 한다는 뜻이다.
Configuration : 구성 정보, 코드 외부에서 구성 관리 도구를 통해 마이크로 서비스에 필요한 작업들을 제어하는 것이다. 동일한 배포가 올바른 구성이 적용된 환경에서 전파될 수 있다! 라는 것이 핵심이다.
Linkable Backing Services : 보조 서비스 ( DB, 캐시, 메시징 서비스, 브로커 ) 를 이용해서 마이크로 서비스가 가져야 할 기능들을 지원함을 의미한다.
Stages of Creation : 빌드, 릴리즈, 실행 환경을 분리하는 것을 뜻한다. 각각은 고유한 id 로 태그를 가지고 있어야 하고, 이전 상태로 돌아가는 roll-back 기능을 지원해야 하며, CI/CD 시스템을 이용하여 자동화된 시스템을 구축하는 것이 좋다.
Stateless Processes : 각각의 마이크로 서비스는 실행되는 다른 서비스와 분리된 채 자체 프로세스에서 운영될 수 있어야 한다. 즉 독립성과도 일치하는 항목이다.
Port Binding : 각각의 마이크로 서비스는 자체 포트에서 노출되는 인터페이스 및 기능과 함께 자체 포함되어 있는 기능이 있어야 한다. 다른 마이크로 서비스와 격리를 위해서이다.
Concurrency : 하나의 서비스가 여러 인스턴스에 동일한 형태로 복사가 되서 운영됨으로써 부하 분산을 이루어낼 수 있다. 따라서 동일한 서비스가 여러 서버 인스턴스에 나눠서 서비스가 되고 있기 때문에 동시성을 가지고 있어야 한다.
Disposability : 서비스 인스턴스 자체가 삭제가 가능해야 한다. 또한 확장성 기회를 높혀야 하고, 정상적으로 종료를 할 수 있는 상태가 되어야 한다.
Development & Production parity : 개발 단계와 프로덕션 단계를 구분해야 한다.
Logs : 마이크로 서비스에 의해 생성된 로그를 이벤트 스트림으로 처리해야 한다. 하나의 시스템 안에서 구성되어 있는 로그를 출력하는 로직은 기존에 있었던 애플리케이션 로직과 분리가 되어 애플리케이션 자체가 실행되지 않은 상태라고 하더라도 정상적으로 로그가 작동해야 한다.
Admin Processes For Eventual Processes : 현재 운영되고 있는 모든 마이크로 서비스들을 어떠한 상태로 사용되고 있으며 어떻게 리소스가 사용되고 있는 지 파악하기 위한 적절한 관리 도구가 있어야 한다. ( 리포팅, 데이터 정리, 데이터 분석 )
최근에는 3가지 항목이 더해지는 추세이다.
new 2. API first : 가지고 있는 모든 마이크로 서비스들은 API 형태로 서비스가 제공된다.
new 14. Telemetry : 12 번 항목인 관리자 항목과 비슷하다. 모든 지표는 시각화, 수치화되어서 관리되어야 한다.
new 15. Authentication and Authorization : API 를 사용함에 있어서 인증과 권한은 필수이다. 분리된 형태로 마이크로 서비스를 개발한다고 하더라도 각 마이크로 서비스는 적절한 인증을 가지고 있는 리소스, 서비스로 구현해야 한다.
Monolithic vs. MSA
Monolith Architecture
- 모든 업무 로직이 하나의 애플리케이션 형태로 패키지되어 서비스된다.
- 애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태이다.
- 시스템의 일부분만 수정해야한다고 하더라도, 전체 애플리케이션을 다시 빌드하고 테스트하고 패키징해야한다는 단점을 가지고 있다.
What is the Microservice ?
- Small autonomous services that work together
- Sigle application as a suite of small services
- These services are built around business capabilities and independently deployable by fully automated deployment machinery
- Bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies
- 각각의 서비스 별로 특색에 맞게 최적의 언어와 DB 를 선택할 수 있다. 예를 들어, 서버 사이드 개발에서는 자바, 하드웨어 제어에서는 C/C++, 데이터 분석 및 머신 러닝은 Python, 서버 사이드의 javascript 와 비동기 통신을 하기위한 node.js 등을 사용하면 각 서비스의 기능에 맞추어 최적의 퍼포먼스를 발휘할 수 있다.
- 마이크로 서비스를 선택하기 전에 고려해야할 것들
Multiple Rates of Change : 기존 개발 대비 비용과 시간을 투자해야하는 것은 분명하다. 그럼에도 불구하고 도입해야한다고 하면 어느정도 공수를 고려하고 받아들일 수 있을까에 대한 문제
Independent Life Cycles : 한 애플리케이션을 구성하고 있는 각각의 서비스들이 독립적으로 개발되고 운영될 수 있도록 서비스 경계가 분명하고 잘 나누어져 있는 가에 대한 문제
Independent Scalability : 각각의 서비스를 운영함에 있어서 서비스의 유지 보수 및 확장이 가능한가에 대한 문제
Isolated Failure : 에러가 발생했을 때 에러 상황이 애플리케이션의 각 서비스들에 대해 독립적인가에 대한 문제
Simplify Interactions with External Dependencies : 외부 종속성과의 상호 작용을 단순화 ( 최소화 ) 하고, 각 서비스의 응집력을 높일 수 있도록 서비스 경계가 잘 구분되어 있는 가에 대한 문제
Polyglot Technology : 여러가지 언어, 스토리지 기술을 사용할 수 있게끔 지원하는 패러다임을 Polyglot 이라고 한다. 이 Polyglot 을 지원하는 가에 대한 문제
SOA vs. MSA
- SOA ( Service Oriented Architecture ) : 재사용을 통한 비용의 절감
- MSA ( Micro Service Architecture ) : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응
- SOA : 공통의 서비스를 ESB 에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
- MSA : 각 독립된 서비스가 노출된 REST API 를 사용
Monolithic vs. SOA vs. MSA 정리
- 모놀리스 아키텍처는 하나의 서버에 다양한 기능이 위치해있는 아키텍처이다. 즉 하나의 프로젝트에 코드가 모여있고 하나의 파일로 구성된다. 보통 DB, View, Controller 로 구성된 컴포넌트들이 하나의 프로젝트에서 관리되고 하나의 공통된 DB 를 바라보고 있다는 특징이 있다.
- 장점 : 과거에 대부분의 서비스는 모놀리스 구조이기 때문에 다양한 레퍼런스가 존재하고 인프라의 구성과 운영이 간편하다. 또한 테스트 및 배포 파이프라인 구성이 쉽다.
- 단점 : 서비스 간에 서로 의존성이 존재하기 때문에 시스템의 일부만 수정하더라도 전체 애플리케이션의 Build, Test, Packaging 과정을 거쳐야 한다. 따라서 간단한 수정에 오랜 down time 이 존재하기 때문에 쉬운 수정이 불가능하다.
- SOA 아키텍처는 공통된 서비스를 ESB 에 모아 사업 측면에서 공통 기능의 집합을 통해 서비스를 제공한다.
- 장점 : 서비스를 단위로 모듈을 분리하다 보니 자연스럽게 결합도가 낮아지는 Loose Coupled 된 아키텍처가 된다. 따라서 버스 형태에 연결만 가능하다면 확장성과 유연성이 증가한다는 특징이 있다.
- 단점 : ESB 도 여전히 하나의 DB 를 사용한다는 점에서 끊어질 수 없는 의존성이 존재하기 마련이다. 또한 구체적이지 않은 특성 덕분에 비지니스에서 실 성공 사례가 드물다는 특징이 있다.
- MSA 아키텍처에서 서비스는 비지니스 단위로 나뉘어있고, 최소한의 중앙 집중식 구성이며, 서로 다른 언어와 DB 로 구성되어 있고, 각각의 서비스들은 HTTP API 를 통하여 데이터를 주고 받는다.
- 장점 : 애플리케이션을 구성하는 서비스 구성요소들이 모두 컨테이너에 의해 나눠지기 때문에 최소한의 의존성을 가지게 될 수 있다. 그에 따라 자연스럽게 새로운 모듈에 대한 추가가 자유로워 진다.
- 단점 : 복잡하게 구성되어 있어 구축하는 데에 많은 비용이 따른다.
- 아키텍처를 결정하는 가장 중요한 지표는 현재 내가 속해있는 집단에서 가장 필요한 기술이 무엇이냐, 와 비용이다.
Microservice Architecture Structures
- MSA 표준 구성 요소
- 2018년 Gartner 라는 시장 조사 기관에서 조사한 바로, 넷플릭스, 트위터, 나이키, 아마존 등의 회사에서 채택한 아키텍처이다. 따라서 널리 많은 서비스들에서 참고되는 구조이다.
모바일 앱, 브라우저 앱과 같은 클라이언트와 댜른 마이크로 서비스들은 API Gateway 라는 진입점을 통해서 필요한 서비스를 요청한다.
API Gateway 에서 수집된 클라이언트의 요청은 Service Router 에게 어디로 가야할 지 묻는다.
Service Discovery 는 마이크로 서비스들이 어디에 어떻게 등록되어 있는 지 저장해두고, Service Router 는 필요한 서비스가 어디에 등록되어 있는 지 Service Discovery 에게 묻는다.
사용할 마이크로 서비스를 찾았고, 마이크로 서비스의 인스턴스가 여러 개라면 앞의 Load Balancer 는 어떠한 마이크로 서비스의 인스턴스를 사용할 지 결정하고 이동한다.
마이크로 서비스 안에서 사용하고 있는 환경 설정 정보는 Configuration 서비스를 통해서 외부 시스템에 저장하고 사용하는 것이 일반적이다.
마이크로 서비스 들은 컨테이너 가상화 기술을 통해서 구성되어 있다.
완성된 애플리케이션은 배포를 위해 CI/CD Automation 기술을 사용한다.
마이크로 서비스 애플리케이션에 대한 CI/CD Automation 을 DevOps Engineer 가 사용하고, 관리할 수 있도록 API 를 공개해야 한다.
Backing Service 는 마이크로 서비스에 저장되어 있는 다양한 스토리지들을 모아서 사용하는 방법, 그리고 MOM 을 통해서 하나의 서비스가 다른 서비스와 같이 연결될 수도 있다.
Telemetry 는 마이크로 서비스의 모니터링, 진단 기능을 가지고 있다.
- Servie Mesh Capabilities
- MSA 를 적용한 시스템의 내부 통신을 말하고, Service Mesh 를 통해서 서비스 간 내부 통신을 추상화하고, 안정적이고, 빠르고, 신뢰성있게 만들어주는 인프라 스트럭쳐의 레이어이다.
- 이러한 추상화로 복잡한 내부 네트워크를 제어하고, 추적하고, 내부 네트워크에 관련된 로직을 추가 함으로써 안정성 신뢰성 탄력성 표준성 가시성 보안성 등을 확보할 수 있게 된다.
- Service mesh 는 하나의 제품이나 서비스를 지칭하는 것이 아닌, 추상적인 개념이다.
- MSA 인프라에서 미들웨어로, 프록시의 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱 등의 기능을 통해 안정적이고 효율적인 마이크로 서비스를 지원하는 데에 목적을 두고 있다.
CNCF ( Cloud Native Computing Foundation )
- https://landscape.cncf.io/
- 클라우드 네이티브를 구축함에 있어서 서로 인터렉티브하게 상호 연관될 수 있는 서비스들이 어떤 것들 인지 알 수 있다.
MSA 기반 기술
