AWS 주니어 코딩 기술면접
새 면접Q. Lambda 함수에서 SES(Simple Email Service)를 사용하여 이메일을 발송하는 기능을 구현하려고 합니다. 발송 실패 시 재시도 로직과 실패 이메일 로깅을 포함한 코드 구조를 설계할 때 고려해야 할 사항과 구현 방법을 설명해주세요.
SES의 sendEmail API를 try-catch 블록으로 감싸고, 실패 시 exponential backoff 방식으로 재시도 로직을 구현합니다. 재시도 횟수는 환경변수로 관리하고, 최종 실패 시 DynamoDB나 CloudWatch Logs에 실패 내역을 기록합니다. 이메일 발송 상태는 SES의 반환 MessageId를 통해 추적하고, IAM Role에 SES 발송 권한(ses:SendEmail)을 부여해야 합니다. 대량 발송 시에는 SES의 발송 할당량(quota)을 체크하는 로직도 추가하는 것이 좋습니다.
- • try-catch와 exponential backoff를 이용한 재시도 로직 구현
- • 실패 로그를 DynamoDB 또는 CloudWatch에 저장
- • IAM Role에 ses:SendEmail 권한 부여 필수
- • SES 발송 할당량 체크 및 MessageId를 통한 추적
SES의 발송 할당량을 초과했을 때 어떻게 대응할 수 있으며, SQS를 활용한 이메일 발송 큐 시스템은 어떻게 설계할 수 있을까요?
Q. 매일 자정에 DynamoDB 테이블의 만료된 데이터를 자동으로 삭제하는 배치 작업을 구현하려고 합니다. EventBridge와 Lambda를 조합할 때 배치 삭제 코드의 효율적인 구조와 처리해야 할 예외 상황을 설명해주세요.
EventBridge에서 cron 표현식(cron(0 0 * * ? *))을 사용하여 매일 자정에 Lambda를 트리거합니다. Lambda 함수에서는 DynamoDB의 Query 또는 Scan으로 만료 대상을 조회하고, BatchWriteItem을 사용하여 최대 25개씩 삭제합니다. 대량 데이터의 경우 페이지네이션을 구현하고, Lambda의 최대 실행시간(15분)을 고려하여 처리량을 조절해야 합니다. 삭제 실패 항목은 별도로 기록하고, CloudWatch 메트릭으로 삭제된 항목 수를 전송하여 모니터링합니다.
- • EventBridge cron 표현식으로 스케줄링
- • BatchWriteItem으로 25개씩 배치 삭제 처리
- • Lambda 15분 제한 고려한 페이지네이션 구현
- • 삭제 실패 항목 로깅 및 CloudWatch 메트릭 전송
Lambda의 15분 제한 때문에 모든 데이터를 처리하지 못할 경우, Step Functions를 활용한 장기 실행 배치 작업은 어떻게 설계할 수 있을까요?
Q. 실시간 로그 데이터를 Kinesis Data Streams로 수집하고 Lambda로 처리하는 시스템을 구현할 때, 레코드 처리 실패와 순서 보장을 위한 코드 구조를 어떻게 설계해야 하나요?
Lambda는 Kinesis 레코드를 배치로 받아 처리하며, 하나라도 실패하면 전체 배치가 재처리됩니다. 부분 실패를 처리하기 위해 bisectBatchOnFunctionError 옵션을 활성화하여 배치를 반으로 나눠 재시도합니다. 순서 보장이 필요한 경우 파티션 키를 동일하게 설정하여 같은 샤드로 전송하고, Lambda 함수에서는 시퀀스 넘버를 확인합니다. 처리 실패한 레코드는 DLQ(Dead Letter Queue)나 별도의 S3 버킷에 저장하여 추후 분석합니다.
- • bisectBatchOnFunctionError로 부분 실패 처리
- • 파티션 키로 샤드 할당 제어하여 순서 보장
- • 시퀀스 넘버 확인으로 순서 검증
- • 실패 레코드는 DLQ 또는 S3에 저장
Kinesis Data Streams의 샤드 수를 동적으로 조정해야 할 때 어떤 지표를 모니터링하고, 어떻게 스케일링을 수행해야 하나요?
Q. API Gateway와 Lambda를 연동할 때 Lambda 함수가 반환해야 하는 응답 형식과 HTTP 상태 코드를 설정하는 방법을 설명하고, CORS 에러를 해결하기 위한 헤더 설정 방법을 설명해주세요.
Lambda 함수는 statusCode, headers, body를 포함한 객체를 반환해야 합니다. statusCode는 200, 400, 500 등 HTTP 상태 코드를 숫자로 지정하고, body는 JSON 문자열로 변환하여 전달합니다. CORS 문제 해결을 위해 headers에 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers를 포함시킵니다. API Gateway에서도 CORS를 활성화하고, OPTIONS 메서드에 대한 응답을 설정해야 브라우저의 preflight 요청을 처리할 수 있습니다.
- • statusCode, headers, body 포함한 객체 반환
- • body는 JSON.stringify()로 문자열 변환
- • CORS 헤더(Access-Control-Allow-Origin 등) 설정
- • API Gateway에서 CORS 활성화 및 OPTIONS 메서드 설정
API Gateway의 Lambda 프록시 통합과 Lambda 사용자 지정 통합의 차이점은 무엇이며, 각각 어떤 상황에서 사용하는 것이 적절한가요?
Q. S3 버킷에 이미지가 업로드되면 Lambda가 자동으로 썸네일을 생성하여 다른 버킷에 저장하는 시스템을 구현할 때, 무한 루프를 방지하고 여러 이미지 형식을 처리하는 코드 로직을 어떻게 설계해야 하나요?
S3 이벤트 알림을 소스 버킷에만 설정하고, 썸네일은 다른 버킷에 저장하여 무한 루프를 방지합니다. 또는 같은 버킷을 사용할 경우 prefix나 suffix 필터링(예: uploads/ 폴더만 트리거)을 적용합니다. Lambda 함수에서는 event.Records를 순회하며 S3 객체 키와 버킷명을 추출하고, 파일 확장자를 확인하여 jpg, png, gif 등 지원 형식만 처리합니다. 이미지 처리 라이브러리(Pillow, Sharp 등)를 Lambda Layer로 추가하고, 처리 실패 시 원본 파일 정보를 로깅합니다.
- • 소스와 대상 버킷 분리 또는 prefix/suffix 필터링으로 무한 루프 방지
- • event.Records에서 버킷명과 객체 키 추출
- • 파일 확장자 검증으로 지원 형식만 처리
- • 이미지 처리 라이브러리를 Lambda Layer로 추가
대용량 이미지 파일 처리 시 Lambda의 메모리와 타임아웃 제한을 초과할 경우, ECS나 Batch를 활용한 대안 아키텍처는 어떻게 설계할 수 있을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!