모놀리식 애플리케이션의 성능 제약 조건
시스템 아키텍처를 변경하도록 선택할 수 있는 여러 가지 이유가 있습니다. 운영 민첩성, 비용, 확장성 및 성능은 시스템의 아키텍처를 결정할 때 중요한 역할을 수행하는 몇 가지 요소에 불과합니다. 이 예제에서는 성능이 드론 배달 시스템의 요인이 되는 방법을 자세히 살펴봅니다.
Fabrikam 드론 배달 비즈니스가 성장함에 따라 시스템 로드가 증가합니다. 현재 아키텍처의 부하가 한계에 달하고 있습니다. Fabrikam은 현재의 모놀리식 아키텍처에서는 사용할 수 없는 애플리케이션 크기 조정의 유연성을 높이고 싶습니다. 애플리케이션의 확장성 개선은 Fabrikam이 애플리케이션을 마이크로 서비스 아키텍처로 이동하는 것을 고려하게 된 요인 중 하나입니다.
모놀리식 및 마이크로 서비스 크기 조정
마이크로 서비스 아키텍처의 주요 혜택 중 하나는 크기 조정 기능이 향상된 것입니다. 서비스는 구분되므로 부하가 증가함에 따라 각 서비스의 크기를 개별적으로 조정하는 것이 더 쉽습니다.
드론 배달 시스템에서 이러한 기능의 차이를 확인할 수 있습니다. 모놀리식 아키텍처의 경우 모든 서비스는 애플리케이션의 단일 인스턴스 내에 포함됩니다. 배달 요청을 제출하고 관리하기 위해 API 인터페이스가 고객에게 노출됩니다. 고객 요청이 증가하면 시스템 부하가 증가합니다. 사용자 환경에 부정적인 영향을 주지 않으려면 시스템에 추가 리소스를 할당해야 합니다.
모놀리식 아키텍처에서 이 서비스의 크기를 개별적으로 조정하려면 다른 서비스의 리소스 크기도 조정해야 합니다. 리소스가 각 애플리케이션 인스턴스 내에 포함되어 있기 때문입니다. 다른 서비스에 대한 부하가 최소화되고 추가 리소스 사용률이 필요하지 않을 수 있으므로 이 정렬은 비효율적입니다.
마이크로 서비스 아키텍처에서는 각 서비스가 별개이기 때문에 다른 서비스와 독립적으로 API의 크기를 조정할 수 있습니다. 이렇게 하면 불필요한 서비스의 리소스를 사용할 필요가 없으므로 효율성이 향상됩니다.
드론 배달 모놀리식 아키텍처의 문제
패키지 서비스는 비즈니스의 중요한 부분으로 확인되었으며, 원래 모놀리식의 일부였습니다. 고객은 이에 대한 의존도를 크게 높이고 있으며, 이 부하가 증가함에 따라 성능에 부정적인 영향을 미칩니다. 이 상황을 해결하기 위해 Fabrikam은 이 비즈니스 부분을 완전히 제어하는 개발 팀을 전담했습니다. 팀은 이 서비스를 개발하고 반복하며 패키지 서비스의 모든 측면을 전적으로 담당할 계획입니다.
패키지 서비스가 모놀리식이므로 팀은 자율적으로 운영될 수 없습니다. 공유 데이터 및 데이터 구조에 의존해야 합니다. 또한 필요한 만큼 신속하게 반복할 수 없습니다. 성능 및 확장성 문제와 더불어 이 서비스는 마이크로 서비스의 주요 후보로 확인되었습니다.
Fabrikam에서 마이크로 서비스 아키텍처를 활용하기 위해 애플리케이션을 분석하고 분해할 수 있는 방법을 자세히 살펴봅시다.