[NCP] WMS(웹 서비스 모니터링 시스템)를 통한 웹 서비스 장애 파악

크롬 또는 엣지 브라우저를 통해서 웹 서핑을 하는데, 이때 사용되는 서비스가 바로 웹 서비스 입니다.

 

이 웹서비스가 대외적으로 그래서 불특정 다수를 위해 제공되는 웹 서비스가 어떠한 문제로 제공되지 않게 된다면 서비스 제공자와 서비스 사용자를 당혹스럽게 만드는 일이 생깁니다.

 

장애라는 것은 숙명적인 것 입니다.

 

언젠가 발생할 수 있는 장애를 빠르게 알고, 빠르게 처리하는 것이 숙명을 극복할 수 있는 최선의 방법 입니다.

 

물론 이중화 삼중화 등으로 최대한의 노력을 할 수 있겠지만 모든 것은 예기치 못하게 이루어집니다.

 

앞서 말한 웹 서비스에 대한 장애 또는 성능등을 모니터링 해주는 NCP 상품이 WMS(Web service Monitoring System) 입니다.

 

WMS는 메소드[method](GET, POST, PUT, DELETE, HEAD) 를 통해 정해져있는 주기로 (1,5,10분) 자동으로 웹 서비스에 방문을 합니다.

 

자동으로 방문을 하며 사람이 브라우저를 통해 방문하는 것과 동일하게 (물론 HEAD,DELETE 와 같은 메소드는 아니지만) 요청(request)과 응답(response)을 받게 됩니다.

 

우리들 눈에는 보이지 않지만 요청과 응답 사이에는 홈페이지를 이루는 매우 많은 파일(js,html,css,etc)들을 참조 합니다.

 

크롬 브라우저의 개발자 도구를 통해서 홈페이지를 통해 어떤 파일들이 참조되는지 알 수 있고, 파일을 처리한 응답 상태, 파일 크기, 요청부터 응답까지 발생한 시간 등에 대한 정보를 알 수 있습니다.

 

아래는 ncloud.com에 방문 했을 때 볼 수 있는 파일 및 네트워크에 대한 정보 입니다.

WMS를 통해 주기적으로 자동으로 방문하며 발생하는 파일, 응답 상태, 시간 등을 리포트 받을 수 있습니다.

 

그리고 일정 시간 이상으로 지연이 발생한다면 그것을 에러라고 판단하고 알람 시스템에 의해 문자 알람을 받아 볼 수 있습니다.

 

아래는 WMS를 통해 볼 수 있는 그래프 입니다.

빨간색 점은 여러 이유로 홈페이지에 발생하고 있는 문제를 볼 수 있습니다.

 

빨간색 점이 무조건 웹 서비스 장애를 의미하진 않습니다.

 

웹 서비스를 제공하던 서버의 문제로 예를 들어 대표적인 웹 서비스 httpd 가 장애로 인해 종료 되었거나 서버 자체가 종료되는 서버 측면의 장애도 있을 수 있고 웹 서비스를 제공하는 기반 자료인 홈페이지 소스 상의 문제로 웹 서비스는 가능 하지만 서비스 지연이 발생하는 경우도 있다.

 

또는 지연이나 웹 서비에 지대한 영향을 미치지 않지만 빨간색 점이 발생할 수 있습니다.

 

웹 서비스에는 응답 코드라는 것이 존재 합니다.

 

가장 대표적으로 많이 알고 있는 404는 "페이지를 찾을 수 없습니다". 라는 대표적인 에러 응답 중 하나입니다.

 

응답에 정상적인 성공을 의미하는 200 또한 대표적인 성공 응답 중 하나입니다.

 

여러 요인이 있긴하지만 사용자의 문제가 아닌 서버 쪽의 문제를 의미하는 5xx 도 에러 응답 입니다.

 

이러한 응답 코드는 웹 서비스가 화면에 정상적으로 보여진다면 최종적으로는 200의 응답코드를 받겠지만, 개발자 도구를 통해서 확인했던 것 처럼 최종 200 응답코드를 받는 중에 있는 여러 다양한 자원들에 대해서도 요청에 대한 응답을 받게 됩니다.

 

여러 자원 중 에러 응답으로 지연이 발생한다면 WMS에서는 빨간색 점으로 에러를 표시 합니다.

 

말할 것도 없이 최종적으로 받는 응답이 4xx,5xx과 같은 에러 응답이라면 그에 따른 빨간색 점으로 에러를 표시 합니다.

 

에러가 몇분 이내에 몇회 이상 유지되면 알람을 전송하는 서비스를 통해서 장애를 인지할 수 있게됩니다.

 

최근 몇 개월동안 2건의 유사한 사례가 있었고 모두 동일한 형태 였습니다.

 

홈페이지를 만들 때 여러 다양한 라이브러리를 사용합니다.

 

이렇게 사용되는 라이브러리는 외부의 다른 서버로 부터 사용하는 경우도 있습니다.

 

이 경우 자신이 제공하고 있는 웹 서비스와 상관없이 라이브러리를 제공하는 서비스에 문제가 생기면 문제가 생깁니다.

 

그래서 최종 홈페이지의 200 응답코드를 받더라도 그 사이에 사용되는 특정 라이브러리가 문제가 있다면 지연이 발생합니다.

 

그리고 그 라이브러리가 만약 홈페이지의 매우 큰 역할을 하고 있다면 서비스 장애 수준이 될 수도 있고, 매우 작은 역할을 한다면 장애가 있는지 인지조차도 못할 수 있습니다.

 

최근 발생했던 에러로그가 자바스크립트에 대한 문제라는 것을 알 수 있습니다.

URL을 접속하는데 있어서 10초의 지연이 발생하는 것을 확인할 수 있습니다.

 

이때 waterfall을 통해서 상세하게 볼 수 있습니다.

 

고객의 정보가 담겨있기에 모든 waterfall 정보를 보여드릴 순 없지만 아래와 같이 어떠한 부분에서 문제가 있었는지를 알 수 있습니다.

스크린샷에는 자세한 정보가 나와있지 않지만 실제로는 어떤 메소드를 사용했고 어떤 응답 코드를 받는지를 볼 수 있지만 자바스크립트 호출에 대해서 0B 라는 파일 크기를 받았다는 것은 원본 파일의 크기가 아무것도 없는 0B가 아니고서야 제대로된 응답을 받지 못했다는 것을 의미합니다.

 

자바스크립트를 제공하는 URL까지 알 수 있습니다.

 

https://unpkg.com/swiper/swiper-bundle.min.js 를 실제로 방문해보았을 때 해당 스크립트가 실제로도 읽히지 않는 다는 것을 알 수 있었습니다.

이때 홈페이지는 정상이 였지만 swiper-bundle.min.js 를 사용하는 홈페이지의 특정 기능에 문제가 있었고 이때문에 지연이 발생하는 것이였습니다.

 

또 다른 한건은 홈페이지에서 구글의 폰트를 사용하고 있었습니다.

 

그런데 그 구글폰트가 외부 URL을 통해서 사용될때 구글폰트를 제공하는 구글의 폰트 서버에서 일시적인 장애가 발생하여 구글의 폰트를 사용하는 고객의 홈페이지에 눈에 띄는 지연이 발생하였습니다.

 

WMS를 통해 장애를 예방하거나 빠르게 감지하는 것 뿐만 아니라 현재 웹 서비스의 성능에 대한 지표도 확인해 볼 수 있습니다.

 

WMS 뿐만 아니라 zabbix를 사용하여 URL을 모니터링하고 있지만 WMS 상품을 통해 매우 웹 서비스에 대한 장애를 판단하고 처리해야하는 방향성을 잡는데 매우 큰 도움이 됩니다.

 

그렇게 큰 비용이 들진 않지만 WMS와 같은 오픈 소스를 한번 찾아보고 싶을 정도로 웹 서비스를 모니터링하는데 큰 도움이 되는 상품입니다.