IL-0584 Monicle · 2024-12-04 (게시일)gcpnetworking
Cloud CDN 이 서일본 사용자에게 손상된 JavaScript 파일을 내보내 일부 사용자의 SPA 가 SyntaxError 로 멈췄다
Monicle 은 Google Cloud 의 Cloud Load Balancing 과 Cloud CDN 을 앞에 두고 Cloud Run 을 백엔드로 서비스를 제공했다. 애플리케이션은 SPA 였고, 큰 JavaScript 파일과 초기 데이터 일부를 SSR 한 HTML 을 내보내며 GraphQL 로 API 를 제공했다. 2024년에 일부 사용자가 시스템을 쓸 수 없다고 알려 왔고, 대상 제품과 영향 범위를 보고 바로 워룸을 열었다. 서일본 사용자의 브라우저에서 SPA 가 SyntaxError 로 멈췄고 동일본 사용자는 영향이 없었다.
개발팀이 Cloud Run 컨테이너 이미지를 다시 만들어 배포했지만 복구되지 않았다. 오키나와에 있던 개발자가 문제를 재현해 JavaScript 파일을 받아 냈고, 파일을 눈으로 훑어 같은 코드가 두 번 들어 있는 등 파일이 손상된 것을 찾았다. 컨테이너 안의 파일은 정상이었다. Cloud CDN 의 오리진이 도쿄의 NRT 일 때는 재현되지 않고 오사카의 KIX 일 때 재현돼서 팀은 먼저 Cloud CDN 캐시를 퍼지했다.
조사를 이어 가던 팀은 Cloud Load Balancing 에서 Cloud CDN 은 켜 두었지만 콘텐츠 압축은 꺼져 있다는 것을 발견했다. 팀은 문제가 Cloud Load Balancing 과 Cloud CDN 사이의 데이터 전송이나 Cloud CDN 캐시 저장소에 쓰는 과정에 있다면 압축이 어떤 식으로든 영향을 줄 수 있다고 봤다. 그래서 compression_mode 를 켰다. 그 뒤 사용자 쪽에서도 시스템이 정상으로 동작해 장애가 끝났다. 압축으로 JavaScript 파일의 전송량이 줄어 화면이 빨라졌다는 의견도 받았다. 팀은 조사 중에 Issue Tracker 와 Cloud Forums 도 찾아봤지만 관련된 정보는 없었다. 결과적으로 압축을 켠 것이 문제를 없앴다.
- 심각도
- –
- 영향 범위
- A single-page app served through Cloud Load Balancing and Cloud CDN stopped working in the browser with a SyntaxError for some users
- 영향 사용자
- Some users in western Japan
- 지역
- Western Japan (Cloud CDN at KIX, Osaka)
- 감지까지
- –
- 복구까지
- –
증상
일부 사용자가 시스템을 쓸 수 없다고 알려 왔다. 그 사용자들의 브라우저에서 SPA 가 SyntaxError 를 내며 동작하지 않았다. 동일본 사용자는 문제가 없었고 서일본 사용자만 영향을 받았다.
시스템이 내보내는 JavaScript 파일이 손상돼 있었다. 같은 코드가 파일 안에 두 번 들어 있는 식이었다. 컨테이너 이미지 안의 같은 파일은 정상이었다. 팀은 로그에 적힌 파일 크기 같은 값을 보고 CDN 을 의심했다.
개발팀은 처음에 Cloud Run 의 컨테이너 이미지를 의심했다. 이미지를 다시 만들어 배포하고 문제가 될 만한 이미지를 조사했지만 복구되지 않았고 원인도 나오지 않았다. 마침 오키나와에 머물며 일하던 개발자가 문제를 재현했다. 그 개발자는 원인이 SPA 가 쓰는 JavaScript 파일에 있다는 것을 찾아 그 파일을 받아 냈다.
Cloud CDN 의 오리진이 도쿄의 NRT 일 때는 문제가 재현되지 않았고 오사카의 KIX 일 때는 재현됐다.
증상 응답 품질 저하
원인
원인 클라우드 제공자 장애
- 촉발
- –
감지
일부 사용자가 시스템을 쓸 수 없다고 알려 와서 알았다. 대상 제품과 영향 범위를 보고 바로 워룸을 열었다.
조치
- Cloud CDN 의 오리진이 도쿄의 NRT 일 때는 재현되지 않고 오사카의 KIX 일 때 재현돼서 우선 Cloud CDN 캐시를 퍼지했다.
- Cloud Load Balancing 에서 꺼져 있던 Cloud CDN 의 콘텐츠 압축을 compression_mode 로 켰고, 그 뒤 사용자 쪽에서 시스템이 정상으로 동작했다.
후속 조치
- 서비스 운영에서 단일 장애 지점이 된 곳을 파악해 두고, 비용을 감당할 수 있으면 그런 곳을 없앤다. PaaS 와 SaaS 에서 난 장애에도 기민하게 대처할 수 있게 준비한다.
교훈
글쓴이는 이 장애에 맞춘 구체적인 대책은 아직 없다고 했다. 대신 서비스 운영에서 단일 장애 지점이 된 곳을 파악해 두고, PaaS 나 SaaS 에서 난 장애에도 기민하게 대처할 수 있도록 준비해야 한다고 정리했다.
출처
관련 사례
같은 원인 · 공통 CDN 과 엣지 네트워크
같은 원인 · 공통 CDN 과 엣지 네트워크
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0584
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0584/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.