[Reminder] Spring Cloud Netflix로 알아보는 MSA

Tech/Cloud

[Reminder] Spring Cloud Netflix로 알아보는 MSA

철테코 2023. 2. 19. 12:59

안녕하세요!

SSAFY 9기 기자단으로 활동 중인 박철순 기자입니다.

오늘은 현대화 애플리케이션의 대표 구조인 MSA 와 함께

백엔드에서 MSA를 실제 구현할 수 있는 Spring Cloud Netflix를 소개해드리겠습니다.

[MSA vs Monolithic]

Monolithic Architecture

모놀리틱 아키텍처는 소프트웨어 모든 구성 요소가 한 프로젝트에 통합된 형태로 기존까지 많이 쓰이던 아키텍처입니다.

Micro Service Architecture(MSA)

MSA는 작고, 독립적으로 배포 가능한 각각의 기능을 수행해야 하는 서비스로 구성된 프레임워크입니다.
각 서비스는 완전히 독립적 배포가 가능하고, 다른 기술 스택이 사용 가능합니다.

Monolithic의 한계

부분의 장애가 전체 서비스의 장애로 연결될 가능성이 큽니다. (특정 서비스 과부하 -> 전체 트래픽에 영향)
하나의 서비스가 강하게 연결되어 있어. 서비스의 변경 및 수정이 어렵습니다.
(프레임워크와 언어에 종속적이기 때문에, 다양한 언어 및 프레임워크 반영이 어렵습니다.)
최근 CI/CD를 통한 빠른 개발과 테스트, 배포까지 애자일한 방식의 개발을 지향하고 있는데 모놀리틱한 구조는 이러한 애자일한 방식과 거리가 있습니다.
(모놀리틱 구조는 작은 변경에 대한 테스팅과 배포 시간 등 오래걸리는 구조입니다.)

MSA의 장점

각각의 서비스가 모듈화되어 있어, 각각 개별의 서비스의 개발을 빠르게 하며, 유지보수도 쉽게 할 수 있습니다.
팀 단위 기술 스택을 다르게 가져갈 수 있습니다.
(회사가 기존에 java 기반 Spring으로 개발하고 있었어도, 신규 서비스 개발 시에 장고로 개발해도 상관없습니다.)
마이크로서비스는 서비스별 독립적 배포가 가능합니다.
(도커, 쿠버네티스의 발달로 서비스의 경량화가 쉬워졌기 때문에 CI/CD도 가볍게 할 수 있습니다.)
서비스의 부하에 따른 개별적인 Scale-Out, 오토 스케일링이 가능합니다.
(클라우드 컴퓨팅의 발달로 자원에 대한 비용적인 측면이 유리합니다.)

MSA의 핵심

제가 생각하는 MSA의 핵심은 다음과 같습니다.

서비스 모듈화와 서비스 단위 개발 및 배포
각 서비스는 Rest API와 같은 가벼운 방식으로 통신
오토스케일링 - 부하에 따른 서비스 단위 서버 증설, 감소 자동화
API Gateway - 사용자의 트래픽 분산을 위한 로드 밸런싱

[Spring Cloud Netflix]

Spring Cloud란?

Spring boot 기반 MSA 구축에 특화된 라이브러리의 집합으로 그 중 Eureka, Hystrix, Ribbon, Zuul 등 많은 넷플릭스 Open Source Software가 통합되어 있습니다.

왜 넷플릭스는 MSA 인가?

넷플릭스는 2007년에 심각한 DB 손상이 발생해 3일간 서비스 장애를 겪었습니다.

이 때문에 클라우드 시스템으로 이전 필요성 느꼈습니다. 그렇게 고가용성, 유연한 스케일링, 빠르고 쉬운 배포의 장점을 가진 MSA로의 전환을 시작했습니다.

MSA로의 전환을 위한 기술들을 도입하고 개발하여 7년에 걸쳐 클라우드 환경으로 이전에 성공했습니다.

넷플릭스는 MSA 전환 노하우와 문제해결 방법을 오픈소스로 공개했습니다. 그것이 Spring Cloud Netflix 입니다.

[Spring Cloud Netflix의 주요 흐름]

Eureka

서비스 디스커버리 서버(Service Discovery Server) (인스턴스 상태 동적 관리 서버)

MSA 구조에서 서비스들은 동적으로 확장되고 축소하며, 오토스케일링이 이루어집니다.
이때 운영자가 일일이 각각의 인스턴스 정보를 수정하고 관리하기란 쉽지 않습니다.
따라서 인스턴스의 상태를 동적으로 관리하는 서버가 필요했고,
이를 서비스 디스커버리 서버라고 말하며
넷플릭스는 Eureka라는 이름으로 공개했습니다.

Eureka(Sevice Discovery) 동작 과정

각 서비스들은 생성과 동시에 Service Discovery(Eureka서버)에 서비스와 위치 정보(IP, port)를 등록합니다.
클라이언트는 Load Balancer 혹은 API Gateway를 통해 요청을 보냅니다.
Load Balancer 혹은 API Gateway는 Service Discovery를 통해 맞는 서비스를 찾고 그에 대한 정보를 다시 넘겨줍니다.
Load Balancer 혹은 API Gateway는 받은 정보를 바탕으로 해당 서비스에 요청을 보냅니다.

Ribbon

클라이언트 사이드 로드 밸런서 (Client Side Load Balancer)

기존 모놀리틱 구조의 로드 밸런서는 L4스위치 같은 하드웨어 장비였습니다.
MSA에서 로드밸런서는 소프트웨어로 구현된 것입니다.
Ribbon은 같은 기능, 서비스를 하는 여러 인스턴스 서버 중에서 어느 서버로 트래픽을 호출해야 할 지 알려주게 됩니다.

Ribbon 구성

ServerList – 로드 밸런싱 대상 서버 목록
Rule – 요청을 보낼 서버를 선택하는 규칙
(일반적 라운드로빈)
Ping – 서버 List가 살아있는지 체크

클라이언트 서비스는 부하 분산 알고리즘에 따라 서버 목록 중 하나를 선택하여 호출합니다.

Zuul

API 게이트웨이(Gateway)

Zuul은 넷플릭스가 개발한 Spring Cloud Netflix에 특화된 API 게이트웨이입니다.

API 게이트웨이는 사용자 요청을 적절한 서비스, 알맞는 서비스로 라우팅합니다.

Zuul은 최전방에서 클라이언트의 요청을 받아 적절한 서비스에 전달하고 결과를 다시 클라이언트에 보내는
엣지 서버 역할을 합니다.

Zuul은 추가적으로 필터 기능을 제공합니다.
사용자가 많은 서비스에는 다양한 요청이 쏟아집니다. Zuul필터는 사용자 요청에 대해 각 리소스의 인증 요구사항을 식별하고 이를 만족하지 않는 요청은 거부합니다.
이외에도 Zuul은 데이터 및 통계를 분석하여 모니터링이 가능합니다.
또한, 스트레스 테스트, 멀티 리전 복원 등의 기능도 지원합니다.