일요일 아침의 예상치 못한 오류

이번 일요일 아침, 컴퓨터 앞에 앉았을 때 평일 동안 설정해 두었던 AI 파이프라인 (AI pipeline)에서 예상치 못한 충돌 (crash)을 발견했습니다. 평소에는 원활하게 작동하며 데이터 검색 및 처리 단계를 자동화하던 이 파이프라인에서 말입니다. 하지만 그날 아침에 받은 오류 메시지는 상당히 이상했습니다. 시스템의 핵심을 이루는 데이터 검색 모듈 (data retrieval module)은 평소처럼 작동해야 했으나, 데이터를 즉시 처리할 수 없는 상태였습니다. 이 상황은 며칠 동안 진행해 온 자동화 프로젝트의 진행을 중단시켰고, 주말임에도 불구하고 저를 디버깅 (debugging) 세션으로 몰아넣었습니다. 보통 주간 업무를 마친 후에는 시스템이 밤사이에 배치 작업 (batch jobs)을 처리할 것이라고 기대합니다. 하지만 이번에는 달랐습니다. 파이프라인은 일요일 아침 08:17에 시작되었고, 첫 번째 데이터 검색 단계에서 즉시 실패했습니다. 오류 로그 (error logs)를 확인했을 때, 일반적인 연결 거부 (connection refused) 오류 대신 더 구체적인 타임아웃 (timeout) 오류가 나타났습니다. 이는 네트워크 연결 문제를 시사했지만, 동일한 네트워크에서 실행 중인 다른 서비스들에는 아무런 문제가 없었습니다. 이는 문제가 이 파이프라인에 국한되어 있으며, 더 깊은 근본 원인 (root cause)이 있을 수 있음을 나타냈습니다.

첫 번째 단계: 기본 점검 및 로그 분석 (Log Analysis)

모든 디버깅 (debugging) 세션의 첫 번째 단계는 항상 가장 단순한 것부터 시작하는 것입니다. 저는 파이프라인 스크립트가 실행되는 환경(이 경우에는 Docker 컨테이너 내부의 가상 환경 (virtual environment))이 정상인지 확인했습니다. 그런 다음, 관련 서비스의 로그 파일 (log files)을 더 자세히 조사하기 시작했습니다. journald 출력 결과는 오류가 발생한 정확한 위치를 보여주었습니다:

May 12 08:17:01 ai-worker-1 python[1234]: INFO: Starting data ingestion process...
May 12 08:17:05 ai-worker-1 python[1234]: ERROR: Failed to connect to data source: Timeout occurred after 30 seconds.

May 12 08:17:05 ai-worker-1 python[1234]: Traceback (most recent call last): File "/app/ingestion.py", line 55, in ingest_data response = requests.get(DATA_SOURCE_URL, timeout=30) File "/usr/local/lib/python3.10/site-packages/requests/api.py", line 117, in get return request('get', url, params=params, **kwargs) File "/usr/local/lib/python3.10/site-packages/requests/sessions.py", line 555, in request resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python3.10/site-packages/requests/sessions.py", line 668, in send r = adapter.send(request, **kwargs) File "/usr/local/lib/python3.10/site-packages/requests/adapters.py", line 519, in send raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: Timeout occurred after 30 seconds.

이 로그들은 requests 라이브러리가 DATA_SOURCE_URL로 보낸 GET 요청이 30초의 타임아웃 (timeout) 기간 내에 응답을 받지 못했음을 나타냈습니다. 하지만 이 URL은 몇 주 동안 안정적으로 작동해 왔습니다. 이로 인해 저는 문제가 네트워크 설정 (network configuration)이나 대상 서비스 (target service)에 있을 수 있다고 의심하게 되었습니다. 저는 즉시 대상 서비스의 상태 페이지 (status page)를 확인했습니다 (이것은 외부 API였으며, 이름을 밝히지는 않겠지만, 대규모 데이터 제공업체들은 종종 이러한 서비스를 제공합니다). 장애나 점검에 관한 정보는 없었습니다. 이는 문제가 제 인프라 (infrastructure)와 관련이 있거나, API가 제 IP 주소에 가한 제한 사항일 가능성이 더 높음을 시사했습니다.

ℹ️ 디버깅 전략 (Debugging Strategy)
항상 가장 단순하고 가능성이 높은 시나리오부터 시작하여 단계적으로 올라가십시오. 이것이 시간을 절약해 줍니다. 로그를 주의 깊게 읽고, 때로는 각 줄을 분석하는 것조차 문제의 근원을 찾는 데 결정적인 역할을 합니다.

2단계: 네트워크 및 방화벽 설정 (Network and Firewall Configuration)
대상 API 자체에는 문제가 없다고 가정하고, 저는 문제가 제 네트워크 및 방화벽 설정 (network and firewall configuration)에 있을 수 있다고 생각하기 시작했습니다. 제 파이프라인 (pipeline)은 Docker 컨테이너 내부에서 실행되고 있었으며, 이 컨테이너의 외부 세계에 대한 접근은 프록시 (proxy)를 통해 제공되었습니다.

보통 이러한 프록시 (proxy) 설정은 올바르게 구성되어 있었습니다. 하지만 일요일 아침이었기에, 주말 정기 점검이나 자동 업데이트가 영향을 미친 것은 아닌지 의구심이 들었습니다. 저는 시스템의 ufw (Uncomplicated Firewall) 규칙과 Docker의 네트워크 브리지 (network bridges)를 확인했습니다. 특정 트래픽이 실수로 차단되고 있지 않은지 확인하기 위해 ufw status verbose를 실행했습니다. 출력 결과는 깨끗했으며, 명백한 차단은 발견되지 않았습니다. 그다음, 컨테이너의 네트워크 구성을 조사했습니다. Docker의 iptables 규칙의 복잡성은 때때로 예상치 못한 문제를 일으킬 수 있습니다. 이러한 이유로, 컨테이너의 직접적인 외부 접근을 테스트하기 위해 docker exec 명령어를 사용하여 일시적으로 컨테이너에 접속한 뒤 ping과 curl 명령어를 시도했습니다.

컨테이너 ID 가져오기

<figure> <Image src ={ cover } alt = "컴퓨터 화면에 코드 라인과 에러 메시지가 표시된 AI 파이프라인 다이어그램." /> </figure>

docker ps

컨테이너 접속

docker exec -it <container_id> /bin/bash

ping 테스트 수행

ping google.com

ping이 작동함, 기본적인 네트워크 연결은 존재함.

curl 테스트 수행

curl -v -m 30 $DATA_SOURCE_URL

curl에서도 동일한 타임아웃 (timeout) 에러가 발생함.

이 테스트들을 통해 기본적인 네트워크 연결은 존재한다는 것을 확인했지만, 왜 특정 URL에 대한 요청이 30초 후에 끊기는지는 이해할 수 없었습니다. 문제는 여전히 미스터리로 남았습니다. 이 시점에서 저는 이 문제가 단순한 설정 오류가 아니라, 더 미묘한 세부 사항과 관련이 있을지도 모른다고 생각하기 시작했습니다.

세 번째 단계: MTU 및 MSS 불일치 의심
기본적인 네트워크 연결은 작동하지만 특정 요청에서 타임아웃이 발생하는 사실은, 제가 가끔 마주치는 MTU (Maximum Transmission Unit) 또는 MSS (Maximum Segment Size) 불일치를 떠올리게 했습니다. 이러한 불일치는 네트워크 장치 간에 데이터 패킷이 파편화 (fragmented)되거나 완전히 드롭 (dropped)되는 원인이 될 수 있습니다. 이러한 유형의 문제는 특히 서로 다른 네트워크 세그먼트 간의 연결이나 VPN 터널을 통해 연결될 때 발생할 수 있습니다.

제 파이프라인은 프록시 서버 (proxy server)를 통해 외부 세계와 연결되어 있었고, 이 프록시 서버 자체는 가상 사설망 (VPN)을 통해 우리의 메인 네트워크에 연결되어 있었습니다. 먼저, 저는 프록시 서버의 MTU 값을 확인했습니다. 보통 1500으로 설정되지만, 일부 VPN 솔루션이나 네트워크 카드 드라이버는 다른 값을 사용할 수도 있습니다.

프록시 서버에서 MTU 확인

ip addr show eth0 | grep mtu

출력: mtu 1500

MTU 값은 정상적으로 보였습니다. 다음 단계는 MSS 클램핑 (MSS clamping)을 확인하는 것이었습니다. MSS 클램핑은 TCP 연결 시작 시 전송되는 MSS 값을 특정 제한값으로 고정하여 패킷 파편화 (packet fragmentation)를 방지하려고 시도하는 기술입니다. 만약 이 기능이 올바르게 구성되지 않거나 네트워크 장치에서 잘못 설정되어 있다면 문제가 발생할 수 있습니다. 하지만 이 단계에서 직접적인 iptables 명령어를 실행하는 대신, 저는 더 쉬운 접근 방식을 시도했습니다. 제 서버에서 대상 API로 traceroute를 시도해 본 것입니다. 이를 통해 패킷이 어떤 라우터 (router)를 통과하는지, 그리고 각 홉 (hop)에서 시간이 얼마나 걸리는지 확인할 수 있습니다.

traceroute -m 30 $DATA_SOURCE_URL

traceroute 출력 결과, 트래픽이 제가 예상했던 것과는 다른 경로를 지나고 있음을 보여주었습니다. 정상적이라면 우리의 기본 게이트웨이 (default gateway)를 통해 직접 나가야 할 트래픽이 중간 지점에서 다른 경로로 이탈하고 있었습니다. 이는 주말 동안의 네트워크 경로 업데이트 결과이거나 라우터의 예기치 않은 동작일 수 있습니다. 이 상황은 문제의 원인을 더 구체적인 네트워크 장치나 경로로 좁히는 데 도움이 되었습니다.

⚠️ MTU 및 MSS 문제
MTU와 MSS 불일치는 특히 복잡한 네트워크 인프라, VPN 솔루션, 그리고 서로 다른 하드웨어 간의 데이터 전송에서 심각한 네트워크 문제를 일으킬 수 있습니다. 이러한 문제를 진단할 때는 일반적으로 -M do (Do Not Fragment) 및 -s (packet size) 파라미터를 사용하는 ping 명령어 또는 traceroute와 같은 도구를 사용합니다.

네 번째 단계: 실제 원인과 해결책
traceroute 출력에서 이상 징후를 발견한 후, 저는 우리 네트워크 인프라를 담당하는 팀에 연락했습니다.

그들은 주말 동안 수행한 라우터 설정 (router configuration) 업데이트가 일부 오래된 프로토콜 (protocols)과 통신하는 서비스에 예기치 않은 부작용을 일으켰음을 확인했습니다. 구체적으로, 제 API가 통신하던 서버는 일종의 NAT (Network Address Translation, 네트워크 주소 변환) 장치 뒤에 있었는데, 이 장치가 특정 TCP 플래그 (TCP flags)를 올바르게 처리하지 못해 문제가 발생했습니다. 문제의 근본 원인은 다음과 같았습니다: 업데이트된 라우터 설정이 기본적으로 특정 TCP 패킷 (TCP packets)을 더 공격적으로 필터링 (filtering)하기 시작한 것입니다. 제 AI 파이프라인 (AI pipeline)의 데이터 검색 요청에는 이 필터링에 걸리는 특정 TCP 패킷이 포함되어 있었습니다. 이 패킷들이 드롭 (dropped)되었기 때문에 대상 서버가 응답할 수 없었고, 제 쪽의 requests 라이브러리 (requests library)는 30초의 타임아웃 (timeout) 기간이 만료된 후 타임아웃 에러를 발생시켰습니다. 요약하자면, "타임아웃"은 실제로는 패킷 손실 (packet loss) 문제였습니다. 해결책으로, 네트워크 팀은 라우터의 관련 규칙을 업데이트하고 제 IP 주소에서 오는 트래픽이 이러한 공격적인 필터링에서 제외되도록 조치했습니다. 이 변경이 이루어진 후 파이프라인을 재시작했고, 이번에는 아무런 문제 없이 작동하기 시작했습니다. 데이터 검색 모듈 (data retrieval module)이 데이터를 성공적으로 가져왔고, 파이프라인의 나머지 부분도 정상적으로 작동을 이어갔습니다. 문제는 일요일 오전 11시 30분경에 해결되었습니다. 이 경험은 인프라 (infrastructure)가 얼마나 복잡하고 상호 연결되어 있을 수 있는지를 다시 한번 보여주었습니다. 때때로 가장 단순해 보이는 에러 메시지가 깊고 복잡한 근본 문제를 나타내는 지표가 될 수 있습니다. 그러한 상황에서는 문제를 좁혀나가는 체계적인 접근 방식이 필수적입니다.

교훈 및 향후 단계
이번 일요일 아침의 사건은 저에게 몇 가지 중요한 교훈을 상기시켜 주었습니다. 첫째, 자동화 시스템 (automation systems)은 예상치 못한 시점에 작동할 수 있으며 주말에도 개입이 필요할 수 있습니다. 둘째, MTU 및 MSS 불일치는 여전히 유효하며 잠재적으로 심각한 네트워크 문제입니다.

셋째, 그리고 가장 중요한 것은 인프라 (Infrastructure) 변경의 영향을 주의 깊게 모니터링하고 잠재적인 부작용을 예측하려고 노력하는 것입니다. 저의 향후 단계는 다음과 같습니다: 더 상세한 모니터링 (More Detailed Monitoring): 파이프라인의 네트워크 연결과 데이터 흐름을 더 즉각적이고 상세하게 모니터링하기 위해 새로운 메트릭 (Metrics)을 추가할 것입니다. 구체적으로, TCP 연결 상태 (TCP connection states), 패킷 손실 (Packet losses), 타임아웃 지속 시간 (Timeout durations)과 같은 메트릭을 추적할 것입니다. 이를 통해 사용자가 영향을 받기 전에 문제를 감지하는 데 도움이 될 것입니다. 네트워크 구성 추적 (Network Configuration Tracking): 네트워크 팀과 정기적인 소통을 유지하여 그들이 수행하는 모든 변경 사항을 인지하고, 그것이 제 파이프라인에 미칠 잠재적 영향을 선제적으로 평가할 것입니다. 어쩌면 저는 "변경 관리 (Change management)" 프로세스에 참여해야 할 수도 있습니다. 오류 관리 최적화 (Error Management Optimization): 오류가 발생했을 때 더 지능적으로 작동하는, 파이프라인 내의 더 스마트한 오류 관리 메커니즘을 개발할 것입니다. 예를 들어, 특정 유형의 타임아웃 오류가 수신되었을 때 대체 데이터 소스로 자동 전환하거나 다른 네트워크 경로를 시도하는 것과 같은 전략을 구현할 수 있습니다. 이러한 문제들은 끊임없이 변화하고 진화하는 기술 세계의 본질적인 부분입니다. 중요한 것은 이러한 문제에 직면했을 때 침착함을 유지하고 체계적으로 해결책을 향해 나아가는 것입니다. 이번 일요일 아침의 경험은 디버깅 (Debugging)이 단순한 기술적 숙련도가 아니라, 인내와 문제 해결의 예술이라는 점을 다시 한번 보여주었습니다.