Post

[Network] 네트워크 장애 대응기

Posted
By 9osari
9 min read
[Network] 네트워크 장애 대응기

네트워크 접속 이슈…

지금 시스템 접속이 안 되는데요? 오늘 PQ 진행해야하는데..

급하게 VPN을 켜고 접속을 시도했다. 내 PC에서는… 멀쩡하게 접속된다.

상황 파악

침착하게 상황을 정리해봤다.

문제 증상

  • 고객사 사용자들만 데이터 조회 시 무한 로딩
  • 내 PC에서 접속 시 정상
  • DB 직접 조회도 정상

시도해본 방법

  • 브라우저 캐시 삭제

  • 방화벽 포드 정상

  • WAS 로그 확인

소거법으로 범인 찾기

패킷은 출발지에서 생성될 때 이미 모든 계층의 정보를 감싸 이동
장애 상황에서는 하위 계층부터 순차적으로 점검하여 문제를 좁혀가는 것이 가장 효율적
하위 계층에 문제가 있다면 상위 계층은 동작할 수 없기 때문에 2계층 → 3계층 → 4계층 -> 7계층 순으로 확인

Ping 테스트 (2-3계층 확인)

1

ping 203.xxx.xxx.xxx

결과: 성공

네트워크 경로는 정상이다. IP까지는 도달한다는 뜻이니, 라우터나 경로 문제는 아니다.

2계층

2계층

3계층

3계층

클라이언트가 외부 서버에 접속할 때:

  1. 목적지 IP가 내부망(192.168.x.x)이 아니면 → 외부망으로 판단
  2. 게이트웨이의 MAC 주소를 ARP로 찾아서
  3. 패킷을 게이트웨이로 전송
  4. NAT로 사설 IP를 공인 IP로 변환하여
  5. 여러 라우터를 거쳐 목적지 서버에 도달

Ping이 성공했다는 건 이 과정이 정상이라는 의미다.

Telnet 테스트 (4계층 확인)

4계층

4계층

Ping이 성공했으니 이제 포트까지 확인해보자.

1

telnet 203.xxx.xxx.xxx 8080

결과: 실패

‘어? 포트가 막혀있나?’

고객사 담당자에게 다시 확인했다. “서버 방화벽에서 8080 포트 열려있는 거 맞죠?” “네, 분명 열려있어요.”

그런데 telnet은 실패한다. 이건 뭔가 중간에 막고 있다는 뜻이다.

패킷에는 이런 정보가 들어있다:

  • 출발지 IP / 목적지 IP (3계층)
  • 출발지 MAC / 목적지 MAC (2계층)
  • 포트 정보 (4계층)
  • 실제 데이터

서버까지는 도달하는데(ping 성공), 포트 연결은 안 된다(telnet 실패). 그럼 서버와 클라이언트 사이 어딘가에 포트를 막는 무언가 있다는 거다.

범인 찾기

“지금 Ping은 성공하고 Telnet이 실패해서 그러는데 서버랑 클라이언트 사이에 다른 네트워크 장비 있는지 확인해 주실 수 있나요? “음… 잠시만요, 네트워크 담당자한테 물어볼게요.”

…

“아, L7 스위치가 있다는데요?”

범인을 찾았다.

고객사도 몰랐던 중간 네트워크 장비가 특정 URL 패턴을 차단하고 있었던 것이다. 주말 사이 보안팀에서 보안 정책을 업데이트했고, 그 과정에서 시스템 경로가 차단 규칙에 걸려버렸다.

L7 스위치

L7 스위치는 7계층(응용 계층)에서 동작하는 로드밸런서다.

L4 스위치 (4계층 - 전송 계층)

  • IP + Port로만 판단
  • 빠르고 단순
  • Round Robin, Least Connection 방식

L7 스위치 (7계층 - 응용 계층)

  • URL, Cookie, Header까지 보고 판단
  • 느리지만 똑똑함
  • URL 기반 라우팅: /api → API 서버, /admin → 관리 서버

우리 경우는 L7 스위치가 URL 패턴을 보고 차단한 케이스였다.

해결

네트워크 담당자와 협업하여:

  • L7 스위치의 ACL(Access Control List) 확인
  • 프로젝트 관련 URL 패턴을 허용 규칙에 추가
  • 설정 적용 후 정상 접속 확인

배운 것들

소거법

무작정 이것저것 시도하는 것보다, 체계적으로 하위 계층부터 확인하는 게 훨씬 효율적이다.

Ping (2-3계층) → 네트워크 경로 확인

  • 성공: 경로 정상
  • 실패: IP 오류, 경로 단절, 라우터 문제

Telnet (4계층) → 포트 연결 확인

  • 성공: 포트 정상, 애플리케이션 문제 의심
  • 실패: 방화벽/보안장비 포트 차단

WAS 로그 (7계층) → 애플리케이션 확인

  • Access Log: 누가, 언제, 어떤 요청
  • Application Log: 에러, 경고, 스택 트레이스
  • Error Log: WAS 자체 에러
  • Slow Query: 느린 쿼리 기록

근거 기반 커뮤니케이션

고객사에 확인을 요청하려면 근거가 필요하다. 우리는 ‘을’ 입장이다.

“뭔가 안 되는데 확인 좀 해주세요”

보다는

“Ping은 성공하는데 Telnet이 실패합니다. 서버 방화벽은 열려있다고 하셨으니, 혹시 중간에 다른 네트워크 장비가 있는지 확인 부탁드립니다.”

네트워크 흐름을 이해하고 있어야 정확하게 요청할 수 있다.

숨어있는 장비들

실제 운영 환경에는 생각보다 많은 장비들이 숨어있다:

  • IPS (침입방지시스템)
  • 프록시 서버
  • L4/L7 스위치
  • WAF (웹 방화벽)

담당자도 모를 수 있으니, 네트워크 담당자와의 협업이 중요하다.

또 다른 장애 케이스

DB Connection Timeout

1
2
3
4
5

증상:
- ping 성공
- telnet 성공
- 서버 접속 500 Error
- WAS 로그에 아무것도 안 뜸

이 경우는 4계층까지는 정상이고, 애플리케이션 레벨 문제다.

원인

  • DB 연결 30초 타임아웃
  • 사용자들이 못 기다리고 새로고침 반복
  • DB 커넥션 풀 고갈

해결

  • 즉시: 애플리케이션 재시작, 슬로우 쿼리 킬
  • 장기: 커넥션 풀 증가, 쿼리 최적화

마치며

네트워크 장애는 패킷이 어떻게 이동하는지 이해하고 하위 계층부터 체계적으로 확인하면 생각보다 빠르게 해결할 수 있다.

물데네전세표응을 외우는 것보다, 흐름을 이해하고 실전에 적용하는 게 중요하다.

다음 장애가 왔을 때는 조금 덜 당황할 수 있을 것 같다.

더 알아보기

network
http was mysql oracle web refactor
This post is licensed under CC BY 4.0 by the author.