컨테이너 확장의 예술: 분포

컨테이너를 확장한다는 것은 단순히 서비스 앞에 프록시를 두고 그냥 방치하는 것보다 더 많은 것입니다. 확장에는 배포 외에도 더 많은 요소가 필요하며, 빠르게 변화하는 컨테이너 세계에서는 확장을 보장하는 데 필요한 다섯 가지 기능, 즉 재시도, 회로 차단기, 검색 , 배포, 모니터링이 있습니다.

컨테이너 확장 기술에 대한 이 게시물에서는 배포에 대해 자세히 알아보겠습니다.

분포

무엇이든 확장하는 비결은 항상, 부분적으로 요청이 유한한 리소스에 어떻게 분산되는지에 달려 있었습니다. 심지어 클라우드와 무한해 보이는 컴퓨팅 공급도 그 조건을 바꾸지는 못합니다. 요청을 받은 순간, 해당 요청을 수락하고 처리할 수 있는 리소스의 가능한 목록은 유한합니다. 기간.

그러므로 요청을 어디로 보낼 것인가에 대한 결정이 매우 중요해집니다. 잘못된 리소스로 보내면 성능이 저하될 수 있습니다. 올바른 담당자에게 보내면 소비자/직원이 결과에 만족할 것입니다.

초창기에는 이러한 결정이 전적으로 알고리즘에 근거했습니다. 라운드 로빈. 연결이 가장 적습니다. 가장 빠른 응답. 이러한 확고한 메커니즘은 오늘날에도 여전히 존재하지만 점차 확실히 의사결정 과정에서 유일한 요소가 아니라 또 다른 요소가 되어 버렸습니다.

그 이유는 더 이상 연결 기반 의사 결정 프로세스(일명 '단순한 로드 밸런싱')에만 의존하지 않기 때문입니다. 부하 분산이 주로 TCP 연결을 관리하는 것이었을 때에는 연결 기반의 분산 방식이 합리적이었습니다. 하지만 이제 규모는 알고리즘만큼이나 아키텍처에 기반을 두고 있으며, 요청 분산은 문자 그대로 4계층 프로토콜을 넘어서는 많은 변수를 포함하는 복잡한 계산이 될 수 있습니다.

분산을 더욱 복잡하게 만드는 것은 오늘날 아키텍처 자체가 점점 더 분산되고 있다는 현실입니다. 클라우드뿐만 아니라 컨테이너 전반에 걸쳐서도 가능합니다. 동일한 앱(또는 API)의 여러 버전이 동시에 서비스될 수 있습니다. 요청을 배포하는 시스템은 요청을 인식하고 구별할 수 있어야 하며 올바른 엔드포인트에 전달되도록 보장해야 합니다.

오늘날에는 연결 용량뿐만 아니라 7계층(HTTP) 매개변수를 고려하여 결정이 내려지는 경우가 점차 늘고 있습니다. 호스트 이름. API 메소드(일명 URI). API 키. 버전 번호가 포함된 사용자 정의 HTTP 헤더. 위치. 장치. 사용자. 요청은 접수된 상황에 따라 평가되며, 결정은 마이크로초 단위로 내려집니다.

오늘날의 유통에는 단계적이고 구조적인 접근 방식이 필요합니다. 앱 아키텍처가 더 깊어질수록 세부적인 내용은 줄어듭니다. 프록시가 동일한 마이크로서비스의 X개 클론 간의 부하 분산 결정을 내릴 때쯤이면, 전통적인 알고리즘 기반 방정식만을 사용하고 있을 가능성이 큽니다. 한편, 환경의 바깥쪽 가장자리에서는 인그레스 컨트롤러가 HTTP 계층 변수를 기반으로 때로는 복잡한 결정을 내립니다.

외부적으로 유통은 건축 에 의해 주도됩니다. 내부에서는 알고리즘 을 통해 .

둘 다 중요한 구성 요소입니다. 아마도 컨테이너 확장에 가장 중요한 구성 요소일 것입니다.

두 방법 모두 요청을 배포할 수 있는 리소스의 상태(health)에 대한 정확하고 실시간 정보에 의존합니다. 이 시리즈의 다음 몇 게시물에서는 모니터링에 대해 다루겠습니다.