배경
2024년 4월 26일 큐리어슬리 회사를 다닐 때였다.
고객사에서 동영상 강의실이 열리지 않는다는 연락을 받았다.
하지만 고객사의 강의실에는 아무 문제가 없었는데 알고 보니 특정 강의에서만 발생한 현상이었다.
해당 강의는 1개의 챕터(묶음)에 동영상 128개가 포함돼 있고 목록리스트를 불러와야 했다.
예전에 테스트 했을 때는 속도도 빠르고 이상이 없었는데 이상했다.
문제파악
[문제 지점 파악]
API response로 403 코드가 전달됐고 특별한 메시지는 없었던 것으로 기억한다.
(시간이 지나서 기억이조금 가물하니 이해 부탁드립니다)
그리고 CloudWatch 로그를 확인해보니 API Gateway 에 로그는 남아 있었다. 하지만 리소스를 불러오는 서버에대한 로그는 없었다.
위와 같은 구조의 요청 순서로 리소스를 요청했었다. Bckend Inventory Server 까지의 로그는 있고 이 서버에서 Hub Server로 가는 요청 로그가 없었다.
[문제 분석 세분화]
우선 다른 리소스들을 잘 가져오는 걸로 봐서 코드에 이상이 있는 것은 아니었다. Timeout 문제도 아니었다.
같은 강의의 동영상 리소스 요청만 따로 떼어 내서 개수를 줄여보았다. 성공이었다.
Query Parameter로 인해 url 길이가 문제였다고 파악하였다.
[API Gateway가 범인인줄 알고 헛다리]
하지만 이상했다. 분명 몇주전까지는 이상이 없었던 API 였다. 이 당시에는 경황이 없어서 API Gateway쪽이 문제일거라 생각하고 추가된 옵션이 있는지 기본 허용 url 길이는 몇바이트인지 찾았다.
https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/limits.html
최대 길이가 8192자 약 8kb 는 됐기 때문에 전혀 문제가 되지 않음을 발견했다.
[WAF 등장!!]
몇주전 WAF가 설정됐었다는 이야기를 이사님과 동료들에게 전해 들었다.
이 단계중 Hub Server를 관장하는 API Gateway에 대해 WAF가 최근에 걸렸다고 한다.
어쩌면 WAF가 범인이라는 생각에 관련된 제한 사항이 있는지 찾아보았다.
https://docs.aws.amazon.com/ko_kr/waf/latest/developerguide/aws-managed-rule-groups-baseline.html
기본룰로 2,048바이트인경우 제한하는 룰이 등장했다. 너무 작은거아닌가...
문제해결
빠른 서비스 정상화를 위해서 당일은 리소스를 조회하는 API를 100개씩 Chunking 하여 조회하게 했고
WAF 담당자에게 해당 사실을 알린뒤 Size 조정을 요청해 이후 쿼리 파라미터 길이가 문제되는 경우는 없었다.
댓글