서비스 응답속도가 갑자기 느려지면 운영자는 가장 먼저 서버와 DB를 확인합니다. 하지만 CPU와 메모리, DB 부하가 모두 정상인데도 사용자가 느린 서비스를 경험한다면 개별 시스템뿐 아니라 서비스와 연결된 전체 인프라 구성을 함께 살펴봐야 합니다. 이번 사례에서는 통합 모니터링을 통해 서비스 이상을 감지하고, 연결 관계를 따라 실제 장애 구간을 확인하는 과정을 살펴보겠습니다.
- 요청량 변화 없이 응답시간이 증가했다면 내부 처리 및 연결 구간을 확인해야 합니다.
- 서비스 구성도를 활용하면 이상이 발생한 인프라 구간을 빠르게 찾을 수 있습니다.
- 인터페이스가 UP 상태여도 패킷 오류와 DROP이 발생하면 서비스 품질이 저하될 수 있습니다.
요청량은 그대로인데 응답시간만 증가했습니다
오전 10시부터 주문 서비스의 응답속도가 평소보다 느려지고 사용자 문의가 들어오기 시작했습니다.
먼저 APM에서 서비스 상태를 확인한 결과, 서비스 처리량은 장애 발생 전후 약 80count/s 수준을 유지하고 있었습니다. 갑작스러운 사용자 증가나 트래픽 폭증은 발생하지 않았습니다.
반면 같은 시점부터 평균 응답시간이 증가하고, 사용자 만족도를 나타내는 Apdex는 하락했습니다.
APM 서비스 영향 확인 화면
세 지표를 함께 보면 요청량 증가로 발생한 단순 과부하가 아니라는 것을 알 수 있습니다. 서비스 처리량에는 큰 변화가 없지만 응답시간이 증가하고 Apdex가 하락했기 때문에 내부 처리 과정이나 연결 구간에서 지연이 발생했을 가능성을 확인해야 합니다.
서비스 구성도에서 이상 구간을 찾습니다
서비스 요청이 많아져 느려진 상황이 아니라면 다음으로 확인해야 할 것은 서비스와 연결된 인프라입니다. 서버와 DB를 하나씩 찾아다니기보다 주문 서비스의 전체 연결 관계에서 이상이 발생한 구간을 먼저 확인합니다.
통합 모니터링의 토폴로지맵에서 주문 서비스의 구성 관계를 확인했습니다. 사용자 요청은 인터넷과 웹 방화벽, 로드밸런서를 거쳐 애플리케이션 서버로 전달되며, 애플리케이션 서버는 업무 스위치와 DB 방화벽을 통해 DB 서버에 연결됩니다.
구성도를 확인한 결과, APP-SVR-01과 업무 스위치 1 사이의 인터페이스에서 이상이 감지됐습니다.
서비스 구성도 이상 구간 확인
구성도를 활용하면 서버, DB, 네트워크 장비를 각각 찾아보지 않고 서비스와 직접 연결된 이상 구간을 빠르게 확인할 수 있습니다. 다만 네트워크 이벤트가 표시됐다는 사실만으로 해당 구간을 서비스 지연의 원인이라고 단정할 수는 없습니다.
같은 시간에 우연히 발생한 이벤트일 가능성도 있기 때문에 서버와 DB, 네트워크의 관련 지표를 함께 살펴봐야 합니다.
통합 모니터링을 통한 연관 지표 확인
연관 지표를 확인한 결과, 서버의 CPU와 메모리 사용률은 정상 범위를 유지하고 있었고 DB 내부 부하에도 특별한 변화가 없었습니다.
반면 애플리케이션 서버에서는 DB 방향의 연결 요청이 완료되지 않고 대기하는 SYN_SENT 세션이 증가했습니다. 서버나 DB 자체의 처리 능력이 부족한 상황이라기보다 두 시스템 사이의 연결 구간에서 문제가 발생했을 가능성이 높아진 것입니다.
- 서비스 처리량에는 큰 변화가 없습니다.
- 서버 CPU와 메모리는 정상 범위입니다.
- DB 내부 부하와 SQL 처리량에도 특별한 변화가 없습니다.
- DB 방향의 SYN_SENT 세션은 증가했습니다.
- 같은 시점에 APP-SVR-01 연결 인터페이스에서 이상이 감지됐습니다.
인터페이스는 UP인데 패킷 오류가 발생했습니다
업무 스위치 1의 인터페이스 이력을 확인한 결과, APP-SVR-01 연결 포트의 상태는 UP으로 표시됐습니다. 연결이 물리적으로 완전히 끊어진 상황은 아니었습니다.
하지만 상세 데이터를 확인하면 다른 인터페이스와 뚜렷한 차이가 나타납니다. 다른 인터페이스의 오류 수치는 모두 0이지만 APP-SVR-01 연결 포트에서만 에러 패킷과 기각 패킷, IN·OUT DROP 수치가 증가했습니다.
장애 인터페이스 상세 화면
인터페이스가 UP이라는 이유만으로 정상이라고 판단해서는 안 됩니다. 물리적 연결이 유지되더라도 패킷 오류와 DROP이 반복되면 서버와 DB 사이의 요청과 응답 전달이 지연될 수 있습니다.
| 단계 | 확인 항목 | 영향 |
|---|---|---|
| 1 | APP-SVR-01 연결 인터페이스 이상 | 에러·기각·DROP 패킷 증가 |
| 2 | 서버와 DB 사이 통신 품질 저하 | DB 방향 SYN_SENT 세션 증가 |
| 3 | 서비스 처리 지연 | 응답시간 증가 및 Apdex 하락 |
APM에서 확인한 서비스 지연 시점과 서버의 연결 대기 증가 시점, 인터페이스 오류 발생 시점이 일치했습니다. 반면 서버의 CPU와 메모리, DB 내부 부하에는 특별한 변화가 없었습니다.
이를 근거로 APP-SVR-01과 업무 스위치 1 사이의 인터페이스 문제를 서비스 지연의 원인으로 판단할 수 있습니다.
장애 지점보다 영향 관계를 확인하는 것이 중요합니다
이번 사례에서는 APM을 통해 사용자에게 발생한 서비스 영향을 확인하고, 서비스 구성도에서 이상이 감지된 네트워크 구간을 찾았습니다. 이후 인터페이스 상세 데이터를 통해 패킷 오류를 확인하고, 관련 지표의 발생 시점을 비교해 서비스 지연과의 연관성을 검증했습니다.
통합 모니터링의 핵심은 장애가 발생할 때마다 여러 솔루션과 화면을 하나씩 찾아다니는 것이 아닙니다. 서비스에서 발생한 이상을 시작점으로 연결된 인프라와 장애 구간을 빠르게 확인하고, 관련 지표를 통해 해당 장애가 실제 서비스에 미친 영향을 검증하는 것입니다.
서비스와 인프라의 장애 원인을 하나의 흐름으로 확인하고 싶다면,
와치올 통합 모니터링 기능을 확인해보세요.