업무를 하던 중 요상한 버그가 발견되었다.
퍼블릭으로 "읽기"가 권한이 설정된 S3 버킷 내 이미지를 외부 api 보냈을때, 외부 사이트에서 우리쪽 S3이미지를 조회할때 403 에러가 난다는것이다.

언제부터 해당 이슈가 발생했는지는 파악이 어려우나, 갈수록 이슈 발생률이 높아져 상품등록 10개중 9개가 실패하는 지경에 이르렀다.

간헐적으로 성공하기도 하여, 우리쪽 문제가 아니라 판단했지만 이슈의 발생 정도가 너무 빈번하여 우리쪽 유저의 불편사항이 날로 커지고 있어서 원인 파악에 착수했다!

우리쪽 문제가 아니지만,
상대쪽 스펙으로 인해 우리쪽 버그가 되는 경우...........

1. S3 액세스 로그 활성화

먼저 해당 S3이미지 접근시 상황을 파악하기 위해 S3 액세스 로그를 살펴보고자 한다.

그러나 활성화가 되어있지 않다!

먼저 S3호출시 상황을 파악하기 위해 "액세스 로그" 활성화를 지정한다.
// 활성화 하는 법

2. AWS athena 사용

액세스 로그가 저장되는 버킷의 내용을 살펴보려고 하는데..
이거 일일히 하나하나 열람하는게 영 보통일이 아니다.

보다 효율적으로 저장된 로그를 파악하는 방법을 찾아보다가 aws 공식문서에서 "athena"를 지원함을 알수 있었다.

3. 공백이 포함된 S3 객체명

객체 자체에는 문제가 없음이 확실하기에, 동일한 객체인데도 어떨때 403 에러가 발생하는지 찾아보았다.
aws 공식문서에 따르면 객체의 이름이 정확하지 않을때 404 에러가 아닌 403 에러가 반환된다고 한다.
// 403 에러난다는 문서 캡쳐본

실제로 postman을 통해 객체명 뒤에 "공백"을 하나 추가하여 호출하니 Access Denied가 발생했다.

오류가 발생한 외부 api는 json 형태로 데이터 처리 후, xml형태로 변환하여 utf-8로 인코딩 하여 byte 형태로 데이터를 전송하고 있다.
즉, byte 형태의 데이터를 해당 외부 사이트에서 가공하여 다시 우리쪽 s3이미지를 호출할때, 가비지 캐릭터가 추가된건 아닐까 하는 의심이 생겼다.

간헐적으로 통신요청이 성공할때와 그렇지 않을때 요청보낸 데이터에 어떠한 차이가 있는지 파악이 필요하다.