모놀리식(Monolithic) 아키텍처

• 하나의 거대한 어플리케이션에서 모든 것을 처리하는 아키텍처
• 유저생성, 결제, 홈페이지 등등 모든 기능을 하나의 백엔드에서 처리함
• 내부 요소간의 의존성이 강하며 구조적으로 강력하게 결합된다.
• 하나의 환경에서 개발하기 때문에 복잡성이 덜하다.
• End-to-End 테스트에 용이하다.
• 프로젝트의 규모가 커질수록 빌드, 배포 시간이 길어지며 어려워진다.
• 특정 부분에서 오류가 나면 전체 서비스의 장애가 생기거나 서버가 다운될 수 있다.
• 서버 확장을 수직적으로만 할 수 있다.
• 강력한 하드웨어를 필요로한다. 한 개의 서버가 모든 것을 처리하기 때문이다.
• 갑자기 트래픽이 급증하면 이를 대응하기 어렵고, 거꾸로 유저가 줄어들었을 때 남는 메모리가 많아진다.

마이크로서비스(Microservice) 아키텍처 (MSA)

• 작고 독립적인 서비스로 쪼개져있어 팀 별로 독립적으로 개발 및 배포를 할 수 있다.
• 상호의존적이지 않으며 다른 언어, 다른 서버를 사용할 수 있다.
• 하나의 서비스가 장애를 일으켜도 다른 서비스를 사용할 수 있다.
  ( 최근 구글에서 유튜브 오류났을 때 생각하면 될 것 같다 )
• 수평적 확장이 가능하며 관리하기 쉽고 클라우드 사용에 적합한 아키텍처이다.
• 특정 서비스에 유저가 몰린다면 그 서비스의 서버만 확장할 수 있다는 장점이 있다.
• 하지만 실제로 이렇게 서비스하기까지 많은 과정이 필요하며 넷플릭스의 경우 자체 서버에서 AWS로 이동하는데 5년이나 걸렸다고한다.
• 서비스가 커질수록 복잡도가 기하급수적으로 늘어난다.
• 데이터가 여러 서비스에 걸쳐 분산되어있기 때문에 한 번에 조회가 어렵고 관리가 어렵다.

정리

간만에 유튜브를 보고 정리해봤다.
어떤 아키텍처가 더 좋다 ! 라기 보다는 서비스 마다, 회사 마다 상황에 맞는 아키텍처를 선택하게 되어있다.

모놀리식은 테스트와 개발이 간편하고 수십년간 성공적으로 사용되었다.
하지만 한 번 기술을 선택하면 변경이 거의 불가능하며 서비스가 지속될수록 개발 속도가 느려진다. 이때문에 지속 가능한 개발이 어렵다고한다.

정반대의 방법인 마이크로서비스는 유연하며, 빠르게 대처할 수 있고 작은 단위로 배포할 수 있는 편리함도 있다.

마이크로서비스 아키텍처 영상을 보면서 가장 먼저 생각났던건 올해 초에 있었던 유튜브 먹통사건이다.
로그인하면 영상 재생이 안되는 오류였나 ? 그랬던 것 같은데 그 부분이 바로 떠올랐다.
스트리밍을 담당하는 부분은 멀쩡하지만 구글 로그인과 연결되어있는 파트가 먹통이라 로그아웃하면 영상이 재생되는 현상 !
모놀리식이면 유튜브 자체가 먹통이었겠지만 마이크로서비스라 특정 부분만 장애가 생겼구나 ~ 하고 생각했었다.