모놀리식 아키텍쳐와 마이크로서비스 아키텍쳐 | 백엔드 입문

각 아키텍쳐의 간단한 도식화. 출처는 https://lion-king.tistory.com/entry

✨아키텍쳐가 무엇이고

 아키텍쳐(Architecture)는 '건축학'이라는 뜻의 단어로서 컴퓨터 공학에 쓰이는 단어이다. 이것을 프로그래밍 언어로서도 많이 쓰이게 되는데 그 뜻을 그대로 가지고 와서 시스템을 만드는데 기반이 되는 기본 베이스라고 생각하면 된다. FE개발자로 나아갈지라도, 백엔드에 대한 지식이 부족하면 서비스를 운용해나가기 어렵다. 아니 사실 그전에 백엔드 개발자와의 협업에서 많이 삐걱거릴것이 분명하다... 그렇기에 백엔드 개발의 겉핥기로 모놀리식 아키텍쳐와 마이크로 서비스 아키텍쳐에 대해서 알아보려고 한다.

 

---

 

✨ 모놀리식 아키텍쳐 (Monolithic Architecture)

 기본적인 아키텍처를 지향하며 아키텍쳐라는 개념이 컴퓨터 공학에 적용되기 전 대부분의 웹 기반의 어플리케이션은 해당 아키텍쳐의 방식으로 만들어졌다. 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 그렇기에 어플리케이션의 한 프로세스에 대한 수요가 증가하면 아키텍쳐 전체를 확장해야 하는데, 코드가 증가하면 증가할 수록 해당 아키텍쳐에 기능을 추가하거나 개선하기가 더욱 복잡해진다.

 

 [장점]

• 개발환경이 같아서 복잡하지 않음
• UI, DB, 엑세스 등 모두가 하나의 배포 가능한 단일 소프트웨어 산출물로 전달됌 
• 개발, 빌드, 배포, 테스트가 매우 용이함

 [단점]

• 어플리케이션 구동시간이 늘어나고 빌드,배포 시간이 길어짐
• 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야함.
• 많은 양의 코드가 몰려있어 유지보수가 힘들다.
• 일부분의 오류가 전체에 영향을 미침.
• 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다로움.

 

✨마이크로서비스 아키텍쳐 (MicroService Architecture)

 모놀리식과는 달리 큰 어플리케이션을 여러개의 작은 유닛으로 쪼개서 변경 및 조합이 가능케 한 서비스 아키텍쳐를 뜻한다. 각 서비스는 상호 통신이 가능하며 이들이 모여 큰 서비스를 구성하게 된다. 서비스가 작기 때문에 클라우드에서 많은 서비스의 시작을 쉽게 시작할 수 있고 어플리케이션의 확장성을 높이며 유지보수의 회복성도 향상할 수 있다. 작고 단순하지만 확장이 유연한 어플리케이션 아키텍쳐이다.

 

 [장점]

• 기능별로 마이크로 서비스를 개발하여 작업 할당을 서비스 단위로 설정하면 개발자가 해당 부분을 쉽게 이해 가능
• 새로 추가되거나 수정사항이 있는 서비스만 빠르게 올리고 배포 가능, 독립적인 서비스로 배포가 빠르고 모놀리식보다 가벼움
• 대형어플의 관리가 쉬움
• 해당 서비스에 적합한 기술, 언어, 버전, DB등을 선택하여 구현 가능
• 이슈가 생겼을때 격리 및 복구가 쉬워서 서비스 장애가 전체 서비스로 확장될 가능석이 적음

 [단점]

• 작은 서비스들이 분산되어 있어서 모니터링 및 관리가 매우 어려움
• 작은단위의 서비스들끼리 서버호출이 이루어지기에 다른 서비스를 호출하는 코드가 무조건 추가, 이에 따라 모놀리식에 비해 개발이 까다롭고 통신오류가 잦을 수 있음. 이에따라 지연시간이 증가할 수 있어 서비스 속도가 저하될 우려와 서버통신비용이 높음.
• 서비스마다 DB가 분리되어 있어 데이터의 조회가 어렵고 데이터의 중복이 발생 가능
•  서비스가 커짐에 따라 복잡도는 상당히 가파르게 상승할 수 있음