[Study][Architecture] 모놀리식(Monolithic)와 마이크로서비스 아키텍처(Microservices, MAS) 정리하기.

안녕하세요. 성조입니다.

 

이번 포스팅은 이전에 모놀리식(Monolithic)과 MAS(Microservices)가 비교 군으로 한참 핫했을 때. 학습했던 내용을 정리하는 포스팅입니다.

혹여나 올바르지 못한 지식을 전달하고 있다면 언제든지 댓글로 얘기해 주시면 감사드리겠습니다.

---

모놀리식(Monolithic) 이란?

모놀리식이라는 단어는 하나의 덩어리를 의미한다.

모놀리식 아키텍처는 애플리케이션을 구성하는 모든 구성요소(UI/UX, 비즈니스 로직, Database 등)가 하나의 단일 코드 베이스에 합쳐져 있는 형태이다. 즉, 큰 하나의 덩어리로 모든 것을 처리한다 보면 이해가 조금 더 수월할 수 있다.

 

모놀리식 아키텍처는 단일 코드 베이스에서 개발, 테스팅, 배포가 이뤄지기 때문에 상대적으로 다른 아키텍처에 비해 간편하게 모두 컨트롤할 수 있다. 또한, 초기에 스타트업이나, 규모가 크지 않은 서비스의 경우에 빠른 개발 속도를 보장할 수 있다.

 

 

마이크로서비스 아키텍처(Microservices, MAS) 이란?

'마이크로(Micro)'라는 단어 자체의 의미가 '아주 작은'이라는 의미를 가지고 있다. 그렇다면 영어 단어 그대로 이해하면 어떻게 이해할 수 있을까?

마이크로서비스 아키텍처→ 아주 작은 서비스 설계 방식으로 풀이할 수 있다.

즉, 아주 섬세한 서비스를 제공하기 위해 설계되는 컴퓨터 아키텍처라고 보면 된다.

 

마이크로서비스 아키텍처는 애플리케이션 레벨을 아주 작고, 독립적인 서비스로 분리하게 되는데 각 서비스는 독립적으로 배포 또는 확장될 수 있으며, 서로 다른 기술 스택을 사용할 수 있는 것 또한 특징이다.

 

 

모놀리식의 장점과 단점

[장점]

1. 원자성 트랜잭션

모놀리식 아키텍처는 데이터의 일관성을 유지하는데 효과적이다. 애플리케이션 내에서 데이터를 관리하기 때문에 복잡한 트랜잭션을 원자성(atomicity)을 보장하면서 처리하는 것이 수월하다.

마이크로서비스 아키텍처의 경우. 아주 작은 여러 서비스로 나누기 때문에 일관성을 유지하기 어려운 부분이 있는데 그것에 대비되는 장점이라 생각한다.

 

2. 통합된 보안

보안 규칙과 정책을 한 곳에서 관리할 수 있는 장점이 있다.

보안을 위한 코드 및 정책의 중복을 줄이고, 일관된 보안 수준을 유지하는 것이 장점이다. 보안을 위한 노력 비용이 감소.

 

3. 비용 효율

모놀리식 아키텍처는 마이크로 서비스 아키텍처에 비해서 초기 비용이 상대적으로 매우 저렴하기 때문에 인프라 비용이나 개발 및 유지 보수 비용이 상대적으로 저렴하다. 그렇기 때문에 초기 스타트업 또는 소규모 개발팀에서 유리할 수 있다.

 

4. 응집력

기능들이 밀접하게 연관되어 동작하므로, 시스템 응집력이 높다고 볼 수 있다. 응집력이 높으면 코드의 재사용성을 향상할 수 있다.

좋은 모듈화를 통해 결합도를 낮추고, 응집도를 높이는 경우. 다른 아키텍처로 전환할 때 수월할 수 있다.

 

5. 각 기능의 통합

하나의 더미에서 모든 것을 처리하기 때문에 작은 규모의 서비스에서 각 기능을 서로 긴밀하게 통합하고, 상호작용이 편리한 서비스를 진행할 수 있는 장점이 있다.

 

[단점]

1. 확장의 한계

시스템이 성장하면 규모에 따라 모든 고려 요소들을 함께 확장해야 한다. 하지만 모놀리식 아키텍처는 특정 부분만 확장이 필요한 경우에도 하나의 코드 베이스에 전체 기능이 묶여있어서 어쩔 수 없이. 전체적인 확장해야 하는 리소스 낭비를 초래할 수 있다.

 

2. 유지보수의 어려움

하나의 공간에 모아두는 것이라서 규모가 커지면 더욱 복잡해지고 유지 보수가 어려워질 수 있다. 또한, 마이그레이션 또는 호환으로 인하여 특정 모듈에 문제가 발생하게 되면 전체 시스템에 영향을 줄 가능성이 크다. 새로운 기능을 추가하는 것도 부담이 될 수 있다.

 

3. 기술적 부채

다양한 기술 스택을 활용하는 것이 아닌. 단일 스택에 의존하기 때문에, 시스템이 성장함에 따라 기술적 부채가 급격하게 늘어날 수 있다. 기존 기술을 다른 기술로 변경하는 것도 상당항 노력 비용이 드는 문제가 있다.

 

4. 장애 전파

하나의 컴포넌트에서 발생한 문제가 전체 시스템에 영향을 줄 수 있다. 이런 문제로 전체 시스템의 가용성이 떨어질 수 있다.

 

5. 유연성 부족

각 기능이 동일한 애플리케이션 내부에 있기 때문에 각 기능을 독립적으로 개발하거나 배포하는 것이 어렵다. 에러가 발생하여 신속한 대응이 필요할 때. 대응하기 어려울 수 있다.

 

 

마이크로서비스 아키텍처(Microservices, MAS) 장점과 단점

[장점]

1. 독립적인 배포 및 확장성

서비스 하나를 수정했을 때. 전체 재배포할 필요 없이 변경된 서비스만 재배포하면 되고, 요구 사항이 변경되더라도 그 부분만 수정하면 되는 확장성 측면의 장점이 있다.

 

2. 기술적 자유도

각 서비스가 분리 됐기 때문에 하나의 서비스에 필요한 기능들에 대한 확장이 유연하게 이뤄질 수 있게 된다. 

 

3. 결함 격리

하나의 서비스에서 문제가 발생하면 해당 서비스를 죽이고, 긴급 조치를 진행하면서 다른 서비스를 이용하게 만들 수 있다. 특정 서비스가 다운됐을 때. 빠르게 복구하거나, 서비스 전체가 종료되지 않는 것 덕분에 문제가 발생했음을 인지해서 시스템 안정성을 높일 수 있다.

 

4. 팀 별 자율성

프론트 백엔드 데브옵스 팀 등이 별도로 구분되어 각자 맡은 파트에 대해서 책임을 지고 개발 및 배포 일정을 관리할 수 있다. 또한 중간에 커뮤니케이션을 통해서 원하는 비즈니스 로직에 대해서 빠른 개발 목표를 정하고, 개선하면서 의사소통을 통해 오버헤드를 줄여낼 수 있다.

 

5. 유지 보수 용이성

서비스가 나눠져 있기 때문에 코드 베이스가 어마 무시하게 거대하지 않다. 그래서 리팩토링이나 기능 개선 작에 속도를 가지고 유지 보수를 진행할 수 있다.

 

6. 비즈니스 중심적 설계

비즈니스 기능 중심으로 서비스를 설계하고 구현하기 편하게 만들어 준다. 비즈니스 로직에 대한 최적화를 진행하는 것이 사용자 측면에서 만족도가 높을 수 있다.

 

[단점]

1. 데이터 일관성

여러 개의 서비스가 데이터 베이스를 나눠 가지기 때문에 일관성을 유지하는 것이 어렵다.

 

2. 서비스 간 통신 오버헤드

작은 서비스 단위들이 통신 과정에서 네트워크 환경이 다른 것으로 인하여 장애가 발생하면 처리하는 비용이 추가적으로 들어간다.

 

3. 개발 팀의 기술 수준 요구

개발 팀이 마이크로서비스 아키텍처의 충분한 이해와 경험이 있어야 한다. 분산시스템, DevOps, 클라우드 인프라 등의 다양한 기술에 대한 파트를 분담해야 한다. 분담 시 학습 비용이라는 노력 비용이 들어간다. (각 팀이 별도로 있으면 또 다른 얘기일 것 같다.)

 

4. 테스트의 어려움

모든 서비스가 함께 잘 동작하는지 확인하기 위해 종합적인 통합 테스트가 필요하며, 비용이 발생된다.

 

5. 분산 시스템의 복잡성

마이크로서비스 아키텍처는 모놀리식 아키텍처와 다르게 기본적으로 분산 시스템이다.

분산 시스템의 장점을 통해 데이터 일관성 유지, 서비스 간 통신, 서비스 검색 등 복잡한 문제가 발생하며, 처리해야 한다. 이 복잡성을 관리하기 위해서 적절한 도구와 기술을 선택하고, 협업하는 데 있어서 전체적인 흐름 이해가 필요하다.

 

6. 운영 오버헤드

각 서버를 하나씩 가지고 별도의 배포 및 모니터링을 진행해야 하기 때문에 각 서비스 간의 통신 비용이 운영에 부담을 줄 수 있다. 배포, 모니터링, 로깅, 트레이싱 등 다양한 요소의 통신 비용 청구가 발생할 수 있다.

 

 

각 아키텍처의 도입 시기

모놀리식 아키텍처 도입 시기

- 소규모 프로젝트나 초기 스타트업 중에서 빠른 출시와 초기 생산성이 주요 포인트가 되는 경우 모놀리식 아키텍처가 적합할 수 있다.

- 개발 팀이 작고, 각각의 구성원이 다른 구성원의 작업에 쉽게 접근하고 이해해야 하는 경우. 'ex) 2~3명이 진행하는 풀스택 개발'은 모놀리식 아키텍처가 적합하다 생각한다.

- 복잡한 트랜잭션 처리나 원자성이 중요한 경우. 다른 서비스와 충돌할 위험이 작아서 모놀리식 아키텍처에서 진행하는 것이 좋을 것이라 생각한다.

 

마이크로서비스 아키텍처 도입 시기

- 서비스하는 애플리케이션의 규모가 너무 커져서 하나의 코드베이스로 관리하기 어려워지는 경우.

- 서비스별로 상세하게 구분 짓고, 다른 기술 스택을 적용하여 확장 및 배포를 독립적으로 관리해야 하는 경우.

- 빠르게 변화하는 비즈니스 요구사항에 신속하거나 능동적으로 대응하는 경우.

- 큰 규모의 팀이나 여러 팀이 함께 작업하게 되는 경우.

- 특정 서비스의 고객 요구가 높아지는 경우. (클릭했을 때 특정 페이지로 0.1초 안에 페이지 전환을 하고 싶어요.)

 

---

오타나 궁금한 부분이 있다면 댓글 달아주시면 답변드릴 수 있도록 노력하겠습니다.

다음 포스팅 때 뵙겠습니다. 감사드립니다.