01. Microservices
1-1 Microservices의 개념
• 업무상의 기능 또는 역할을 하나의 기능 묶음으로 개발된 컴포넌트 → 한 가지의 역할만 수행
• REST API 등을 통하여 서비스들의 기능을 제공하고 사용
• 데이터를 공유하지 않고 서비스별로 독립적으로 가공하고 저장함
1-2 Microservices의 특징 :
프로그램 언어, 프레임워크, 미들웨어 등에 초점을 맞춘 개념이 아님
① 작게 쪼개진, 범위가 명확한 다수의 작은 서비스들
- 단일 책임 원칙(Single Responsibility Principle)
- 도메인 주도 개발(Domain Driven Development)
- 제한된 컨텍스트(Bounded Context)
- 독립적으로 관리됨(Independently Managed)
② 각 서비스의 명확한 소유권
- 일반적으로 “DevOps” 모델 필요/채택
③ Componentization via Services
- (부품화 된 서비스) 한 가지 기능만 수행 기본 원리
④ Organized around Business Capabilities
- (비즈니스 기능/역할에 따른 분할)
⑤ Products not Projects
- (프로젝트가 아닌 개별 제품)
⑥ Smart endpoints and dumb pipes
- (단순한 어플리케이션간 연동과 파이프처리 – 유닉스의 철학)
⑦ Decentralized Governance
- (통제의 분권화)
⑧ Decentralized Data Management
- (데이터 관리의 분권화 – Polyglot Persistence)
⑨ Infrastructure Automation
- (자동화된 환경구축 – DevOps)
⑩ Design for failure
- (장애에 대비한 설계)
⑪ Evolutionary Design
- (변화에 대응하는 설계)
* 지금 개발하고 있는 것이 마이크로서비스 모델인지 아닌지 결정하는 단 하나의 심플한 규칙을 적용하고 싶다면,
서비스가 다른 서비스 및 서비스 버스(EBS)에 영향을 주지 않고 독립적으로 업데이트되고 배치될 수 있는지 보면 된다.
* 잘 개발된 마이크로서비스는 명확한 인터페이스와 프로토콜을 사용하며, 비즈니스를 독립적인 미들웨어로 압축 요약한다.
1-3 아키텍쳐 :
1. 아키텍쳐 모델 예시 : 서비스를 분할하고 서비스별로 별도의 데이터베이스 구축
2. 아키텍처 배경 : 더 나은 소프트웨어를 더 빨리 출시 – 빠른 출시주기가 경쟁 우위의 원천
3. 아키텍처를 구성하기 위한 핵심 요소 :
1-4 : Microservices의 장점과 단점
1. Microservices의 장점
• Technology Heterogeneity
- 요구사항을 구현하기 위해 최적화된 언어와 아키텍처의 선택 : 다른 프로그래밍언어, 다른 도구를 사용하여 개발 가능
• Resilience
- 오류 발생 시 복구될 때까지 요청 가능 서비스에서 제외 (Circuit Breaker와 로드밸런서가 담당)
• Scaling
- 서비스들은 서로 독립적이므로 타 서비스에 영향을 주지 않고 서비스 단위로 확장 가능 →API(특히 REST API)를 통해
서비스 간 통신
- X축 확장으로 불리는 멀티 애플리케이션(또는 서버)의 확장과 Z축 확장(Partitioning 또는 Sharding)으로 불리는
확장을 독립적으로 수행
• Ease of Deployment
- DevOps와 결합된 각각의 마이크로서비스는 단순한 구조 → 개발속도와 개선에 높은 효용성
- 자동화된 단위 테스트와 시나리오 테스트는 빠른 배포주기에도 불구하고 뛰어난 품질을 유지할 수 있도록 함
• Organizational Alignment
- 각각의 마이크로서비스는 개별 팀에서 독립적으로 개발/배포가 가능.
- 시스템의 규모가 커짐에 따라 추가로 발생하게 되는 오버헤드가 일정수준으로 관리가 가능
• Composability
- 개별 비즈니스 요구사항에 특화된 단순한 서비스 → 개발자의 관리 범위 명확 → 소프트웨어의 복잡성을 제어(UI와 컨트롤, 도메인 로직이 별도의 마이크로서비스로 구성되어 완전히 독립적으로 개발)
- 각 서비스는 다른 데이터 저장소를 사용할 수 있으며 서로 느슨하게 연결
• Replaceability
- 서비스를 나누는 규칙, 즉 서비스를 모듈화하는 규칙으로 동일한 기능을 하는 서비스는 하나의 서비스로 대체 가능
간단하게 :
• 보다 빠르고 간단한 배치와 롤백
– 팀별 독립적인 Delivery 속도
• 각 도메인에 적합한 프레임워크/도구/언어
– 컴포넌트는 Python 언어로, 카탈로그 서비스는 Java로…
• 더 큰 탄력성
– 오류 격리(Fault Isolation)
• 더 나은 가용성
– 단, 적합한 설계의 경우
2. Microservices의 단점
• 복잡성(Complexity)
- Hard to develop features span multiple services
- Greater operational complexity – more moving parts
- Additional complexity of creating a distributed system – network latency, fault tolerance, serialization, …
- Multiple Database & Transaction Management
- Service interfaces and versioning
• Complicated Test : End-to-end testing
- 개별 서비스에 대한 테스트는 만들기가 수월하지만 런타임 환경상에서 비동기 상호작용을 테스트하기는 까다로움
- Require Automation for Deploy/Operation
- Devs need significant ops skills
• 중복성(Duplication)
- Duplication of effort across service implementations
- 코드 중복: 여러 언어를 사용하여 개발이 진행되는 경우 코드중복은 필연 → 오버헤드, 라이브러리 호환성 등을
충분히 고려한 이후 도입
- 데이터 중복: Maintaining availability and consistency with partitioned data
- Avoiding latency overhead of large numbers of small service invocations
- Designing decoupled non-transactional systems is hard
- Locating service instances
02. API Gateway
2-1 API의 정의 : MSA(Micro-Services Architecture)와 함께 근래에 떠오르는 기술
* API 게이트웨이는 API 서버 앞단에서 모든 API 서버들의 엔드 포인트를 단일화하여 묶어주고
API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능까지
많은 기능을 담당
• 소프트웨어가 서로 의사소통을 하는 규약
• 특정한 task 가 수행되는 방법을 표현
• 일반적 의미로는 운영체제, 어플리케이션, 라이브러리 등 다양한 수준의 인터페이스를 총칭
• REST-API와 같은 표준화된 방식의 API를 사용하여 각 서비스/어플리케이션 간의 통신
• 표준화된 통신 방식을 사용하기 때문에 각 서비스의 구현은 Polyglot Programming과 같이 다양한
방향으로 구현 가능
• API 게이트웨이는 여러 개의 엔드포인트를 설정하고, 각 엔드포인트 마다 메세지 흐름을 워크플로우
엔진 설정을 통해서 API 에 대한 Mediation, Aggregation 설정을 할 수 있는 미들웨어
2-2 ESB와의 관계
• SOA : ESB = MSA : API 게이트웨이
• ESB : API Gateway로 발전 : ESB의 대부분의 컨셉을 많이 승계
• ESB가 SOAP/XML 웹서비스 기반의 많은 기능을 가지는 구조였다면, API 게이트 웨이는
JSON/REST 기반에 최소한의 기능을 처리하는 경량화 서비스
• ESB의 실패와, MSA, REST 구현 사례를 통해서 필요에 의해서 탄생한 솔루션 실용성 강화
**API Gateway를 도입하기 위해서는 적절한 Gateway 아키텍처를 설계 필요**
2-3 주요 기능
'PaaS-Ta > 이론' 카테고리의 다른 글
[Paas-Ta] Service Broker (0) | 2022.01.20 |
---|---|
[Paas-Ta] BOSH (0) | 2022.01.18 |
[Paas-Ta] Cloud Native Application (0) | 2022.01.17 |
[Paas-Ta] SaaS (0) | 2022.01.17 |
[Paas-Ta] PaaS (0) | 2022.01.17 |