모놀리식 및 마이크로 서비스 아키텍처
Fabrikam은 새 드론 서비스를 기존 애플리케이션에 통합했습니다. Fabrikam은 이 솔루션이 애플리케이션에 적합한 장기 계획이 아니라는 것을 알고 있습니다. 기존 시스템이 모놀리식 아키텍처라는 말의 정확한 의미는 무엇일까요?
모놀리식 아키텍처란?
모놀리식 아키텍처는 애플리케이션의 모든 구성 요소가 단일 단위 내에 배치되는 아키텍처입니다. 이 단위는 일반적으로 애플리케이션의 단일 런타임 인스턴스 이내로 제한됩니다. 기존 애플리케이션은 대체로 웹 인터페이스, 서비스 계층, 데이터 계층으로 구성됩니다. 모놀리식 아키텍처에서는 이러한 계층이 애플리케이션의 인스턴스에서 결합됩니다.
모놀리식 아키텍처는 대체로 작은 애플리케이션에는 적합한 솔루션이지만 애플리케이션이 커짐에 따라 제어하기 어려워질 수 있습니다. 원래는 작았던 애플리케이션이 곧 크기 조정, 배포, 혁신이 어려운 복잡한 시스템이 될 수 있습니다.
모든 서비스가 단일 단위 내에 포함됩니다. 이러면 비즈니스와 이후의 시스템 부하가 커짐에 따라 문제가 발생합니다. 몇 가지 문제는 다음과 같습니다.
- 독립적으로 서비스 크기의 조정이 어려움.
- 코드베이스가 증가함에 따라 배포 개발과 관리가 복잡해져 릴리스 및 새로운 기능 구현 속도가 느려짐.
- 아키텍처가 단일 기술 스택에 매여 있어서 새로운 플랫폼 및 SDK에서의 혁신이 제한됩니다.
- 데이터 스키마 업데이트가 점차 어려워질 수 있음.
마이크로 서비스 아키텍처와 같은 대체 아키텍처를 통해 이러한 문제를 해결할 수 있습니다.
마이크로 서비스 아키텍처란?
마이크로 서비스 아키텍처는 작고, 독립적이며, 느슨하게 결합된 서비스로 구성됩니다. 각 서비스를 독립적으로 배포하고 크기를 조정할 수 있습니다.
마이크로 서비스는 소규모 개발자 팀이 작성하고 유지 관리할 수 있을 만큼 작습니다. 서비스를 독립적으로 배포할 수 있기 때문에, 팀이 전체 애플리케이션을 다시 빌드하여 다시 배포하지 않고도 기존 서비스를 업데이트할 수 있습니다.
일반적으로 각 서비스에서 자체 데이터를 처리합니다. 데이터 구조가 격리되어 있으므로 스키마 변경이나 업그레이드가 다른 서비스에 종속되지 않습니다. 데이터 요청은 일반적으로 API를 통해 처리되며, 잘 정의되고 일관된 액세스 모델을 제공합니다. 내부 구현 세부 정보는 서비스 소비자에게 숨겨집니다.
각 서비스가 독립적이므로 서로 다른 기술 스택, 프레임워크 및 SDK를 활용할 수 있습니다. 일반적으로 서비스는 RPC(원격 프로시저 호출) 또는 기타 사용자 지정 통신 방법 대신 잘 정의된 API를 사용하여 서비스 간 통신을 위한 REST 호출에 의존합니다.
마이크로 서비스 아키텍처는 기술 중립적이지만 컨테이너 또는 서버리스 기술이 구현에 사용되는 경우가 많습니다. 개발 활동의 속도와 품질 향상을 위해 CI/CD(지속적인 배포 및 연속 통합)가 자주 사용됩니다.
마이크로 서비스 아키텍처의 혜택
마이크로 서비스 아키텍처를 선택해야 하는 이유는 무엇일까요? 마이크로 서비스 아키텍처에는 몇 가지 주요 혜택이 있습니다.
- 민첩성
- 소규모 코드, 소규모 팀
- 기술의 혼합
- 복원력
- 확장성
- 데이터 격리
민첩성
마이크로 서비스는 독립적으로 배포되기 때문에 버그 수정 및 기능 릴리스를 관리하기가 더 쉽습니다. 전체 애플리케이션을 다시 배포하지 않고 서비스를 업데이트할 수 있고, 문제가 발생하면 업데이트를 롤백할 수 있습니다. 많은 기존 애플리케이션에서는 애플리케이션의 한 부분에서 버그가 발견되면 전체 릴리스 프로세스가 차단될 수 있습니다. 결과적으로 버그 수정이 통합, 테스트, 게시될 때까지 새 기능이 보류될 수 있습니다.
소규모 코드, 소규모 팀
마이크로 서비스는 규모가 작기 때문에 한 기능 팀에서 충분히 구축, 테스트 및 배포할 수 있습니다. 소규모 코드베이스는 파악하기가 더 쉽습니다. 대규모 모놀리식 애플리케이션에서는 시간이 지남에 따라 코드 종속성이 꼬이는 경향이 있습니다. 새 기능을 추가하려면 여러 지점의 코드를 손봐야 합니다. 마이크로 서비스 아키텍처는 코드 또는 데이터 저장소를 공유하지 않음으로써 종속성을 최소화합니다. 그러면 새 기능을 보다 쉽게 추가할 수 있습니다.
팀 규모가 작으면 민첩성 또한 높아집니다. “피자 두 판의 법칙(two-pizza rule)”에 따르면 이상적인 팀의 규모는 피자 두 판으로 한 끼를 때울 수 있을 만큼 작아야 합니다. 물론 정확한 메트릭은 아니며, 팀원의 식욕에 따라 달라집니다. 하지만 요점은 대규모 그룹일수록 커뮤니케이션 속도가 느리고, 관리 오버헤드가 증가하며, 민첩성이 감소하기 때문에 생산성이 저하되는 경향이 있다는 것입니다.
기술의 혼합
팀이 해당 서비스에 가장 적합한 기술을 선택할 수 있습니다. 기술 스택을 적절히 혼합해 사용할 수 있습니다. 각 팀은 서비스를 지원하는 기술을 독립적으로 발전시킬 수 있습니다. 이러한 독립성 때문에 서비스에서 각기 다른 개발 언어, 클라우드 서비스, SDK 등을 사용할 수 있습니다. Teams는 서비스 소비자에게 미치는 외부 영향을 최소화하면서 서비스에 가장 적합한 옵션을 선택할 수 있습니다.
복원력
개별 마이크로 서비스를 사용할 수 없게 되면 모든 업스트림 마이크로 서비스가 오류를 올바르게 처리하도록 설계된 경우(예: 회로 중단을 구현하여) 전체 애플리케이션이 중단되지 않습니다. 사용자 또는 서비스 소비자는 애플리케이션 상시 환경의 혜택을 보게 됩니다.
확장성
마이크로 서비스 아키텍처를 사용하면 다른 서비스와 독립적으로 각 마이크로 서비스의 크기를 조정할 수 있습니다. 전체 애플리케이션을 수평 확장하지 않고도 더 많은 리소스가 필요한 하위 시스템을 수평 확장할 수 있습니다. 이로써 애플리케이션의 전반적인 성능이 향상됩니다. 비용을 최소화하는 데도 도움이 됩니다. 전체 애플리케이션을 수직 확장하는 대신 리소스가 필요한 서비스에만 리소스를 추가할 수 있습니다.
데이터 격리
단일 마이크로 서비스만 영향을 받기 때문에 마이크로 서비스 아키텍처에서는 데이터 스키마 업데이트를 수행하는 기능이 향상됩니다. 모놀리식 애플리케이션에서는 스키마 업데이트가 어려울 수 있습니다. 애플리케이션의 여러 부분에서 동일한 데이터를 사용할 수 있기 때문에 스키마 변경에 위험이 따릅니다. 마이크로 서비스 아키텍처를 사용하면 API 표면 손상 없이 스키마를 업데이트할 수 있습니다. 기본 데이터 아키텍처에 관계없이 서비스 소비자에게는 동일한 환경이 제공됩니다.
마이크로 서비스 아키텍처의 잠재적인 문제
마이크로 서비스 아키텍처의 장점이 많은 것은 사실이나 모든 문제를 해결해 주는 것은 아닙니다. 마이크로 서비스 아키텍처에도 고유한 문제가 있습니다.
- 복잡성
- 개발 및 테스트
- 거버넌스 부족
- 네트워크 정체 및 대기 시간
- 데이터 무결성
- 관리
- 버전 관리
- 기능
복잡성
마이크로 서비스 애플리케이션에는 동등한 모놀리식 애플리케이션보다 움직이는 부분이 더 많습니다. 각 서비스는 더 간단하지만, 전체 시스템은 더 복잡합니다. 서비스 검색, 오케스트레이션 및 자동화 도구를 사용하여 전체 애플리케이션에서 관리해야 하는 부분이 더 많을 수 있습니다.
개발 및 테스트
다른 종속 서비스를 사용하는 소규모 서비스를 작성하려면 기존 모놀리식 또는 계층화된 애플리케이션 작성과는 다른 방법이 필요합니다. 기존 도구는 서비스 종속성 작업에 맞게 설계되지 않았을 수 있습니다. 서비스 경계를 넘는 리팩터링이 어려울 수 있습니다. 특히 애플리케이션이 빠르게 발전하는 경우 서비스 종속성을 테스트하기도 어렵습니다.
거버넌스 부족
마이크로 서비스 빌드에 대한 분산 접근 방법에는 장점이 있지만 문제가 발생할 수도 있습니다. 언어와 프레임워크가 너무 많아서 애플리케이션 유지 관리가 어려워질 수 있습니다. 팀의 유연성을 지나치게 제한하지 않고 몇 가지 프로젝트 전체 표준을 적용하는 것이 유용할 수도 있습니다. 특히 로깅, 메트릭 등의 교차 기능에는 통일적 표준이 필요합니다.
네트워크 정체 및 대기 시간
다수의 작고 세분화된 서비스를 사용하면 서비스 간 통신이 증가할 수 있습니다. 서비스 종속성의 체인이 너무 길어지면(예: 서비스 A가 C를 호출하는 B를 호출하는 경우) 이러한 네트워크 호출의 추가 대기 시간이 문제가 될 수 있습니다. API를 신중하게 설계하세요. 통신량이 과도한 API를 피하고, 직렬화 형식을 고려하고, 비동기 통신 패턴을 사용할 영역을 찾습니다.
데이터 무결성
각 마이크로 서비스의 데이터 지속성은 해당 마이크로 서비스가 담당합니다. 그 결과, 데이터 일관성이 문제가 될 수 있습니다. 가능한 경우 결과적 일관성을 수용합니다. 중복된 데이터가 발생하거나 데이터 아키텍처가 무질서하게 확장될 수도 있습니다. 이런 상황에서는 서비스 및 데이터 중복으로 인해 원시 스토리지 비용과 데이터 플랫폼 서비스 비용이 증가할 수 있습니다.
관리
마이크로 서비스에 성공하려면 성숙한 DevOps 문화가 필요합니다. 서비스 간 상관 관계 로깅이 까다로울 수 있습니다. 일반적으로 로깅은 단일 사용자 작업에 대한 여러 서비스 호출을 상호 연결해야 합니다.
버전 관리
서비스 업데이트로 인해 종속된 서비스가 손상되지 않아야 합니다. 언제든지 여러 서비스가 업데이트될 수 있습니다. 신중하게 설계하지 않으면 이전 버전 또는 이후 버전과의 호환성 문제가 발생할 수 있습니다. 새 API 버전 도입이 늦는 서비스로 인해 이전 API에 필요한 리소스 및 유지 관리가 늘어날 수 있습니다.
기능
마이크로 서비스는 고도로 분산된 시스템입니다. 이러한 분산된 시스템을 적절하게 개발, 관리 및 유지 관리하려면 다양한 기능이 필요한 경우가 많습니다. 팀에게 성공에 필요한 기술과 경험이 있는지 신중하게 평가합니다. 팀의 능력을 발전시키는 데 필요한 시간과 계획을 감안합니다.
마이크로 서비스 아키텍처를 선택해야 하는 경우는 언제인가요?
이 배경 정보를 감안할 때 마이크로 서비스 아키텍처가 가장 적합한 상황은 무엇인가요?
- 높은 릴리스 속도가 필요한 대규모 애플리케이션
- 높은 확장성이 필요한 복잡한 애플리케이션
- 풍부한 도메인 또는 다양한 하위 도메인을 보유한 애플리케이션
- 소규모 개발 팀으로 구성된 조직