모놀리스는 부끄러운 아키텍처 인가?

아마존 프라임 비디오 팀의 사례

: 초기에는 서버리스를 사용하는 분산 시스템으로 설게했고, 이는 신속하게 서비스를 구축하기 위한 좋은 선택이었다

: 그러나 대규모로 해당 솔루션을 채택하기에는 모든 빌딩 블록의 전체적인 비용이 너무 높았다

: 문제를 해결하기 위해 모든 구성요소를 하나의 프로세스로 옮겨 데이터 전송을 프로세스 메모리 내에 유지했고, 이를 통해 오케스트레이션 로직도 간소화 하는데 성공

 

- 결과

: 서버를 모놀리스로 이전한 결과 인프라 비용이 90% 이상 줄었고 확장 역량도 증대되었다

 

 

 

정리

: 마이크로 서비스로 서비스를 구현하면 분명 기능을 병렬화 하여 관리하는데 편리할 수 있다. 그러나, 그만큼 애플리케이션이 쪼개지는 것이기 때문에 복잡성이 커질 수 있다는 단점이 존재한다

: 모놀리스는 불필요한 개념적 모델을 최대한 축소하고 쓸데없는 추상화를 최대한 많이 제거한 통합 시스템이라고 할 수 있다

: 모놀리스를 오답, 마이크로 서비스를 정답으로 규정하는 것에서 탈피해야한다

 

 

 

 

IT 전문가가 기억해야할 6가지 교훈

1. 핵심은 기술이 아니다

: 기술이 아니라 목표부터 시작하고 제시되는 요구사항에 따라 시스템을 구축해나가야 한다

 

2. 절충점을 분석하라

: 마이크로 서비스는 유연성을 제공하고 개별 서비스의 개발, 배포, 확장성을 실현한다

: 그러나 서비스 검색 필요성, 서비스간 통신, 분산된 시스템 관리 등의 복잡성도 따른다

 

3. 첫 설계를 제대로 하라

: 애플리케이션이 실행되는 기반 인프라는 처음부터 제대로 돼야한다

 

4. 언어와 종속성을 간소화 하라

: 마이크로서비스 광기의 나쁜 부작용 중 하나는 수없이 많은 프로그래밍 언어와 프레임워크와 생태계를 포용하는 경향

: 언어는 2가지가 넘지 말아야 한다

 

5. 특정 사용례를 목표로 삼아라

: 효과적인 마이크로 서비스를 보면 시스템에서 좁은 범위에서 격리된, 일반적으로 성능이 중요한 특정 부분을 대상으로 하는 경우가 많다

 

6. 비용을 고려하라

: 서버리스의 경우 코드가 실행되는 시간만큼 비용을 청구하므로, 장기간 실행되는 프로세스가 있는 애플리케이션이라면 비용 효율성이 떨어질 수 있다

 

 

 

 

 

 

Reference

송요창 / 모놀리스는 부끄러운 아키텍처인가 | 커리어리

아마존 프라임 비디오의 ‘서버리스 vs. 모놀리스’ 논란에서 얻는 6가지 교훈