MicroServices

 

마이크로 서비스에 대해서 이번 블로그에 정리해보려고 한다.

이는 서버 구조 개념으로 기존의 방식을 먼저 소개하고 어떤 방식으로 변화했는지 알아보려고 한다.

 

우선, 기존에는 Monolith Architecture 기반으로 서버를 구성을 하였다.

 

 

 

Monolith Architecture

모든 업무 로직을 하나의 애플리케이션 형태로 묶어 서비스 하는 형태를 의미한다.

한 서버를 생각해보면 검색 기능, 로그인 기능, 메신저 기능 등 다양한 기능들을 한 애플리케이션에 묶어서 개발을 하였었다.

 

개발 과정을 살펴보면,

여러가지 팀들이 각각 코드 작성을 한 가지 소스코드 저장소에 작성을 하고 이를 빌드, 테스트, 릴리스 과정(젠킨스/CI, 백로그, 테스트)을 통해서 하나의 애플리케이션으로 생성한다.

 

이는 큰 단점을 갖고 있는데 예를들어, 한 웹사이트에 여러가지 기능이 있다고 가정하자. 그 때, 한 기능 수정시 모든 기능을 수정해야하는 대참사가 불러와질 수 있다. 따라서, 매우 복잡하고 이런 기능 수정 등에 대한 민첩성이 낮으며 확장성 또한 현저히 낮다.

또한 이는 새로운 기술 적용에 대해서도 굉장히 부정적인데, 예를 들어, 한 팀이 Mysql, 한 팀이 Oracle 사용, 이런것이 불가능하다는 얘기다. 

 

단점 정리

- 구조가 매우 복잡해 개발자가 프로그램의 흐름을 읽기 어려움.

- 기능 수정 등에 대해 민첩성이 현저히 낮음. 예를 들어, 이 기능을 수정하면 어떤 다른 기능에 영향을 끼치는지 파악하기 어려움.

- 따라서 기능 확장에 대해서도 부정적.

- 기술의 다양성도 불가능한 형태, A팀은 Oracle, B팀은 Mysql 어려움.

- 트래픽 처리에 부정적.

 

 

 

SOA(Service Oriented Architecture)

서비스 단위로 애플리케이션을 제작하고 이 애플리케이션들이 커뮤니케이션이 가능하게 하여 전체 서비스를 제공하는 형식을 의미한다.

이를 통해, 기능마다 서로 다른 기술Set을 적용할 수 있으며 각 팀의 기능 변화 등 다양한 변화에 대해서 각자 빌드, 배포가 가능한 형태이다.

 

개선점

- 구조가 좀 더 단순해짐, 즉, 각자의 팀에서 자신이 맡은 기능만 구현하면 됨.

- 기능 수정의 민첩성도 증가.

- 기능 확장에서도 좀 더 긍정적.

- 기술 다양성 증가, 빌드, 배포에서도 좀 더 유연해짐.

 

그럼 서비스 단위마다 통신은 어떻게 하는가? 

- SOAP ( SImple Object Access Protocol) : ESB(Enterprise Service Bus)라는 별도의 미들웨어를 통해서 커뮤니케이션, 통신을 진행, 하지만 굉장히 무거운 통신 방식.

 

단점 정리

- 각 기능간 통신 방식 SOAP 방식이 굉장히 무거움.

 

 

 

MicroServices(MSA)

SOA의 기본 형태를 지키되 서비스 간 통신 방식을 Rest API, gRPC 등 다양한 방식으로 변경한 형태.

하나의 마이크로서비스는 독립적으로 디자인, 개발, 배치, 서비스 관리되는 잘 정리된 비즈니스 하나를 제공한다.

이 마이크로서비스들이 모여 하나의 큰 서비스를 이루는 구조를 의미.

 

 

구조

• 1. Client(Web, App으로 부터 Request) ->
• 2. API Gateways(내용들을 알맞는 기능 Application에게 전달) ->
• 3. 각각 Application (각각의 Application은 내부에서 통신하는 방식)

 

 

MicroServices Traffic vs Monolith Traffic

• Monolith : 서버의 수를 증가시키는 것이 어려움, 따라서 트래픽 관리를 위해 서버의 성능을 높여야하는데(Vertical Scaling) 비용이 굉장히 비쌈.
• MicroServices : 서버의 수를 증가시키는게 유연, Cloud 환경(AWS 등), Cloud Native 환경 (Docker, Kubernates) 등을 활용해 여러가지 서비스들이 나눠져 구현되는 게 가능.

 

장점 정리

- 작은 코드 베이스를 가지므로 관리가 용이하다.

- 개별적인 컴포넌트로 스케일 관리가 쉽다, 즉, 서버의 성능을 높이기 용이하다.

- 여러가지 기능을 다양한 기능에서 사용가능하다.

- 결함을 고립하여 전체 시스템의 다운을 방지한다, 한가지 기능 문제시 다른 기능에 영향이 적다.

- 동시에 작업하는 더 작은 개발팀 구성이 가능하다, 개발의 속도 향상 및 복잡도 축소.

- 독립적인 배포가 가능하다.

 

 

단점 정리

- 서비스간의 강한 일관성(ACID)를 갖기 어렵다.

- 분산환경이므로 디버깅과 추적이 어렵다.

- End-to-end 테스트의 필요성 증가.

- 애플리케이션 개발과 배포방법(CI/CD)가 중요해진다, 각각 서비스 별로 개발, 배포가 되기 때문에.

- 서비스간 호출, 통신에 따른 커뮤니케이션 비용이 증가한다.

 

 

(+) API Gateways(Edge Server)

- Client에서 각각의 서비스(기능) 접근 시, 각각의 서비스 접근에 대한 인증/인가 를 동일하게 가져야하며 API 호출에 대한 기록, 관리에 어려움이 존재함. -> API Gateways 가 해결해준다.

- Client는 API Gateways를 통해 각각의 서비스에 접근 가능, API Gateways가 각각의 마이크로서비스들을 매핑해 줌.

- 종류 : Zuul1.0, Zuul2.0, Spring Cloud Gateway 등

 

 

 

Spring Cloud Netflix

MicroServices의 문제점들을 해소하고자 Spring과 Netflix에서 제공해주는 다양한 기능들을 의미.

 

 

MicroServices의 단점과 Spring Cloud Netflix에서 제공하는 해결책 (Library)

 

 

• 다수의 필요한 서비스를 어떻게 찾아야 하는가? 
• -> 이용량이 많은 마이크로서비스를 여러 인스턴스 생성을 통해 사용자들이 사용하는 구조에서
• -> Eureka (서비스 디스커버리)

 

• 사용하기 위한 다수 마이크로 서비스의 인스턴스를 어떻게 결정해야 하는가?
• -> Ribbon (클라이언트 - 사이드 로드 밸런싱( 인스턴스 관리 ))

 

• 개별적인 마이크로 서비스가 응답하지 않을 때 어떤 일이 발생하는가? ( 각각의 마이크로 서비스가 연결되어 있다면? )
• -> Circuit-Breaker/Hystrix ( 결합허용 )

 

• 보안, 속도 제한과 같은 서비스 제안을 어떻게 제안하는가?
• -> OAuth2 ( 서비스 보안 )

 

• 다수의 마이크로 서비스는 서로 어떻게 커뮤니케이션 하는가?
• -> Feign/Spring Cloud Stream ( HTTP/메시징 )

 

• 마이크로 서비스 간 ACID는 어떻게 달성하는가?
• -> Conductor/Camel ( CQRS )

 

• 마이크로 서비스 간 여러가지 기술 환경( Java, Node.js, Mysql, Oracle 등 ) 관리를 어떻게 할 것인가?
• -> Spring Cloud Config ( Git 중앙 집중 관리 )

 

• 한 기능을 여러가지 마이크로 서비스가 거쳐서 진행된다고 할 때, 어디서 문제가 발생하는 지 추적은?
• -> Spring Cloud Sleuth