사이드 프로젝트 진행 전 기술 스텍을 정하기 위한 나의 생각을 정리한다.
네 번째로 어떤 아키택쳐로 구성 할 것인가에 대해 정리해본다.
Monolithic / MSA 가 뭔데 ?
Monolithic : 단일 코드 베이스 애플리케이션
MSA : 애플리케이션을 작은 서비스로 분할하고 각 서비스가 독립적인 애플리케이션의 집합
모놀리식과 MSA의 장단점에 대한 내용을 조금씩 간추려서 작성해본다.
Monolithic 의 장점 과 단점
장점
- 단순성: 변경 사항이 발생할 경우 필요한 모든 코드가 한곳에 존재한다.
- 간편한 배포: 단일 프로젝트로 배포하면 되기 때문에 간편하다.
- 보편성: 프로젝트를 쉽게 시작할 수 있다.
- 디버깅이 쉬움: 추가 구성을 수행하지 않고 코드를 실행하여 디버깅하면 된다.
- 쉬운 테스트: 테스트 수행이 쉽다.
- 쉬운 모니터링: 오류 시 문제가 발생한 위치를 식별하기 쉽다.
단점
- 규모가 커지면 유지 보수가 어려움: 시간이 지남에 따라 애플리케이션이 커지면 관리가 어려울 수 있다.
- 유연하지 않은 확장성: 애플리케이션의 특정 부분에 대해 요청을 받으면, 이 부분만 확장할 수는 없고 전체 애플리케이션을 확장해야 한다.
- 대규모 팀 작업이 어려움: 모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀이 작업에 영향을 줄 수 있다.
- 기술 사용 제한: 모놀리식 애플리케이션을 다른 기술로 변경하는 것은 많은 공수가 들어간다.
- 전체 서비스 중단 위험: 특정 서비스가 치명적 에러가 발생하면 전체 애플리케이션에 영향을 미치게 된다.
MSA 의 장점 과 단점
장점
- 유연한 확장: 각 마이크로서비스는 다른 서비스와 독립적으로 확장할 수 있다.
- 독립적인 배포: 마이크로서비스는 느슨하게 결합되어 있으므로 하나의 마이크로서비스만 배포할 수 있다.
- 단일 실패 지점 제거: 애플리케이션을 여러 소규모 서비스로 분할하여, 전체에 영향을 미치는 단일 실패 지점을 제거한다.
- 전체 서비스 중단 위험 감소: 특정 마이크로서비스가 중단되더라도 전체 애플리케이션에 영향을 미치지 않고, 해당 마이크로서비스에만 영향을 미친다.
- 최적의 데이터베이스를 소유: 각 마이크로서비스별로 최적의 데이터베이스를 소유할 수 있다.
- 다양한 기술 수용 가능: 각 마이크로서비스는 서로 다른 기술을 가질 수 있다.
- 민첩성: 마이크로서비스를 이용하면 전체 애플리케이션에 큰 영향을 주지 않고, 새로운 것을 추가할 수 있어 새 버전을 배포하는 것이 매우 쉽다.
단점
- 개발 생산성 필요: 여러 개의 마이크로서비스 중 하나에 새로운 기능을 구현해야 할 때, 다른 서비스에 접근할 수 있도록 로컬에서 많은 애플리케이션을 실행할 수 있는 환경을 갖춰야 한다.
- 디버깅이 어려움: 디버깅하거나 테스트를 위해 둘 이상의 마이크로서비스를 실행해야 해서, 디버깅이 어려울 수 있다.
- 마이크로서비스 간 통신: 동기/비동기 방식의 통신을 고려해야 하며, 이런 부분이 애플리케이션의 복잡성을 증가시킨다.
- 오류 처리가 어려움 : 두 개 이상의 마이크로서비스를 사용해 요청을 처리한다면, 첫 번째 마이크로서비스에 대한 요청에서 문제 발생 시 작업을 이전 상태를 되돌릴 수도 있음을 고려해야 한다.
- 표준화 부족: 마이크로서비스에서 발생하는 모든 오류 또는 문제를 모니터링할 수 있는 중앙 모니터링 체계를 갖추는 것이 필요하다.
- 오류 식별의 어려움: 마이크로서비스 아키텍처에서 오류를 식별하는 것은 모놀리식보다 훨씬 복잡하고 어렵다. 특히 비동기 통신일 때 더욱 어렵다.
그래서 너는 뭘로 하고 싶은데 ?
결론 : Monolithic
나는 MSA를 정말 조금 이지만 혼자 찍어먹어 봤었다. 내가 아직 많이 부족해서 그럴지도 모르지만 그 때의 경험 이후로 MSA에 대해 아직 필요성도 느껴보지 않은 주니어가 굳이 유행 따라서 MSA를 시도하는 건 어리석은 짓이라는 것을 매우 크게 깨달았다.
1. MSA가 어렵다는 말은 겁주는게 아니다.
MSA의 개념만해도 모놀리식에 비해서 매우 어렵다고 생각한다.
그런데 MSA를 도입하겠다 라고 한다면 수도없이 많은 지식이 필요하게 된다.
마이크로 서비스 간의 통신을 위한 지식,
각각의 DB를 가지고 있으니 데이터 싱크를 어떻게 맞출건지,
메시지 큐를 사용할 것이라면 어떤 메시지 큐가 적합한지,
카프카를 선택 했다면 카프카 메시지 처리 중 랙이 생겼을 때 어떻게 대처 할 것인지,
내가 겪은 것만해도 많은데 이게 빙산에 일각이라고 생각한다.
2. MSA를 공부 할 만큼 기본에 충실하다고 생각하는가 ? 난 아니다.
MSA를 시도 한다면 사실상 해당 프로젝트의 목적을 MSA에 대한 이해도를 높이는 사이드 프로젝트라고 하더라도 전혀 과한 목표가 아니라고 생각한다. MSA로 전환 했기 때문에 발생하는 이슈들을 테스트 해보고 해결해 나가는 과정 자체가 매우 방대하고 많은 지식을 공부해 나가야 한다고 생각하기 때문이다.
하지만 주니어인 내가 구현도구에 관한 이해도, 요구사항 분석/해결 능력, 협업능력과 같은 것을 뒤로 하고 MSA를 파고들만큼 주니어로써의 역할을 완벽히 수행 하는가 ? 라고 물어본다면
나는 아직 아니라고 생각한다. 노력하고 있지만 분명히 부족하고 언젠간 꼭 필요한 지식이겠지만 현재의 내 역할에 충실하면서 추가적인 지식을 습득하는게 중요하다고 생각한다.
3. MSA를 사용하는 것은 그만한 인력이 배치되어 있을 때 사용한다고 생각한다.
우리는 백엔드 인원이 총 3명이다. 가능한 각 마이크로서비스만 맡으려고 노력하긴 하겠지만 상황에 따라 타 마이크로서비스를 담당하게 될수도 있고 1명이 2개의 마이크로서비스를 담당할 수 있다.
이런 상황에서의 MSA는 사실상 정말 먼 미래의 대비는 될 수 있겠지만 현재는 생산성을 매우 낮추는 걸림돌이 된다. 타 마이크로 서비스와 연동을 위해 관련 코드를 매번 작성해야하고 DB마저 분리했다면 생각해야 할 부분은 더 늘어난다.
우리는 가능한 빨리 포트폴리오를 만들고 싶다 또한 백엔드 개발자만 있는 팀이 아니다 그렇기에 기한이 미뤄지는 것의 책임은 백엔드 개발자들만 가져가는 것이 아니라 팀 모두가 가져가게 되기 때문에 MSA는 현 상황에는 매우 어려운 결정이라고 생각된다.
