etc/특강, 강연, 세미나

우아한 모노리스 - 박용권님

hojak99 2020. 1. 24. 19:29

운이 좋게 "우아한 모노리스" 라는 세미나를 듣게 되었다. 

https://www.facebook.com/woowahanTech/photos/a.1925530564354206/2487165348190722/?type=3&theater

 

우아한Tech

[마감] 2020년 우아한Tech의 첫 세미나 1월 우아한테크세미나 우아한형제들 박용권님의 "우아한모노리스" 세미나 소식을 전합니다.🙇‍♀️🙇 하단 내용을 확인하시고 링크를 통해 신청해주세요. 😉 제목 : 우아한모노리스 일시 : 1월 23일 목요일 오후 7시 30분 장소 : 우아한형제들 작은집 7층 교육장 http://naver.me/Gx536FCe...

www.facebook.com

 

간단하게 얘기하자면 박용권이라는 분은 기존 모놀리틱 서비스에서 마이크로서비스로 전환한 후 다시 모놀리틱 서비스로 전환을 하신 것데 애해서 이야기를 하셨다.

### 모놀리틱 서비스 -> 마이크로 서비스??

박용권님께서 말씀하신 것을 내가 느낀대로 얘기하자면 모놀리틱 서비스에서 마이크로 서비스를 전환하면 확장성, 배포성, 장애 회복성이 높아지는 등 모놀리틱 서비스에서 느꼈던 단점들을 해결해주는 듯 했지만, 또 다른 상황이 발생했다는 것이다.

마이크로서비스로 전환하면서 서비스는 불안해져 장애 직전까지 가는 상황이 존재했으며 조직 규모 상 N개의 서비스를 1명의 개발자가 관리해야 할 수 있으며, N개 서비스를 동시적으로 배포할 때 운에 맡기는 등, 비즈니스 로지이 여러 서비스에 존재했을 때 특정 기능을 수정해야 한다면 여러 서비스의 코드를 확인해야 하기 때문에 생산성이 낮아진다는 것이다. 

아마 장애 직전까지 가는 상황은 아마 다음과 같은 상황 때문에 그럴 것 같기도 하다. 

사용자 - > A 서비스 요청 -> B 서비스 요청 -> A 서비스 요청 -> 끝

이런 식으로 계속 요청을 하니 요청은 하나인데 요청이 여러 개로 생기는 마법과 같은 상황이 존재할 수 있을 듯하다. 즉, 설계를 잘 해놓고 이런 상황이 생기지 않도록 잘 분리시켜야 한다.

즉 조직 규모에 맞춰서 마이크로서비스, 모놀리틱을 사용해야 한다. 무작정 마이크로서비스로 구성한다고 해서 뿅! 하고 모든게 해결되는 것이 아니다.

 

### 마이크로서비스 -> 모놀리틱 서비스??

여러 서비스로 나타낸 서비스를 다시 하나의 서비스로 합치려고 한다. 

먼저, 프로젝트 구조(패키지 등)를 일관성 있게 변경하도록 해야하며, 의존성도 생각한 뒤에 저장소를 합쳐야 한다. 이 때 저장소를 새로 팔지 기존 커밋 히스토리를 위해 합칠지는 선택에 따른다.

박용권님께서 인용하신 문장 중 하나를 내가 느낀대로 얘기해보자면 좋은 아키텍처는 모놀리틱에서 마이크로서비스로 가든 다시 모놀리틱으로 갈 수 있어야 한다는 얘기였다.

이제 이 세미나의 거의 중심이 되는 이야기다.

모듈형 모놀리틱 구조란 뭘 말하는 것일까? 내가 느끼기엔 모놀리틱 구조이면서,,,, 마이크로서비스 구조이다,,,, 라고 말할 수 있을 것 같다.

예를 들면 모놀리틱 구조로 프로젝트를 구성하지만 내부에 모듈로 여러 서비스를 분리시켜 놓는다. 그 뒤 여러 모듈로 분리시킨 것을 이용해서 기능을 개발하는 것이다.

이 때 모듈은 도메인으로 분리해야 한다. 여기서 살짝 DDD(Domain Driven Design) 개념이 나오긴 하지만 그거까진 얘기하지 않도록 하겠다.

하여튼 각 모듈은 도메인 별로 나뉘어져 있으며 각 내부에는 간단한 CRUD 정도의 기능만 존재.
이 때 해당 기능들은 특정 interface 를 구현하는 클래스 내에 구현하며, 외부에서는 이 interface 를 DI 받아 사용하도록 한다.

그리고 application 에서는 해당 interface 를 DI 받아 실제 비즈니스 로직을 작성하는 식으로 개발을 하면 좋다! 라고 하시는 것 같다.
이 때 각 모듈들은 독립적인 모듈이다. 즉, 이 모듈 자체가 서비스가 될 수 있어야 한다는 말이다. 이게 바로 "좋은 아키텍처란 모놀리틱에서 마이크로서비스로, 다시 모놀리틱으로 갈 수 있어야 한다" 라는 것을 뜻하는 듯하다.

---

듣고 이해는 했지만 이런 모듈형 모놀리틱 구조로 경계가 무너지지 않도록 잘 개발하려면 매우 신경을 써서 개발을 해야 할 것 같다.

그리고 각 모듈마다 각각의 dataSource 를 이용할 때 transaction 설정은? 여러 모듈을 이용해야 한다고 했을 때 interface 는 어디에 있어야 하고 어디서 해당 interface 를 구현할까? 와 같은 질문은 아직 제대로 해결되지 않은 상태이다.

직접 한 번 개발을 해봐야할 것 같다. 

해당 구조는 마이크로서비스까지는 오바인데,,,,, 모놀리틱 구조로는 개발하기 싫다..... 일 때의 해결책이 될 수도 있을 것 같다는 생각이 든다.
그래서 지금 사이드프로젝트에 한 번 적용해볼 예정이다.

---

두서없이 썼지만 이런 세미나도 내가 이제 이해할 수 있는 것을 보니 신입은 벗어난 것 같다.

반응형