* 피그마로 만든 이미지를 첨부했는데 다크 모드에서는 보기 별로 안 좋네요 .. ㅜㅜ 라이트 모드로 보시는 것을 추천드립니다 🥲
안녕하세요! 최근 들어 Spring Security를 공부하기 시작했는데요, 모놀리식과 마이크로서비스 용어가 자주 등장하여 이에 대한 궁금증이 생겼습니다. 두 아키텍처를 공부하며 알게 된 내용을 간략히 정리해 보려고 합니다.
우리가 서버 개발을 하다 보면 수많은 기능들을 개발하게 됩니다. 하나의 프로그램에 모든 기능을 쑤셔 넣는 것(?)을 모놀리식 아키텍처라고 합니다. 이렇게 여러 기능들을 하나의 프로그램에 다 쑤셔넣어서 개발하다 보면 많은 문제가 발생하게 됩니다.
모놀리식 아키텍처(Monolithic Architecture, MA)
모놀리식의 단점은 다음과 같습니다.
1. 기능 하나가 망가지면 전체가 망가진다.
프로그램을 개발하다 보면 한 기능을 개발하다가 나도 모르게 다른 기능을 건드리게 되는 경우가 많습니다. 이때 기능 하나를 잘못 건드려 망가지게 되는 경우, 프로그램 전체가 다 망가지게 되는 문제점이 발생합니다.
2. 하나의 기능을 실행하기 위해, 전체 프로그램을 실행시켜야 한다.
만약 신기능을 개발하게 되면, 이를 테스트, 컴파일, 빌드, 배포 등의 과정을 거쳐야 합니다. 모놀리식 아키텍처에서는 기능 하나를 실행시키기 위해 전체 프로그램을 실행시켜야 하기 때문에, 프로그램 크기가 크면 실행 작업이 오래 걸리게 됩니다.
3. 프레임워크 or 라이브러리 등의 업데이트 시 문제가 발생한다.
프로그램 내 프레임워크나 라이브러리의 버전을 업데이트 하다가 다른 기능들이 정상 작동하지 않는 대참사가 일어나, 코드가 업데이트 되지 않고, 썩는 문제가 발생하게 됩니다.
4. 코드가 복잡해질 수 있다.
소스 코드가 너무 복잡해지면, 신입 개발자가 그 코드에 적응하는 데 어려움이 생길 수 있습니다.
이러한 문제점들을 해결하기 위한 방법 중 하나가 여러 기능을 한 곳에서 개발하는 것이 아니라, 기능들을 나누어 독립적인 서비스로 운영하는 것입니다. 👉🏻 이 방법이 바로 마이크로서비스 아키텍처입니다.
마이크로서비스 아키텍처 (Microservies Architecture, MSA)
마이크로서비스 아키텍처로 설계할 시, 필요한 기능에 해당하는 서비스만 동작시키면 됩니다. 예를 들어, 로그인 기능이 필요하면 회원 서비스만 동작시키면 되고, 게시글 작성 기능이 필요하면 게시글 서비스만 동작시키면 되는 것입니다.
마이크로서비스의 장점은 다음과 같습니다.
1. 프로그램 수정이 편하고, 개선이 빠르다.
한 기능에 대한 수정이 필요할 시 해당하는 서비스만 건드리면 되기 때문에, 다른 기능을 건드려 오류가 발생하는 상황을 피할 수 있습니다.
2. 프레임워크나 라이브러리의 버전을 관리하기 쉽다.
작은 서비스 단위로 프레임워크나 라이브러리의 버전을 관리하기 쉬워, 코드를 원활하게 업데이트 할 수 있고, 코드가 고여 썩을 일이 없습니다.
3. 각 서비스에서 자유롭게 기술 스택 선정이 가능하다.
각 서비스별로 자유롭게 기술 스택 선정이 가능합니다. 예를 들어, Users 서비스에서는 Java 언어를 선택하고, Posts 서비스에서는 Python 언어를 선택하여 개발할 수 있습니다.
4. 클라우드 자원을 효율적으로 사용할 수 있다.
트래픽이 몰리는 서비스가 있으면 그 서비스만 선택해서 사이즈를 키울 수 있기 때문에, 클라우드 자원을 효율적으로 사용할 수 있습니다.
마이크로서비스를 운영할 때 자주 쓰이는 기술과 툴
- Docker: 컨테이너에 담아 서비스를 배포할 수 있습니다.
- Kubernetes, Docker Swarm: 컨테이너가 많아지면 이들을 관리합니다.
- Kafka: 서비스 간 메시지를 주고받을 때, kafka를 통해 빠르고 효율적으로 주고받을 수 있습니다.
- Prometheus: 서비스를 모니터링합니다.
- GitHub Actions: 서비스 배포를 자동화합니다.
그런데, 무작정 대기업을 따라 마이크로서비스를 썼다가 망한 사례가 많습니다. 마이크로서비스들의 다음과 같은 단점들 때문입니다.
1. 운영 복잡도 증가
마이크로서비스를 사용하면 개발 복잡도를 감소시킬 수 있지만, 운영 복잡도는 더 증가합니다. 마이크로서비스가 많으면 앞서 설명한 툴 사용이 거의 필수이기 때문에, 이를 관리하는 데 필요한 시간과 비용이 늘어납니다. 개발자가 적은 회사에서 마이크로서비스를 사용할 시 운영 시간이 늘어나 개발할 수 있는 시간이 줄어드는 문제점이 발생할 수 있습니다.
2. 서비스 간 통신 어렵다.
서비스 간 통신이 많으면 오래 걸리고, 누락되는 경우가 발생하게 됩니다. 또, 어떤 서비스랑 통신해야 하는지 한참을 찾아야 합니다.
3. 문제 발생 시 원인을 일으킨 서비스를 찾기 어렵다.
어떤 버그나 이슈가 생겼을 때, 어떤 서비스가 문제인지 찾기 어려운 문제점이 있습니다.
그럼 어떤 아키텍처를 선택해야 할까? 🧐
서비스가 크다고 해서 항상 마이크로서비스를 사용해야 하는 것이 아닙니다. 실제 MAU 1억 서비스인 stackoverflow도 마이크로서비스를 사용하지 않고 scale up monolith로 운영하고 있습니다.
또, 미래에 서비스가 커질 것을 대비해 처음부터 마이크로서비스로 만들 필요도 없습니다. 나중에 코드를 일부만 MSA로 변경해도 무방하다고 합니다. 실제 마이크로서비스의 개념을 정립한 Martin Flower도 "모놀리식으로 운영한 후, 나중에 마이크로서비스를 도입하라"라고 말했습니다.
실제 코드를 짜다가 너무 복잡해져 생산성이 저하되는 시점이 발생할 것입니다. 그러면 그 시점부터 한 두 개씩 마이크로서비스로 만들면 된다고 합니다. 마이크로서비스 때문에 운영 복잡도가 늘어나는 것을 선호하지 않는다면, severless 형태로 배포하는 것도 하나의 방법이라고 합니다.
서비스의 아키텍처를 설계할 때 무작정 다른 서비스의 아키텍처를 따라 하는 것이 아닌, 개발하려고 하는 서비스의 상황을 고려하고, 주체적으로 판단하여 설계할 수 있는 개발자가 됩시다 !! 💪🏻
