리포트 서빙을 CDN 직결로 바꾸고 서버를 걷어내려 했다. 리포트 데이터는 브라우저에서 CDN으로 직접 간다는 통념이 있었고 그것이 정말인지 확인하기로 했다.
Table of contents
Open Table of contents
전수로 센 호출
프런트 스크립트에서 외부 호출을 전부 찾으니 일곱 건이었다. 라인 번호를 적어 하나씩 열어 봤다.
CDN이냐 서버냐를 가르는 분기는 리포트 키가 있으면 CDN 주소를 앞에 붙이고 없으면 같은 출처로 보내는 형태였다. 그 게이트가 걸린 곳은 월별 데이터를 미리 불러오는 함수 한 군데뿐이었다.
게이트가 없는 호출들
다른 호출들은 그 분기 없이 그냥 서버 경로로 가고 있었다. 같은 데이터를 부르는데 한쪽은 게이트를 타고 한쪽은 안 타는 상태였다.
나중에 추가된 코드가 앞의 패턴을 안 따랐거나 앞의 것에만 나중에 게이트를 붙인 것으로 보인다. 게이트가 있으면 다 있을 것이라고 가정한 것이 틀렸다.
서버에 의존하는 세 경로
전수로 세니 브라우저가 서버에 의존하는 경로가 셋이었다. 추세행 지연 로드와 리포트 키 발급과 월 인덱스다.
두 번째가 특히 아이러니했는데 CDN을 쓰려면 키가 필요한데 그 키를 서버에서 받는다. 서버를 걷어내면 키를 못 받고 그러면 게이트가 있는 곳도 CDN으로 안 가므로 의존이 순환처럼 얽혀 있었다.
조용히 죽는 실패
통념대로 걷어냈으면 셋 다 실패한다. 그중 추세행 쪽이 특히 나빴는데 실패를 빈 처리로 삼키고 있었다.
응답이 실패해도 예외가 안 뜨고 콘솔에도 안 남으므로 추세행이 그냥 안 나온다. 사용자는 데이터가 없나 보다 하고 넘어가고 몇 주 뒤에야 누가 이상하다고 말한다. 삼키더라도 흔적은 남겨야 조사할 때 보인다.
흐름과 체크리스트
전수 조사하면서 초기화 흐름을 순서대로 적었다. 키를 받고 월 목록을 받고 월별 데이터를 병렬로 로드한 뒤 렌더하는 순서다.
순서를 그리니 의존이 보였는데 키를 못 받으면 그다음이 전부 막힌다. 결론은 서버를 대체할 때 이 세 경로를 함께 이관해야 하고 게이트가 없는 곳에는 새로 넣어야 한다는 것이었다. 작업이 서버를 걷어낸다는 말에서 이 셋을 어디로 옮긴다는 말로 구체화됐고 통념 위에서 무언가를 걷어낼 때 그 통념을 확인하는 시간은 대부분 값어치를 한다.
정리
- 알려져 있다는 말을 확인한다
- 그 위에서 무언가를 걷어낼 때는 특히 그렇다
- 게이트가 한 곳에 있다고 다 있는 것이 아니다
- 호출을 전수로 센다
- 키를 서버에서 받으면 CDN 전환에 서버 의존이 남는다
- 실패를 빈 처리로 삼키면 조용히 안 나올 뿐이다
- 초기화 흐름을 순서대로 그리면 의존이 보인다
- 삼키더라도 흔적은 남긴다