이번 주 토픽은, MSA!
MSA 의 개념
MSA 와 Monolothic Architrecture 의 비교
Netflix에서 사용되는 MSA 구성. 구성요소별 역할
MSA 운영 중 발생 가능한 문제점과 해결방안 (2가지 이상)
MSA 의 개념
MSA란?
MicroService Architecture의 줄임말.
마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크이다. 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 각 서비스들은 API 호출을 하는 형식으로 통신을 한다.
MSA 와 Monolothic Architrecture 의 비교
Monolithic Architecture
Monolithic이란 하나의 구조로 단단히 이루어진 이라는 뜻을 지니고 있다.
즉, 프로젝트가 하나의 아키텍쳐로 묶여져 이루어진 구조를 뜻한다.
웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고,
개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포되는 형태를 말한다.
이런 어플리케이션을 모놀리식 어플리케이션이라 하며, 웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태를 말한다.
주로 소규모 프로젝트에서 사용된다.
- 장점
-
로컬 환경에서 개발이 편리하다.
-
통합 시나리오 테스트 진행이 수월하다.
-
배포 과정이 간편하다.
- 단점
-
부분 장애가 전체 서비스의 장애로 확대될 수 있다.
개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 생겼을 때, 서비스 전체의 장애로 확대될 수 있다. -
부분적인 *Scale-out(여러 server로 나누어 일을 처리하는 방식)이 어렵다.
Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기 때문에 부분 Scale-out이 어렵다. -
서비스의 변경이 어렵고, 수정 시 장애의 영향도 파악이 힘들다.
여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대한 영향도 파악이 힘들다. -
배포 시간이 오래 걸린다.
최근 어플리케이션 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세이다. 그러나 규모가 커짐에 따라 작은 변경에도 높은 수준의 테스트 비용이 발생하기도 하며, 많은 사람이 하나의 시스템을 개발하여 배포하기 때문에 영향을 줄 수 밖에 없다. -
한 Framework와 언어에 종속적이다.
Spring framework를 사용할 경우, blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이나 선정했던 framework가 Spring이기 때문에 java를 이용하여 해당 모듈을 작성할 수 밖에 없다.
프로젝트가 하나의 어플리케이션으로 이루어져 있으니 개발 / 배포하기도 편하고, 전체적인 테스트가 수월하다.
하지만 프로젝트 규모가 점점 커질수록 Monolithic Architecture 의 한계가 있다.
너무 많은 기능들이 하나의 어플리케이션에 묶여있다보니 서로 의존성이 높아지고 이는 개발자들에게 있어서는 이해하기 어려운 코드가 된다.
실제로 아직 많은 소프트웨어가 Monolithic 방식으로 개발되고 유지되고 있으며 소규모 프로젝트의 경우에는 특별히 나눌 필요없이 Monolithic Architecture 가 더 합리적일 수 있다.
하지만 프로젝트의 규모가 커지고 한 프로젝트에 속한 개발자가 많아질수록 부적합하다.
다들 아시다시피 최근에 등장하는 프로젝트들은 모두 규모가 크고 많은 기능들을 필요하므로
MSA가 등장하였다.
Micro Service Architecture
Monolithic과 반대되는 개념으로 작은 단위의 서비스로 나누어 이루어진 구조를 뜻한다.
하나의 어플리케이션을 기능별(그 외의 다양한 기준)로 패키징하여 여러개의 작은 어플리케이션으로 나누어 서비스를 담당하도록 설계하는 구조이다.
- 장점
-
빌드 및 테스트 시간을 단축할 수 있다.
처음부터 끝까지 서비스를 빌드하고 테스트하는 시간은 같습니다. 하지만 개발을 하다보면 부분적으로 테스트를 해야하는 순간도 필요할텐데 MSA 는 이를 가능하게 하여 시간을 절약할 수 있다. -
유연하게 기술을 적용 가능하다.
서버가 분리되다보니 각 서버의 언어와 프레임워크도 유연하게 가져갈 수 있다.
auth 서버는 django로 채팅서버는 node로 구현하는 방식이 가능하다. -
scale out 가능하다.
-
서비스간의 연관성이 낮다.
한 서버에서의 문제가 다른 서버에 영향을 미치지 않게 된다.
- 단점
-
성능 이슈가 있다.
Monolithic 의 경우 다른 기능을 호출할 경우 같은 프로젝트 내에서 method 호출로 끝나므로 단순히 하나의 어플리케이션 내에서 일어나 매우 빠르고 문제의 소지가 적다.
하지만 MSA의 경우에는 다른 서비스 간에 Network 통신(주로 http)을 주고 받으므로 단순하지 않다. -
트랜잭션이 불편하다.
서버가 나뉘고 다른 서버 간의 트랜잭션 처리를 해야할 경우, 불편함이 따른다. -
개발 시간이 증가한다.
MSA 는 서버가 분리 됨에 따라 이에 따라 관리가 필요하다. DB가 서버에 맞춰 증가할 수도 있고, 로깅 / 모니터링 / 배포 / 테스트 등 여러 관리에 신경을 더 써야한다.
Netflix에서 사용되는 MSA 구성. 구성요소별 역할
Netflix OSS(Open Source Software)
‘Netflixed’라는 신조어가 있다.
직역하면 ‘넷플릭스 당하다’인데, 미국 실리콘밸리에선 기존 비즈니스 모델이 붕괴되었을 때 이 말을 사용한다.
Netflix는 실제로 여러가지 혁신을 하였는데, 그중에서 기존 Legacy 시스템은 MSA로 모두 전환하여 운영/개발 상의 효율성을 극대화 하였다.
2007년 심각한 데이터베이스 손상으로 3일간 서비스 장애를 겪은 넷플릭스는 신뢰성 높고 수평 확장이 가능한 클라우드 시스템으로 이전할 필요성을 느꼈는데, 단순히 플랫폼 이전만으로는 기존의 문제점과 한계를 탈피할 수 없다고 판단한 넷플릭스는 고가용성, 유연한 스케일링, 빠르고 쉬운 배포를 위해 MSA를 선택하였다고 한다.
그리고 MSA 전환을 위한 기술들을 도입하여 무려 7년에 걸쳐 클라우드 환경으로 이전하였으며, 이 과정에서 넷플릭스가 경험한 노하우와 문제해결 방법을 공유하기 위해 MSA 전환 기술을 오픈소스로 공개 하였다.
이렇게 탄생한 넷플릭스 OSS는 MSA를 도입하려는 많은 사람에게 좋은 선택지가 되고 있다.
Spring Cloud Netflix
Netflix 내부 솔루션 대신 Spring Boot를 사용하여 Netflix OSS 구성 요소를 함께 연결하려는 커뮤니티 노력이었으며, 시간이 지남에 따라 커뮤니티에서 Netflix의 오픈 소스 소프트웨어를 채택하는 데 선호되는 방법이 되었다.
Netflix는 2018 년부터 Spring Cloud Netflix 를 통해 커뮤니티의 기여를 활용하여 핵심 Java 프레임 워크로 Spring Boot로 전환하고 있음을 발표하게 되었다.
결론은 Netflix OSS와 Spring Boot의 결합은 Netflix 외부에서 시작되었으며, 이제 그것을 Netflix 내부에서 수용하고 있다.
Eureka
Service Discovery & Registry이다. Microservice Architecture에서는 기존의 Legacy한 Monolithic Architecture와는 달리 작은 Service 단위로 시스템을 구축 한다.
Service 단위로 시스템이 구축되다 보니 MSA에서는 이 Service들은 어떠한 Registry에 등록하고, 이 Registry를 기반으로 다른 서비스를 찾는 Service Discovery & Registry라는 개념이 필요하다.
Netflix에서는 Eureka라는 Service Discovery & Registry를 제공하고 있고, 우리는 잘 파악해서 사용하면 된다. 그래서 Eureka는 어떻게 이루어져 있을까?
Eureka는 크게 Eureka Server와 Eureka Client로 나뉘어 진다.
MSA 시스템에서의 모든 service들은 Eureka Client로 만들어지게 된다.
그리고 Eureka Client(각 service)들은 자신을 Eureka Server(Registry)에 등록한다.
Eureka Client는 자신을 Eureka Server에 등록하고 hostname, ip address, port 등 자신의 meta data를 Eureka Server(Registry)에 전송한다.
이 meta data는 Eureka Server(Registry)에 저장되는 것이다.
그리고 등록된 Eureka Client는 이 Registry에 저장된 다른 Eureka Client의 정보를 사용할 수 있다.
그리고 Eureka Server는 각 Client로 부터 30초마다(default) heartbeat(Eureka Client가 살아있음을 알리는)를 수신하게 된다.
Client로 부터 heartbeat가 오지 않으면 Eureka Server는 Client가 죽은 것으로 판단하고 Registry에서 제거하게 된다.
또한 Eureka Server는 모든 Client에게 Registry의 정보를 전달해주고, Client는 자신의 localStorage에 정보를 저장한다.
정리해보자면 각 Eureka Client가 자신의 정보를 Eureka Server에 보내고, Eureka Server는 각 Eureka Client에게 업데이트 된 정보를 전달해주는 체계를 가지는 것이다.
이는 다수의 서비스가 지속적으로가능하게 하며, 각 Eureka Client는 Eureka Server로 부터 받은정보를 일정 시간동안 보유하고 있어 다른 서비스의 연결에 문제가 되지 않는다.
Eureka의 활용도는 무궁무진하며 Netflix의 다른 component인 Hystrix, Ribbon, Zuul과 결합되어 질 때 활용도가 매우 높아진다.
Ribbon
클라이언트 사이드 로드 밸런서(Client Side Load Balancer)이다.
시스템 부하 분산을 위해 L4 스위치등 하드웨어 장비를 통해 앞단에 두어 부하를 분산하게 되는데, Ribbon은 클라이언트 소프트웨어로 트래픽을 분산/제어 할수 있다.
100개의 서비스가 있는 환경에서 트래픽 이슈로 서비스가 추가/삭제 된다면, L4와 같은 하드웨어에서도 똑같은 대응을 해야 하는데,그런일이 빈번하다면 꽤 고달퍼 질것이다.
Ribbon은 물론 정적 서버 리스트를 가지고 부하 분산을 할 수도 있으며, Eureka와 연동하여, 동적으로 리스트를 관리하면서 부한 분산이 가능하다.
부하 분산 방식도 라운드 로빈, 3회 연속 호출 실패 시 30초 동안 목록에서 제외하는 Availability filtering 등 여러가지 설계가 가능하다.
API Gateway 그리고 Zuul
- API Gateway
MSA는 작은 단위의 서비스로 분리함에 따라 서비스의 복잡도를 줄일 수 있으며, 변경에 따른 영향도를 최소화하면서 개발과 배포를 할 수 있다는 장점이 있다. 하지만 여러 서비스의 엔드포인트를 관리해야 하는 어려움이 있으며 각 서비스의 API에서 공통적으로 필요한 기능을 중복으로 개발해야 하는 문제가 있다.
API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리 할 수 있으며, 모든 클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 전달한다.
API Gateway는 즉 라우터 및 reverse proxy 기능뿐 아니라, 엔드포인트 서버에서 공통으로 필요한 인증, 접근 제어등 공통적인 부분도 구현이 가능하다.
zuul은 Netflix OSS에서 제공하는 API Gateway의 구현체라고 보면 된다.
- zuul
zuul은 인증요구 식별, 라우팅, 스트레스 테스팅 등등 여러 기능이 있는데, 요청 온 request를 필터 / 라우팅 하는 그림은 아래와 같이 표현될수 있다.
요청이 들어면 PRE Filter를 실행하고, ROUTING Filter에 의해 정해진 서버로 요청을 보낸다.
정해진 서버에서 응답이 오면 POST Filter를 실행시킨다.
Hystrix
분산 환경에서는 불가피하게 많은 서비스 종속성 중 일부가 실패한다.
Hystrix는 대기 시간 허용 오차 및 내결함성 논리를 추가하여 이러한 분산 서비스 간의 상호 작용을
제어하는 데 도움이되는 라이브러리이다.
Hystrix는 서비스 간 액세스 지점을 격리하고 여러 서비스에서 계단식 오류를 방지하며 대체 옵션을 제공하여 시스템의 전반적인 복원력을 향상시킬수 있다.
어떠한 특정 서비스에서의 응답이 지연되어 정의된 임계값을 넘게 되면, 기다리는 대신 사용자가 정의한 풀백(fallback) 메서드 실행하여 응답값을 클라이언트에게 전달하게 된다.
그리고 새롭게 들어오는 다음 request는 장애가 난 서비스에 컨택하지 않고 정의된 fallback 메서드를 즉시 실행하며 장애가 복구되면 hystrix는 모니터링 하고 있다가 정상화된 서비스에 다시 연결시켜 준다.
MSA 운영 중 발생 가능한 문제점과 해결방안
1.여러 서비스에 걸쳐져 있는 feature의 경우, 트랜잭션을 다루기 어렵다.
: 보상 트랜잭션 또는 부분적으로 composite 서비스로의 병합 고려한다.
2.여러 서비스에 걸쳐져 있는 feature의 경우, 테스팅이 복잡하다.
: 테스팅 계획 및 방법에 노력 투자한다.
3.서비스 간 dependency가 있는 경우 릴리즈가 까다롭다.
: 관련 개발조직 간 roll-out 계획 마련 및 dependency의 명백한 관리한다.
- 질문
FLO MSA 구조에서 Ribbon과 Zuul이 어떻게 적용되어있는지 궁금합니다~ 확인할 수 있는 페이지나 정리된 wiki가 있을까요?
MSA 운영에 대한 문제점을 찾는 중에 장애추적, 모니터링이 어렵다고 하는데 왜 어려운지 이해가 안됩니다. 혹시 이런 문제점이 나올만한 원인을 아시나요?
참고
https://phantasmicmeans.tistory.com/entry/Service-Discovery-Registry-Spring-Cloud-Netflix-Eureka
