구글의 4가지 황금 신호를 기준으로 네트워크 성능 정의하기

Network World
만나서 커피를 마시기로 했는데 상대방이 약속 시간에 3분 늦는다면? 별 문제 없다. 그러나 30분 늦는다면 무례한 일이다. “문제 없다”에서 “무례함”으로의 전환은 어느 순간 한 번에 이뤄지는 전환일까, 아니면 무례함의 단계적인 상승인가? 늦은 이유가 중요한가? 물론 타당한 이유는 관대함을 높여준다. 반면 항상 늦는 사람에 대해서는 관대함이 낮아진다.

네트워크 성능도 많은 부분에서 비슷하다. 한때는 정전이 주 대화 소재였지만 정전 사고는 갈수록 줄어드는 추세다. 지금은 “느린 속도”가 가장 큰 문제로 거론된다. 얼마나 느려야 느린 걸까? 사용자 경험을 이해하기 위해 노력하고 그 경험을 성능 모니터링에 반영해 조정하는가? 아니면 누군가 느린 속도에 대해 불평할 때까지 그냥 기다리는가?

최근 엔터프라이즈 매니지먼트 어소시에이츠(Enterprise Management Associates)는 250명의 네트워크 전문가를 대상으로 설문 조사를 실시했다. 질문 중 하나는 “네트워크 성능 문제 중에서 네트워크 운영 담당자가 아닌 최종 사용자가 처음 보고한 문제의 비율은 몇 %인가”였다. 평균 응답은 39%, 중간값 응답은 35%였다. 결국 문제의 1/3을(일부 조직의 경우 그보다 훨씬 더 높음) 사용자가 불평할 때까지 인지하지 못한다는 이야기다. 개선이 필요하다!

보고서는 부족하지 않다. 네트워크 운영 팀에 들어오는 정보는 넘쳐나지만 너무 많은 정보는 잡음보다 거의 나을 게 없다. 증발하는 데이터에서 통찰력을 응결할 수 있어야 한다. 문제는 그 방법이다.

가장 먼저 할 일은 최종 사용자 관점에서 네트워크 성능을 정의하는 것이다. 최종 사용자 경험에 초점을 두는 것은 최종 사용자의 경험이 판단 기준이 된다는 의미다. 현재나 미래의 최종 사용자 경험에 전혀 영향을 미치지 않는 문제가 있다면 그걸 문제라고 할 수 있을까? IoT나 특수 시스템을 제외하면 대답은 ‘아니다’이다.



무엇이 중요한지를 알면 중요하지 않은 것을 배제할 수 있다. 중요한 것을 판단하기 위해 참고할 만한 좋은 자료는 구글의 사이트 안정성 엔지니어링(Site Reliability Engineering, SRE) 팀이다. 이 그룹이 작성하고 벳시 베이어 등이 편집한 “사이트 안정성 엔지니어링(Site Reliability Engineering)”이라는 무료 책자가 있다. 이 책은 IT에 대한 전통적인 사고방식에 질문을 던진다. 모니터링에 관해 저자들이 제시한 중요한 개념 중 하나는 “4개의 황금 신호”, 즉 지연, 트래픽, 오류, 포화다.

“황금” 신호가 네트워크 성능에서 중요한 이유가 무엇일까? 네트워크 성능 모니터링 전략을 수립할 때 황금 신호를 어떻게 사용해야 할까? 하나씩 살펴보자.

지연
요청 충족 대기 시간이 길어지는 “지연”은 최종 사용자가 빈번하게 경험한다는 측면에서 가장 유용한 신호다. 사용자가 원격 애플리케이션에 요청한다. 아무런 응답이 없다. 기다리다가 다시 요청하려는 순간 응답을 받는다. 지연이 한 번씩 발생하면 몇 분 정도 지속되다가 사라지고, 애플리케이션은 다시 정상적으로 응답한다. 그러다가 또 발생하고 사라진다. 사용자는 약간 짜증스러울 이 경험을 얼만큼 참은 다음 문제 티켓을 생성할까?

네트워크 운영 팀이 지연을 모니터링할 수 있다면 사용자가 처음 문제를 경험할 때 그 문제를 볼 수 있다. 그러나 지연을 보는 것만으로는 충분하지 않다. 지연의 원인이 네트워크 지연인지, 애플리케이션 서버의 느린 응답 속도인지를 확인해야 한다. 또는 두 가지가 동시에 발생할 수도 있다(결코 드물지 않은 경우임). 원인을 파악했다면 정확한 문제의 위치는 어디인가? 많은 경우 그 답만 알면 문제를 해결할 수 있다.

트래픽
다음 황금 신호는 “트래픽”으로, 구글 SRE 팀은 발생하는 요청의 양을 모니터링하는 것으로 정의한다. 트래픽 모니터링을 위한 좋은 방법은 네트워크 대화의 수를 보는 것이다.

필자가 아는 한 대기업은 네트워크 세그먼트에서 주기적으로 문제를 겪었다. 이상한 점은 모니터링 중인 어느 지표와도 연관성이 없었다는 것이다. 일부 들어맞는 부분은 있었지만 근본적인 원인을 파악하기에는 부족했다. 네트워크 트래픽의 양(Gbps)이 올라가면 문제가 더 자주 발생했지만 항상 그렇지는 않았다. 시간, 트래픽의 종류, 가장 활발한 서버, 모두 문제와 느슨하게 연관될 뿐이었다. 마지막으로 네트워크 대화의 수를 측정하기 시작했고 10G 링크에서 네트워크 대화의 수가 75만 개에 도달하는 즉시 트래픽의 유형이나 양과는 무관하게 인프라 일부가 한계에 도달한다는 것을 발견했다. 원인을 파악한 후에는 신속하게 문제를 해결할 수 있었다.

오류
그 다음은 “오류” 신호다. 오류는 실패한 요청보다 더 넓은 범위를 포괄한다. 사용자 경험의 품질을 대변한다고 생각하면 된다. 응답성은 아주 좋은데 상대방 말을 알아듣기 어려운 VoIP는 명확한 저품질이다. 품질에서 가장 두드러진 요소는 RTP(Real Time Transport Protocol) 문제지만 그게 유일한 요소는 아니다. 예를 들어 페이로드에서 일부 비트가 뒤집히는 등의 지속적인 데이터 손상이 발생하는 경우는 매우 드물지만 낮은 TCP(Transmission Control Protocol) 품질은 재전송, 프레임 누락, 지연 등 여러 가지 문제의 원인이 된다. 가장 중요한 점은 오류는 더 큰 문제가 임박했음을 알리는 경고 신호인 경우가 많다는 것이다.

포화
마지막 황금 신호는 트래픽의 양(트랜잭션의 수와 대비)인 “포화”다. 물론 네트워크 용량을 충분히 활용하는 상태가 바람직하지만 사용률 급등도 허용해야 한다. 포화된 네트워크는 까다로운 장애를 유발할 수 있다. 오류와 재시도 메시지가 트래픽에 추가되면서 상황은 더욱 악화된다. 이 사이클이 계속 확산되면서 결국 어느 선을 넘으면 트랜잭션이 실패하고 세그먼트는 정상 상태로 복귀했다가 다시 패턴이 반복된다.

지속적인 운영을 지원하고 미래의 디지털 변혁에 대비하기 위해 네트워크 성능 관리 방법을 평가할 때 4가지 “황금 신호”는 중요한 역할을 할 수 있다. 4가지 신호를 통해 문제 티켓을 기다리는 대신 선제적으로 네트워크를 관리할 수 있게 된다.

성능 표준을 설정할 때 조직이 직면하는 과제는 무엇인가? 그 외의 다른 “신호”를 사용하는가? 활용하는 다른 신호가 있다면 토론을 위해 댓글로 알려주기 바란다.  editor@itworld.co.kr