마이크로 서비스 아키텍쳐 aka.MSA

• 현재 우리는 앱스토어가 나오면서 1인~5인 이하와 같이 소규모로 사업이 가능해지고, 클라우드의 도입을 통해 누구나 백엔드를 만들고 아무나 운영할 수 있는 시대를 직면하게 되었다.
• 이러한 시대에 가장 중요한 것은 무엇일까? 비즈니스의 Agility가 매우 중요해졌다. 그에 따라 많은 아키텍쳐들이 변화하고 있다. 그렇게 등장한 것이 마이크로 서비스 아키텍쳐이다

1. Microservice Architecture

• SOA 아키텍쳐에서도 비즈니스 민첩성을 위해 intermediary 서비스와 bpm을 통해서... 하지만 먹히지 않았다. 왜냐하면 너무 기술적인 부분에만 치중이 되었기 때문이다. 사실 개발이 진행되면서 시간이 가장 오래걸리는 부분은 사람들간의 의사소통이다 (기능 하나 바꿀려면...어쩌구...저쩌구...)
• 마이크로 서비스는 이런 부분을 착안해 업무별로 시스템과 권한을 분리하여 각 팀에게 독립적인 의사결정권(물론 다는 아니고;;)을 부여해서 비즈니스의 민첩성을 높인 것이 마이크로 서비스 아키텍쳐이다

• 모놀리식 아키텍쳐 같은 경우에는 하나의 서비스에서 모두 핸들링하기 때문에 트랜젝션 보장을 실현하기 어렵지 않다. 그리고 회사 같은 곳에서 기술 유지가 편하다. 자바면 자바만 가르치면 되니까. 대신 규모가 커지면 배포, 빌드 속도가 엄청 오래 걸림
• 하지만 마이크로 서비스에서는 위에서처럼 하나의 서비스에서 여러 DB에 엑세스가 가능해야 트렌젝션 보장을 할 수 있다. 대신 마이크로 서비스 아키텍쳐는 각각의 서비스끼리 Loose Coupling이기 때문에 기능 변화가 용이하다는 장점이 있어서 비즈니스에 Agility를 부여할 수 있다. 하지만 여러가지를 복합적으로 사용할 수 있다보니 어떤 서비스가 어떤건지를 잘 정리해두지 않으면 문제가 발생발생했을 때 처리하기가 쉽지 않다. (서비스 Discovering의 중요성)
• 서비스 Discovering를 위해 시각화해주는 오픈소스도 있다
  https://kiali.io/

Kiali

• 마이크로 서비스는 서비스 간의 의존성 관리가 중요하다

2. API Gateway

• API Gateway는 모든 API 앞 단에 존재한다
• API Gateway가 필요한 이유는 API 서비스가 여러 개가 있을 때 도메인 하나로 관리를 할 수 있고, 인증도 통합해서 진행할 수 있다. 추가적으로 라우팅, 컨디션에 따라 동적 포맷팅 등 많은 기능이 있다
• API Gateway 종류
  • Lightweight API Gateway: 경로 기반 라우팅, 인증 통합, Swagger 문서 제공 ex) AWS API Gateway
  • Enterprise API Gateway (Heavy API Gateway) : 동적 라우팅, 메시지 변환, API 포탈 제공 ex) apigee, mulesoft
• Enterprise API Gateway는 무겁기 때문에 보통 안쓰고 오픈 API를 제공하거나 API 플랫폼을 제공하는 경우에 쓰인다. Enterprise API Gateway 기능 중에 monetization이라는 기능이 있는데 이건 API 호출 수를 측정하는 기능이다. API 호출 수를 기반으로 가격 책정을 하는데 이용할 수 있다
• Rate Limiting (QoS) : 유저마다 트랜잭션 수를 통제
• IP white listing, WAF 기능

• API Gateway를 사용할 때 가장 주의해야할 것은 병목 현상을 주의해야 한다. 그렇기 때문에 API Gateway에 너무 많은 기능들을 넣어버렸다가 죽어버리면 모든 서비스가 죽는다. 그래서 웬만한 경우에는 Lightweight를 사용하자.

3. Service Mesh

• 다양한 API 서비스들을 사용하고 있으면 서로 의존성이 생길 수 있다. 그래서 각 API 서비스들의 통신이 복잡해지면서 관리하기가 힘들어진다

• 그래서 ESB와 같은 아키텍쳐를 사용할 수 있다. 하지만 ESB와 같은 경우에는 구현하기에 난이도가 있기 때문에 등장한 것이 Service Mesh 아키텍쳐이다

3-1. Incident Propagation (장애 전파)

• 장애 전파를 막는 아키텍쳐를 Circuit Breaker 패턴이라고 부른다

• 서비스 A가 서비스 B를 호출했는데 일정 시간 응답이 없을 경우 중간에서 Circuit Breaker가 끊어버린다. 그래서 장애 전파가 되지 않는다.

• 스프링에서는 아예 내부적으로 써킷 브레이커를 구현한 기능이 있다.
• 응답 오류 발생 시 그냥 에러를 던지는 것이 아닌 getFallback 함수를 불러서 거기에 있는 것들을 return 해주게할 수 있다. 예를 들어 쿠팡에서 추천 상품 보여주는 섹션이 있는데 거기가 오류가 났을 경우, 그냥 아무것도 없는 빈칸으로 보이게 하는게 아니라 getFallback 함수로 미리 지정해둔 default 추천 상품들을 보여주거나 할 수 있다
• 단점 → 자바만 사용 가능
• 그래서 다양한 플랫폼에서 사용할 수 있게 애플리케이션 단에서 작동하던 기능들을 인프라 단으로 내려버렸다. 이게 Service Mesh Architecture이다. 대표적으로 Istio 솔루션이 있다

3-2. Service Mesh 개념

• 서비스 A가 서비스 B를 호출하면 (코드 단) 중간에 proxy가 가로채서 Control Plane으로 보내버리고 Control Plane은 설정된 정책(ex. 초당 100call)에 따라서 트래픽 속도를 조절하던가 해서 서비스 B 쪽으로 보내준다.
• 또한 Control Plane이 중간에서 모든 호출들을 관리하기 때문에 로그를 한곳에서 관리할 수 있게 되고 각 서비스들의 Dependency 관리가 가능해진다
• 코드의 수정 없이 이런 것들이 가능해진다 (인프라 단에서 동작하기 때문에)

• 코드의 수정 없이 트래픽 라우팅도 가능하다

• 모니터링도 가능
• 정말 많은 기능들이 있다. 하지만 항상 이것들이 꼭 필요한가를 먼저 생각해보자. 안 그러면 오버 엔지니어링이 될 수 있다. 그리고 인프라 운영의 난이도가 높아짐

3-3. Distributed Transaction

• 가장 쉬운 방법은 트렌젝션 로그를 각각 비교해서 서로 다른지 확인 - Comparing Log

• 각각이 다른 서버이기 때문에 로그로 확인하기 힘듬
• 그래서 헤더에 Id를 만들어서 넣어줌. 그러면 Trace Id 1로 검색하면 위에 전체를 서치할 수 있고, Span Id를 통해 각각의 어느 서버에서 에러가 발생했는지 확인할 수 있다

• 메서드 호출할 때마다 매개변수로 넘기게 구현하지 말고 Thread Local 영역(쓰레드 전역변수)을 사용하면 간단하게 구현할 수 있다.

• 분산 트렌젝션 모니터링 오픈 소스

오픈 소스 Zipkin

오픈 소스 Jaeger

3-4. Important part of the Microservice Architecture

• 컨웨이의 법칙 : 소프트웨어 아키텍쳐의 구조는 소프트웨어를 개발하는 팀의 구조를 따라야 한다

• Product vs Project :
  1. Product는 만들고 계속해서 개선해서 나가는 것
  2. Project는 요구사항을 가지고 만들면 끝
• 이런 분산형 아키텍쳐는 Product와 잘 맞는 아키텍쳐이다

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

• 마이크로 서비스 공부할 때 보면 좋은 사이트
  https://learn.microsoft.com/en-us/azure/architecture/microservices/design/patterns

Design patterns for microservices - Azure Architecture Center