2023.05.03(모놀리식 vs 마이크로서비스)

모놀리식 애플리케이션은 하나의 통합된 유닛으로 만들어지는 반면, 마이크로서비스 아키텍처는 독립적으로 배포할 수 있는 소규모 서비스의 모음입니다. 어떤 것이 적합한지는 여러 요인에 따라 다릅니다.

2009년 Netflix는 성장통을 겪었습니다. 빠르게 성장하는 동영상 스트리밍 서비스에 대한 수요를 인프라가 따라갈 수 없었습니다. Netflix는 IT 인프라를 프라이빗 데이터 센터에서 퍼블릭 클라우드로 마이그레이션하고 모놀리식 아키텍처를 마이크로서비스 아키텍처로 대체하기로 결정했습니다. 한 가지 문제는, 그 당시 “마이크로서비스”라는 용어가 없었으며 그 구조는 잘 알려져 있지 않았습니다.

Netflix는 모놀리스에서 클라우드 기반 마이크로서비스 아키텍처로 성공적으로 마이그레이션한 최초의 유명 기업 중 하나가 되었습니다. 2015년에 JAX 특별 심사위원상을 수상한 것도 부분적으로는 DevOps를 내부에 두는 이 새로운 인프라 덕분이었습니다. 오늘날 Netflix는 플랫폼의 개별 부분을 관리하고 지원하는 1,000개 이상의 마이크로서비스를 가지고 있고 엔지니어는 코드를 때로는 매일 수천 번에 달할 정도로 자주 배포합니다.

오늘날에는 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 전환하는 것이 점점 더 보편화되고 있지만, Netflix는 초기 선구자였습니다.

 

모놀리식 아키텍처란 무엇입니까?

 

 

모놀리식 아키텍처는 소프트웨어 프로그램의 전통적인 모델로, 자체 포함 방식이며 다른 애플리케이션과 독립적인 통합된 유닛으로 만들어집니다. “모놀리스"라는 단어는 거대하고 빙하 같은 것을 의미하는 경우가 많은데, 소프트웨어 설계의 모놀리식 아키텍처도 크게 다르지 않습니다. 모놀리식 아키텍처는 모든 비즈니스 관련 사항을 함께 결합하는 하나의 코드 베이스를 갖춘 대규모의 단일 컴퓨팅 네트워크입니다. 이러한 종류의 애플리케이션을 변경하려면 코드 베이스에 액세스하고 서비스 측 인터페이스의 업데이트된 버전을 구축 및 배포하여 전체 스택을 업데이트해야 합니다. 이로 인해 업데이트에 제한이 많고 시간이 오래 걸립니다.

프로젝트 초기에는 코드 관리, 인지 오버헤드 및 배포의 용이성 면에서 모놀리스가 편리할 수 있습니다. 모놀리스에서 모든 것을 한꺼번에 릴리스할 수 있기 때문입니다.

 

모놀리식 아키텍처의 장점

 

다양한 요인에 따라, 조직에 모놀리식 아키텍처 또는 마이크로서비스 아키텍처가 도움이 될 수 있습니다. 모놀리식 아키텍처를 사용하여 개발하는 가장 큰 장점은 애플리케이션이 하나의 코드 베이스에 기반을 두어서 단순하기 때문에 개발 속도가 빠르다는 것입니다.

모놀리식 아키텍처의 장점에는 다음이 포함됩니다.

손쉬운 배포 – 실행 파일 또는 디렉토리가 하나여서 배포가 더 쉽습니다.

개발 – 하나의 코드 베이스로 애플리케이션을 구축하여 개발이 더 쉽습니다.

성능 – 중앙 집중식 코드 베이스 및 리포지토리에서는 대부분 하나의 API만으로 마이크로서비스에서 여러 API가 수행하는 것과 동일한 기능을 수행할 수 있습니다.

테스트 간소화 – 모놀리식 애플리케이션은 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 엔드투엔드 테스트를 더 빠르게 수행할 수 있습니다.

간편한 디버깅 – 모든 코드가 한 곳에 있으므로 요청을 따라가서 문제를 찾기가 더 쉽습니다.

 

모놀리식 아키텍처의 단점

 

Netflix의 경우에서 볼 수 있듯이, 모놀리식 애플리케이션은 규모가 너무 커지고 확장이 어려워지면 더 이상 효과적이지 않습니다. 하나의 기능을 조금만 변경하려고 해도 전체 플랫폼을 컴파일하고 테스트해야 하기 때문에, 오늘날의 개발자들이 선호하는 애자일 접근 방식과 맞지 않습니다.

모놀리식 아키텍처의 단점에는 다음이 포함됩니다.

느린 개발 속도 – 대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려집니다.

확장성 – 개별 컴포넌트를 확장할 수 없습니다.

안정성 – 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 영향을 줄 수 있습니다.

기술 채택의 장벽 – 프레임워크 또는 언어를 변경하면 애플리케이션 전체에 영향을 미치므로 변경 시 비용과 시간이 많이 소요되는 경우가 많습니다.

유연성 부족 – 모놀리스의 경우 모놀리스에서 이미 사용한 기술로 제한됩니다.

배포 – 모놀리식 애플리케이션을 약간만 변경하는 경우에도 전체 모놀리스를 다시 배포해야 합니다.

 

마이크로서비스란 무엇입니까?

 

간단하게 마이크로서비스라고도 하는 마이크로서비스 아키텍처는 독립적으로 배포 가능한 일련의 서비스를 이용하는 아키텍처 방법입니다. 이러한 서비스에는 특정한 목표를 가진 자체 비즈니스 로직 및 데이터베이스가 있습니다. 업데이트, 테스트, 배포 및 확장은 각 서비스 내에서 이루어집니다. 마이크로서비스는 주요 비즈니스, 도메인별 문제를 별도의 독립적인 코드 베이스로 분리합니다. 마이크로서비스는 복잡성을 줄여주지는 않지만, 작업이 서로 독립적으로 작동하고 전체에 기여하는 더 작은 프로세스로 분리하여 복잡성을 눈으로 볼 수 있고 관리하기 쉽도록 만듭니다.

마이크로서비스 채택은 팀이 사용자 요구 사항에 빠르게 적응할 수 있도록 하는 지속적 배포 관행의 기반이기 때문에 DevOps 채택과 함께 이루어지는 경우가 많습니다.

 

 

마이크로서비스의 장점

 

마이크로서비스는 특효약은 아니지만, 성장하는 소프트웨어와 회사의 여러 문제를 해결합니다. 마이크로서비스 아키텍처는 독립적으로 실행하는 유닛으로 구성되므로, 다른 서비스에 영향을 주는 일 없이 각 서비스를 개발, 업데이트, 배포 및 확장할 수 있습니다. 향상된 안정성, 가동 시간 및 성능으로 소프트웨어 업데이트를 더 자주 수행할 수 있습니다. 이전에는 업데이트를 일주일에 한 번 수행했다면 나중에는 하루에 두세 번까지 진행할 수 있게 되었습니다.

 

간단히 설명하면 마이크로서비스의 장점은 다음과 같습니다.

애질리티 – 배포가 잦은 소규모 팀에서 애자일 작업 방식을 유도합니다.

유연한 확장 – 마이크로서비스가 부하 용량에 도달하면 해당 서비스의 새 인스턴스를 포함하는 클러스터에 신속하게 배포하여 부담을 완화할 수 있습니다. 이제 여러 인스턴스에 고객이 분산되어 있는 다중 테넌트 및 상태 비저장(stateless)이 되었으며 훨씬 더 큰 크기의 인스턴스를 지원할 수 있습니다.

지속적 배포 – 이제 더 자주 릴리스하고 릴리스 주기가 빨라졌습니다. 이전에는 업데이트를 일주일에 한 번 수행했다면 나중에는 하루에 두세 번 정도까지도 수행할 수 있게 되었습니다.

높은 유지 관리성 및 테스트 편의성 – 팀에서 새로운 기능을 실험해 보고 문제가 발생하면 롤백할 수 있습니다. 따라서 코드를 보다 쉽게 업데이트하고 새로운 기능의 시장 출시 시간을 단축할 수 있습니다. 또한 개별 서비스의 결함과 버그를 쉽게 격리하고 해결할 수 있습니다.

독립적 배포 가능 – 마이크로서비스는 개별적인 유닛이므로 개별 기능을 빠르고 쉽게 독립적으로 배포할 수 있습니다.

기술 유연성 – 마이크로서비스 아키텍처를 사용하면 팀에서 원하는 도구를 자유롭게 선택할 수 있습니다.

높은 안정성 – 전체 애플리케이션이 중단될 위험 없이 특정 서비스에 대한 변경 사항을 배포할 수 있습니다.

 

마이크로서비스의 단점

 

소수의 모놀리식 코드 베이스에서 제품을 작동하는 더 많은 분산 시스템 및 서비스로 전환했을 때 의도하지 않은 복잡성이 발생했습니다. 처음에는 과거와 동일한 속도와 확신을 가지고 새로운 기능을 추가하는 데 어려움을 겪었습니다. 마이크로서비스는 복잡성을 증가시켜 무분별한 개발 확장 또는 관리되지 않는 급속한 성장으로 이어질 수 있습니다. 서로 다른 컴포넌트가 서로 어떻게 관련되어 있는지, 특정 소프트웨어 컴포넌트를 누가 소유하고 있는지, 또는 종속 컴포넌트를 방해하지 않으려면 어떻게 할지 판단하기가 어려울 수 있습니다.

 

마이크로서비스의 단점에는 다음이 포함됩니다.

무분별한 개발 확산 – 마이크로서비스의 경우 여러 팀이 더 많은 장소에 더 많은 서비스를 만들기 때문에 모놀리스 아키텍처에 비해 더 복잡해집니다. 무분별한 개발 확산이 적절하게 관리되지 않으면 개발 속도가 느려지고 운영 성능이 저하되는 결과가 나타납니다.

기하급수적인 인프라 비용 – 각각의 새 마이크로서비스는 테스트 도구, 배포 플레이북, 호스팅 인프라, 모니터링 도구 등에 대한 자체적인 비용이 발생할 수 있습니다.

조직 오버헤드 추가 – 팀에서는 업데이트 및 인터페이스를 조정하기 위해 또 다른 커뮤니케이션과 공동 작업이 이루어져야 합니다.

디버깅 문제 – 각 마이크로서비스는 자체적인 로그 집합을 가지고 있어 디버깅이 더 복잡합니다. 또한 여러 시스템에서 하나의 비즈니스 프로세스가 실행될 수 있으므로 디버깅이 더욱 복잡해집니다.

표준화 부족 – 공통 플랫폼이 없어 여러 언어, 로깅 표준 및 모니터링이 사용될 수 있습니다.

명확한 소유권 부족 – 더 많은 서비스가 도입됨에 따라 서비스를 실행하는 팀의 수도 늘어납니다. 시간이 지나면서 팀에서 어떤 서비스를 활용할 수 있는지, 그리고 지원을 받으려면 누구에게 문의해야 하는지 파악하기가 어려워집니다.

 

 

출처

https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith