안녕하세요! 오늘은 Node.js 관련 토픽이 아닌 새로운 주제로 찾아뵙게 되었습니다. 그것은 바로!
Microservices Architecture!
필드에서 개발자로서 일을 시작한 지 어언 3년이 다 되어 가지만 마이크로서비스 아키텍쳐가 무슨 의미인지 몰랐습니다. 물론 가끔씩 보긴 했지만 사실 딱히 관심도 많이 없었고 언제나처럼 나 하는 일도 바쁘다 하는 핑계로 넘어가기 일쑤였는데요..
그러다가 문득 갑자기 궁금해졌습니다. 마이크로서비스 아키텍쳐가 무엇인데 이렇게 많이 언급이 되나? 그럼 이직을 준비해야 하는 입장에서 이게 뭔지 알고 있어야 도움이 되겠네? 하는 여러가지 생각이 듦과 동시에, 본격적으로 알아보기 시작하였습니다. 물론 아직도 100% 이해하고 있다고 말씀 드릴 수 없기에, 이번 포스트를 작성하면서 함께 공부해 보는 시간을 가졌으면 좋겠습니다.
저는 어렸을 때 공부하는 걸 매우 매우 싫어해서 항상 운동부 학생들과 자웅을 겨루곤 했는데, 어쩌다 보니 지금은 지속적으로 공부를 하지 않으면 살아남을 수 없는 직종에서 일을 하고 있네요.. 가끔씩 이게 옳은 판단인가 싶기도 한데요, 그래도 어려워서 🤬 이 절로 나오기도 하지만, 복잡한 문제를 해결했을 때의 쾌감도 좋고, 뭔가 새로운 것을 배웠을 때 느끼는 성취감도 있으니 당분간은 개발자로 인생을 살지 않을까 싶네요. 그럼 각설하고 본격적으로 마이크로서비스 아키텍쳐가 무엇인지 알아보도록 하겠습니다.
Microservices Architecture 는 무엇인가?
마이크로서비는 애플리케이션 아키텍쳐를 지칭하는 용어로서, 모든 애플리케이션의 기능을 각각의 서비스로 만드는 것을 의미합니다. 그리고 이 서비스들은 컨테이너의 형태로서 배포가 되고, 이 컨테이너들은 API 를 통해서 소통 하게 됩니다. 무슨 말인지 이해가 가시나요?
저는 아닌 것 같습니다.. 그래서 조금 더 자세하게 알아보고자 Monolithic 과 비교하여 차이점을 알아보기 전에, 그럼 Monolithic 은 또 무엇인지 먼저 알아봐야 하겠죠?
Monolithic Architecture 는 무엇인가...
모놀리틱 아키텍쳐는 하나의 애플리케이션을 기본으로 하는 서버 사이드 시스템입니다. 예를 들어 자바의 경우, WAR 혹은 JAR 파일의 형태로서 배포가 되게 되죠. 모놀리틱 아키텍쳐의 장점은 개발, 배포, 관리가 용이하다 입니다. 이 또한 글로만 봤을 때는 확 와닿지 않는 느낌이네요. 그렇다면, 다이어그램으로 본다면 조금 더 이해하기 쉬워질까요?
마이크로소프트 아키텍쳐 다이어그램과 모놀리틱 아키텍쳐 다이어그램
출처: https://docs.oracle.com/en/solutions/learn-architect-microservice
이렇게 그림으로 보니 조금 더 명확해 지는 것 같습니다. 그렇다면 지금부터는 각 아키텍쳐 타입이 가지고 있는 장단점들을 분석해 보며, 어떤 use case 에 어떠한 아키텍쳐 타입을 사용하는 것이 좋을지 공부해 보겠습니다.
모놀리틱 아키텍쳐의 장단점
장점 - 하나의 애플리케이션만 관리하면 되기에,
- Cross-cutting concerns 가 적다. 로깅, 퍼포먼스 모니터링 등 관리하기에 용이하다.
- 디버깅과 테스팅도 쉬운 편이다
- 개발과 deploy 가 쉽다.
단점
- 구조의 이해 (understanding) - 아키텍쳐 규모 확장 상황에서, 구조를 이해하기 매우 어려워진다. 또한 하나의 앱에 모든 코드를 입력하는 것은 관리 측면에서도 좋지 않다.
- 크고 복잡한 규모의 앱에 새로운 기능을 추가하는 것 또한 매우 어렵다. 모든 서비스들이 의존적으로 엮여있기 때문에, 하나의 기능을 추가한다고 가정하여도 모든 서비스들과의 호환성 등을 체크해야 하기에 개발 시간을 지연시킬 우려가 있다.
- 확장성 (scalability) - 모든 서비스들이 의존적으로 엮여있기 때문에, 하나의 컴포넌트만 독립적으로 규모 상향을 시킬 수 없다.
- 새로운 기술을 접목시키기 위해 전체 애플리케이션이 다시 만들어져야 하는 상황이 발생할 수도 있으므로 쉽지 않다.
마이크로서비스 아키텍쳐의 장단점
장점
- 독립성 (independence) - 모든 서비스가 독립적인 컴포넌트로서 존재하기에, 각각의 서비스 또한 유연하게 관리가 가능하다. 이 독립성에 의하여, 하나의 서비스에 문제가 생겼을 때에도 시스템 전체보다 그 특정 서비스에만 영향을 미치므로, 시스템 다운 타임을 줄일 수 있다.
- 새로운 기술을 접목시킴에 있어 모놀리틱 아키텍쳐보다 훨씬 쉽다.
- 각 서비스들의 규모가 모놀리틱 아키텍쳐보다 작기에 시스템을 이해하기 쉽다.
- 역시 독립성에서 오는 장점인데, 확장성이 매우 좋다. 모놀릭틱 아키텍쳐와는 다르게 각 서비스들을 개별적으로 규모 확장 시킬 수 있기에, 비용이나 시간적인 측면에서도 매우 큰 이점이 있다.
단점
- Cross-cutting concerns 가 많다. 아키텍쳐의 독립성에서 오는 단점이다.
- 배포가 어렵다. 마이크로서비스 아키텍쳐는 다양한 모듈과 데이터베이스 등 많은 서비스들이 독립적인 컴포넌트로서 존재하기에, 각별하게 주의를 기울여 각 서비스들이 잘 연결될 수 있도록 해야 한다.
- 테스트가 어렵고 복잡하다.
이렇게 두가지 타입의 아키텍쳐의 장단점을 보았는데요, 제가 이해하는 바로는 모놀리틱 아키텍쳐의 장점은 마이크로서비스 아키텍쳐의 단점이고, 반대로 모놀리틱 아키텍쳐의 단점은 마이크로서비스 아키텍쳐의 장점인 것 같습니다. 이렇듯 두 아키텍쳐의 장단점이 극명하니, 도대체 어떤 상황에 어떤 아키텍쳐 모델을 사용해야 설계 잘 했다고 소문이 날까요?
언제 사용해야 하나?
Monolithic Architecture
- 소규모의 팀 혹은 프로젝트 스케일이 작을 때 - MSA 는 설계가 매우 복잡하므로, 소규모 스타트업 혹은 프로젝트의 스케일이 크지 않을 때, 모놀리틱 아키텍쳐를 사용하는 것이 좋은 방향이라고 생각합니다.
- MSA 전문가의 부재 - 역시 MSA 는 복잡하므로, 전문적인 지식이 없이 MSA 설계를 시도했을 때 하지 않으니만 못한 결과를 초래할 수도 있습니다.
- 빠른 개발 & 배포 - 모놀리틱 아키텍쳐의 가장 큰 장점
Microservices Architecture
- MSA 전문가가 존재할 때 - 단순한 지식만으로도 아직 충분하지 않으며, DevOps 와 도메인 모델링 전문가는 필수입니다.
- 복잡하고 확장성이 요구되는 애플리케이션
- 다양한 분야의 전문가
주저리 주저리 말이 많았지만, 이렇게 글로만 보면 어느 정도 이제 이해하고 구분할 수 있는 정도는 되었다고 생각합니다. 하지만 아직 한번도 제대로 MSA 를 설계해 보거나 직접 본 경험이 없기에 막상 개발하게 되는 상황이 온다면, 얼마나 패닉 상태에 빠지게 될 지.. 혹은 그런 경험을 은퇴하기 전에 할 수나 있을 지 모르겠습니다. 그러나 세상에 배워서 해가 되는 것들은 몇 가지 없다고 생각하며, 특히 이 아키텍쳐 설계에 관한 것들은 요즘 매우 핫한 토픽이고, DevOps 분들 또한 아주 좋은 대접을 받고 계신 걸로 알고 있습니다. 이 포스트에서는 개념 정리 정도로 마치지만, 이쪽에 관심이 있으신 분들이라면, 충분히 지속적으로 공부할 만한 가치가 있는 분야라고 생각합니다.
오늘은 이정도로 마무리 하고, 다음 포스트때 새로운 마음가짐으로 뵙도록 하겠습니다. 그럼
