서버리스로 전환하면서 얻은 교훈

간단한 이미지 공유 데모 앱인 serverless variant of imgn 에서 작업할 때 API 게이트웨이 및 AWS Lambda를 사용하여 다중 파트 양식 데이터POST 요청을 처리하는 것과 관련된 문제에 직면했습니다. 이 게시물은 내가 어떻게 해결했는지 보여줍니다.
imgn 앱은 정말 간단합니다. 이미지 파일을 업로드한 다음 공개 갤러리에서 볼 수 있습니다. 백그라운드에서 일부 이미지 메타데이터(지금은 치수만)를 추출하여 이미지와 함께 표시합니다.


imgn의 서버리스 변형을 개발하는 동안 API 게이트웨이를 통해 Lambda 함수를 사용하여 이미지를 S3에 업로드하는 맥락에서 문제가 발생했습니다. StackOverflow에서 문제 설명을 자세히 읽을 수 있지만 핵심은 다음과 같습니다. API 게이트웨이가 Lambda 함수에 전달하는 페이로드가 어떻게든 도살되어 이미지가 각각의 위치에 도착하면 손상됩니다. S3 버킷.

이 SNAFU가 발생하는 범위를 좁히기 위해 먼저 http.request를 생성하고 ParseForm 메서드를 사용하여 parsing the multipart form-data의 자체 구현으로 이미지 데이터에 도달하는 초기 코드를 교체했습니다. 그래도 부정부패는 그대로였다.

다음으로 "S3 버킷에 업로드"부분을 데이터 손상의 주범으로 제외하기 위해 Lambda 호출 결과 API Gateway에서 받은 파싱된 이미지 데이터를 반환했습니다. 이를 통해 hexdump를 사용하여 결과 파일을 원본과 비교할 수 있었지만 여전히 bueno는 없습니다. 문제는 지속되었습니다.



요청 경로에 남은 유일한 것은 API 게이트웨이에서 Lambda 함수로의 (바이너리) 이미지 데이터의 핸드오버였습니다.

StackOverflow를 검색하고 AWS 포럼에서 겉보기에 관련이 있어 보이는 게시물을 많이 읽은 후, 다른 접근 방식이 필요하다고 판단했습니다. 나는 pre-signed URLs을 읽고 이것을 시도하기로 결정했습니다. 이러한 미리 서명된 URL을 사용하면 사람들이 S3 버킷의 객체를 조작하도록 허용할 수 있으며 어떤 작업, 어떤 객체에 대한 작업 및 허용 기간에 대한 제한을 설정할 수 있습니다.

따라서 아이디어는 사용자가 UI를 통해 다중 파트 양식 데이터POST 요청을 발행할 때 UploadImageFunction가 이미지를 S3에 직접 업로드하지 않고 PUT 요청에 대해 pre-signed URL을 생성한다는 것입니다. S3 버킷, 이전 양식 데이터POST 요청에서 참조된 파일에 유효하고 5분으로 제한됨:

req, _ := s3c.PutObjectRequest(&s3.PutObjectInput{
        Bucket: aws.String(gallerybucket),
        Key:    aws.String(imgname),
})
presurl, err := req.Presign(5 * time.Minute)

... UI의 JavaScript code은 미리 서명된 URL을 사용하여 이미지를 S3 버킷에 직접 업로드하는 두 번째PUT 요청을 발행합니다. 그리고 그것은 매력처럼 작동합니다!

이 전략을 해킹 또는 모범 사례로 인정해야 하는지 여전히 확신이 서지 않으며 다른 서버리스 실무자의 의견을 듣고 싶습니다.