EP194: HTTP의 진화
이번 주 시스템 설계 복습:
- HTTP의 진화
- 모든 엔지니어가 알아야 할 시스템 성능 메트릭
- Nginx가 인기 있는 이유
- 모든 엔지니어가 알아야 할 네트워크 디버깅 명령어
- Hub, Switch, Router 설명
HTTP의 진화
Hypertext Transfer Protocol (HTTP)은 단순한 텍스트 전송부터 고성능 실시간 경험까지, 현대 애플리케이션의 요구사항을 충족하기 위해 수년에 걸쳐 발전해왔습니다.
HTTP가 어떻게 발전해왔는지 살펴보겠습니다:
- HTTP/0.9: 단일 GET 요청으로 간단한 HTML 문서를 가져오기 위해 만들어졌습니다.
- HTTP/1.0: 더 풍부한 상호작용을 지원하기 위해 헤더와 상태 코드가 추가되었지만, 모든 요청마다 여전히 새로운 연결이 필요했습니다.
- HTTP/1.1: 지속적 연결(persistent connections)과 더 많은 메서드가 도입되어, 일상적인 웹 브라우징이 더 빠르고 효율적이 되었습니다.
- HTTP/2: 멀티플렉싱(multiplexing)으로 성능 병목 현상을 해결하여, 여러 요청이 하나의 연결을 공유할 수 있게 되었습니다.
- HTTP/3 (QUIC): 지연 시간을 줄이고 신뢰성을 개선하기 위해 QUIC와 함께 UDP로 전환했으며, 특히 모바일과 실시간 앱에 적합합니다.
Over to you: 여러분의 프로젝트에서 이미 HTTP/3를 활용하고 계신가요?
모든 엔지니어가 알아야 할 시스템 성능 메트릭
API가 느립니다. 하지만 정확히 얼마나 느린 걸까요? 숫자가 필요합니다. 실제로 무엇이 문제이고 어디를 수정해야 하는지 알려주는 실제 메트릭 말입니다.
시스템 성능을 분석할 때 모든 엔지니어가 알아야 할 네 가지 핵심 메트릭입니다:
-
Queries Per Second (QPS): 시스템이 초당 처리하는 들어오는 요청의 수입니다. 서버가 1초에 1,000개의 요청을 받으면 1,000 QPS입니다. 간단해 보이지만, 대부분의 시스템은 문제가 발생하기 시작하기 전까지 피크 QPS를 오래 유지할 수 없습니다.
-
Transactions Per Second (TPS): 시스템이 초당 처리하는 완료된 트랜잭션의 수입니다. 트랜잭션은 전체 왕복을 포함합니다. 즉, 요청이 나가고, 데이터베이스에 도달하고, 응답과 함께 돌아오는 것입니다.
TPS는 단순히 수신된 요청이 아닌 실제로 완료된 작업에 대해 알려줍니다. 이것이 비즈니스가 관심을 갖는 부분입니다.
-
Concurrency (동시성): 주어진 순간에 시스템이 처리하고 있는 동시 활성 요청의 수입니다. 초당 100개의 요청이 있을 수 있지만, 각각 완료하는 데 5초가 걸린다면 실제로는 한 번에 500개의 동시 요청을 처리하고 있는 것입니다.
높은 동시성은 더 많은 리소스, 더 나은 커넥션 풀링, 더 스마트한 스레드 관리가 필요함을 의미합니다.
-
Response Time (RT): 요청이 시작된 시점부터 응답을 받을 때까지 경과된 시간입니다. 클라이언트 레벨과 서버 레벨 모두에서 측정됩니다.
간단한 관계식이 이 모든 것을 연결합니다: QPS = Concurrency ÷ Average Response Time
동시성이 높거나 응답 시간이 낮을수록 = 처리량이 높아집니다.
Over to you: 성능을 분석할 때 QPS, TPS, Response Time 중 어떤 메트릭을 먼저 확인하시나요?
Nginx가 인기 있는 이유
Apache는 20년간 웹 서버 시장을 지배했습니다. 그러다 Nginx가 등장해 모든 것을 바꿔놓았습니다. 이제 Nginx는 Netflix, Airbnb, Dropbox, WordPress.com을 포함한 인터넷에서 가장 큰 사이트들을 구동합니다. 더 새롭거나 트렌디해서가 아니라, Apache가 효율적으로 처리할 수 없었던 문제들을 해결하기 때문입니다.
Nginx가 인기 있는 이유입니다:
- 고성능 웹 서버
- Reverse Proxy 및 Load Balancer
- 캐싱 레이어
- SSL Termination (Offloading)
Over to you: 오늘날 Nginx를 주로 웹 서버, reverse proxy, load balancer 중 어떤 용도로 사용하고 계신가요?
모든 엔지니어가 알아야 할 네트워크 디버깅 명령어
누군가 "네트워크 문제야"라고 말할 때, 이 명령어들이 무엇이 잘못되었는지 빠르게 찾는 데 도움이 됩니다.
- ping: 목적지가 응답하는지 확인하고 기본적인 도달 가능성에 대한 왕복 시간을 보고합니다.
- traceroute / tracert: 경로상의 각 홉을 보여주어 패킷이 어디서 느려지거나 멈추는지 확인할 수 있습니다.
- mtr / pathping: 홉별 지연 시간과 손실을 지속적으로 측정하여 간헐적인 문제를 포착합니다.
- ip addr, ip link / ipconfig /all: 로컬 IP, MAC, 인터페이스 상태를 출력하여 머신의 네트워크 ID를 확인할 수 있습니다.
- ip route: 라우팅 테이블을 표시하여 시스템이 어떤 게이트웨이와 다음 홉을 사용할지 확인합니다.
- ip neigh: IP-to-MAC 항목을 표시하여 LAN에서 중복되거나 오래된 ARP 레코드를 감지합니다.
- ss -tulpn: 리스닝 소켓과 PID를 나열하여 서비스가 실제로 예상 포트에 바인딩되어 있는지 확인할 수 있습니다.
- dig: DNS 레코드를 확인하여 클라이언트가 연결할 정확한 IP를 검증합니다.
- curl -I: HTTP(S) 헤더만 가져와서 상태 코드, 리다이렉트, 캐시 설정을 확인합니다.
- tcpdump / tshark: 패킷을 캡처하여 실제 트래픽을 검사하고 무엇이 송수신되는지 검증합니다.
- iperf3: 두 호스트 간의 엔드투엔드 처리량을 측정하여 대역폭 제한과 앱 문제를 분리합니다.
- ssh: 원격 머신에서 보안 셸을 열어 검사를 실행하고 수정 사항을 직접 적용합니다.
- sftp: 파일을 안전하게 전송하여 인시던트 중에 로그를 가져오거나 아티팩트를 푸시할 수 있습니다.
- nmap: 열린 포트를 스캔하고 버전을 탐색하여 어떤 서비스가 노출되어 있고 응답하는지 확인합니다.
Over to you: 네트워크 문제를 디버깅할 때 가장 먼저 사용하는 명령어는 무엇인가요?
Hub, Switch, Router 설명
모든 가정과 사무실 네트워크는 hub, switch, router 이 세 가지 장치에 의존하지만, 그 역할은 종종 혼동됩니다.
Hub는 Layer 1 (Physical Layer)에서 작동합니다. 세 가지 중 가장 단순하며, 주소나 데이터 유형을 이해하지 못합니다. 패킷이 도착하면 단순히 연결된 모든 장치에 브로드캐스트하여 하나의 큰 충돌 도메인을 만듭니다. 이는 모든 장치가 동일한 대역폭을 두고 경쟁한다는 것을 의미하며, 현대 네트워크에서 hub가 비효율적인 이유입니다.
Switch는 Layer 2 (Data Link Layer)에서 작동합니다. MAC 주소를 학습하고 프레임을 올바른 목적지 장치에만 전달합니다. switch의 각 포트는 자체 충돌 도메인으로 작동하여 LAN 내 통신의 효율성과 속도를 향상시킵니다.
Router는 Layer 3 (Network Layer)에서 작동합니다. IP 주소를 기반으로 패킷을 라우팅하고 서로 다른 네트워크를 연결합니다. 예를 들어 홈 네트워크를 인터넷에 연결합니다. 각 router 인터페이스는 별도의 브로드캐스트 도메인을 형성하여 로컬과 외부 트래픽을 격리합니다.
이 세 가지 레이어가 어떻게 함께 작동하는지 이해하는 것은 홈 Wi-Fi부터 글로벌 인터넷 백본까지 모든 현대 네트워크의 기초입니다.
Over to you: 네트워크 문제가 router 때문인지 switch 때문인지 보통 어떻게 파악하시나요?
Thank you for reading.