[원티드 포텐업 BE 1기] 17주차 회고 - MSA 2차

17주차 회고하기

17주차에는 MSA를 사용하면서 필요한 서비스들에 대해서 학습을 진행했다. 

Service Registry, API Gateway, Config Server, Message Queue, Obserbillity, Log 등을 배웠다.

> 진짜 배운게 많았다.. 

 

Service Discovery / Registry

MSA는 여러 서비스 간의 호출로 이루어 진다. 서비스 호출은 IP주소와 Port를 이용하는데, 클라우드 환경에서는 서비스가 동적으로 변경되는 일이 잦아 IP가 동적으로 변경된다. 

 

그래서 한 서비스가 다른 서비스를 호출 할 때, 서비스의 위치 (IP & port)를 알아낼 수 있는 기능이 필요하다.

이를 서비스 디스커버리(Service Discovery)라고 한다.

기본적으로 서비스를 등록하고, 등록된 서비스의 목록을 반환한다. 

 

Service Registry는 서비스의 위치를 정보를 저장하는 데이터베이스이며, 항상 최신 정보를 유지해야하며 고가용성이 필요하다.

 

Java Spring 환경에서는 Spring Cloud Netflix Eureka(유레카)를 사용해서 서비스 디스커버리를 구현하지만, 최근 MSA는 서비스마다 필요한 기술스택이 다르기 때문에 java에 종속되지 않도록 구성한다고 한다. 그래서 수업 시간에는 Consul을 이용하여 서비스 디스커버릴르 구성하였다. 

 

Gateway

 

웹 서비스에서는 항상 최신 서버로 요청을 보내는 것이 중요하다.
그런데 클라우드 환경에서는 서버가 늘어나거나 줄어들면서 IP 주소가 자주 바뀔 수 있기에 클라이언트가 직접 서버 IP를 알고 요청하는 방식은 관리가 어렵다.

 

이 문제를 해결하기 위해서 나온 기술이 Gateway이다.

 

Gateway는 클라이언트와 백엔드 서버 사이에 위치해서, 클라이언트의 요청을 받아 적절한 백엔드 서비스로 대신 전달해주는 역할을 한다. 

 

즉, 클라이언트는 Gateway 주소만 알고 실제 서버 IP 변경은 Gateway가 알아서 처리하게된다.

이 구조 덕분에 IP 변경 걱정 없이 안정적인 서비스 운영이 가능해졌다.

 

실습으로 Spring Cloud Routing - Reactive Gateway를 사용하여 비동기(Non-blocking)방식으로 동작하는 웹 서버를 구현했다.

 

 

Config Server

 

Config Server는 여러 서버에서 사용하는 설정 값들을 한 곳에서 관리해주는 서버이다. 

 

서버가 많아질수록 서버마다 application.yml을 각각 수정해줘야하는 문제가 발생한다. 설정 값이 서로 달라지면 오류가 발생하고 배포를 할 때 마다 설정 변경이 번거로운 문제가 있다.

 

이 문제들을 해결하기 위해서 Config server를 사용하는 것이고, 보통 Git 저장소에 저장해서 사용한다.

Config Server는 Git에서 설정을 읽어오고 백엔드 서버들은 Config Server에게 설정을 요청하여 빌드하게 된다.

 

Message Queue

 

Message Queue는 서버끼리 동기적으로 통신하는 것이 아니라 비동기적으로 메시지를 남겨두는 중간 보관함같은 것이다. 

 

해당 서비스가 필요한 이유

- 상대 서버가 느리거나 장애가 발생하면 요청을 보낸 서버도 같이 멈추게 된다.

- 요청이 한번에 몰리면 서버가 처리하지 못하고 성능 저하나 장애로 이어질 수 있다.

- 처리 순서/재시도 관리가 어렵다

 

Obserbillity와 Log

 

Obserbillity는 서비스가 잘 동작하고 있는지, 문제가 생겼으면 어디에 왜 생겼는지 특정 서비스를 사용해서 확인할 수 있음을 의미한다. 

단순하게 에러가 발생했다는 것이 아닌 원인까지 추적할 수 있는 상태가 목표인 것이다.

 

로그는 서버가 동작하면서 남기는 기록을 의미한다.

언제 요청이 들어왔고, 어떤 에러가 발생했는지 등 문제가 발생했을 때 트래킹하기 위해 사용한다.

마치며

17주차에는 MSA에 사용되는 사이드 서비스들에 대해서 학습을 하였다.

현재 진행하고 있는 프로젝트에 모든 사이드 서비스들을 적용해 볼 수는 없었지만.. 대기업 JD를 확인 했을 때, 보였던 용어들을 학습할 수 있어서 좋았다. 

 

하지만 MSA에서도 트레이드 오프가 있었는데, 그만큼 사이드 서비스를 서버로 만들어야 해서 돈이 많이 발생한다는 점이다.. 
그래서 실제 서비스 운영회사에서는 SOA(Service-Oriented Architecture)를 많이 사용한다고 한다.

 

그래서 다음에는 SOA에 대해서 개인 공부를 진행할 예정이다 !

 

Reference

1. https://velog.io/@wnwjq462/Service-Discovery-Registry