• 소규모 코드 수정(단 하나의 if 문 추가)으로 시스템 안정성에 큰 기여를 한 PR 사례 소개
  • "bpf:nat: Restore ORG NAT entry if it's not found" PR의 영향력과 중요성

NAT(Network Address Translation)의 기본 원리

  • NAT는 여러 기기가 하나의 공용 IP를 공유할 수 있게 하는 기술
  • 내부 장치(Private IP:Port)와 외부 인터넷 간 통신을 가능하게 함
  • NAT 테이블은 원본 주소와 변환된 주소 간의 매핑 정보를 저장
  • 과정:
    1. 내부 기기가 외부 서버에 연결 시도
    2. NAT 장치가 원본 IP/포트를 공용 IP/포트로 변환(SNAT)
    3. 외부 서버의 응답을 다시 내부 기기로 변환(DNAT)

Kubernetes에서의 NAT 활용

  • Kubernetes에서 NAT가 중요하게 사용되는 두 가지 주요 사례:
    1. Pod에서 클러스터 외부로의 통신: Pod의 내부 IP를 노드의, 공용 IP로 변환
    2. NodePort를 통한 외부에서 Pod로의 통신: 외부 요청을 특정 Pod로 라우팅

Cilium의 NAT 구현 방식

  • 일반적으로 Linux에서는 conntrack과 iptables로 NAT 처리
  • Cilium은 eBPF 기술을 사용하여 전통적인 Linux 네트워크 스택을 우회
  • Cilium은 LRU 해시맵(BPF_MAP_TYPE_LRU_HASH)을 사용하여 NAT 테이블 직접 관리

문제 발생 원인

  • Lookup 문제: 양방향(나가는/들어오는) 패킷 처리를 위해 동일 데이터를 두 번 저장(RevSNAT)
  • LRU의 한계: 제한된 자원으로 인해 사용 빈도가 낮은 항목이 제거됨
  • **연결 손실 # Cilium의 작은 코드 수정으로 큰 네트워크 안정성 향상을 이룬 사례

소개: 작은 코드 변경의 큰 영향력

  • 단 하나의 if 문 블록 추가만으로 시스템 안정성에 엄청난 기여를 한 사례
  • 해당 PR: "bpf:nat: Restore ORG NAT entry if it's not found"
  • 네트워크 분야 비전문가도 이해할 수 있도록 설명

NAT(Network Address Translation)의 기본 원리

  • NAT는 여러 기기가 하나의 공용 IP를 공유할 수 있게 하는 기술
  • 내부 Private IP:Port 조합을 외부 Public IP:Port로 매핑하는 방식으로 작동
  • 작동 과정:
    • 내부 기기가 외부 서버에 접속 시도
    • NAT 장치가 내부 통신을 외부 통신으로 변환(SNAT)
    • 응답이 돌아오면 다시 원래 내부 통신으로 변환(DNAT)
    • 변환 정보는 NAT 테이블에 기록

쿠버네티스에서의 NAT 활용

  • 쿠버네티스는 복잡한 네트워크 구조를 가지며 다양한 곳에서 NAT 활용
  • 주요 NAT 활용 사례:
    1. Pod에서 클러스터 외부로의 통신: Pod의 사설 IP를 노드의 공용 IP로 변환(SNAT)
    2. NodePort를 통한 외부에서 Pod로의 통신: 외부 트래픽을 적절한 Pod로 전달하기 위해 DNAT와 SNAT 동시 수행

Cilium의 특별한 접근 방식

  • 일반적인 Linux 시스템에서는 conntrack 서브시스템과 iptables로 NAT 관리
  • Cilium은 eBPF 기술을 사용하여 전통적인 Linux 네트워크 스택을 우회
  • SNAT 처리를 위해 LRU 해시 맵(BPF_MAP_TYPE_LRU_HASH) 형태로 직접 SNAT 테이블 관리

문제의 원인과 증상

  • 조회(Lookup) 문제:

    • NAT 처리 검증을 위해 해시 테이블 조회 필요
    • 빠른 조회를 위해 동일 데이터를 src와 dst 값을 뒤집어 RevSNAT로 테이블에 두 번 삽입
  • LRU(Least Recently Used) 문제:

    • 리소스 제한으로 데이터가 LRU 로직에 의해 제거될 수 있음
  • 결합된 문제점:

    • 하나의 TCP 연결에 대해 동일한 데이터가 두 번 기록됨
    • 두 데이터 중 하나라도 LRU에 의해 제거되면 전체 연결이 끊어질 수 있음

단순하지만 효과적인 해결책

  • 핵심 아이디어: 한쪽 방향의 패킷이 관찰되면 반대 방향의 항목도 함께 업데이트
  • 이 간단한 접근 방식으로:
    • 양방향 항목이 모두 업데이트되어 LRU 제거 우선순위에서 멀어짐
    • 한쪽 항목만 삭제되어 전체 통신이 끊어지는 시나리오 발생 가능성 감소
    • 벤치마크 테스트에서 네트워크 안정성 크게 향상

결론 및 교훈

  • 복잡한 시스템 내에서도 단순한 아이디어가 큰 변화를 가져올 수 있음을 보여주는 사례
  • 기본적인 CS 지식(NAT 작동 방식)을 바탕으로 문제 해결
  • 문제 회피를 위한 다른 방법: NAT 테이블 크기 증가
  • 객관적인 증거 데이터로 문제를 철저히 분석하고 기여한 개발자의 열정에 경의

기술적 접근의 가치

  • 문제의 근본 원인을 이해하고 해결하는 방식의 중요성
  • 간단한 코드 수정으로 시스템 전체의 안정성을 크게 개선할 수 있다는 교훈
  • 복잡한 시스템에서도 기본 원리를 이해하는 것의 중요성

멋진 경험 소개해주셔서 감사합니다!