마이크로서비스
- 마이크로 아키텍처 라고도 함
- 유지보수에 유리하고, 테스트 가능해야 함
- 느슨하게 결합되어야 함
=> 시간이 지남에 따라 서비스가 복잡해지면 더 작은 서비스로 분할할 수 있음
- 독립적으로 배포 가능함
=> 다른 서비스의 기능에 영향을 주지 않음
=> 해당 서비스의 코드 및 구현을 다른 서비스와 공유할 필요 없음
- 비즈니스 역량을 중심으로 구성해야 함
=> 모든 규모에 부합하는 접근 방식이 아닌 각 팀별 특정 문제에 대한 적합한 도구를 자유롭게 선택 가능
- 작은 팀에 의해 소유됨
=> 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속한 업무처리 가능, 개발주기 시간 단축
서비스로서의 컴포넌트화
컴포넌트 - 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위
컴포넌트화 - 시스템을 구성요소(component)를 나누고 이를 연결하여 구축하는 것
컴포넌트화 방법 - 소프트웨어를 여러 서비스로 분리하는 것
컴포넌트화 방법 별 차이
라이브러리 & 서비스
monolithic & microservices
모놀리식
- 내부 요소간 의존성이 강하며 어떤 서비스든지 개발 되어 있는 환경이 같음
- 쉽게 고가용성 서버 환경을 만들 수 있음
- 조그마한 수정사항이 있어돋 전체르 다시 빌드하고 배포해야함
- 일부 오류가 전체에 영향을 미침
- 기능별 기술, 언어, 프레임워크 선택이 까다로움
마이크로 서비스
- 서비스 별 기능이 구분되어 있음
- 배포가 쉬우면 뛰어난 복구능력이 있음
- 높은 확장성을 가짐
비즈니스 수행에 따른 구성
before - 기술적 계층에 따른 팀 분류
=> 단순한 변경이 필요한 경우에도 팀간의 협업 비용이 증가함
after - 비즈니스 수행 능력에 따른 팀 분류
=> 도메인 ? - 쇼핑몰의 경우 회원/상품/배송이 각각의 도메인이 됨
- 하나의 온전한 시스템의 단위
=> 팀이 하는일이 하나의 서비스로 나뉘어짐 -> 마이크로 서비스
- 소프트웨어 스택, 데이터베이스 스택, 프로젝트 관리 등이 독립적임
- 각 팀은 서비스에 대한 책임을 가져야함
- 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야함
장애 방지 설계 (마이크로 서비스가 모놀리틱 설계에 비해 불리한 점)
- 서비스는 언제든 실패할 가능성이 있음
- 신속하게 장애를 감지하고 가능하면 자동으로 복구할 수 있어야함
- 대시보드와 모니터링은 필수
마이크로서비스 아키텍처 구현 단계
- 모든 경우에 마이크로서비스 아키텍처가 필요한 것은 아님
- 레벨을 진화 시킨다고해서 더 나은 서비스는 아님
- 마이크로서비스 아키텍처 도입 전
1. 각 단계에 있어 해당 방식이 갖는 장단점
2. 기존 시스템의 작동방식
3. 현재 시점의 요구사항 을 이해한 후 도입 해야함
서버리스 란?
- 서버가 없는 것이 아닌 서버에 대한 고민을 안하는 것
- 등장배경 => 웹 어플리케이션을 빠르고, 적은예산으로, 확장 가능하도록, 관리 운영 쉽게, 혼자 제작 등을 고려하는 것에 대한 해답
- 데이터 센터 물리적 서버 -> 데이터 센터 가상서버
=> 활용률 증가, 프로비전이 속도 증가, 높아진 가동 시간, 재해 복구, 하드웨어 독립성
- 데이터 센터 가상서버 -> 클라우드 가상서버
=> 자본비용 -> 운용비용
=> 높은 확장성, 탄력적 리소스, 빠른속도와 민첩성, 유지보수 비용 감소, 고가용성과 내결함성
=> 단점 : 가상 서버 관리, 용량 및 활용률 관리, 워크로드 사이징, 고가용성과 내결함성 관리, 간헐적 작업 시 비쌈
상시 대기가 아니라 상시 대기 서버보다 느림, 서버 제공자에 대한 의존도 높음
서버리스 장점
- 서버관리 불필요 (제품 출시 빠르게 가능)
- 유연한 확장성 (사용규모 신경 X)
- 고가용성
- 유휴 용량 없음
- 요청이 없으면 서버 유지 비용 X
Q1. 마이크로 서비스와 서버리스의 관계
- 마이크로 서비스를 도입하면서 서비스별 기능이 분리 되었고 이에 대한 서버관리량이 증가하여 서버에 대한 고민을 줄이기 위해 서버리스를 도입하게 됐다. 서버리스를 도입하게되면 서버 관리 인원을 줄일 수 있음
Q2. 서버리스의 특징 중 하나인 무상태성(Stateless)의 의미
- 무상태성이란, 시스템이 현재 상태를 나타내는 데이터를 보유하지 않고, 단지 입력 내용에 따라 출력 내용이 결정되는 방식
- 함수가 실행 되는 중에만 자원을 할당함
- DB에 접근하게되어 사이드 이펙트가 생기므로 상태 관리를 하지 않는것이 서버리스에서의 빠른 처리를 가능하게 함
https://www.redhat.com/en/topics/cloud-native-apps/stateful-vs-stateless
Stateful vs stateless
Whether something is stateful or stateless depends on how long the state of interaction with it is being recorded and how that information needs to be stored.
www.redhat.com
Q3. 마이크로서비스 구성 시 데이터 베이스의 분리는 꼭 필요한가? 데이터가 한곳에 모여있지 않고 중복되어도 괜찮은가?
(+ 모범사례)
- 데이터 베이스를 점진적으로 분리해 나가는것이 좋을 것 같음, 프로젝트 실패 시 부담해야 할 리스크가 클 것으로 예상됨
- 마이크로 서비스의 기본 원리는 각 서비스가 자체 데이터를 관리하는 것이므로(데이터 스키마 변경 시 해당 데이터 베이스를 사용하ㅡㄴ 모든 서비스에서 변경 내용이 적용 되어야 함) 데이터가 한곳에 모여있으면 안되며 데이터 저장소를 공유하는 것은 안된다. 데이터 베이스를 격리하여 변경의 범위를 제한하고 완전히 독립적인 배포를 가능하게 하여야 함.
- 데이터 베이스의 스키마 온 리드(schema-on-read) 기능이 필요할 수 있음, 참조 무결성 필요
https://learn.microsoft.com/ko-kr/azure/architecture/microservices/design/data-considerations
마이크로 서비스에 대한 데이터 고려 사항 - Azure Architecture Center
마이크로 서비스 아키텍처에서 데이터를 관리하는 방법에 대해 알아봅니다. 데이터 무결성 및 데이터 일관성은 마이크로 서비스의 중요한 과제입니다.
learn.microsoft.com
참고 링크
https://aws.amazon.com/ko/microservices/
https://www.redhat.com/ko/topics/microservices/what-are-microservices
마이크로서비스란?
마이크로서비스란 애플리케이션을 구축하기 위한 아키텍처 기반의 접근 방식으로 애플리케이션의 각 요소가 독립적으로 작동합니다.
www.redhat.com
What are microservices?
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous
microservices.io
'DevOps > DevOps' 카테고리의 다른 글
| 독립적 서비스 구성 - AWS Lambda, API Gateway (0) | 2023.02.02 |
|---|---|
| API 디자인, 프로세스 간 통신(Inter-process communication, IPC ,마이크로서비스 간의 통신) (1) | 2023.02.01 |
| [Mac OS]Mac OS Proxy 서버 구동 (nginx) (0) | 2022.12.30 |
| MLOps 란? (DevOps 와 비교) (0) | 2022.12.21 |
| ETL 과 ELT (0) | 2022.12.21 |