ingress 와 egress: 터널 설정과 청구서에서 만난 두 방향

하루에 두 번 이 단어들을 만났습니다. 오전에는 터널 설정 화면에서 ingress 를 봤고, 오후에는 데이터베이스 청구 항목에서 egress 를 봤습니다. 몇 년째 둘 다 쓰고 있었는데, 그날에서야 같은 축의 양쪽이라는 게 눈에 들어왔습니다.

방향은 경계가 정합니다

라틴어에서 온 말입니다. in-gress 는 들어가는 것, e-gress 는 나가는 것입니다. 어렵지 않습니다.

문제는 무엇의 안팎이냐입니다. 여기가 매번 헷갈리는 지점이고, 사실 헷갈릴 만합니다. 같은 패킷 하나가 보는 쪽에 따라 둘 다이기 때문입니다.

데이터베이스가 조회 결과를 앱에 돌려준다고 해봅시다.

데이터베이스 입장   나갔다  → egress
앱 입장            들어왔다 → ingress

같은 바이트인데 이름이 둘입니다. 그래서 누가 "egress 가 많이 나온다"고 하면 "무엇의 밖으로?" 를 먼저 물어야 합니다. 그걸 안 정하고 대화하면 서로 다른 걸 말하게 됩니다.

터널 설정의 ingress: 무엇을 들여보낼지의 목록

터널을 쓰면 설정에 ingress 라는 항목이 있습니다. 형태는 대개 이렇습니다.

ingress:
  - hostname: a.example.com
    service: http://내부주소:포트
  - hostname: b.example.com
    service: http://다른내부주소:포트
  - service: http_status:404

바깥에서 들어오는 요청을 안쪽 어디로 보낼지의 표입니다. 호스트명으로 갈라서 내부 서비스에 꽂아 줍니다. 마지막 줄이 어디에도 안 맞는 요청을 404 로 떨구는 기본값입니다.

쿠버네티스의 Ingress 오브젝트도 이름이 같은 이유가 여기 있습니다. 하는 일이 같습니다. 클러스터 밖에서 들어오는 트래픽을 안쪽 서비스로 라우팅하는 규칙입니다. 도구는 달라도 개념은 하나입니다.

여기서 ingress 는 비용이 아니라 규칙입니다. 라우팅 테이블에 가깝습니다.

청구서의 egress: 나가는 데만 돈을 받습니다

반대편은 성격이 완전히 다릅니다. 클라우드 요금에서 egress 는 돈입니다.

거의 모든 사업자가 같은 구조를 씁니다.

들어오는 데이터(ingress)   무료
나가는 데이터(egress)      GB당 과금

처음 봤을 때는 좀 이상했습니다. 왜 한쪽만 받을까요. 회선은 양방향인데 말이죠.

몇 가지 이유가 있는 것 같습니다. 상위 통신망과의 정산 구조가 실제로 나가는 쪽에 치우쳐 있기도 하고, 데이터를 들여올 때 공짜여야 사람들이 옮겨 오기 때문이기도 합니다. 그리고 일단 들어온 데이터는 나갈 때 돈이 드니 잘 안 나갑니다. 의도했든 아니든 결과적으로는 그렇게 작동합니다.

실무에서 중요한 건 여기입니다. 쿼리 하나를 잘못 짜면 그게 곧 요금이 됩니다.

오늘 실제로 겪은 egress

블로그 목록 쿼리가 요약과 읽는 시간만 쓰면서 발행 글 전체 본문을 통째로 받아 오고 있었습니다. 받아서 두 값을 계산하고 본문은 버렸습니다.

SELECT id, title, content, ...   -- content 를 받아서 버림

목록 화면에서는 본문이 필요 없는데도 매번 실어 날랐습니다. 캐시가 만료될 때마다 이 조회가 돌았고, 크롤러와 피드 구독기가 꾸준히 두드리니 하루 수백 번 반복됐습니다. 무료 한도를 두 배 넘게 넘겼습니다.

고친 건 한 줄입니다.

SELECT id, title, LEFT(content, 600) AS excerpt, length(content), ...

요약에 필요한 앞부분과 글자수만 받습니다. 발행 글 전수로 재보니 400자 지점에서 요약이 100% 일치해서 여유를 두고 600자로 잡았습니다. 본문 전송량이 6.7배 줄었습니다.

egress 는 대역폭 이야기처럼 들리지만 실제로는 SELECT 목록 이야기였습니다. 인프라를 옮기거나 플랜을 올려서 풀 문제가 아니었습니다. 처음에는 저도 DB 를 옮길 생각부터 했습니다.

그리고 ingress 를 egress 로 얻었습니다

같은 날 터널을 하나 세웠는데, 그 구조가 이 두 단어의 관계를 잘 보여줍니다.

바깥에서 안쪽 서비스로 들어오게 하려면 보통 방화벽에 구멍을 냅니다. 포트를 열고, 고정 주소를 확보하고, 그 구멍을 계속 지켜야 합니다. 명시적인 ingress 입니다.

터널은 방향을 뒤집습니다.

안쪽 서버가 바깥 대문 서버로 먼저 나갑니다   (egress)
그 연결을 끊지 않고 유지합니다
바깥에서 온 요청이 그 통로를 거꾸로 타고 들어옵니다   (결과적으로 ingress)

나가는 연결 하나로 들어오는 길을 만든 겁니다. 방화벽에는 아무 구멍도 안 냈습니다. 나가는 연결은 원래 허용돼 있으니까요. 고정 주소도 필요 없습니다. 안쪽에서 먼저 나갔으니 상대는 답만 하면 됩니다.

같은 원리를 쓰는 것들이 생각보다 많습니다. 상용 터널 제품, 사무실 장비의 원격 관리, CI 러너가 중앙 서버에 붙는 방식이 전부 이 모양입니다. 나가는 연결을 유지해서 들어오는 길을 대신합니다.

그래서 정리하면

	ingress	egress
뜻	들어옴	나감
네트워크 설정에서	라우팅 규칙	나가는 트래픽 정책
클라우드 요금에서	대개 무료	과금 대상
볼 때 물어야 할 것	무엇의 안으로?	무엇의 밖으로?

두 단어가 어려운 게 아니라 경계를 안 정하고 쓰는 게 어려운 것이었습니다. 터널 설정의 ingress 는 사설망이 경계이고, 청구서의 egress 는 사업자의 데이터센터가 경계입니다. 경계를 먼저 말하면 헷갈릴 일이 없습니다.

그리고 실무에서는 이 한 줄이 제일 쓸모 있었습니다. egress 가 문제일 때, 회선이 아니라 무엇을 실어 보내고 있는지를 먼저 보는 것. 저는 반대로 갔다가 돌아왔습니다.