외부 툴 호환성 테스트
간만에 터졌다
서비스가 정말 오랜만에 불능이 되버렸다. 더 간만인것은 내가 감지하지 못한 에러라는 것이다. 사실 너무 안이한 배포를 진행했던 탓이었던 것 같다. 그날의 사건의 흐름을 거슬러 올라가보자.
설날 배포와 외부 의존성
다들 명절 음식 맛있게 드시고 주무시던 새벽에 나는 시골에서 코드를 뚱땅뚱땅 중이었다. 중요한 이벤트에 맞게 코드 배포가 나가야해서 이리저리 수정 후 배포를 진행했다.
문제는 나도 명절이라 마음이 풀렸는지, 새벽이라 졸린건지 테스트코드 통과하길래 배포하고 즐거운 마음으로 다시 서울로 올라왔다. 문제는 내 코드 이외의 영역을 테스트 해봍 생각조차 안했다.
이게 무슨 말이냐면, 내 서비스는 모종의 사건들로 인해 필연적으로 외부 확장 프로그램들에 의존하는 구조로 변했다. 간략하게만 설명하자면, 기존에는 여러 위성 이미지를 재가공해서 넓은 하나의 지도 이미지로 파일화 시켜주고 있었는데 이게 약관 위반이었다. 재가공도 금지고, 파일화도 금지여서 현재는 이런 과정들을 유저에게 전부 위임한 상태이다.
나는 넓은 지도 이미지를 렌더링 해주는 것 까지만 제공하고, 유저는 크롬 외부 확장프로그램 같은 것을 사용해서 직접 이미지 파일을 만들어야 한다. 이 과정에서 간편하게 화면 전체를 캡쳐해 주는 툴들인 Full page screen capture나 fireshot와 같은 외부 툴에 많이 의존하게 되었다. 어떻게 보면 약관 위반을 피하기 위한 꼼수이다.
문제는 저런 외부 툴들이 당연히 잘 작동할 줄 알고 테스트를 전혀 안한채 배포를 해버렸다.
인지, 재배포
결국 내 마지막 모니터링 체계는 유저 문의다. 정말 여기까지는 최대한 안오게 하려고 온갖 툴들을 다 붙여놨던 것인데, 결국 와버렸다.
일단 최근 배포 후에 문제가 발생한 것이니 바꾼 내용들을 다 롤백 후 다시 배포했다. 그리고 문제의 원인을 하나씩 찾아보기 시작했다.
about:blank
에러가 났던 배포에 레이트 리미터를 도입했다. 그 전까지는 프론트단에서 바로 지도 템플릿 생성이 가능한 형태였다. 사실 지금까지의 운영 경험에 미뤄봐서는 큰 문제가 없는 구조이기는 하다. 하지만 과다 호출로 경고 메일 받은것도 있고, 누가 마음먹고 마구잡이로 호출하면 구글 지도 같은건 유료라서 호출할 때 마다 과금이 카운팅된다. 물론 지도 api단에서 최대 호출량을 지정해 놓긴 했지만, 누군가 스크립트 돌려서 몇분만에 하루치 사용량을 다 써버리면 다른 유저들은 아무것도 사용하지 못하는 상황이 되어버리니 겸사겸사 공부도 할겸 도입을 해봤다.
문제는 렌더링 방식이 문제였다. 프론트 단에서 빈 html 페이지를 띄우고, 서버에서 받아온 좌표값 설정이 완료된 html 페이지를 내부에 띄워서 유저에게 서빙하고 있었는데 이 때 빈 html 파일이 about:blank 주소로 띄워졌다.
크롬 브라우저, 꼭 크롬 뿐만이 아니라 대부분의 브라우저가 비슷할 것 같은데 chrome://, about:blank, file://과 같은 url들은 보안 문제로 확장 프로그램의 실행을 제한한다고 한다. 그래서 html 구조가 아무리 완성되고 컨텐츠가 띄워졌다 하더라도 외부 툴 자체가 작동을 안했다. 서비스를 사용하는 플로우는 동일하고 내부적인 로직만 변경된 것이기 때문에 유저들 입장에서는 ‘갑자기 야가 왜이래?’ 싶었을 것 같다.
그래서 어떻게 할까 생각을 하다가, 그냥 서버쪽 지도 템플릿 url로 리다이렉트를 시켜버렸다. 지금 생각하면 이걸 굳이 왜 별도로 받아와서 다른 html에 꾸겨넣으려고 했는지 잘 모르겠다. 새벽에 코드짜다보니 피곤했나 보다.
이걸 어떻게 방지, 감지해야 하나?
예전에도 cdn 같은걸로 불러오는 외부 라이브러리나 서버에 다운로드하기 힘들고 url로 불러올 수 밖에 없는 구글 애널리틱스 같은 라이브러리들에서 에러가 나면 어떻게 대처해야 할지 고민을 했던 적이 있다. 이런 곳에서 에러가 나면 평소에 나지 않던 에러라 센트리로 바로 잡히기 때문에 어느정도 감지가 쉽긴 하다.
그러나 아예 제어권이 외부 툴에 있는 이런 상황에서는 어떻게 에러를 방지해야 할 지 아직도 잘 모르겠다. 지금 생각하는건 셀레니움같은 웹 ui 에 접근할 수 있는 툴로 테스트를 하나 짜야되나 싶다. 어떻게 보면 유저 플로우와 동일하게 구성할 수 있기 때문에 사전에 예방할 수 있는 가장 확실한 방법 중 하나가 아닐까 싶다.
이런식으로 방지까지는 어느정도 구상을 해봤는데, 아무리 생각해도 감지를 어떻게 할지는 글을 쓰는 이 순간까지도 모르겠다. 게다가 워낙 특이한 케이스라 이건 그냥 방지를 잘 하는 쪽으로 포커즈를 맞춰봐야겠다.
솔직히 내가 배포전에 개발 서버에서 몇 번 딸깍딸깍만 해봤어도 발생하지 않았을 일이긴 하다. 요즘 배포할 때 서비스 안정성에 너무 무던해졌나 보다. 신경 좀 더 써야겠다.