개발과 일상

이전 글에는 문제가 있다. 현재 DDB Table에는 이미 3천개 이상의 데이터가 쌓여있고, 앞으로 꾸준히 데이터가 쌓일 예정이다. 그런데 조회 쿼리 ScanCommand를 사용했다. 이 조회 방식은 언젠가 문제를 일으킬 것이다. 어떤 문제인지는, AWS의 DDB 스캔 사용 모범사례를 보면 알 수 있다. 일반적으로 Scan 작업은 DynamoDB의 다른 작업보다 비효율적입니다. Scan 작업은 항상 전체 테이블이나 보조 인덱스를 스캔합니다. 그런 후 값을 필터링하여 원하는 결과를 얻기 때문에 결과 세트에서 데이터를 제거해야 하는 단계가 추가됩니다. 가능한 경우, 대용량 테이블 또는 인덱스에서 필터를 사용해 다수의 결과를 제거해야 하는 경우에는 Scan 작업을 최대한 피하는 것이 좋습니다. 여기에 테이블이..

상용 배포를 앞두고, dev 서버에서 잘 동작하던 Lambda에서 문제가 발생했다. Dynamo DB(이하 DDB) 조회해서 데이터의 존재여부를 검증하는데, 분명 조회 데이터가 존재하는데도 Count가 계속 0으로 찍히는 문제였다. dev에선 분명히 잘 동작했고 prod에서도 에러가 나지 않았기 때문에, 오류를 찾기가 너무 힘들었다. 커넥션이 올바르게 되고 있는지부터 쿼리가 올바른지, 로직에 문제가 없는지 다 검증해봤는데, 의외의 곳에서 실마리를 얻었다. prd DDB에 저장된 데이터는 3000개 이상이었는데, 위 조회 방법으로 조회하니 ScannedCount가 709개로 나왔다. 여기서부터 문제가 있음을 인지하게 되었다. 조회 쿼리를 날렸을 때 결과물이 아래와 같이 나왔다. { '$metadata': ..