DVA-C02는 클라우드 인프라 지식뿐만 아니라, 실제로 코드를 작성해서 AWS 서비스를 다루는 방법까지 묻는 개발자 시험입니다. 이 글에서는 개발자가 AWS 서비스와 소통하는 방법(SDK), 메시지를 주고받는 방법(SQS), 실시간 데이터를 처리하는 방법(Kinesis)을 초보자 눈높이에서 설명합니다.
AWS SDK 기본 — 코드로 AWS 서비스 제어하기
SDK(Software Development Kit)는 개발자가 프로그래밍 언어(Python, Java, Node.js 등)를 이용해서 AWS 서비스를 코드로 조작할 수 있게 해주는 도구 모음입니다. 쉽게 말하면 AWS 서비스와 대화할 수 있는 번역기입니다. Python 코드로 S3에 파일을 올리거나, DynamoDB에 데이터를 저장하려면 SDK를 사용합니다.
코드에서 AWS를 사용하려면 "나는 누구다"라고 증명하는 자격 증명이 필요합니다. SDK는 이 자격 증명을 찾을 때 정해진 순서(자격 증명 체인)를 따릅니다. 먼저 환경 변수에서 찾고, 없으면 공유 자격 증명 파일을 확인하고, 마지막으로 서버에 연결된 IAM 역할을 확인합니다. 이 순서를 알아두면 "왜 권한 오류가 나지?"라는 상황을 빠르게 해결할 수 있습니다.
리전 설정은 SDK 클라이언트를 만들 때 어느 AWS 데이터센터(리전)를 사용할지 지정하는 것입니다. 환경 변수로도 설정할 수 있습니다.
페이지네이션은 조회 결과가 너무 많을 때 SDK가 자동으로 여러 페이지로 나누어 가져오는 기능입니다. 책의 목차처럼 결과를 나누어 받을 수 있습니다.
SQS 개발 핵심 — 안전한 메시지 전달
SQS는 서비스 간에 메시지를 안전하게 주고받는 우편 시스템입니다. 보내는 쪽(생산자)과 받는 쪽(소비자)이 직접 연결되지 않아도 됩니다.
메시지 수명 주기
메시지가 어떻게 처리되는지 단계별로 살펴봅시다.
먼저 생산자가 메시지를 큐(줄)에 전송합니다. 소비자가 메시지를 꺼내 가면 그 순간부터 가시성 타임아웃이 시작됩니다. 가시성 타임아웃이란 "이 메시지는 처리 중이니 다른 소비자는 건드리지 마세요"라는 임시 잠금 시간입니다. 소비자가 처리를 마치면 메시지를 삭제합니다. 만약 가시성 타임아웃 안에 삭제하지 않으면(처리 실패 또는 지연) 메시지가 다시 큐에 나타나서 다른 소비자가 처리할 수 있습니다.
Dead Letter Queue (DLQ)
몇 번을 시도해도 처리에 계속 실패하는 메시지가 있을 수 있습니다. 이런 메시지를 그냥 두면 계속 재처리 시도가 반복되어 리소스를 낭비합니다. DLQ는 일정 횟수(maxReceiveCount) 이상 실패한 메시지를 별도의 격리 큐로 이동시켜 보관합니다. 개발자는 나중에 이 DLQ를 분석해서 오류 원인을 찾을 수 있습니다. 병원의 격리 병동과 비슷한 개념입니다.
Long Polling vs Short Polling
SQS에서 메시지를 가져오는 방법에는 두 가지가 있습니다.
Short Polling은 큐에 즉시 "메시지 있어요?" 하고 물어보는 방식입니다. 메시지가 없어도 빈 응답을 즉시 반환합니다. 문제는 메시지가 없을 때도 계속 물어보기 때문에 API 호출 비용이 낭비됩니다.
Long Polling은 메시지가 생길 때까지 최대 20초 동안 기다리는 방식입니다. WaitTimeSeconds를 설정하면 됩니다. 빈 응답이 줄어들고 API 호출 수도 줄어 비용이 절감됩니다. 일반적으로 Long Polling을 권장합니다.
!Short Polling vs Long Polling
Kinesis 스트리밍 — 실시간 데이터 처리
Kinesis는 SNS/SQS와 달리 실시간으로 대량의 데이터를 처리하는 스트리밍 서비스입니다. SNS/SQS가 개별 메시지를 다룬다면, Kinesis는 강물처럼 끊임없이 흘러오는 데이터를 처리합니다. 예를 들어 수백만 명의 앱 사용 로그를 실시간으로 분석하거나, IoT 센서 데이터를 처리하는 데 사용합니다.
Kinesis Data Streams는 샤드(shard)라는 단위로 구성됩니다. 샤드를 레인이 있는 고속도로로 생각하면 됩니다. 생산자는 파티션 키를 이용해 데이터를 특정 레인(샤드)으로 보내고, 소비자는 각 레인에서 데이터를 읽습니다.
Enhanced Fan-out은 여러 소비자가 같은 스트림을 읽을 때 소비자별로 전용 처리량을 보장하는 기능입니다. 샤드당 초당 2MB의 속도로 각 소비자에게 독립적으로 데이터를 전달합니다.
데이터 보존 기간은 기본 24시간이며 최대 365일까지 늘릴 수 있습니다.
회복력 있는 코드 패턴
재시도 로직 — Exponential Backoff
네트워크 오류나 일시적인 서비스 장애가 생겼을 때 즉시 재시도하면 오히려 서버에 부하를 더 줄 수 있습니다. Exponential Backoff는 실패할 때마다 재시도 간격을 두 배씩 늘리는 방식입니다. 1초 후 재시도, 실패하면 2초 후, 또 실패하면 4초 후, 8초 후... 이렇게 점점 늘어납니다. AWS SDK에 기본으로 내장되어 있지만 상황에 따라 직접 구현이 필요할 수도 있습니다.
차단기 패턴 — Circuit Breaker
전기 누전 차단기처럼, 외부 서비스가 계속 실패하면 아예 호출을 잠시 차단하는 패턴입니다. 계속 실패하는 서비스에 요청을 보내다 보면 내 서비스도 느려지거나 다운될 수 있습니다. Circuit Breaker는 "이 서비스는 지금 문제가 있으니 잠깐 연결을 끊겠다"고 판단해서 시스템 전체로 장애가 번지는 것을 막습니다.
시험 핵심 정리
"메시지 처리 실패 시 별도 큐로 이동" -- Dead Letter Queue
"API 호출 수를 줄이고 빈 응답 방지" -- Long Polling (WaitTimeSeconds)
"점점 더 긴 간격으로 재시도" -- Exponential Backoff
"외부 서비스 실패 시 호출 차단" -- Circuit Breaker 패턴
"실시간 데이터 스트리밍" -- Kinesis Data Streams
"소비자별 전용 처리량" -- Kinesis Enhanced Fan-out
"SDK가 자격 증명을 찾는 순서" -- 자격 증명 체인
SQS 가시성 타임아웃은 처리 시간보다 길게 설정해야 함