MSA (Microservices Architecture)
MSA는 마이크로서비스 아키텍쳐로 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.
고가용성, 유연한 스케일링, 배포가 빠르고 쉽다는 장점이 있으며, 기능 단위로 Application을 모듈화 하는것이 큰 특징이다. MSA의 반대는 모놀리식 구조로 하나의 애플리케이션으로 모든 기능을 갖고 있는 것을 의미한다.
그림에서 보듯MSA의 각 마이크로서비스들은 자체 비지니스 계층과 데이터베이스를 가지고 있다. 이렇게 함으로서 하나의 마이크로 서비스의 변경이 다른 마이크서비스에 영향을 주지 않게 된다. 또한 마이크로서비스들은 서로간 메소드 호출이 아닌 HTTP, REST와 같은 프로토콜을 이용해서 통신을 하게된다.
MSA를 대표적으로 도입하여 성공한 사례가 바로 넷플릭스이다. 얼마나 성공적이였나면 이들이 7년여간에 걸쳐서 도입한 MSA를 Netflix OSS로 공개하였고 스프링은 이 오픈소스의 주요기능들을 스프링 클라우드와 함께 담아서 스프링 클라우드 넷플릭스를 만들었다.
스프링 클라우드 넷플릭스 == (스프링 클라우드 ∩ 넷플릭스 OSS) == Eureka, Hystrix, Ribbon, Zuul ... (넷플릭스 OSS 주요 기능 들) 이라고 볼 수 있다.
MSA의 특징
- 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트(모듈)로 분해하고 이들을 조합해서 솔루션을 제공한다.
- 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 이들은 비지니스 영역의 한 부분에서만 책임을 담당하게 되며, 애플리케이션에서 재사용될 수 있다.
- 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP, JSON과 같은 무상태의 경량 통신 프로토콜을 사용한다.
- 애플리케이션은 보통 JSON 프로토콜을 사용해서 통신하므로 서비스 구현 기술과는 무관하다. 즉, 마이크로서비스의 부분들을 서로다른 언어와 기술로 개발하더라도 구축하여 통신하는것이 가능하다는 것이다.
따라서 기존의 Java 스프링 애플리케이션에 가볍고 빨라야 하는부분만 Go언어로 구현하는 등 다양한 활용이 가능하다. - 마이크로서비스를 사용하므로서 조직은 명확히 정의된 책임 영역을 담당하는 소규모의 팀들을 갖게 된다. 이 팀들은 앱 출시라는 공통의 목표를 향해 일하면서도, 자기가 개발하는 서비스만 책임을 지게 된다.
MSA의 목적
이렇게 마이크로서비스를 도입함으로서 결과적으로 시스템에 대한 개발 및 운영 복잡성을 낮출 수 있다.
- 서비스별로 모듈화 하였으므로 특정 서비스에만 집중할 수 있고, 코드의 규모가 작아져서 효율적으로 유지보수를 할 수가 있다.
- RESTful API를 통한 통신을 통해 효과적인 상호 연계가 가능하다.
- 독립적인 서비스 단위로 규모확장이 가능하므로 효율적인 자원 활용이 가능하다.
MSA의 도입
MSA의 가장 중요한 기능 중 하나는 자동확장(Auto Scale-Out)이다. 자동 확장이란 특정 서비스에 트래픽이나 부하가 증가할 경우 인스턴스를 추가 생성하고, 반대로 잉여 자원이 남을 경우 불필요한 인스턴스를 서비스를 제거하는것을 의미한다.
서비스 단위로 확장이 가능하므로 매우 효율적인 자원 관리를 할 수 있지만 이를 위해서는 고려해야할 점이 많다. 먼저 동적으로 추가하는 인스턴스 정보를 다른 서비스로 전달하는 방법이 필요하다. 또한, 새롭게 추가된 인스턴스 간의 로드밸런싱을 고려해야 하고 장애 대응 방법도 필요하다.
빈번한 인스턴스의 확장 및 축소가 일어나고 각 서버들의 물리적 환경이 모두 다르다면 매우 복잡하고 어려울 것이다. 이러한 문제들을 해결하기 위해 넷플릭스 OSS는 어떠한 기능을 사용했는지 알아보자.
넷플릭스 OSS를 알아보기 위해 이들의 주요 기능을 상당부분 통합한 Spring Cloud Neflix를 통해 알아보겠다. Spring Cloud는 스프링 부트 기반으로 MSA 구축에 특화된 라이브러리들의 집합이다.
MSA 주요 기능
1. 서비스 디스커버리 서버(Service Discovery Server) _ Eureka
필요성
- MSA 구조에서 서비스들은 동적으로 확장되고 축소된다. 이를 운영자가 일일이 인스턴스 정보를 맞게 수정, 관리하는건 매우 어려울 것이다. 따라서 인스턴스의 상태를 동적으로 관리하는 서버가 필요한데 이 역할을 하는 것이 서비스 디스커버리 서버이다.
- 넷플릭스는 Eureka라는 이름으로 서비스 디스커버리 서버를 공개했다.
작동
새로운 인스턴스는 시작할 때 Eureka 서버에 IP, 호스트 주소, 포트 정보를 스스로 전송한다. Eureka 서버는 받은 정보를 가지고 일정한 간격으로 상태를 체크하면서 해당 인스턴스를 관리한다.
추가적인 인스턴스가 새로 실행될 때마다 자신의 정보를 서버에 동적으로 등록하므로 서비스 수평 확장 시(특정 서비스의 트래픽 부하로 인해 인스턴스를 늘려 처리량을 늘리는 것) 해당 인스턴스의 IP 정보에 대해 신경 쓸 필요가 없어졌다.
운영자들은 설정 파일에 Eureka 서버만 등록하면 되고, 서비스들은 다른 서비스를 호출 할 때 Eureka 서버에 등록된 인스터스를 조회하면 되는것이다.
2. 클라이언트 사이드 로드 밸런서 - Ribbon
필요성
- 모놀리식 시스템에서는 부하 분산을 위해 하드웨어 장비를 앞단에 두고 트래픽을 여러 서버로 분산했다. 이는 로드 밸런서에 장애가 생기면 전체 서비스에 문제가 생기는 위험성이 있다. 또한 동적으로 서버가 추가 / 삭제 되는 환경에서 하드웨어를 이용한 로드밸런싱으로는 한계가 존재했다. 이에 소프트웨어로 구현한 클라이언트 로드밸런서가 탄생했다.
- 넷플릭스는 Ribbon이란 이름으로 클라이언트 사이드 로드밸런서를 공개했다.
작동
참고로 이때 클라이언트는 사용자 단말이 아니라, MSA에서 다른 서비스를 호출하는 클라이언트 서비스를 말한다.
클라이언트 서비스는 부하 분산 알고리즘에 따라 호출할 서비스의 서버 목록 중 하나를 선택해서 호출한다. 이때 유레카와 연동하여 동적 리스트로 서버목록을 사용할 수도 있다.
이때 사용하는 알고리즘으로 순서대로 인스턴스를 고르는 Simple Round Robin, 서버의 응답시간에 따라 선택하는 Weighted response time, 3회 연속 호출 실패시 30초간 호출 목록에서 제거하는 Availability filtering 방식 등이 존재한다.
구성요소
Rule : 요청을 보낼 서버를 선택하는 알고리즘 (바로 위에 있는 알고리즘을 말함)
Ping : 서버가 살아있는지 체크하는 프로토콜
Server List : 로드 밸런싱 대상 서버 목록 / *Configuration을 통해 정적으로, 또는 Eureka를 통해 동적으로 설정할 수 있다.
3. 서킷 브레이커 (Circuit breaker) - Hystrix
필요성
- MSA도 특정 서비스에 과부하가 걸리거나 어떤 문제로 정상적으로 작동하지 않으면 전체 서비스에 장애가 전파될 수 있다. 이를 방지하기 위한 기능이다. 서킷 브레이커는 특정 서비스에서 발생한 장애가 전체적인 서비스의 장애로 확산되지 않도록 차단해주는 기능을 말한다.
- 넷플릭스는 Hystrix라는 이름으로 서킷 브레이커를 공개했다.
작동
Hystrix 서버는 각 서비스의 오류 상태나 복구 상태 그리고 현재 오류 내용이 무엇인지 파악한다. API호출 통계를 기반으로 상태 서비스에서 이상이 감지되면 즉시 통신을 중단하고, 문제가 있던 서비스를 격리한다. 이후 문제가 해결될 때까지 호출수를 제한한 후 정상이 되면 통신을 재연결하여 다시 호출을 받게 한다.
추가적인 기능은 폴백(Fallback)이 있다. 정해진 시간내에 호출이 실패하면 대신 동작하는 예외처리이다. 개발자가 폴백 메소드
를 구현함으로써 시스템 장애로부터 유연하게 복구를 실행할 수 있다. 예를들어 5초이상 응답이 없다면 서비스가 지연되고 있다는 팝업을 뜨게 하는 등 유연한 대처가 가능하다.
또한, 서킷 브레이커의 정보나 서버의 상태를 확인할 수 있는 모니터링 서비스도 제공하여 로그를 중앙 집중형으로 관리, 검색할 수 있다.
4. API 게이트웨이 - Zuul
필요성
- API 게이트웨이는 사용자 요청을 적절한 서비스로 프록시 or 라우팅 하는 MSA의 컴포넌트이다.
- 넷플릭스는 API 게이트웨이를 Zuul이라는 이름으로 공개했다.
작동
Zuul은 최전방에서 클라이언트의 요청을 받아 적절한 서비스에 전달하고 응답 결과등을 다시 클라이언트에 보내는 엣지 서버 역활을 한다.
추가적으로 필터기능을 제공한다. 사용자가 많은 서비스는 다양한 형태의 요청이 쏟아지는데 예상치 못한 요청도 있어서 운영 이슈가 발생할 수 있다.
이때 필터는 리소스의 인증 요구사항을 식별하고 조건에 어긋나면 요청을 거부한다. 또한 필터는 동적으로 작동하여 실시간 수정 반영이 가능하므로 서비스 중단 없이 즉각적인 대응이 가능하다.
Q. 사용자에게 Zuul(API 게이트웨이)만 오픈하고 다른 마이크로서비스의 종단점을 숨기는 이유가 무엇일까?
MSA 환경은 하나의 서비스에 여러 개의 서버가 존재할 수 있기 때문에 사용자에게 다수의 진입점이 생긴다. 진입점은 인증, 보안, 잘못된 요청 등을 처리해야하는 데 진입점에 변경이 필요한 경우 전체가 영향을 받기 때문에 관리가 어렵다.
따라서 도메인을 하나로 통합하고 단일 진입점을 생성하여 효율적으로 관리하기 위한 목적인 것이다.
주요기능
- 인증 및 보안 - 클라이언트 요청 시 각 리소스에 대한 인증 요구 사항을 식별, 미충족 시 해당 요청을 거부.
- 모니터링 - 모든 트래픽이 지나가는 곳이므로 의미있는 데이터와 지표를 수집할 수 있는 기능을 제공.
- 동적 라우팅 - 필요에 따라 즉시 원하는 백엔드 클러스터로 트래픽을 동적 라우팅 할 수 있다.
- 부하 테스트 - 성능 측정을 위한 부하 테스트 기능 제공.
- 트래픽 드랍 - 트래픽 용량을 할당할 수 있고, 초과 분에 대해 제한할 수 있다.
- 정적 응답 처리 - 백엔드로 안보내고 api 게이트웨이에서 바로 응답 처리할 수 있다.
5. Config 서버
Config 서버는 분산 시스템에서 애플리케이션의 환경설정 정보 특히 서비스, 비지니스 로직과 연관성 있는 정보들을 애플리케이션과 분리해 외부에서 관리하도록 한 환경설정 서버이다. 이를 사용하면 수많은 애플리케이션들의 환경설정 속성정보들을 중앙에서 관리할 수 있다.
환경설정 속성 정보는 일반적으로 DB 접속정보 들을 포함하는 메타데이터들이며 외부에 공개해서는 안되는 아이디 및 비밀번호들도 포함된다. 이런 값들은 application.yml과 같은 파일에 기록하여 사용하는데, 이러한 정보들을 마이크로서비스 별로 제각각 관리하게 될 경우 환경설정 값이 변경되면 모든 마이크로서비스들을 새로 빌드해야 한다. 만약 서비스의 수가 많다면 이에 대한 비용이 많이 발생할 것이다.
따라서 이러한 문제를 해결하기 위해서 Spring Cloud Config 컴포넌트가 제공된다. Config서버를 구축하여 사용하면 마이크로서비스들의 환경설정 파일을 중앙서버 한곳에서 관리할 수 있게 된다.
위 그림과 같이 Config 서버가 구동될 때 환경 저장소(Git, DB 등)에서 설정내용을 가져온다. 각 마이크로서비스들은 서비스가 구동될 때 Config 서버에서 설정 내용을 내려받아 해당 정보를 가지고 애플리케이션이 초기화되어 구동된다.
만약 서비스 운영 중에 설정파일을 변경해야 할 경우 Spring Cloud Bus를 이용하여 모든 마이크로서비스의 환경설정을 업데이트 할 수 있다. 스프링 클라우드 버스는 각 서비스들간의 실시간 메시지 통신 역활을 하는 RabbitMQ 또는 Kafka와 같은 경량 메시지 브로커들을 사용할 수 있도록 해주고, 이 메시지 브로커를 이용해서 각 서비스들에게 변경된 Config 설정정보를 전파하게 되는 것이다.
Reference
- https://www.samsungsds.com/kr/insights/msa_and_netflix.html
- https://www.egovframe.go.kr/home/ntt/nttRead.do?menuNo=76&bbsId=171&nttId=1809
- https://howtodoinjava.com/microservices/microservices-definition-principles-benefits/