AWS Multipart 파일 업로드 시 403 오류 해결

개요

 요새 소프트웨어 마에스트로에서 프로젝트를 하느라 정신이 없다. 백엔드와 기타 잡무(...)를 맡아 불태우는 중이다. 저저번 주에 예비군을 갔다와서 몸살에 걸려 저번 주를 통째로 날렸지만 말이다... 시간도 없는데 이게 무슨 날벼락인지 모르겠다. 

 어쨌든 프로젝트 개발 과정에서 발생한 나름 큰 난관의 해결책을 한국어 웹에서 잘 찾아볼 수 없어서 여기에라도 남기려한다. 문제가 발생한 배경은 다음과 같다. 지금까지는 퍼블릭 서브넷에 있는 EC2의 퍼블릭 IP를 통해 스프링 서버에 API 요청을 보냈다. 

 하지만 아무리 개발 서버라고 해도 퍼블릭 서브넷에 스프링 서버를 두는 것은 좋지 않다. 게다가 오토스케일링이나 로드밸런서도 포함되어 있지 않았다. 그래서 다음과 같이 바꾸었다. 

 이런 식으로 구성하면 애플리케이션 로드밸런서를 통해 오토스케일링 되는 여러 스프링 서버에 골고루 요청할 수 있다. 하지만 여전히 문제는 남아있는데, ALB의 도메인을 그대로 노출시켜 사용해야 한다는 점이다. 여기엔 로드밸런서의 이름, 지역 등의 정보가 포함되어 있어 보안상 좋지 않고, 알아보기 어려워 편의성도 떨어진다. 그래서 Route53을 이용해 도메인을 구입하고 그 도메인의 A 레코드에 로드밸런서를 연결했다. 

 

 

파일 업로드 문제

 그런데 이 도메인으로 서버에 요청을 보낼 때 문제가 생겼다. 우리 서비스는 클라이언트가 이미지 파일을 서버로 전송해야 한다. 그래서 multipart/form-data로 이미지 파일을 전송하려는데 403 에러가 발생하는 것이었다. 

 문제는 이 오류가 스프링 출력이나 톰캣 로그에도 보이지 않았다는 것이다. 200이나 400, 500대 응답이 기대되는 요청을 보냈을 때는 다 남는데 이 경우에만 남지 않았다. 더욱 신기한 것은 multipart/form-data만 보내지 않으면 403이 아니라 500이 찍히고 서버 로그에도 뜬다는 것이다. 그래서 파일 업로드와 관련된 문제라고 판단했다. 

 스프링 서버 앞단에 Route53이나 ALB, 오토스케일러 등 많은 것들이 있기 때문에 스프링 문제인지 알고 싶었다. 동일한 스프링 서버를 퍼블릭 서브넷에 새로 생성하고 퍼블릭 IP를 주었을 때는 그 IP로 동일한 요청을 보내면 정상적으로 요청을 처리하는 것을 보았다. 그러니 스프링은 문제가 없었던 것이다. 

 Route53은 단지 도메인으로 라우팅만 해줄 뿐이니 문제일 가능성이 낮았고, 가장 의심되는 곳은 실제 트래픽을 관리하는 ALB였다. 하지만 내가 알기론 ALB는 단지 라운드로빈으로 트래픽을 분산시켜주기만 할 뿐 다른 일은 하고 있지 않았다. 

 그렇게 며칠을 머리 뜯으며 디버깅한 결과...

 

ALB WAF 설정

 ALB를 만들면서 처음엔 퍼블릭으로 접속할 수 있도록 했다. 이 과정에서 기본 제공해주는 방화벽인 디폴트 WAF를 연결했던 기억이 났다. 그래서 WAF를 키워드로 좀 찾아봤더니 이런 답변을 찾을 수 있었다. 

 nginx(질문자의 웹서버)가 HTTP 요청을 받지 못하는 것을 보면 ALB 같이 그 앞단에 있는 것들의 WAF가 이를 막고 있는 것 같다는 내용이다. WAF는 기본적으로 8KB 이상의 요청은 허용하지 않는다는 것이다. 번뜩 놀라 현재 서버의 WAF 설정을 찾아봤다. 

 AWS WAF에는 AWSManagedRulesCommonRuleSet이라는 규칙 모음이 있는데, 여기에서 잘 찾아보면 다음과 같은 규칙을 볼 수 있다. 

 저 규칙 중 SizeRestrictions_BODY가 바로 HTTP 요청의 바디가 8KB를 넘어갈 경우를 제어하는 규칙이다. 사진처럼 허용으로 바꿔주면 이제 8KB가 넘는 요청도 정상적으로 스프링 서버로 전달된다. 실제로 이를 바꾸고 나서 이미지 업로드 요청은 의도한대로 작동하였다. 

403 응답이 아니라 정상적인 200 응답이 온 것을 알 수 있다. 이후 스프링 서버 로그에서도 요청과 응답을 찾아볼 수 있었다. 

 

느낀 점

 항상 그렇다시피 문제가 생기면 언제나 문제의 원인을 차근차근 좁혀보자. 그러다보면 키워드가 나오고 언젠가 해결할 수 있다.