후기 단계 마이크로서비스

May 09 2023

마이크로서비스를 모놀리스로 결합하여 비용을 90%까지 절감하고 확장하려는 Amazon Prime Video 팀의 노력에 대해 읽었습니다. 여기에 더 많은 이야기가 있다고 확신하지만 인터넷에 비슷한 이야기가 게시되어 있습니다. 지난 10년 동안의 마이크로서비스 열풍에 대한 일종의 반박입니다.

마이크로서비스를 모놀리스로 결합하여 비용을 90%까지 절감하고 확장하려는 Amazon Prime Video 팀의 노력에 대해 읽었습니다 . 여기에 더 많은 이야기가 있다고 확신하지만 인터넷에 비슷한 이야기가 게시되어 있습니다. 지난 10년 동안의 마이크로서비스 열풍에 대한 일종의 반박입니다.

그것은 트래픽이 증가함에도 불구하고 마이크로 서비스의 수가 정점에 도달한 후 감소하기 시작했던 Twitter에서 보낸 지난 몇 년을 생각나게 했습니다. 모든 종류의 애플리케이션 논리는 일종의 모놀리식 관리 플랫폼에 흡수되었습니다. 목적에 맞게 구축된 마이크로 서비스를 만드는 원칙은 본질적으로 좋지 않으며 특정 시점 이후에도 많은 팀에 긍정적인 ROI가 되지 않는 것 같습니다.

마이크로서비스 아키텍처는 비용이 많이 들 수 있습니다. 지난 10년 동안 다음과 같은 이유로 이것이 대규모 엔지니어링 조직에 대한 자연스러운 정책이라는 이야기가 있었습니다.

팀은 더 넓은 조직 및 해당 코드의 자율성을 사용하여 서비스를 반복할 수 있습니다.
더 큰 시스템을 중단하지 않고 서빙 아키텍처의 작은 구성 요소를 수정할 수 있습니다.
이 아키텍처는 독립적인 서비스를 통해 명확하고 관리 가능한 애플리케이션 및 장애 도메인을 정의할 수 있습니다.
아키텍처는 독립적으로 조정 가능하거나 확장 가능한 워크로드를 허용합니다.

단일 또는 소수의 모놀리스와 달리 결과적으로 소규모 서비스 소유 팀과 더 넓은 생태계에 오프로드되는 작업의 복잡성을 고려해야 합니다. 오프로드된 작업은 조직의 기술 스택의 성숙도에 따라 다릅니다. 그러나 다음을 포함할 수 있습니다.

모든 서비스 소유 팀 간에 분산된 운영 책임 및 오버헤드

작업 예약 및 배포 도구, 서비스 검색, RPC 프레임워크, VM 및 관련 조정, 서비스 모니터링 및 로깅에서 서비스 인프라 구성 요소에 대한 이해 및 구성
SLO 및 SLI, 서비스 실패 및 결함 처리, 배압 처리 및 오류 신호에 대한 분산 정의 및 개발 프로세스
분산되고 종종 조정되지 않는 용량 계획, 부하 테스트, 통합 테스트 구현 및 책임

많은 백엔드 서비스와 상호 작용하는 애플리케이션 로직은 종종 일련의 맞춤형 서비스 API 정의, 시맨틱, 데이터 모델, 버전 관리 시스템 및 때때로 다른 프로토콜을 탐색합니다.
엔지니어는 기능적인 것을 구축하기 위해 전반적인 서비스 아키텍처와 트래픽 패턴을 이해하고 추론해야 합니다.
최적이 아니거나 병목 현상이 있는 서빙 경로, 분산 데이터 복제 및 소비, 순환 요청 종속성에 대한 유기적 해결 방법

추론 및 순위 지정, 이벤트 처리, HTTP/내부 프로토콜 API 변환 및 데이터 모델 매핑 문제에 대한 현지화된 접근 방식
일반 조각화 및 스택 전체에서 표준을 유지하기 어려움

문제는 새로운 서비스를 만들고 구축하고 운영하는 과정이 비싸다 는 것입니다 . 해당 서비스를 프로덕션 서비스 아키텍처에 통합하는 것은 어렵습니다. 효율적인 운영을 위해 다른 서비스를 조정하는 데 필요한 주의 해당 서비스 계정, 관찰 가능성 및 로깅 프로필, 통합 테스트, 대기 중 교체 및 기타 모든 항목을 설정하는 것은 팀의 유지 관리 및 운영 오버헤드에 추가됩니다. 대부분의 조직에는 이러한 종류의 복잡한 상용구 작업을 위한 자동화 및 엔드 투 엔드 스캐폴딩이 부족합니다.

이 오버헤드는 팀이 UNIX에서 영감을 받은 마이크로서비스 아키텍처 원칙인 " 한 가지만 잘 수행 "을 고수하는 데 큰 의욕을 꺾는 요인입니다. 기존 서비스에 새로운 사용 사례를 구축하는 것이 더 쉽습니다. 스펙트럼의 맨 끝에서 팀은 다양한 제품 또는 기능을 포함할 수 있는 팀으로서 책임지는 모든 것을 캡슐화하기 시작하는 "매크로" 서비스를 운영합니다. 조직 개편은 비교적 흔하게 발생하기 때문에 시간이 지남에 따라 소유권 품질이 떨어집니다. 당신은 진흙 덩어리로 작업하고 있습니다.

매크로 서비스 중단은 하나의 특정 기능 세트로 제한되지 않고 대신 과거 조직도와 유사할 수 있는 예측할 수 없거나 원칙이 없는 시스템 범위입니다. 사이트는 이러한 서비스를 사용할 수 없는 것을 허용하거나 허용하지 않을 수 있습니다. 이기종 워크로드에 대한 서비스를 최적화하는 것은 더 어렵습니다. 호출 경로는 풀릴 수 없습니다. 이전 동료가 이 "마이크로리스"를 만들어 냈습니다.

마이크로서비스는 로컬 최적화를 서비스 아키텍처로 인코딩하고 인센티브를 제공합니다. 목표가 서비스 개발 연합일 때 서비스 아키텍처를 위한 원칙적인 디자인에 대한 책임을 팀에 부여하는 것은 어렵습니다. 마찬가지로 종속 서비스의 속성이 맞춤형일 때 백엔드 전체 최적화 문제를 해결하기 어렵습니다. 신중하게 설계된 서비스 아키텍처 및 지원 서비스 플랫폼이 없으면 활용하기가 어렵습니다. 재사용 가능한 제품 플랫폼 코드는 일련의 대규모 서비스 또는 공유 라이브러리 에 흩어져 있습니다 . 프런트 엔드 서비스는 일반적으로 맞춤형입니다.

마이크로서비스 활용은 컴퓨팅 계층(서비스 작업 또는 컨테이너를 오케스트레이션하고 실행하는 모든 것), 서비스 검색, VM(특정 컨텍스트에서 적용 가능), 서비스 프레임워크(예: gRPC , Finagle 또는 Rest.Li ) 및 중앙 집중식 개발자 도구 에서 발견되었습니다. 물론 서비스 메시는 이러한 우려 사항 중 일부를 훌륭하게 요약합니다.

이러한 문제에 접근하는 또 다른 방법은 기능적 오버헤드를 줄이는 것입니다. 따라서 서비스 실행 의 반복되는 인프라 오버헤드를 줄이려고 시도하는 대신 공통 작업 클래스를 다시 구현하는 팀의 비용을 줄일 수 있습니다 . 이것이 관리형 플랫폼이 매우 성공적인 이유입니다. 서비스를 생성하거나 운영하는 데 비용이 많이 들더라도 공용 또는 개인 관리형 플랫폼에 아웃소싱하여 응용 프로그램 논리를 얇게 만들 수 있다면 소유 팀의 부담이 줄어듭니다.

조직이 특정 요구 사항, 목표 및 기술 스택 성숙도를 기반으로 아키텍처 상충 관계를 신중하게 평가하는 것이 중요합니다. 마이크로서비스는 특정 이점을 제공합니다. 또한 처음에는 관리할 수 있는 것처럼 보이지만 시간이 지나면서 복잡해지는 복잡성과 운영 오버헤드를 도입합니다. 이러한 문제를 해결하지 못하면 전체 개발 프로세스가 모놀리식에서 작업하는 것보다 조금 더 쉬워집니다.