본문 바로가기

PaaS-Ta/이론

[Paas-Ta] Microservices와 API Gateway

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