[나의 MSA 구축 일기] 처음 MSA를 구축해보며 겪었던 시행착오들

 

해보고 싶어서 그랬어요.

 

작년 여름이었다. 제대로 공부 한 번 해보자는 생각으로 JPA를 공부하고 있었는데 MSA라는 것을 알게되었다.

기존의 거대한 하나의 애플리케이션을 쪼개 여러 개의 애플리케이션으로 분리하고, 서로간의 통신은 RESTful-API로 구현하는 아키텍쳐인데 거기서 오는 장점에 매료되어 바로 관련 자료를 찾고 프로젝트를 시작했다.

 

• 각각의 모듈(분리된 애플리케이션)은 서비스의 특성과 목적에 따라 다른 개발 환경을 가질 수 있다.
• 제대로 구축된 MSA에서는 특정 모듈이 오류가 발생해 정상적인 서비스 제공이 불가능하더라도 전체 서비스가 죽지 않고 해당 모듈을 이용하는 서비스만 제한되었다.
• 특정 서비스의 코드 개선, 비즈니스 로직 수정 등의 변경이 발생할 경우 자그마한 하나의 모듈만 재배포하면 된다.
• MSA를 공부하면 동시에 공부할 것들이 넘쳤다.

 

2주 정도 찾아봤을까, 대략적인 내용은 파악했지만 실제로 어떻게 MSA를 적용하는지는 감이 오지 않았다. 그래서 주변에 사이비 신도마냥 "MSA를 아시나요?" 하고 물어보고 다녔다. 그런 내 모습이 사이비 신도 같았는지 정말 몰랐는지 주변에는 MSA를 알고있는 사람이 나타나지 않았다.

 

결국은 수소문을 포기하고 구글신에 맡기기로 했다. 다행히 MSA 관련 예제 프로젝트를 잘 만들어주신 블로그를 찾았고, MSA를 해보고 싶은데 어떻게 시작할지 모르는 개발자들은 아래 블로그를 참고하면 좋을 것 같다.

 

요령과 기본(Spring)

위 블로그를 참고해 다섯개의 마이크로 서비스로 구성된 MSA 프로젝트를 세팅했고, 수많은 삽질이 시작되었다.

이번 포스팅에서는 그 삽질 중에서 두가지 정도를 포스팅 해보려고 한다.

 

---

 

철이 없었죠. 뭔지 궁금해서 MSA를 했다는게.

 

나는 똑똑한 편이 아니다.

사실 좀 바보같기도 하다. 간혹가다 똥인지 된장인지 먹어봐야 알기도 한다. 그리고 이 때가 그랬다.

 

어찌어찌 기본적인 구성이 완료되고, Bootstrap을 이용해 UI 프로젝트를 구성했다. 그리고 첫번째 삽질이 시작됬다.

ajax를 이용해서 데이터를 불러오게 코드를 작성했는데, 바보같이 요청 주소를 바로 gate-way로 해버렸다. 때문에 ajax를 사용하는 모든 코드에서 gate-way의 도메인과 gate-way에서 각각의 microservice로 요청을 넘겨주는 route path까지 노출되었다.

 

gate-way ➡️ microservice 방향의 zuul route path가 UI 프로젝트의 js에 박혀버려, zuul route path가 변경되면 모든 코드를 수정해야했고, 사용자에게 요청의 주소가 노출되었다.

 

 

 

뒤늦게 이 사실을 깨닫고 Spring RestTemplate을 UI 프로젝트에 적용시켰고, gate-way에 직접 요청을 보내는 모든 트랜잭션 코드를 수정했다.

• 변경 전 : JS(ajax) -> gate-way
• 변경 후 : JS(ajax) -> UI Project Servlet(Controller) -> Spring RestTemplate -> gate-way

 

---

 

왜 좋은 아이디어는 하고나서 생각날까요.

 

Spring RestTemplate을 UI 프로젝트에 적용하면서, DTO 클래스를 작성했다. 각각의 마이크로 서비스에 요청하는 데이터와 응답한 데이터를 DTO 객체를 통해서 통신을 하는데, 이 DTO 클래스를 작성할 때 아무 생각도 안한게 나의 문제였다.

 

UI 프로젝트에서는 메뉴별로 패키지를 구분해두었는데, 동일한 DTO 클래스를 각각의 패키지에 만들어버린 것이다.

좀 더 상세하게 설명하자면,

 

1. UI 프로젝트에는 고객 관리, 결재 메뉴가 있고 각각 customer, sale 패키지로 구분되어있다.
2. 고객 관리 메뉴에서 고객을 조회하기 위해 customer.template 패키지에 고객 마이크로 서비스로 GET /customer/{id} 요청을 보내는 로직을 작성했고, 응답 DTO를 customer.dto 패키지에 만들었다.
3. 결재 메뉴에서 고객 조회가 필요해 sale.template 패키지에 고객 마이크로 서비스로 GET /customer/{id} 요청을 보내는 로직을 또 작성했고, 응답 DTO도 역시 sale.dto 패키지에 만들었다.

그래서 고객 마이크로 서비스에서 응답 DTO 또는 고객 조회 요청의 변경사항이 생길때 마다 두 곳의 코드를 모두 수정해야했다.

 

 

이번 삽질도 호되게 당하고 또 수정했다. common 패키지를 만들고 그 안에 dto와 template 패키지를 만들었다.

• common.dto ➡️ 마이크로 서비스와 통신 시 사용되는 DTO를 모아두었다.
• common.template ➡️ 마이크로 서비스와의 Spring RestTemplate 통신을 위한 클래스를 마이크로서비스별로 작성해두었다.

 

---

 

그래도 삽질이 아예 도움이 안되는건 아니다. 왜 이런 방식으로 하는게 나은지 몸소 겪으면서 똑같은 실수는 반복하지 않기 때문이다.

그리고 나는 오늘도 삽질을 한다.