백엔드 엔지니어를 위한 네트워킹

백엔드 시스템은 요청을 받고, 로직을 실행한 뒤, 응답을 반환하도록 설계됩니다. 실제로는 이러한 요청이 보통 백엔드가 실행 중인 같은 컴퓨터가 아니라 다른 머신에서 발생합니다.

사용자가 웹 또는 모바일 애플리케이션과 상호작용할 때, 사용자의 기기는 인터넷을 통해 원격 서버로 요청을 보냅니다. 그 요청은 백엔드 애플리케이션에 도달하기 전에 여러 네트워킹 구성 요소를 거칩니다.

백엔드 시스템은 내부적으로도 통신합니다. 한 서비스가 다른 서비스를 호출하거나, 데이터베이스 서버를 조회하거나, 외부 API로 요청을 보낼 수 있습니다. 이러한 상호작용은 모두 네트워크를 통해 발생합니다.

이 때문에 많은 시스템 문제는 애플리케이션 코드보다 네트워크 동작에서 비롯됩니다. 느린 API 호출은 네트워크 지연 때문에 발생할 수 있고, 연결이 끊기면 요청이 중단될 수 있으며, 응답이 제때 도착하지 않으면 재시도가 발생하는 경우가 많습니다.

머신이 네트워크를 통해 어떻게 통신하는지 이해하면 엔지니어가 분산 시스템에서 시스템 성능, 신뢰성, 그리고 장애 시나리오를 더 잘 추론할 수 있습니다.

클라이언트 애플리케이션이 백엔드 시스템으로 요청을 보내면, 백엔드 코드가 실행되기 전에 여러 네트워킹 단계가 먼저 발생합니다.

이 과정은 일반적으로 api.example.com과 같은 도메인 이름에서 시작됩니다. 컴퓨터는 도메인 이름만으로 직접 통신할 수 없기 때문에, 클라이언트는 먼저 DNS 조회를 수행해 대상 서버의 IP 주소를 확인합니다.

IP 주소를 알게 되면, 클라이언트는 해당 머신과 TCP 연결을 설정합니다. 이 연결은 클라이언트와 서버 사이에서 데이터를 전송하기 위한 신뢰할 수 있는 채널을 만듭니다.

연결이 설정된 후, 클라이언트는 HTTP 요청을 보냅니다. 이 요청에는 메서드, 헤더, 그리고 백엔드 시스템에 필요한 데이터가 포함됩니다.

현대적인 아키텍처에서는 요청이 애플리케이션 서버에 도달하기 전에 로드 밸런서를 거치는 경우가 많습니다. 로드 밸런서는 어떤 백엔드 머신이 요청을 처리할지 결정하며, 여러 서버에 트래픽을 분산하는 데 도움을 줍니다.

마지막으로 요청은 애플리케이션 서버에 도달하고, 여기서 백엔드 애플리케이션이 이를 처리하고 비즈니스 로직을 실행한 뒤, 클라이언트로 돌아가는 응답을 생성합니다.

컴퓨터는 142.250.72.14와 같은 숫자 IP 주소를 사용하여 서로 통신합니다. 하지만 사람은 api.example.com처럼 기억하기 쉬운 도메인 이름을 통해 서비스와 상호작용합니다.

도메인 이름 시스템(DNS)은 이러한 도메인 이름을 해당 IP 주소에 매핑하는 분산 디렉터리처럼 동작합니다. 클라이언트가 도메인 이름을 사용해 서버에 연결하려고 하면, 올바른 IP 주소를 확인하기 위해 DNS 쿼리를 보냅니다.

이 조회 과정에는 여러 DNS 서버가 함께 동작할 수 있습니다. 시스템은 결국 요청된 도메인과 연결된 IP 주소를 반환하여 클라이언트가 요청을 어디로 보내야 하는지 알 수 있게 합니다.

효율성을 높이기 위해 DNS 응답은 운영 체제, 브라우저, 중간 서버에 의해 자주 캐시됩니다. 최근 조회 결과가 이미 캐시에 있으면, 시스템은 새 DNS 쿼리를 수행하는 대신 저장된 IP 주소를 재사용할 수 있습니다.

DNS는 인터넷 인프라의 핵심 구성 요소입니다. DNS가 없다면 사용자와 애플리케이션은 상호작용하는 모든 서비스에 대해 숫자 IP 주소를 기억하고 수동으로 관리해야 합니다.

클라이언트가 서버의 IP 주소를 알게 되더라도, 그 서버에서 어떤 애플리케이션이 요청을 처리해야 하는지는 여전히 알아내야 합니다. 이때 포트가 사용됩니다.

포트는 기계 위의 논리적인 통신 엔드포인트입니다. IP 주소가 호스트 자체를 식별하는 반면, 포트는 들어오는 연결을 기다리는 특정 서비스를 식별합니다.

예를 들어, 웹 서버는 일반적으로 HTTP 트래픽에는 포트 80을, HTTPS 트래픽에는 포트 443을 사용해 수신합니다. 데이터베이스와 다른 서비스들도 잘 알려진 포트를 사용합니다. PostgreSQL은 일반적으로 포트 5432에서 수신하고, Redis는 자주 포트 6379에서 실행됩니다.

포트가 서비스를 분리해 주기 때문에, 하나의 기계에서 여러 애플리케이션을 동시에 실행할 수 있습니다. 백엔드 서버는 HTTP API, 데이터베이스, 캐싱 서비스를 동시에 호스팅할 수 있으며, 각각은 서로 다른 포트에 바인딩됩니다.

IP 주소와 포트 번호를 함께 사용하면 네트워크 엔드포인트가 정의됩니다. 이 엔드포인트는 요청이 어디로 전달되어야 하는지를 고유하게 식별합니다.

전송 제어 프로토콜(Transmission Control Protocol, TCP)은 인터넷에서 사용되는 핵심 통신 프로토콜 중 하나입니다. 두 머신 사이에 신뢰할 수 있는 통신을 제공하도록 설계되었습니다.

어떤 데이터도 전송되기 전에, TCP는 three-way handshake라고 하는 과정을 통해 연결을 설정합니다. 클라이언트는 먼저 서버에 SYN 메시지를 보냅니다. 서버는 요청을 확인하고 준비 상태를 알리기 위해 SYN-ACK로 응답합니다. 그런 다음 클라이언트는 연결을 확인하는 ACK 메시지를 보냅니다. 이 교환이 끝나면 두 머신은 데이터를 보내기 시작할 수 있습니다.

TCP는 데이터를 packets라고 하는 더 작은 단위로 나누어 네트워크를 통해 전송합니다. 네트워크에서는 패킷이 손실되거나 순서가 바뀔 수 있으므로, TCP에는 누락된 데이터를 감지하고 필요하면 패킷을 재전송하는 메커니즘이 포함되어 있습니다.

TCP의 또 다른 중요한 기능은 패킷 순서 보장입니다. 패킷이 전송된 순서와 다르게 도착하더라도, TCP는 애플리케이션에 데이터를 전달하기 전에 이를 올바르게 다시 조립합니다.

이러한 메커니즘 덕분에 TCP는 웹 요청, 데이터베이스 통신, 그리고 대부분의 API 상호작용처럼 정확한 데이터 전송이 필요한 애플리케이션에 신뢰할 수 있습니다.

TCP와 UDP는 머신 간 통신에 사용되는 두 가지 주요 전송 프로토콜이지만, 서로 다른 문제를 해결합니다.

TCP(Transmission Control Protocol)는 신뢰성을 위해 설계되었습니다. 두 머신 사이에 연결을 설정하고, 패킷이 성공적으로 도착하도록 보장하며, 손실된 데이터를 재전송하고, 패킷이 올바른 순서로 전달되도록 보장합니다. 이러한 보장 덕분에 TCP는 정확성이 중요한 애플리케이션에서 사용됩니다.

많은 백엔드 시스템은 TCP에 의존합니다. HTTP 같은 웹 프로토콜은 TCP 위에서 동작하며, 데이터 무결성이 필수적이기 때문에 데이터베이스 연결도 일반적으로 TCP를 사용합니다.

UDP(User Datagram Protocol)는 다른 접근 방식을 취합니다. 연결을 설정하지 않으며, 전달이나 순서를 보장하지도 않습니다. 대신 목적지로 패킷을 가능한 한 빠르게 전송합니다.

UDP는 신뢰성에 대한 오버헤드를 제거하므로 더 빠르고 가볍습니다. 따라서 실시간 비디오 스트리밍, 온라인 게임, 많은 DNS 쿼리처럼 가끔의 패킷 손실이 허용되는 애플리케이션에 적합합니다.

TCP와 UDP의 트레이드오프는 본질적으로 신뢰성과 속도 사이의 선택입니다. 시스템은 애플리케이션의 요구에 가장 잘 맞는 프로토콜을 선택합니다.

HTTP(Hypertext Transfer Protocol)는 대부분의 웹 시스템에서 사용되는 애플리케이션 계층 프로토콜입니다. 클라이언트와 서버가 주고받는 메시지의 구조를 정의합니다.

통신은 요청–응답 모델을 따릅니다. 클라이언트는 무엇을 하고 싶은지 설명하는 HTTP 요청을 보내고, 서버는 그 요청을 처리한 뒤 HTTP 응답을 반환합니다.

요청에는 여러 구성 요소가 포함됩니다. HTTP 메서드는 데이터 조회를 위한 GET이나 새 데이터를 보내기 위한 POST처럼 의도된 작업을 나타냅니다. 요청에는 인증 토큰, 콘텐츠 타입, 캐싱 지시문 같은 메타데이터를 담는 헤더도 포함됩니다.

서버는 요청을 처리한 후 응답을 반환합니다. 응답에는 작업 결과를 나타내는 상태 코드가 포함됩니다. 예를 들어 200 OK는 성공을 의미하고, 404나 500 같은 코드는 오류를 나타냅니다.

HTTP는 브라우저, 모바일 앱, 백엔드 서비스가 인터넷 전반에서 일관되게 통신할 수 있도록 해주는 표준화된 언어를 제공합니다.

지연 시간(latency)은 요청이 클라이언트에서 서버로 이동하고 응답이 다시 돌아오는 데 걸리는 시간을 의미합니다. 분산 시스템에서는 단순한 작업도 이 지연에 기여하는 여러 단계를 포함합니다.

먼저, 요청은 네트워크를 통해 이동해야 합니다. 데이터는 목적지 서버에 도달하기 전에 라우터, 스위치, 때로는 여러 데이터 센터를 거칩니다. 신호가 먼 거리를 전파하는 데 시간이 걸리기 때문에, 지리적 거리만으로도 눈에 띄는 지연이 발생할 수 있습니다.

요청이 서버에 도달하면 백엔드 시스템이 이를 처리해야 합니다. 여기에는 애플리케이션 로직 실행, 검증 수행, 또는 다른 내부 작업 실행이 포함될 수 있습니다.

많은 요청은 데이터베이스, 캐시, 외부 API와 같은 다른 시스템에도 의존합니다. 추가되는 각 의존성은 자체적인 처리 시간과 네트워크 지연을 가져옵니다.

네트워크 혼잡이나 과부하된 서비스와 같은 다른 요인들도 지연 시간을 더 늘릴 수 있습니다. 분산 시스템은 여러 상호 연결된 구성 요소에 의존하므로, 여러 곳에서 발생하는 작은 지연이 누적되어 눈에 띄는 응답 시간이 될 수 있습니다.

네트워크 통신은 본질적으로 신뢰할 수 없습니다. 요청이 지연될 수 있고, 연결이 끊길 수 있으며, 서비스가 응답하지 않을 수도 있습니다. 따라서 백엔드 시스템은 느리거나 실패한 네트워크 호출을 안전하게 처리하도록 설계되어야 합니다.

가장 흔한 보호 방법 중 하나는 타임아웃입니다. 타임아웃은 시스템이 응답을 기다릴 수 있는 최대 시간을 정의합니다. 그 시간 안에 응답이 도착하지 않으면 요청은 중단되고 시스템은 다음 작업으로 넘어갑니다.

재시도도 또 다른 일반적인 전략입니다. 일시적인 네트워크 문제로 요청이 실패하면, 시스템은 짧은 지연 후 요청을 다시 시도할 수 있습니다. 이는 짧은 네트워크 중단과 같은 일시적 실패를 복구하는 데 도움이 됩니다.

하지만 재시도는 신중하게 제어해야 합니다. 많은 서비스가 실패한 요청을 반복해서 재시도하면 하위 시스템에 과부하를 주고, 하나의 느린 서비스가 광범위한 장애를 일으키는 연쇄 실패를 만들 수 있습니다.

이러한 이유로 현대의 백엔드 시스템은 네트워크의 일부가 예측 불가능하게 동작하더라도 신뢰성을 유지할 수 있도록 타임아웃, 재시도, 실패 처리 전략을 신중하게 구성합니다.

애플리케이션이 성장하면 단일 서버가 모든 들어오는 트래픽을 처리하지 못하는 경우가 많습니다. 더 많은 사용자를 지원하고 성능을 유지하기 위해, 시스템은 동일한 기능을 제공하는 여러 백엔드 서버를 실행합니다.

로드 밸런서는 들어오는 요청의 진입점 역할을 합니다. 클라이언트가 개별 서버에 직접 연결하는 대신, 로드 밸런서에 요청을 보냅니다. 그러면 로드 밸런서는 각 요청을 어떤 백엔드 서버가 처리할지 결정합니다.

이 분산 방식은 트래픽을 여러 서버에 나누어, 어떤 한 대의 머신도 과부하되지 않도록 합니다. 라운드 로빈 분산, 최소 연결 라우팅, 지연 시간 기반 라우팅 같은 다양한 알고리즘이 사용될 수 있습니다.

로드 밸런싱은 장애 허용성도 향상시킵니다. 어떤 서버가 사용 불가능해지면, 로드 밸런서는 다른 정상 서버로 트래픽을 라우팅하여 시스템이 계속 동작하도록 할 수 있습니다.

이 접근 방식은 수평 확장을 가능하게 합니다. 수평 확장은 단일 서버를 업그레이드하는 대신 더 많은 머신을 추가하여 시스템 용량을 늘리는 방식입니다. 수평 확장은 크고 안정적인 백엔드 시스템을 구축하기 위한 기본 전략입니다.