[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 18차 - MSA

📚 서론

이번 주 포스팅은 MSA (MicroService Architecture)에 대해 써보겠습니다.

 

사실 특강은 몇 주 전에 했는데 그땐 내용 정리도 덜 됐고

무엇보다 오라클 비교글이 너무 잘 써진 바람에 어쩔 수 없었습니다...

덕분에 ERD를 몇 번을 갈아엎었는지...🫠

 

그렇게 속 썩인 것 치곤 테이블 생성 이후엔 별다른 차이점은 없습니다.

 

테이블 생성에만 이렇게 차이가 나는 걸 보면...

어쩌면 데이터베이스의 핵심은 테이블 구조에 있는 걸지도 모르겠네요.🤔

 

음? 그러니까 갑자기 DB구조가 궁금해지는데..? 나중에 찾아볼까?

 

 

 

 

 

 

🎷 MSA 탄생 배경

전통적인 웹 애플리케이션 구조는

프론트 엔드, 백엔드, 데이터베이스로 나뉘는 3계층 아키텍처입니다.

셋이서 일심동체!

 

예시로 홈페이지에 게시판을 하나 추가한다고 해보죠.

 

가장 먼저 DBA에서 게시판의 데이터를 담을 테이블을 생성할 것이고

백엔드에서 만들어진 테이블에 연결해 데이터를 가져오거나 추가, 생성, 삭제하는 API를 만들고

프론트 엔드는 API를 이용해 클라이언트가 조작할 수 있는 화면을 만들어줄 것입니다.

경우에 따라선 혼자 다 하는 경우도 있고요...🫠

 

 

이 방식은 구조적으로는 깔끔했지만 서비스가 커질수록

 

팀원끼리 코드 충돌도 자주 일어나고

한 기능만 수정해도 전체를 다시 빌드해야 하거나

트래픽이 몰리면 전체 시스템을 확장해야 하고

장애가 발생하면 애플리케이션 전체가 멈춰버리는 일이 생기기도 했습니다.

 

단 하나만 잘못해도 애플리케이션 전체가 안 돌아가...

 

이러한 문제를 해결하고자

비즈니스 기준으로 서비스를 나눠 관리하자는 아이디어가 생겨났고

이것이 바로 마이크로 서비스 아키텍쳐(MSA)입니다.

 

 

 

 

 

🎺 Gateway

서비스를 나눠 관리하는 건 좋은데 그러자면 URL 경로가 달라지게 됩니다.

클라이언트가 알아서 이용하려는 서비스에 맞춰 찾아갈 수도 있겠지만 제법 번거롭겠죠?

 

그래서 등장한 방책이 게이트웨이(gateway)입니다.

 

 

게이트웨이는 클라이언트의 요청을 가장 먼저 마주하는 컴포넌트입니다.

 

클라이언트의 요청을 확인한 후 적절한 경로에 알아서 포워딩(=요청을 다른 곳으로 넘기는 것) 해줍니다.

 

가장 먼저 마주하는 컴포넌트이므로 인증, 로깅 같은 공통 기능을 처리하기도 합니다.

 

 

강사님이 스프링 부트 공식 문서를 통해 실습하는 방법을 알려주셨기에

공식 문서를 참고해 간단한 Gateway 예제를 실습해 보겠습니다.

 

1️⃣ Initializr를 이용해 Gateway 프로젝트 생성

스프링 부트 공식 문서 가이드에서 Building a Gateway를 검색하면 게이트웨이에 대한 가이드를 볼 수 있습니다.

https://spring.io/guides/gs/gateway

 

그중 Starting with Spring Initializr 항목을 확인하면 필요한 의존성을 선택해둔

Initializr로 이동할 수 있는 링크가 있습니다.

pre-initialized project 클릭!

필요 의존성이 추가된 initializr 페이지

 

필수적으로 필요한 의존성은 Reactive Gateway이며 Resilience4J와 Contract Stub Runner는

실습에 사용할 샘플(=서비스 단위로 별도의 포트로 분리된 프로젝트)을 대신할 의존성입니다.

 

저는 샘플로 쓸 프로젝트 2개를 만들어둔 상태이므로 Resilience4J와 Contract Stub Runner는 제외해주었습니다.

 

필요에 따라 Group, Artifact, Name, Package name 등을 수정해도 되고

저처럼 초기 상태 그대로 GENERATE를 해서 압축파일을 다운로드 해줘도 됩니다.

생성된 프로젝트 압축파일 다운로드

 

 

2️⃣ 게이트웨이 테스트 해보기

압축파일을 해제한 다음 IDE로 프로젝트를 열어줍니다. (저는 인텔리제이를 사용했습니다.)

 

Writing Test

 

공식문서를 살펴보면 Writing Test 항목이 있는데

여기에 적힌대로 Application.java 파일을 찾아 빈을 추가해줘야 합니다.

 

저는 프로젝트명을 gateway로 하였으니 GatewayApplication.java 파일을 찾으면 됩니다.

 

src/main/java/기본 패키지 경로로 들어가서 GatewayApplication.java 파일을 찾고

GatewayApplication 클래스 내부 가장 하단에 공식문서에서 추가하라는 빈을 복사해 붙여넣습니다.

추가해야하는 빈

 

빈에서 필요한 최소 요소는 route와 그 안의 path와 uri 입니다.

 

그 외에는 전부 삭제한 다음 매핑할 패스와 해당 패스로 들어왔을 때 포워딩할 경로를 적어줍니다.

 

경로 하나당 route 하나를 작성해야 하므로 분리한 서비스 수만큼 route를 작성해야 하고

마지막에는 .build()를 반드시 붙여줍니다.

완성한 빈

 

추가로 앞서 만든 서비스 프로젝트들과 포트를 분리하기 위해 게이트웨이 포트를 8888로 설정해주었습니다.

포트 설정

 

이제 완성한 게이트웨이 프로젝트를 실행하고

이어서 분리된 서비스 프로젝트들도 실행해주면

localhost:8888/posts/ 경로로 요청하면 자동으로 localhost:8081로 포워딩 되고

localhost:8888/comments/ 경로로 요청하면 자동으로 localhost:8082로 포워딩 됩니다!

 

 

 

 

 

📯 MSA의 단점

1️⃣ 운영 복잡도 증가

게이트웨이를 이용해 자동으로 포워딩까지 해줬지만 문제는 이제부터 시작입니다.

 

서비스가 점점 더 많이 분리되면 그만큼 연결해야 하는 route가 늘어나고

보안을 위해 경로를 게이트웨이에 직접 언급하지 않도록 별도의 공간에 저장해야 할 필요성이 생깁니다.

 

이를 위해 Config Server를 추가하고

나중에는 클라이언트 분산을 위해 Eureka Server도 추가해줘야 할 것입니다.

 

 

MSA는 앞서 이야기 했던 전통적인 3계층 아키텍쳐의 문제점들을 해결해줄 수 있지만

파생되는 문제를 해결하고자 또 다른 해결책을 필요로 하게 되면서 점점 더 복잡한 구조를 가집니다.

 

복잡한 구조만큼 모니터링, 배포, 로깅 방식도 복잡해집니다.

 

 

2️⃣ 개발 난이도 상승

복잡한 구조만큼 개발 난이도도 상승하게 됩니다.

 

 

3️⃣ 데이터 일관성 문제

또한 서비스가 분리되어 DB에 접속하는 경로가 늘어난 만큼

데이터에 일관성을 유지하는 문제도 신경써야 합니다.

 

예를 들어 주문과 결제로 서비스가 나뉘었다고 가정해 보겠습니다.

 

주문을 접수하는 동시에 결제를 진행하게 된다면

접수된 주문 내역을 DB에 업데이트하면서 동시에 결제정보도 DB에 저장해야 할 것입니다.

 

나뉜 두 서비스가 동시에 DB를 업데이트 하려고 하면 누가 먼저 수정할지,

중간에 오류라도 생겨 둘 중 하나의 작업이 누락되면 어떻게 롤백할지 등등... 트랜잭션 처리가 꽤나 복잡해집니다.

 

 

4️⃣ 네트워크 비용 증가

뿐만 아니라 각각의 서비스가 별도의 프로젝트로 실행되므로

정보를 주고 받는데 발생하는 네트워크 비용도 함께 증가하게 됩니다.

 

 

 

 

 

🔥 결론

MSA는 분명 문제를 해결하고자 시작한 개념이었는데

거기서 파생되는 문제로 인해 또 다른 새로운 방책이 생겨나면서 점점 더 복잡해졌습니다.

 

이런 걸 보면 세상에 완벽한 아키텍처란 없는 것 같습니다.

 

하지만 상황에 가장 적합한 아키텍처는 찾을 수 있겠죠?

 

그걸 위해선 열심히 개발 근육(?)을 키워야겠지!

 

최선의 방법을 찾을 수 있도록

나중에는 MSA 뿐 아니라 다양한 아키택쳐를 접해봐야겠습니다.