모놀리식으로 배포 까지 성공하였지만 우리의 프로젝트에는 다음과 같은 특징이 있었습니다.
- 서비스
- EC2 Free Tier 를 사용하기때문에 한정적인 자원
왜 MSA 로 전환을 해야할까?
전환을 고민할때 두가지를 고민했습니다.
1. 사용자입장에서
2. 개발자 입장에서
물론 이 두가지를 만족하기엔 쉽지 않을거라고 생각합니다. 이 두가지를 최대한 만족시키는것이 MSA 로의 전환이라고 생각을 했고 그 이유는 아래와 같습니다.
1. 서비스
변경/확장 용이
문제식별:
서비스 라는 말은 결국 사용자의 needs에 맞춰 우리의 프로젝트를 변화를 시킬 수 있다는 말 입니다. 변경하기에 용이해야하지만 현재 모놀리식은 변경을 할때 하나하나 전부 수정을 해줘야합니다.
결론:
결합도를 느슨하게하고 각서비스 별로 관리 할 수있도록 하면 변경/확장성이 용이해질겁니다.
사용자 입장에서의 서비스
문제 식별:
우리는 프로젝트에 서비스를 더 키우고싶습니다. 하지만 모놀리식은 1개의 서비스때문에 모든 서비스를 이용하지 못할 수 있습니다. 2023.05.12 기준으로 알고리즘 서비스만 제공하지만, 추후에 팀프로젝트, 학습 스터디 등 사용자들이 원하는 서비스를 점차 도입하여 확장 시키고자 합니다.하지만 1개의 서비스 때문에 다른 서비스들을 이용하지 못한다는것은 문제가 있다고 생각하였습니다.
결론:
각 서비스별로 나누어 관리하고 문제가 있다면 그 문제를 해결해야하지만 그 문제때문에 다른 서비스를 이용하지 못하면 안된다고 생각
2. 한정적인 자원
물론 과금을하여 인스턴스를 더 좋은 것을 사용 즉, 오토스케일링 하여 scale-up scale-out 을 통해 서버의 성능을 향상시키면 되는 문제입니다. 하지만 우리는 서비스 제공이 목적이며 현재 별다른 수익이 없기때문에 부담이 될 수밖에없습니다.
이러한 상황에서 각 서비스별로 독립적으로 나누고 쿠버네티스를 통해 관리한다면 좀더 효율적으로 리소스를 사용 할 수 있을것이라 판단했습니다.
3. 어떤 아키텍처를 사용할 것인지?
우리는 스케줄링 기능으로 서비스가 자동화 되어있습니다. MSA 에 DDD 방식을 많이 사용하지만 event driven 방식으로 설계하는것이 좀더 적합하다고 생각을 하고 적용할 예정입니다.
4. 오버엔지니어링 은 아닌가?
이제 막 시작한 프로젝트 이기때문에 큰 트래픽이 발생하지않으며 MSA 의 큰장점인 독립적인 서비스를 제공하는 측면에서 MSA로 전환하기에는 이르지 않은가? 라는 생각이 들긴 했습니다.
하지만
-
아키텍처 경험
개발자라면 서비스 목적에 맞는 코드를 짤줄 알아야하고 아키텍처를 설계할줄 알아야 한다고 생각합니다. 그런 측면에서 모놀리식 -> MSA 전환을 A to Z 하나하나 직접 함으로써 아키텍처의 이해도가 올라가고 응용함에 있어 큰 도움이 될것입니다. -
다양한 기술스택 경험
MSA 는 독립적인 서비스로 다양한 기술스택을 사용할 수 있습니다. 따라서 이러한 기술을 왜 사용해야하는가? 다른 기술스택과 차이점은 무엇인가? 라는 생각을 가지며 접근 하며 여러가지 기술스택을 사용해볼 수있었습니다. -
대용량 트래픽 처리
2번과 유사하다고 할 수있지만 제가 대용량 트래픽을 경험하기는 쉽지않습니다. 하지만 대용량 트래픽을 처리할때 어떤식으로 구현하는지? 주로 비동기 처리를 하게되는데 동시성 문제와 트랜잭션 처리 등 다양한 방면에서 생각 할 수있는 경험이었습니다.
과 같은 점들이 오버엔지니어링 이라는 걱정을 없애주었고 과감하게 도입하게 되었습니다.
회고
MSA 로 전환 하고자 하는데 고려 해야할 것이 많았습니다.
- bounded context는 어떻게 나눌것인지?
- DB분리를 어떻게 해야하는지? 성능 저하의 문제는 없을지
- DB를 분리를 하면 DB동기가 잘 이루어 질 것인지?
- MS 의 API 교환은 어떻게 진행할 것인지?
- 여러가지 아키텍쳐가 있는데 어떤 방식을 사용할 것인지 어떻게 우리 프로젝트에 맞게 변형 해야할지
등등 고려해야할 것이 너무많았고 첫 MSA 프로젝트다 보니 우리 프로젝트에 맞게 사용할 수 있을지 좀더 고민을 해봐야겠다고 생각이 들었습니다.
