의도치 않은 결과: 부하 중인 프록시

요즘에는 확장성의 필요성은 의문의 여지가 없습니다. 대답은 항상 '예'입니다. 필요합니다. 사업의 성장은 오늘날의 사업 모델의 일부인 애플리케이션의 운영적 성장에 달려 있습니다. 이는 어떤 산업이든 마찬가지입니다. 따라서 시스템은 일반적으로 필요할 때가 아니라 필요할 때 그 규모를 달성하는 데 필요한 것들과 함께 배포됩니다. 이는 일반적으로 프록시를 의미합니다. 따라서 확장을 담당하는 프록시(일반적으로 로드 밸런서)는 모든 현대 아키텍처에서 매우 중요한 구성 요소입니다.

이러한 프록시가 확장 메커니즘으로 기능한다는 것만이 문제가 아닙니다. 자동 확장의 경이로움을 통해 점점 더 자동으로 확장하도록 요구받고 있습니다. 하이픈으로 연결된 이 간단한 단어는 많은 것을 의미합니다. 예를 들어, 프로그램에 따라 시스템에 추가 용량을 제공할 뿐만 아니라 확장성을 담당하는 프록시가 해당 용량의 존재를 알고 요청을 직접 전달할 수 있도록 지시하는 기능입니다.

가치 있는 모든 프록시는 필요한 프로그래밍 인터페이스를 갖추고 있다고 가정합니다. 결국 API 경제는 앱과 사람 간의 공유에 관한 것이 아니라 온프레미스와 오프프레미스, 클라우드의 시스템 간의 공유에 관한 것입니다. 하지만 우리가 종종 인식하지 못하는 점은 부하 분산 프록시에 새로운 리소스를 추가하는 작업이 데이터 평면이 아닌 관리 또는 제어 평면에서 이루어진다는 것입니다.

그렇군요. 통계를 수집하거나 구성을 조작하는 동안 시스템 실행을 방해하고 싶지 않습니다. 특히 시스템이 최대 속도로 실행 중이고 앱을 열성적인 사용자에게 제공하고 있어서 용량을 추가하려고 하는 상황에서는 그럴 수 없습니다.

하지만 그 반대의 상황이 발생하면 어떻게 될까요? 시스템 실행이 시스템 관리 능력을 방해하는 경우는 언제인가요?

자동 크기 조정(또는 수동 크기 조정)은 실패할 것입니다. 즉, 앱 용량은 늘어나지 않고 사업은 타격을 받게 됩니다.

그거 나쁘네요. 내가 그걸 말해줄 필요가 있을까요?

이런 일이 일어나는 이유는 많은 프록시(이러한 역설을 염두에 두고 만들어지지 않음)가 제어 평면과 데이터 평면 모두에 대한 시스템 리소스를 공유하기 때문입니다. 그들 사이에는 고립이 없습니다. 앱을 제공하는 것과 동일한 네트워크가 프록시를 관리하는 데 사용됩니다. 앱을 제공하는 데 할당된 것과 동일한 RAM과 컴퓨팅이 프록시를 관리하는 데도 할당됩니다. 부하가 걸리면 이 둘 중 하나만 리소스를 얻습니다. 확장을 위해 프록시에 앱 리소스를 추가하려고 하지만 시스템에 액세스하여 이를 수행할 수 없다면 큰 문제가 될 것입니다.

그렇기 때문에 관리 용이성을 고려하여 프록시를 선택하는 것이 중요합니다. 관리하기 쉬운 것만이 아닙니다. API와 스크립팅 기능뿐만 아니라 부하 속에서 의 관리 용이성도 뛰어납니다. 대규모에 맞춰 특별히 설계된 프록시에는 "관리" 리소스로 지정된 별도의 리소스 세트가 있어야 하며, 데이터 플레인이 앱을 제공하면서 아무리 로드되어 있어도 여전히 관리 및 모니터링할 수 있어야 합니다.

네트워크 세계에서는 이를 대역 외 관리라고 부르는데, 이는 데이터 경로 외부, 즉 기본 경로, 중요 경로에서 발생하기 때문입니다.

부하가 걸리는 상황에서 대역 외 프록시를 관리할 수 있는 능력은 앱과 이를 통한 비즈니스를 자동 또는 수동으로 확장하는 전반적인 능력에 중요합니다.