개요
어느 날 아침, 모니터링 시스템에서 "서비스 응답 없음" 알람이 발생하고 사용자들의 접속 불가 문의가 빗발치기 시작합니다.
시스템을 총괄하는 엔지니어로서, 이제 차가운 머리와 명확한 절차로 문제의 근원을 빠르게 찾아내야 합니다.
당신이라면 어떻게 하시겠습니까?
혹시 두려움이 몰려오기 시작하셨나요?
이 두려움을 없앨 수 있는 가장 강력한 무기는 바로 OSI 7계층 기반의 체계적인 접근법 입니다.
이 모델은 인프라의 가장 낮은 레벨부터 사용자와 가장 가까운 애플리케이션까지, 장애의 원인을 논리적으로 추적하는 완벽한 로드맵을 제공합니다.
장애 상황
회사 웹 서비스(www.my-service.com)에 접근할 수 없어요!
Level 1: 물리 계층 - "서버가 살아있나?"
가장 먼저 데이터센터의 서버 랙으로 달려가거나 원격 콘솔에 접속하여 하드웨어의 물리적 상태부터 확인합니다.
🕵️♂️ 점검 포인트
- 서버 하드웨어, 네트워크 장비의 물리적 상태
💻 엔지니어의 확인 사항
- 서버 전원 및 상태 LED: 서버의 전원 LED가 정상인가? 장애를 의미하는 주황색 LED가 점등되지는 않았는가?
- 네트워크 케이블 연결: 서버의 네트워크 포트와 스위치 포트에 연결된 케이블은 단단히 체결되어 있는가?
- 스위치/라우터 상태: 서버와 연결된 스위치, 라우터 장비의 전원 및 포트 상태 LED는 정상인가?
💡 장애 처리 시나리오
원격 콘솔로 확인 결과, 이중화된 파워 서플라이 중 하나에 장애(Fault) LED가 켜져 있지만, 다른 하나가 정상 작동하여 서버 자체는 부팅된 상태임을 확인.
물리 계층은 직접적인 원인이 아님을 판명하고 다음 단계로 이동.
Level 2: 데이터 링크 계층 - "서버가 네트워크에 속해있는가?"
하드웨어에 이상이 없다면, 서버가 속한 로컬 네트워크내에서 정상적으로 통신하고 있는지 검증해봐야 합니다.
🕵️♂️ 점검 포인트
- 스위치 레벨의 연결성, VLAN 설정
💻 엔지니어의 확인 사항
- 스위치 MAC 테이블 확인: 스위치에 접속하여 해당 서버의 MAC 주소가 정상적으로 학습되고(Learned) 올바른 포트와 매핑되어 있는지 확인합니다. (show mac address-table | include [서버 MAC])
- VLAN 설정: 서버가 연결된 스위치 포트가 올바른 VLAN에 할당(assigned)되어 있는지 확인합니다. 잘못된 VLAN에 속해 있으면 게이트웨이와 통신할 수 없습니다.
- 케이블 오류 카운트: 스위치 포트의 인터페이스 정보에서 CRC 에러, 프레임 드랍(drop) 등의 카운트가 증가하고 있는지 확인하여 케이블 또는 NIC 불량을 의심합니다.
💡 장애 처리 시나리오
스위치에서 확인 결과, 서버의 MAC 주소가 다른 포트에서 간헐적으로 발견되는 'MAC 플래핑(Flapping)' 현상을 발견.
이중화된 네트워크 카드(NIC)의 본딩(Bonding) 설정 오류임을 인지하고, 문제가 되는 NIC 포트를 비활성화하여 문제를 해결.
2계층에서 문제 해결 완료.
Level 3: 네트워크 계층: "서버가 외부와 소통할 경로/주소를 알고 있는가?"
내부 통신이 정상이라면, 서버의 IP 설정과 외부로 나가는 경로(라우팅)에 문제가 없는지 확인해야 합니다.
🕵️♂️ 점검 포인트
- 서버 IP 설정, 라우팅 테이블, 방화벽/ACL
💻 엔지니어의 확인 사항
- 서버 IP 설정 확인: 서버에 접속하여 ip addr 또는 ifconfig 명령어로 고정 IP, 서브넷 마스크, 게이트웨이 정보가 정확히 설정되어 있는지 확인합니다.
- 라우팅 경로 확인: 서버에서
ping [게이트웨이 IP]를 실행하여 내부망 출구까지의 통신을 확인하고, ping 8.8.8.8로 외부 인터넷과의 통신을 확인합니다. - 네트워크 접근 제어 목록(ACL): 서버 앞단의 방화벽이나 L3 스위치의 ACL에서 해당 서버의 IP에 대한 deny 정책이 있는지 확인합니다.
💡 장애 처리 시나리오
서버의 IP 설정과 내부 통신은 정상이지만 외부로의 ping이 실패.
상단 라우터의 라우팅 테이블을 확인해보니, 최근 네트워크 대역 변경 작업 후 해당 서버 대역의 정적 라우팅(Static Routing) 경로가 누락된 것을 발견.
경로를 추가한 후 외부 통신 정상화. 3계층 문제 해결 완료.
Level 4: 전송 계층 - "서비스의 문(Port)이 열려 있는가?"
네트워크 경로에 이상이 없다면, 서비스가 사용하는 특정 포트가 정상적으로 열려 응답을 기다리고 있는지 확인합니다.
🕵️♂️ 점검 포인트
- 서비스 포트 리스닝 상태, 서버 방화벽, 로드밸런서 헬스체크
💻 엔지니어의 확인 사항
- 포트 리스닝 확인: 서버에서
netstat -anp | grep LISTEN또는ss -lntp명령어로 웹 서비스 포트(80, 443)가 LISTEN 상태인지 확인합니다. - 서버 방화벽 확인:
iptables -L또는firewalld --list-all명령어로 서버 자체 방화벽이 해당 포트로의 접근을 허용하고 있는지 확인합니다. - 로드밸런서(L4/L7) 헬스 체크: 서비스 앞단에 로드밸런서가 있다면, 로드밸런서가 서버의 서비스 포트로 보내는 헬스 체크(Health Check)가 성공하고 있는지 대시보드에서 확인합니다.
💡 장애 처리 시나리오
로드밸런서 대시보드에서 해당 서버로의 헬스 체크가 계속 실패하는 것을 확인.
서버에서 netstat으로 확인해보니 웹서버(Nginx)가 80 포트를 LISTEN하고 있지 않음. 문제의 원인이 상위 계층에 있음을 파악하고 다음 단계로 이동.
Level 5: 응용 계층 - "애플리케이션이 제대로 동작하고 있는가?"
인프라의 모든 것이 정상이라면, 이제는 서비스의 핵심인 애플리케이션 자체를 들여다볼 차례입니다.
🕵️♂️ 점검 포인트
- DNS, SSL 인증서, 웹/애플리케이션 서버 로그 및 상태
💻 엔지니어의 확인 사항
- DNS 확인 (Application):
dig www.my-service.com또는nslookup으로 도메인 이름이 설정된 공인 IP로 정확히 변환되는지 확인합니다. - SSL 인증서 확인 (Presentation):
openssl s_client -connect www.my-service.com:443명령어로 SSL 인증서가 만료되거나 깨지지 않았는지 확인합니다. - 웹 서버/WAS 상태 및 로그 확인 (Application):
systemctl status nginx(또는 apache2, tomcat 등) 명령어로 서비스 프로세스가 활성 상태인지 확인합니다./var/log/nginx/error.log등 웹 서버의 에러 로그 파일을 실시간으로 확인(tail -f)하여 어떤 오류가 발생하는지 직접 봅니다.- 애플리케이션의 성능 모니터링(APM) 툴에서 트랜잭션 실패나 DB 연결 오류 등을 확인합니다.
💡 장애 처리 시나리오
Nginx 프로세스는 살아있지만, 에러 로그에 "upstream timed out" 메시지가 대량으로 쌓이는 것을 발견.
Nginx가 요청을 전달하는 WAS(Web Application Server)가 응답하지 않는 상황.
WAS 로그를 확인해보니, 최근 배포된 코드의 버그로 인해 DB 커넥션 풀(DBCP)이 고갈되어 모든 요청을 처리하지 못하고 있었음.
애플리케이션 버그가 원인임을 최종 확인하고 긴급 롤백 조치 후 서비스 정상화.