CloudFront, Error Cache 삽질기

최근에 나에게 있었던 삽질기를 다른 사람은 겪지 않기를 바라며 글을 적어본다.

내가 다니고 있는 회사에서 신규 API서버를 오픈하였는데, AWS CloudFront(이하CF)를 붙여서 서비스를 오픈하였다.

이 API 서버는 결과가 있다면 200 OKAY 없으면 404를 주는 매우 간단한 서버였다.

그리고 서비스를 배포하고 실서버에서 최종 테스트를 해보고 있는데, 테스트 서버에서 발생하지 않는 문제가 AWS CloudFront의 설정 미스로 인하여, 실 서버에서 발생하는것이었다.

이 글은 그 이슈를 해결 한 이야기이다.

결과가 디비에 있는데 왜 실서버는 결과를 안주지?

QA조직에서 데이터를 올렸으나, 결과가 나오지 않는다 라는 이야기를 듣고 확인을 해보았다.

분명 DB에는 있다.. 진짜 있다.. 정말 있는데, 실제 서버에서 응답이 안오는것이없다.

무슨 문제가 생겼는가 하고 로컬에 더미 데이터를 넣어서 테스트도 해보고 다 해보았지만.. 테스트 서버의 결과에서는 200 OKAY였지만, 실 서버에서만 404결과가 나오고 있는것이었다.

엄청난 멘탈붕괴가 발생하는 이 시점에 문득 머리속에서 Invalidation을 한번 해봐야겠다. 라는 생각이 들었다.

Invalidation을 날리고, 다시 확인을 해보니 놀랍게도 결과가 정상적으로 내려오는것이었다.

AWS CloudFront가 Cache 하는 방법

처음에 내가 생각했던 Cache 전략은 100 ~ 3xx (HTTP 성공)에 대한 결과만 Cache 할것이라고 무의식적으로 생각 하고 있었다.

하지만, 내가 생각했던 방식과 달랐던것이 이 문제의 시발점이었다.

일단 기본적으로 아마존은 Origin 서버에서 응답을 모두 Cache 하게 된다.

이뜻은 결론적으로 400 ~ 5xx (오류 or 실패) 역시 Cache 되어버린다는 뜻이다.

위에서 이야기 했던것처럼, 내가 만든 API서버는 처음에는 404의 결과가 나오다가 데이터가 들어오면 200으로 바뀌는 서버다.

당연히, 처음 요청했을때 404를 CloudFront가 Cache하기 때문에 MAX TTL 시간이 지날때까지 결과는 404로 Cache되게 되는것이다.

AWS CloudFront에서 Error Status Code에 대한 Cache전략 변경 방법

How CloudFront Processes and Caches HTTP 4xx and 5xx Status Codes from Your Origin - Amazon…
Describes how CloudFront processes and caches HTTP status codes for when errors occur.docs.aws.amazon.com

해당 이슈를 해결 하기 위하여, 구글을 통해 검색을 해본 결과 역시나 많은 사람들이 나와 비슷한 이슈로 삽질을 하고 있었다.

이제 이 문제를 해결 할 방법을 정리 해보면, 우선 CF설정으로 들어간다.

그리고 상단 탭중 “Error Pages” 탭을 선택하고 Create Custom Error Response를 클릭한다.

그럼, 정책을 변경할 Error Status Code와 Cache TTL을 지정할수있게 된다.

이렇게 되면 Error를 Cache 하는 문제를 해결 할 수 있다.

마치며

사실 처음에 되게 당황스러운 이슈였다. 분명 디비에 결과가 있는데 결과가 없다고 하는 메세지가 나오고 있었기 때문이다.

하지만, 처음에 서버의 아키텍처를 설계 했을때, CF에 대해 조금만 더 깊게 알아봤으면 이런 이슈는 없었을것같은데, 이 부분에 대해서는 앞으로 조금 더 조심해야 할 부분이라고 생각된다.

어쨌든, 나와 같은 이슈를 겪는 사람이 이 글을 보고 명쾌하게 해결 했으면 하는 바램과 함께 이 글을 마치겠습니다.