마이크로서비스와 모놀리식 아키텍처 비교

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Atlassian은 Jira와 Confluence의 성장 및 확장과 관련된 문제에 직면한 후 2018년에 마이크로서비스로 경로를 변경했습니다. 온프레미스에서 실행하는 단일 테넌트, 모놀리식 아키텍처는 미래의 요구 사항에 맞춰 확장할 수 없다는 것을 알게 되었습니다.

Atlassian은 Jira와 Confluence를 다시 설계하여 상태 저장(Stateful) 단일 테넌트 모놀리식 시스템을 Amazon Web Services(AWS)에서 호스팅하는 다중 테넌트 상태 비저장(Stateless) 클라우드 애플리케이션으로 전환하기로 결정했습니다. 그런 다음 시간에 걸쳐 마이크로서비스로 나눕니다. “정말 마음에 드는 아이디어지만 현기증(Vertigo)이 납니다.”라는 한 선임 엔지니어의 언급에 따라서 이 프로젝트의 이름은 Vertigo가 되었습니다. AWS로의 전환을 완료하는 데 2년이 걸리고 서비스 중단 없이 10개월 만에 10만 명 이상의 고객을 마이그레이션한 현재까지 가장 큰 규모의 인프라 프로젝트였습니다. 또한 서비스를 마이크로서비스로 나누기 위해 노력했습니다.

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

Atlassian이 성장함에 따라, 마이크로서비스를 통해 서비스 소유권의 라인을 따라 분할하여 팀과 지리적 위치를 더 안정적으로 확장할 수 있습니다. Vertigo를 시작하기 전에 Atlassian은 전 세계에서 5개의 개발 센터를 운영했습니다. 이러한 분산된 팀은 중앙 집중식 모놀리스에 의해 제약을 받았으며 Atlassian에서는 이들을 자율적인 방식으로 지원해야 했으며 마이크로서비스를 통해 가능했습니다.

Vertigo의 장점에는 배포 속도 향상, 재해 복구, 비용 절감 및 성능 개선이 포함됩니다. 이를 통해 목표에 더 빨리 도달하는 동시에 고객에게 더 많은 가치를 제공할 수 있습니다.

또한 일반적으로 마이크로서비스를 사용하면 CI/CD(지속적 통합 및 지속적 배포)를 통해 팀이 코드를 더 쉽게 업데이트하고 릴리스 주기를 가속화할 수 있습니다. 팀에서 코드를 실험해 보고 문제가 발생하면 롤백할 수 있습니다.

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

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

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

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

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

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

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

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

팀의 만족도 향상 – 마이크로서비스를 사용하는 Atlassian 팀은 더 자율적이며 풀리퀘스트가 승인될 때까지 몇 주씩 기다리지 않고도 직접 구축 및 배포할 수 있기 때문에 훨씬 더 만족도가 높습니다.

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

Atlassian은 Vertigo를 통해 기존에 가지고 있던 제품과 앞으로 인수할 제품 및 만들 제품 모두를 지원할 공통의 기능을 구축했습니다. 제품이 하나인 회사의 경우 마이크로서비스가 필요하지 않을 수 있습니다.

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

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

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

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

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

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

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

많은 프로젝트는 처음에 모놀리스로 시작한 다음 마이크로서비스 아키텍처로 발전합니다. 모놀리스에 새로운 기능이 추가되면서 단일 코드 베이스로 작업하기가 많은 개발자에게 번거로워질 수 있습니다. 코드 충돌이 더 자주 발생하고, 하나의 기능을 업데이트할 때 관련 없는 기능에 버그가 발생할 위험이 높아집니다. 이러한 바람직하지 않은 패턴이 발생하면 마이크로서비스로의 마이그레이션을 고려해야 할 시기일 수 있습니다.

다음은 마이그레이션을 통해 배운 몇 가지 모범 사례입니다.

2016년 1월에는 마이크로서비스가 총 15개 정도였습니다. 이제 그 수는 1,300개를 넘습니다. Atlassian은 10만 명의 고객을 클라우드로 마이그레이션했으며, 그 과정에서 새로운 플랫폼을 구축하고, 우리의 문화를 바꾸며, 결과적으로 새로운 도구를 가지게 되었습니다. 팀의 만족도와 자율성이 높아졌으며 DevOps 문화도 개선되었습니다.

마이크로서비스가 모두에게 적합하지는 않을 수도 있습니다. 기존의 모놀리스에 전혀 문제가 없어 굳이 바꿀 필요가 없을 수도 있습니다. 하지만 조직이 성장하고 애플리케이션에 대한 수요가 증가함에 따라 마이크로서비스 아키텍처가 이득이 될 수 있습니다.

많은 조직에서 분산 아키텍처를 갖춘 마이크로서비스가 트렌드이기 때문에, Atlassian은 회사들이 확장하면서 분산 아키텍처의 복잡성을 관리하도록 지원하는 Compass를 개발했습니다. Compass는 확장 가능한 개발자 경험 플랫폼으로, 모든 엔지니어링 결과물에 대한 단절된 정보와 팀 차원의 공동 작업을 검색 가능한 중앙 집중식 위치로 모아줍니다.