인그레스 컨트롤러: 새로운 이름, 익숙한 기능

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

지역 특유의 표현. 특정 지역에서만 통하는 독특한 의미를 지녀 그 지역 출신이 아닌 사람들을 당황하게 할 수 있는 단어나 문구를 말합니다. 예를 들어 저는 밖에 나갔다가 목이 마르면 ‘버블러’를 찾습니다. 아마 여러분은(위스콘신 사람이 아니라고 생각하니) 식수대를 찾겠죠. 위스콘신에서는 거리를 마일이 아니라 시간으로 잽니다. 신호등은 ‘멈췄다 가는’ 불이라고 부릅니다. 실제로 그렇게 하니까요.

남편(위스콘신 토박이가 아니다)이 가장 재미있어하는 표현은 “C’mere once.”입니다. 저와 제가 이 말을 쓰는 아이들에게는 자연스럽게 통한다는 것 외에는 굳이 설명하려 하지 않겠습니다. 그리고 우리는 “Up North”가 방향이 아니라 장소를 뜻한다는 것을 본능적으로 이해합니다. 정확히 어디인지는 말하는 사람마다 다를 수 있지만, 모든 위스콘신 토박이에게는 “모든 것에서 벗어나기 위해 가는 그곳”이라는 공통된 의미를 지닙니다.

당신도 다른 곳에서 자랐으니 아마 자신만의 목록이 있을 것이다. 하지만 이건 내 블로그니까, 나는 내 목록을 쓰겠다.

하지만 오늘의 요점은 의미론 자체를 논하는 데 있는 것이 아니라, 바로 여러분의 뒷마당에서 일어나는 좀 더 국지적인 현상에 이를 어떻게 적용할 수 있는지에 있습니다. 적어도 그 뒷마당이 여러분의 조직이라면 말이죠.

컨테이너와 이를 운용하는 데 필수적인 자동화된 클러스터 제어 시스템(흔히 오케스트레이션이라고 함)의 부상은 한 영역에서 쓰이던 용어를 다른 영역으로 억지로 넘어가게 하는 의도치 않은 결과를 낳았습니다. 여기서 말하는 영역은 애플리케이션 개발과 본격적인 IT 운영입니다.

컨테이너 용어의 흥미로운 사례

필요한 규모의 유연성과 안정성을 확보하기 위해 요구되는 여러 기능으로 인해, 이전에는 프로덕션 환경에서만 사용되던 일부 서비스가 컨테이너 ‘환경’으로 이전되었습니다. 이제 이러한 기능은 표면적으로 해당 환경에 ‘내장’되어 있으며, 경량 통합(API 및 메시지 큐잉)을 활용해 지금까지 완전하게 구현된 클라우드 컴퓨팅 환경에서만 가능했던 자동 확장과 고가용성 애플리케이션을 실현합니다.

이렇게 하면 작고 데몬과 유사한 서비스를 통해 로드 밸런싱 기능이 포드/노드에 기본적으로 내장됩니다. 고도로 발전된 수준은 아니지만(네트워크 로드 밸런싱 기능을 간신히 넘어서는 정도입니다), 애초에 설계된 목적은 충실히 수행합니다. 이러한 서비스는 이른바 플러그형으로 구성할 수 있으며, 실제로도 그렇게 사용되고 있어 더 고급 기능과 (바라건대) 알고리즘을 제공하는 다른 프로젝트(오픈 소스 및 벤더 제공)를 활용할 수 있습니다.

하지만 이러한 부하 분산 기능만으로는 우리가 궁극적으로 원하는(그리고 프로덕션 환경에서 반드시 필요한) 확장성과 고가용성을 확보할 수 없습니다. 또한 HTTP(L7) 수준의 지능적인 처리가 필요한 API 라우팅도 지원하지 못합니다. 마이크로서비스를 기반으로 하고 API 파사드를 전면에 둔 최신 애플리케이션을 효율적으로 확장하려면 이러한 기능이 필요합니다. 보다 강력한 솔루션이 필요합니다.

바로 이 지점에서 인그레스 컨트롤러가 등장합니다. 인그레스 컨트롤러는 URI와 HTTP 헤더를 기반으로 인그레스 트래픽을 분석하고 전달하여 애플리케이션 계층의 라우팅과 확장성을 지원하는 ‘로드 밸런서’입니다.

결국 이를 만들고 (이후 사용하게 된) 개발자들은 인그레스 컨트롤러를 통해, 네트워크 운영(netops) 분야에서 트래픽 관리, 애플리케이션 전송 또는 콘텐츠 스위칭/라우팅이라고 부르는 기능을 사실상 재현한 셈입니다. 네트워크 운영 분야에서는 지난 수년간 다양한 용어를 사용해 왔으며, 개발(운영), 즉 dev(ops) 분야도 마찬가지입니다. 앱 라우팅과 페이지 라우팅 역시 개발자들이 L7 라우팅을 설명할 때 사용해 온 용어입니다. 이 개념 자체는 어느 쪽에도 낯설지 않습니다. 다만 용어, 즉 각 분야에서 통용되는 표현이 낯설 뿐입니다.

An 인그레스 컨트롤러는 컨테이너 클러스터 내의 적절한 (가상) 서비스로 요청을 라우팅하는 역할을 합니다. 해당 서비스는 또 다른 부하 분산 프록시일 수도 있고, 컨테이너 시스템에 특화된 구성 요소일 수도 있습니다. 어느 경우든 인그레스 컨트롤러의 역할은 HTTP 요청의 HTTP 헤더에 포함된 계층 7(HTTP) 값을 기준으로 트래픽을 라우팅하는 것입니다. 일반적으로 이 값은 URI이지만, 호스트 이름이나 다른 사용자 지정 값(예: 버전 번호 또는 API 키)일 수도 있습니다.

Once the 인그레스 컨트롤러가 헤더에서 값을 추출하면 리소스 파일에 정의된 정책을 사용하여 요청을 어떻게 분산할지 결정합니다. 요청을 균등하게 분산하거나, 서비스의 한 버전에 75%를 보내고 다른 버전에 25%를 보낼 수도 있습니다. 이처럼 상당히 유연하게 처리할 수 있습니다. 또한 인그레스 컨트롤러는 모니터링(상태 및 정상 작동 여부)도 담당하므로, 요청이 ‘작동하지 않는’ 서비스로 전달되지 않도록 각별히 주의해야 합니다.

네트워크 운영 담당자라면 익숙하게 들리시나요? 그럴 만도 합니다. 이는 기본적으로 BIG-IP 같은 스마트한(L7 지원) 프록시가 수행하는 기능이기 때문입니다.

이제 둘의 공통점을 알았으니, 몇 가지 차이점도 있다는 점을 말씀드리겠습니다. 특히 인그레스 컨트롤러는 선언적 방식으로 구성됩니다. 즉, 컨트롤러 외부의 리소스 파일에 있는 설명에 따라 구성이 결정됩니다. 이는 인그레스 트래픽을 제어하고 전달하는 기존의 스마트 프록시와는 다릅니다. 기존 스마트 프록시는 환경에 대한 권위 있는 정보 소스입니다. 하지만 인그레스 컨트롤러는 그렇지 않습니다. 대신 구현의 유연성을 제공하는 일종의 ‘추상화 계층’ 역할을 하는 외부 파일에서 해당 정보를 찾습니다. 따라서 인그레스 컨트롤러(또는 보완 구성 요소)는 이 파일을 읽고 해석하여 설명에 맞는 구성을 생성해야 합니다. 또한 구성을 최신 상태로 유지해야 합니다. 컨테이너화된 환경의 인그레스 제어 지점은 시스템 내부보다 변동성이 낮지만, 여전히 변경되므로 지속적으로 모니터링해야 합니다.

결국 인그레스 컨트롤러는 외부에서 들어오는 요청을 컨테이너화된 환경 내부의 적절한 리소스로 전달하는 애플리케이션 계층 라우팅을 담당합니다. 이는 사실상 스마트 로드 밸런서의 정의와 거의 같습니다.

이름은 바뀌었을지 몰라도 기능은 거의 그대로입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물