인턴의 당돌한 고래사육(a.k.a OJT 프로젝트에 MSA를 태워?) - 2

DevSeoRex·2023년 10월 29일

Micro Service Architecture Opensearch msa webflux

🤠 신에겐 아직 10일이란 시간이 남았나이다..

첫 Opensearch 쿼리 성공 후 속전속결로 API 제작이 끝나자 자신감이 넘치기 시작했습니다.
Spring Cloud 제품을 쓰라는 요구사항이 있었기 때문에 사이드 프로젝트를 기획하며 연습해둔 얄팍한 MSA 구축 지식을 써보고 싶은 마음도 커지고 있었죠..

그래! 어차피 과제인데 실험 정신이 중요한거야!
라는 정신 승리 버프와 함께 바뀌고 바뀌어 현재 아키텍처가 탄생하게 되었습니다.

꽤나 많은 Spring Cloud 제품들을 사용하게 되었는데, 이것들에 대해서 간단히 정리하는 시간으로 이번 게시글을 다뤄볼까 합니다.

Spring Cloud Eureka

Spring Cloud Eureka는 MSA에서 충족시켜야 할 패턴인 Service Discovery 패턴과 연관있는 제품입니다.

MSA와 같이 복잡한 분산 시스템을 가지고 있는 경우, 대부분 서비스는 원격 호출로 구성되게 됩니다.
원격 서비스 호출은 IP 주소와 포트를 이용하는 경우가 많습니다.

클라우드 네이티브 환경에서 개발을 하면서 Auto-Scaling이나 Self-Recovery등 다양한 이유로 동적으로 IP가 변경되는 일이 많아졌습니다.

즉, 애플리케이션 코드나 설정 파일(yml 등)에 호출할 서비스의 IP 또는 포트를 작성해 두는 것으로는 동적으로 변경된 IP 주소를 알아낼 방법이 없다는 의미이기도 합니다.

Spring Cloud에서 이런 서비스 디스커버리 역할을 해주는 제품 중 하나가 Spring Cloud Eureka 입니다.

Eureka는 Eureka Server와 Eureka Client로 구분할 수 있습니다.
Eureka Server는 서비스 레지스트리 역할을 하는 서버 그 자체라고 할 수 있고,
모든 마이크로 서비스는 Eureka Sever에 등록되기에 Eureka Client라고 할 수 있습니다.

Eureka의 주된 역할은 Eureka에 등록된 서비스의 Heartbeats를 설정한 주기에 따라 주기적으로 확인하고, 응답이 오지 않는 서비스는 제거합니다.

대부분 API Gateway 패턴과 같이 쓰이기 때문에, API Gateway에서 Eureka에 등록된 서비스 이름을 기반으로 라우팅하는 용도로도 사용합니다.

Eureka는 서비스의 인스턴스 ID, IP, PORT 정보를 Local Cache에 등록하여 관리하게 됩니다.

Spring Cloud Gateway

SCG(Spring Cloud Gateway)에 대해서 보기 전에, API Gateway에 대해서 먼저 알아보겠습니다.

API Gateway는 Reverse Proxy와 닮은 점이 많습니다.
요청이 들어오면 어디로 가야하는지 라우팅 해줄 수 있고, 가장 앞단에 있기 때문에 들어오는 요청의 내용을 로깅하고 보안을 위한 인증 & 인가 작업을 해줄 수 있습니다.

MSA에서 인증 & 인가를 API Gateway 한 곳에서 책임지지 않고 서비스마다 그 책임을 부여한다면 인증과 인가는 공통 관심사인데 스프링의 핵심 개념인 AOP와도 맞지 않아 패러다임 불일치를 가져가게 됩니다.

Spring Cloud Gateway는 Netty를 이용한 비동기 처리를 이용해 높은 성능을 자랑하는 Spring Cloud의 표준 API Gateway 입니다.

모든 사용자는 API Gateway를 통해 요청을 수행하게 되고, API Gateway는 Predicates를 활용해 다양한 규칙을 설정하고 각 규칙마다 필터를 추가하거나 부가 작업을 할 수 있도록 지원하고 있습니다.

저는 이번 프로젝트에서 API Gateway를 통과하는 모든 요청에 대해 DB에 저장하는 로직을 LoggingFilter를 통해 수행하도록 했습니다.

사용자는 API Gateway를 통해 요청을 보내게 되고, API Gateway는 요청 Path와 맞는 Predicate를 찾아 올바른 서비스에 라우팅하게 됩니다.

Spring Cloud Config

Spring Cloud Config는 분산 시스템에서 설정 정보(application.yml)를 외부에 보관할 수 있도록 지원해주는 서비스입니다.

Spring Cloud Config를 이용하면 여러가지 장점을 얻을 수 있습니다.

여러 서버의 설정 파일을 중앙 서버에서 관리할 수 있다.
서버를 재배포 하지 않고 설정 파일의 변경사항을 반영할 수 있습니다.

Spring Cloud Config Server는 여러가지 방법으로 설정 파일을 외부에서 관리할 수 있는데, 로컬 Git 저장소나 파일 시스템 또는 원격 Git 저장소등을 이용할 수 있습니다.

보통은 원격 private git repository에 ssh를 이용해 접근하는 것이 일반적입니다.
Spring Cloud Config Server는 민감한 정보 보호를 위해서 암호화와 복호화 기능을 제공합니다.

private git repository에는 암호화된 설정 정보를 업로드하여, 탈취되었을때 의미 없는 정보를 주도록 유도하고 애플리케이션에 필요한 설정 정보들은 모두 Spring Cloud Config Server가 복호화 하여 평문으로 제공하게 됩니다.

설정 정보가 변경 되었다면, Spring Actuator의 refresh API를 호출해야 변경 사항이 마이크로 서비스에 반영됩니다.

만약 마이크로 서비스가 매우 많은 경우에는 일일히 Actuator의 refresh API를 호출하는 것도 부담이 될 수 있고, 실수로 누락할 가능성도 있습니다.

이 문제를 해결하기 위해 Spring Cloud Bus를 이용합니다.

Spring Cloud Bus

Spring Cloud Bus의 특징은 아래와 같습니다.

분산 시스템의 노드를 경량 메시지 브로커와 연결
상태 및 구성에 대한 변경 사항을 연결된 노드에게 전달

Spring Cloud Bus를 이용하면 마이크로 서비스 하나만 busrefresh를 호출해줘도 다른 서비스들도 변경 사항이 있다면 이벤트가 전파되어 새로운 설정정보를 반영합니다.

Spring Cloud Config Server에 요청을 보내서 이벤트를 전파할 수 있도록 Spring Cloud Monitor도 이용하도록 결정했습니다.

Spring Cloud Monitor

Spring Cloud Monitor를 활용하면 설정 정보가 변경되었을때 변경을 감지하고 자동으로 반영해주는 역할을 해줄 수 있습니다.

repository에 웹훅을 걸어두면 설정정보 변경부터 반영까지 완전 자동화 시킬 수 있게 되는 것입니다.

Zipkin & Micrometer Tracing Bridge Brave

Spring Boot 3.X 버전을 채택하면서 Spring Cloud Sleuth를 사용하지 못하게 되었습니다.
Spring Boot 3.X 버전 부터는 Micrometer Tracing Bridge Brave를 이용해야 Zipkin과 연동할 수 있습니다.

Zipkin을 활용해 분산된 마이크로 서비스들을 추적하고 요청이 잘 처리되고 있는지, 각 서비스별로 의존성은 어떻게 구성되어 있는지를 확인할 수 있습니다.

Zipkin을 이용해 로그를 ES와 같은 저장소에 저장할 수 있습니다.
Zipkin은 분산환경에서 로그 트레이싱을 위해 트위터에서 개발되었고 가장 활성화된 오픈 소스입니다.