- 📝 Microservices in Action, Microservices Patterns 을 읽고 중요한 내용들을 발췌하여 정리하였습니다.
- Tech Dummies's Microservices Architecture 영상과 Microsoft의 클라우드 디자인패턴, AWS 아키텍처 센터의 글들을 읽으며, 주요 microservice 패턴들을 요약, 정리하였습니다.
- 작성 일자: 2020-10-25
1. API Gateway
1) 배경:
- service1, service2, service3가 전부 사용되는(join) 데이터가 필요해지면 각각의 서비스를 일일이 호출해야하고, 각각의 요청을 한뒤, 결과값을 기다려야한다. 이에 따라 high latency가 발생하게 된다.
- service1, service2, service3의 주소를 전부 알아야한다.
2) 해결법:
- appliction과 service사이에 API gateway를 두어서, 요청을 동시에 service1, service2, service3에 보낸 후, 데이터를 취합하여, 다시 client에 보낸다.
- API gateway를 두어서, 하나의 api point만 알아도 된다.
API GateWay는 이외에도 다양한 기능을 가지고 있다.
1) Authentication
2) SSL termination
3) Load Balancer
2. Service Discovery
1) 배경:
- 클라우드를 사용할 경우, auto scaling에 따라 service instace가 생겼다가 사라졌다가 하면 ip 주소가 계속 바뀌게 되며, 이에 대한 정보를 취득할 수 있는 방법일 필요해짐
- 클라이언트나 API 게이트웨이가 호출할 서비스를 찾는 매커니즘이 필요
2) 해결법:
- The Client‑Side Discovery Pattern
- The Server‑Side Discovery Pattern
- 서비스 레지스트리(일종의 데이터베이스)에 서비스 주소, 포트가 등록되면, client가 직접 쿼리를 하든지, 로드벨런서를 통해 쿼리를 하여, 서비스 주소를 알아내게 된다.
Service Registry에 Service를 등록하는 방법
1) Self‑Registration Pattern
2) Third‑Party Registration Pattern
3. Service Mesh
1) 배경:
- Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services.
2) 해결방안:
- side-car 패턴을 이용하여 service-mesh를 구축
- load balance, service discovery, metric, retry, circuit breaking, timeout 등 각종 부가적인 것들을 관리해줌
4. Saga
1) 배경:
- 분산된 service들을 이용함에 따라 ACID 트랜잭션이 불가능해짐
- 분산된 service들에 대한 트랜잭션을 관리할 방법의 필요성이 생김
- ACID properties are difficult to achieve in interactions across multiple services; microservices require different approaches to achieve consistency.
2) 해결방안:
1) The choreographed approach:
-
A saga is a coordinated series of local transactions; a previous step triggers each step in the saga.
-
compensating actions(실패시 어떤 액션을 할지 정의한 것)을 통해서, operation을 취소하거나, 일정한 state를 유지하도록 한다.
-
장점: participating services don’t need to explicitly know about each other
-
단점: 1) compensating actions들을 추가하게 됨으로써 시스템 복잡도를 높힌다. 2) cyclic dependencies between services를 발생시킬 수 있다. 3) the order of rollback might be important(롤백이 보장되지 않는다. compensation actions 또한 실패할 수 있기 때문에)
2) The orchestrated approach:
- It may interact with participants in the saga via asynchronous events or request/response messages.
- it should track the state of execution for each stage in the process; this is sometimes called the saga log.
-
saga log(example에서는 order)에다가 트랜잭션이 발생할때마다 로깅을 한 후, 중간에 실패가 발생하면, rollback작업을 통해 전체 opertation이 취소된다.
-
장점: Centralizing the saga’s sequencing logic in a single service makes it significantly easier to reason about the outcome and progress of that saga, as well as change the sequencing in one place. In turn, this can simplify individual services, reducing the complexity of states they need to manage, because that logic moves to the coordinator.
5. 이외의 많은 패턴들
- 이외의 주요 패턴들은 Python으로 클린 아키텍처 적용하기2 에서 다루었기 때문에 생략합니다.
- 저는 특히 Microsoft의 클라우드 디자인패턴을 통해서 많은 microservices 패턴에 대한 지식을 습득할 수 있었고, 패턴에 대한 적용 사례들은 AWS 아키텍처 센터을 통해 구체적으로 이해할 수 있었기에 이 두 사이트를 쭈욱 살펴보길 강력 추천드립니다.
🏝이 글이 도움이 되셨다면 추천 클릭을 부탁드립니다 :)
참고자료:
