컨테이너 확장의 예술: 발견

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

컨테이너 확장 기술에 대한 이 게시물에서 우리는 발견에 대해 깊이 파고들 것입니다.

발견

전통적인 규모 모델은 구성이 비교적 고정되어 있습니다. 부하 분산 프록시는 알고리즘을 사용하여 상당히 정적인 리소스 풀에서 리소스를 선택합니다. 리소스 선택(배포)은 실시간 이벤트이며 부하와 응답 시간과 같은 적시(just-in-time) 변수를 고려할 수 있지만, 전반적인 환경은 그렇지 않습니다. 운영자는 용량 증가나 감소를 관리하는 엔터프라이즈 정의 프로세스에 따라 리소스를 추가하고 제거합니다.

현대적 규모 모델은 본질적으로 불안정하고 역동적이다. 현대 시스템에서 규모의 전제는 모든 것을 '자동화'하는 것입니다. 클라우드에 의해 구체화된 개념인 자동 확장은 수요에 따라 리소스 풀을 확장하거나 축소하는 개념을 강요합니다. 하지만 이는 기존 모델에서 반걸음밖에 벗어나지 못했습니다. 부하 분산 알고리즘이 선택을 하는 "핵심" 리소스 풀이라는 개념이 여전히 존재합니다. 해당 풀은 동적으로 확장되거나 축소될 수 있지만, 여전히 운영 방식에 사용되는 상당히 전통적인 모델에 의해 제한을 받습니다.

컨테이너, 특히 컨테이너 오케스트레이션 환경은 그런 틀에서 완전히 벗어납니다. 엔드포인트 (ingress )의 개념은 컨테이너 기반 규모에서 몇 안 되는 '고정' 요소 중 하나이며, 라우팅 규칙부터 지원 풀을 구성하는 리소스에 이르기까지 모든 것은 매우 가변적인 것으로 간주됩니다. 이론적으로는 용기는 몇 초만 생존할 수 있습니다. 그러나 실제 적용에서는 일반적으로 며칠 동안 생존하는 경향이 있습니다. 리소스가 몇 개월(때로는 몇 년) 동안 유지되는 기존 모델과 비교했을 때, 이러한 수명은 자동화 없이는 운영자에게 감당할 수 없는 압박을 가합니다.

따라서 발견은 컨테이너 확장에 있어서 중요한 구성 요소입니다. 부하 분산 프록시는 1분 전과 동일할 수도 있고 그렇지 않을 수도 있는 리소스 풀에서 리소스를 선택할 수 있어야 합니다. 따라서 대부분의 컨테이너 오케스트레이션 환경에는 프록시가 리소스를 실시간으로 검색하여 확장성을 보장할 수 있도록 돕는 리소스 '레지스트리'가 포함되어 있습니다.

이 프로세스를 위해서는 프록시가 컨테이너 오케스트레이션 생태계에 통합되어야 할 뿐만 아니라 이러한 환경의 공용어를 구사해야 합니다. 즉, 컨테이너 오케스트레이션 환경 내에서 선언적 구성 파일(리소스 파일)과 메타데이터를 사용하여 프록시가 확장하려는 서비스에 연결된 리소스를 식별할 수 있도록 해야 합니다. 이를 통해 프록시는 리소스 "풀"을 실시간으로 자동 조정할 수 있으며, 이미 유감스럽게도 종료된 리소스를 선택하는 당혹스러운 상황을 피할 수 있습니다.

검색 없이는 로드 밸런싱 프록시가 컨테이너 환경에서 애플리케이션과 서비스를 확장할 수 있는 효율적인 방법이 없습니다. 어떤 운영자도 수동 구성 방법을 사용하여 이러한 환경의 변화에 발맞출 수 없습니다. 어떤 리소스가 활성화되어 있고 어떤 서비스에 연결되어 있는지 추적하는 데만도 대부분의 시간이 소모되어, 실제로 필요한 변경 작업을 할 시간이 거의 없습니다.

발견은 컨테이너 오케스트레이션 환경의 구성 요소가 실시간으로 작동할 수 있는 수단을 제공하고, 로드 밸런싱 프록시가 필요에 따라 리소스를 선택하는 데 필요한 정보를 확보함으로써 앱과 서비스를 확장할 수 있도록 합니다.