네트워킹 개요
네트워킹 전문가가 아니어도 Calico Cloud를 바로 사용할 수 있어요. 복잡한 부분은 Calico Cloud가 대신 숨겨 주거든요. 그래도 겉면 아래에서 무슨 일이 벌어지는지 더 깊이 이해하고 싶다면, 이 문서가 네트워킹의 핵심 기본 개념 몇 가지를 짧게 소개해 줘요.
출처: 문서
본문
참고(SECONDARY): 이 가이드는 Calico Cloud에 한정되지 않는 교육용 자료예요.
이 가이드에서 배우게 될 내용이에요:
- 네트워크의 여러 계층을 가리키는 데 쓰이는 용어.
- 네트워크 패킷의 구조.
- MTU가 무엇이고 왜 차이를 만드는지.
- IP 주소 지정, 서브넷, IP 라우팅이 동작하는 방식.
- 오버레이 네트워크가 무엇인지.
- DNS와 NAT가 무엇인지.
네트워크 계층
네트워크를 통해 데이터를 주고받는 과정은 보통 7개 계층으로 나눠 설명해요(OSI 모델이라고 부르는 구분이에요). 각 계층은 보통 L1부터 L7까지로 줄여서 표기해요. 데이터는 애플리케이션에서 보내지거나 받아질 때 이 계층들을 차례로 통과한다고 생각하면 좋아요. 각 계층은 네트워크로 데이터를 주고받는 데 필요한 처리 가운데 자기 몫을 담당해요.
현대의 엔터프라이즈 네트워크나 퍼블릭 클라우드 네트워크에서는 계층이 보통 이렇게 대응돼요:
- L5-7: 대부분의 애플리케이션 개발자가 익숙한 프로토콜들. 예를 들면 HTTP, FTP, SSH, SSL, DNS가 있어요.
- L4: 출발지·목적지 포트를 포함하는 TCP 또는 UDP.
- L3: IP 패킷과 IP 라우팅.
- L2: 이더넷 패킷과 이더넷 스위칭.
네트워크 패킷의 구조
네트워크로 데이터를 보낼 때는 네트워크 스택의 각 계층이 자기 헤더를 추가해요. 이 헤더에는 패킷이 네트워크를 지나가는 동안 해당 계층이 패킷을 처리하는 데 필요한 제어 정보·메타데이터가 담기고, 그 결과물이 스택의 다음 계층으로 넘어가요. 이런 식으로 완성된 패킷에는 스택의 모든 계층이 필요로 하는 제어 정보·메타데이터가 들어 가지만, 어느 계층도 데이터 자체를 이해하거나 인접 네트워크 계층의 제어 정보·메타데이터를 처리할 필요는 없어요.
IP 주소 지정, 서브넷, IP 라우팅
L3 네트워크 계층에서 IP 주소가 등장하고, 보통 여기가 애플리케이션 개발자가 관심 갖는 네트워킹과 네트워크 엔지니어가 관심 갖는 네트워킹의 경계선이에요. 애플리케이션 개발자는 IP 주소를 네트워크 트래픽의 출발지이자 목적지로 보지만, L3 라우팅이나 그보다 낮은 스택 영역을 이해할 필요는 훨씬 적어요. 그쪽은 네트워크 엔지니어의 영역이거든요.
IP 주소에는 두 가지 종류가 있어요: IPv4와 IPv6.
- IPv4 주소는 32비트이며 가장 널리 쓰여요. 보통 0~255 범위의 10진수 4바이트를 점으로 구분해 표기해요. 예를 들면
192.168.27.64죠. IP 주소 중에는 "사설(private)"로 예약된 범위가 여러 개 있는데, 이 주소들은 로컬 사설 네트워크 안에서만 쓸 수 있고 인터넷을 가로질러 라우팅되지 않아요. 덕분에 기업은 이 주소들을 원하는 만큼 자주 재사용할 수 있어요. 반대로 "공용(public)" IP 주소는 인터넷 전체에서 전역적으로 고유해요. 인터넷에 연결되는 네트워크 기기와 네트워크 수가 늘면서 지금은 공용 IPv4 주소가 부족해진 상태예요. - IPv6 주소는 128비트이며 IPv4 주소 공간의 부족을 극복하도록 설계됐어요. 보통 4자리 16진수 8개 그룹으로 표기해요. 예를 들면
1203:8fe0:fe80:b897:8990:8a7c:99bf:323d죠. 128비트 길이 덕분에 IPv6 주소는 부족할 일이 없어요. 하지만 많은 기업이 IPv6 도입을 더디게 진행해 왔기에, 적어도 지금까지는 IPv4가 여전히 많은 엔터프라이즈·데이터 센터 네트워크의 기본값으로 남아 있어요.
IP 주소의 묶음은 보통 CIDR 표기법으로 나타내요. IP 주소 뒤에 /를 붙이고 유효 비트 수를 적는 방식이에요. 예를 들어 192.168.27.0/24는 192.168.27.0부터 192.168.27.255까지 256개 IP 주소의 묶음을 가리켜요.
하나의 L2 네트워크 안에 있는 IP 주소 묶음을 서브넷이라고 불러요. 서브넷 안에서는 L2 헤더(과 푸터)만으로도 어떤 기기 쌍 사이든 패킷을 단 한 번의 네트워크 홉으로 주고받을 수 있어요.
패킷을 하나의 서브넷 너머로 보내려면 L3 라우팅이 필요해요. 각 L3 네트워크 기기(라우터)는 L3 라우팅 규칙에 따라 패킷을 보낼 경로를 결정하는 역할을 맡아요. 라우터 역할을 하는 각 네트워크 기기는 특정 CIDR로 향하는 패킷을 어디로 보낼지 정해 주는 라우트(route)를 가지고 있어요. 예를 들어 Linux 시스템에서 10.48.0.128/26 via 10.0.0.12 dev eth0라는 라우트는 목적지 IP가 10.48.0.128/26 안에 든 패킷을 eth0 인터페이스로 내보며 다음 홉 10.0.0.12로 라우팅해야 한다는 뜻이에요.
라우트는 관리자가 정적으로 설정할 수도 있고, 라우팅 프로토콜을 써서 동적으로 프로그래밍할 수도 있어요. 라우팅 프로토콜을 쓸 때는 각 네트워크 기기가 어떤 기기들과 라우트를 주고받아야 하는지 설정해 둬야 하는 게 보통이에요. 그러면 라우팅 프로토콜이 기기가 추가·제거되거나 네트워크 링크가 들어오고 나갈 때 네트워크 전체에 맞는 라우트를 알아서 프로그래밍해 줘요.
대형 엔터프라이즈와 데이터 센터 네트워크에서 흔히 쓰는 라우팅 프로토콜 하나가 BGP예요. BGP는 인터넷을 떠받치는 주요 프로토콜 중 하나라 믿을 수 없을 만큼 잘 확장되고, 현대 라우터 대부분이 널리 지원해요.
오버레이 네트워크
오버레이 네트워크는 밑에 깔린 네트워크(언더레이, underlay라고 불러요)가 오버레이에 연결된 기기들을 전혀 모르는 상태에서도, 기기들이 그 위에서 서로 통신하게 해 줘요. 오버레이 네트워크에 연결된 기기들 입장에서는 그냥 평범한 네트워크처럼 보여요. 이걸 실현하기 위해 서로 다른 프로토콜을 쓰는 오버레이 네트워크가 여러 종류 있지만, 대체로 공통점이 하나 있어요. 바로 패킷(내부 패킷, inner packet이라고 불러요)을 바깥쪽 네트워크 패킷 안에 캡슐화한다는 점이에요. 이렇게 하면 언더레이는 내부 패킷을 처리하는 방법을 몰라도 바깥 패킷만 보면 되니까요.
오버레이가 패킷을 어디로 보낼지 아는 방법은 오버레이 종류와 그것들이 쓰는 프로토콜에 따라 달라져요. 패킷을 감싸는 방식도 오버레이 종류마다 달라요. 예컨대 VXLAN의 경우 내부 패킷을 감싸서 외부 패킷 안에 UDP로 실어 보내요.
오버레이 네트워크는 밑에 깔린 네트워크 인프라에 대한 의존성이 최소라는 장점이 있지만, 단점도 있어요:
- 오버레이가 아닌 네트워킹에 비해 성능에 작은 영향을 줘요. 네트워크 집약적인 워크로드를 돌린다면 피하고 싶을 수도 있어요.
- 오버레이 위의 워크로드는 나머지 네트워크에서 직접 접근하기 어려워요. 그래서 오버레이로 들어오거나 나가는 모든 트래픽에 대해 NAT 게이트웨이나 로드 밸런서가 오버레이와 언더레이 네트워크 사이를 연결해 줘야 해요.
Calico Cloud의 네트워킹 옵션은 매우 유연해서, 오버레이 네트워크와 오버레이가 아닌 네트워크 중 무엇을 Calico Cloud가 제공하게 할지 직접 고를 수 있어요.
DNS
네트워크를 가로지르는 패킷 흐름은 IP 주소로 결정되지만, 사용자와 애플리케이션은 보통 잘 알려진 이름을 쓰고 싶어 해요. 밑에 깔린 IP 주소가 바뀌어도 시간이 지나도 일관되게 유지되는 이름 말이에요. 예를 들어 google.com을 216.58.210.46에 대응시키는 거죠. 이름을 IP 주소로 바꾸는 이 번역 작업은 DNS가 처리해요. DNS는 지금까지 설명한 기본 네트워킹 위에서 동작해요. 네트워크에 연결된 각 기기는 보통 하나 이상의 DNS 서버 IP 주소로 설정되어 있어요. 애플리케이션이 도메인 이름으로 연결하려 하면 DNS 메시지가 DNS 서버로 보내지고, DNS 서버는 그 도메인 이름이 어떤 IP 주소(들)에 대응되는지 알려 줘요. 그러면 애플리케이션은 선택한 IP 주소로 연결을 시작해요.
NAT
NAT(Network Address Translation, 네트워크 주소 변환)는 패킷이 NAT를 수행하는 기기를 통과할 때 패킷 안의 IP 주소를 다른 IP 주소로 매핑하는 과정이에요. 사용 사례에 따라 출발지 IP 주소에 적용할 수도, 목적지 IP 주소에 적용할 수도, 아니면 둘 다에 적용할 수도 있어요.
NAT의 대표적인 사용 사례 하나는 사설 IP 주소를 가진 기기가 인터넷을 가로질러 공용 IP 주소를 가진 기기와 통신하게 해 주는 거예요. 예를 들어 사설 IP 주소를 가진 기기가 공용 IP 주소로 연결을 시도하면, 사설 네트워크 경계의 라우터가 보통 SNAT(Source Network Address Translation)를 써서 패킷의 사설 출발지 IP 주소를 라우터 자신의 공용 IP 주소로 매핑한 뒤 인터넷으로 전달해요. 그러고 나서 라우터는 반대 방향으로 들어오는 응답 패킷을 원래 사설 IP 주소로 되돌려 매핑해요. 그 결과 패킷이 양방향으로 끝까지(end-to-end) 흐르는데도 출발지와 목적지 어느 쪽도 매핑이 일어나고 있다는 걸 알아차리지 못해요. 같은 기법이 오버레이 네트워크에 연결된 기기가 오버레이 밖의 기기와 통신할 때도 흔히 쓰여요.
NAT의 또 다른 흔한 사용 사례는 로드 밸런싱이에요. 이 경우 로드 밸런서가 DNAT(Destination Network Address Translation)를 수행해 들어오는 연결의 목적지 IP 주소를, 자신이 로드 밸런싱할 대상으로 고른 기기의 IP 주소로 바꿔요. 그러고 나서 로드 밸런서는 응답 패킷에 이 NAT를 되돌려 적용해서 출발지·목적지 기기 어느 쪽도 매핑이 일어났다는 걸 모르게 만들어요.
MTU
네트워크 링크의 최대 전송 단위(MTU)는 그 네트워크 링크를 가로질러 보낼 수 있는 패킷의 최대 크기예요. 네트워크의 모든 링크를 같은 MTU로 설정하는 게 흔한데, 이는 패킷이 네트워크를 통과하는 동안 단편화(fragmentation)될 일을 줄여 주기 때문이에요. 단편화는 네트워크 성능을 눈에 띄게 떨어뜨릴 수 있어요. 게다가 TCP는 경로 MTU를 알아내려고 시도하고, 네트워크 경로에 있는 링크 중 가장 작은 MTU를 기준으로 경로별 패킷 크기를 조정해요. 애플리케이션이 한 패킷에 담길 수 있는 양보다 많은 데이터를 보내려 하면, TCP는 MTU를 넘지 않도록 데이터를 여러 TCP 세그먼트로 잘게 나눠요.
대부분의 네트워크는 MTU가 1,500바이트인 링크를 쓰지만, 9,000바이트 MTU를 지원하는 네트워크도 있어요. Linux 시스템에서는 MTU를 크게 잡으면 대량의 데이터를 보낼 때 Linux 네트워킹 스택이 처리하는 패킷 수가 줄어 CPU 사용량이 낮아질 수 있어요. 사용 중인 네트워크 인터페이스 하드웨어에 따라 이 오버헤드 일부를 네트워크 인터페이스 하드웨어가 대신 떠안는 오프로드가 이뤄질 수도 있어서, 작은 MTU와 큰 MTU의 영향은 기기마다 달라져요.
더 알아보기 (Learn more)
이 문서의 개념은 Calico Cloud의 네트워킹 옵션을 고를 때 바로 쓰이는 배경 지식이에요. 오버레이와 라우팅 개념을 익혀 두면 나중에 IP 풀 캡슐화 모드나 BGP 피어링 설정 문서를 훨씬 쉽게 읽을 수 있어요.