개요
안녕하세요
저는 최근에 쿠버네티스의 중요성을 깨닫고 관련 이론들을 하나씩 공부하고 있는데요!
가장 먼저 마주치게 된 의문점이 하나 있었습니다.
인그레스(Ingress)와 서비스(Service) 모두 외부에서 특정 팟(Pod)으로 접근할 수 있도록 하는 공통점이 있습니다.
그러면 언제는 인그레스를 생성하여 배포하고, 또 언제는 서비스를 사용해야 하는가? 두 컴포넌트의 차이점은 무엇일까?
처음 공부하는 입장에서, 두 컴포넌트가 굉장히 혼란스럽더라구요
그래서 이번 시간에 통해 두 컴포넌트의 관계를 살펴보고, 어떤 상황에서 적절하게 컴포넌트를 사용할 수 있을 지 고민해봅시다!
인그레스와 서비스
인그레스 또는 서비스 둘 중 어느 하나를 이용하더라도, 팟이 속한 클러스터 외부에서 내부로 접근이 가능합니다.
(물론, 서비스의 타입이 ClusterIP인 경우는 클러스터 내부에서만 통신이 가능합니다.)
그렇다면, 인그레스와 서비스의 가장 큰 차이점은 무엇일까요?
바로, 로드 밸런싱 대상입니다!
인그레스는 L7 로드 밸런서를 통해, 클러스터 외부에서 들어온 트래픽을 적절한 서비스에 전송하는 역할을 수행합니다.
한편, 서비스는 L4 로드 밸런서를 통해, 서비스에 들어온 트래픽을 여러 개의 팟 중 적합한 곳으로 전송하는 역할을 수행합니다. (물론, 서비스에 포함된 팟의 갯수가 한 개일 수도 있습니다.)
결과적으로, 인그레스는 서비스 대비 상위 계층에 속한다고 볼 수 있어요.
아래의 그림을 보면, 이해가 더 쉬울 것 같습니다
따라서, 인그레스는 서비스 컴포넌트 대비 다음과 같은 추가 기능을 제공합니다.
•
클러스터 외부에서 들어온 트래픽에 따라 여러 서비스로 로드 밸런싱이 가능
•
HTTP(S) 프로토콜 사용을 위한 SSL 인증서 로직 처리
•
URL을 통해, 클러스터 내부의 컴포넌트(서비스, 팟 등)에 접근이 가능
여기서, L4 로드 밸런서와 L7 로드 밸런서에 대하여 조금만 더 살펴보도록 하죠!
L4 로드 밸런서와 L7 로드 밸런서
인그레스는 L7 로드 밸런서, 서비스는 L4 로드 밸런서를 사용한다고 하였습니다.
두 로드 밸런서의 특징을 살펴보고, 사용 가능한 적절한 상황에 대해 생각해보도록 합시다.
L4 로드 밸런서
L4 로드 밸런서는 OSI(Open Systems Interconnection) 7계층 중 네 번째 계층인 전송 계층(Transport Layer)에서 동작하는 로드 밸런서입니다.
해당 로드 밸런서는 클라이언트의 IP 주소와 포트, 그리고 서버의 IP 주소와 포트 정보를 바탕으로 로드 밸런싱을 수행하게 됩니다.
전송 계층에서는 IP 패킷(IP Packet)에 TCP 연결을 위한 포트 정보를 담은 세그먼트(Segment) 단위로 트래픽을 처리합니다. (UDP 프로토콜도 있지만, 본 포스팅에서는 TCP를 예시로 들었습니다)
따라서, 애플리케이션 계층에 비하여 빠른 응답 속도를 제공합니다.
하지만, 애플리케이션 계층에서 제공하는 여러 기능(L7 로드 밸런서 파트에 몇 가지 예시가 있습니다)을 사용할 수 없다는 것이 단점입니다.
L7 로드 밸런서
L7 로드 밸런서는 OSI 7계층 중 최상위 계층인 애플리케이션 계층(Application Layer)에서 동작하는 로드 밸런서입니다.
클라이언트와 가장 가까운 곳에 위치한 계층인 만큼, L4 로드 밸런서에 비하여 다양한 정보를 처리할 수 있습니다. 이에 따라, L4 로드 밸런서에서 제공할 수 없는 여러 기능들을 포함하고 있습니다.
•
HTTP(S) 프로토콜, 웹 애플리케이션 방화벽 등 외부 트래픽에 대한 여러 보안 기능을 제공
•
클라이언트 애플리케이션에서 발생한 트래픽을 분석 → 비정상적 혹은 악의적인 트래픽으로 판단될 경우, 해당 트래픽을 차단할 수 있음
•
쿠키, 세션 등의 정보를 기반으로 클라이언트가 이전에 연결했었던 서버로 지속적인 연결이 가능
하지만, 애플리케이션 데이터를 추가로 사용하는 만큼 L4 로드 밸런서에 비해 처리 속도가 느리다는 단점이 있습니다.
사용처
그렇다면, L4 & L7 로드 밸런서를 각각 언제 사용하는 것이 효율적일까요?
L4 로드 밸런서의 경우, 상대적으로 트래픽 처리 속도가 빠르다는 장점이 있습니다. 따라서, 실시간 트래픽 처리가 중요하게 요구되는 온라인 게임, 스트리밍 서비스 등에 사용하면 바람직하겠지요
MLops 관점에서 또 다른 상황을 생각해봅시다.
여러분이 멋지게 개발한 머신러닝 모델을 클라이언트가 웹 상에서 사용할 수 있게 배포를 한다고 가정해볼게요.
웹을 담당하는 서버가 FastAPI로 구현되었다고 하면, 모델 추론 코드는 FastAPI 엔드포인트에 존재할 것입니다.
더불어, 클린 코드를 위해 단일 책임 원칙을 적용한다면, 웹 서버에서 직접 모델 추론을 수행하지는 않을 것입니다.
대신, FastAPI 엔드포인트에서는 추론 서버로 모델 추론에 대한 request만 수행하겠지요
또한 Request 과정에서, URL 대신 IP 주소를 통해 추론 서버와 연결해도 충분할 것입니다. 클라이언트가 직접 모델 추론을 수행하는 것은 아니니까요!
결과적으로, 해당 상황에서는 모델 추론 코드를 Service 레벨로 배포해도 충분할 것 같습니다 :)
반면, 웹 서버는 클라이언트와 직접적으로 상호작용이 이루어지는 공간입니다!
따라서, 웹 서버(또는 웹 서비스)에서 제공하는 서비스를 사용할 수 있는 권한을 클라이언트가 가지고 있는 지 확인할 수도 있습니다.
권한이 있는 사용자만 모델 추론의 결과 값을 받고, 이를 사용할 수 있도록 말이죠!
이러한 경우에는, 웹 서버를 인그레스 레벨로 배포하는 것이 바람직하다고 볼 수 있을 것 같아요
정리
이번 시간에는 개인적으로 매우 헷갈렸던 인그레스와 서비스에 대한 차이점을 알아보는 시간을 가졌어요.
네트워크 지식이 탄탄할수록 쿠버네티스 개념을 받아들이는 것이 쉽다는 것을 깨닫게 되었습니다. 공부할 분야가 정말 많지만, 네트워크를 소홀하게 생각하면 안될 것 같습니다!
다음에도 쿠버네티스와 관련하여 좋은 주제로 찾아오겠습니다!!
설명드린 내용 중 잘못된 것이 있거나, 피드백이 있는 경우 주저 말고 알려주세요
그럼 안녕히 가세요
Reference