CertNote/ 출퇴근 학습 노트
로드맵
KOEN
CLF-C02 · FoundationalCloud Practitioner - Foundational
DVA-C02 · AssociateDeveloper - Associate
SAA-C03 · AssociateSolutions Architect - Associate
SOA-C02 · AssociateCloudOps Engineer - Associate
SAP-C02 · ProfessionalSolutions Architect - Professional
  • Week 1
    • 1.SAP 시험이라는 게임: 시나리오를 분해하는 손기술
    • 2.IAM·STS·Federation: 권한이라는 단어를 여섯 층으로 쪼개기
    • 3.VPC의 해부학: 라우팅 테이블이 진짜로 결정하는 것
    • 4.컴퓨팅 4종의 깊이: Nitro, EBS, ELB, Auto Scaling을 Pro 시야로 다시 보기
    • 5.1주차 통합: IAM·VPC·EC2가 한 시나리오에서 만날 때
  • Week 2
  • Week 3
  • Week 4
  • Week 5
  • Week 6
  • Week 7
  • Week 8
    • 1.Lambda 고급: 동시성, 콜드 스타트, SnapStart의 내부 동작
    • 2.Step Functions: 분산 워크플로우의 상태 모델과 Saga 패턴
    • 3.EventBridge: Event Bus, Pipes, Scheduler의 통합 모델
    • 4.AppSync GraphQL과 SQS/SNS/Kinesis 메시징의 본질
    • 5.Week 8 종합 — 서버리스·이벤트 아키텍처 시나리오 12선
  • Week 9
  • Week 10
  • Week 11
  • Week 12
  • Week 13
  • Week 14
  • Week 15
  • Week 16
DOP-C02 · ProfessionalDevOps Engineer - Professional
SCS-C03 · SpecialtySecurity - Specialty
MLA-C01 · AssociateMachine Learning Engineer - Associate
AIF-C01 · FoundationalAI Practitioner - Foundational
DEA-C01 · AssociateData Engineer - Associate
MLS-C01 · SpecialtyMachine Learning - Specialty
합격 후기

© CertNote · 주간랩스

  • 소개
  • 수정 기록
  • 문의
  • 이용약관
  • 개인정보처리방침
← SAP-C02/Week 8/Day 5

기준: SAP-C02 시험 가이드·오류 제보

SAP-C02· ProWeek 8 · Day 5읽기 약 20분
핵심 정리

Lambda (Day 1)

  • Firecracker micro VM 위 실행, Slot 풀에서 워밍업, 콜드 스타트는 다운로드/런타임/Init/JIT 4단계
  • 동시성 3종: 계정 한도(1,000) / Reserved(격리+상한) / Provisioned(따뜻함, 비용)
  • SnapStart(CRaC 기반): Java/Python/.NET, 무료, init uniqueness 주의
  • Hyperplane ENI(2019~): VPC 통합 시 ENI 공유, RDS Proxy로 connection 폭증 해결
  • 비동기 재시도 2회 + Destinations(SNS/SQS/EB/Lambda)
  • Function URL (API GW 우회), Container Image 10GB + lazy loading, Graviton2 ARM 20%↓
  • Burst Concurrency 한도(us-east-1=3,000) → 예측 스파이크는 PC + Auto Scaling

Step Functions (Day 2)

  • 분산 영속 상태 머신, Saga = Catch + 별도 보상 분기
  • Standard(1년·전이당) vs Express(5분·호출+시간) — 빈도·시간으로 분기
  • State 7종 + Distributed Map(10K 병렬 + S3 ItemReader)
  • 통합 3패턴: Request-Response / .sync (Job 대기) / .waitForTaskToken (외부 콜백)
  • Retry + Catch: 지수 백오프 + JitterStrategy(2023)
  • Workflow Studio로 시각 작성 + IAM 자동 생성

EventBridge (Day 3)

  • Bus 3종: Default(AWS) / Custom(도메인) / Partner(SaaS)
  • Rule = Pattern + 최대 5 Targets, JSON 깊은 필드 매칭 + API Destination 외부 HTTPS
  • Pipes: SQS/Kinesis/DDB Stream/MQ/MSK → Filter → Enrich → Target, 코드 없이
  • Scheduler: 100만+ 스케줄, time zone, flexible window, 200+ API 직접 호출
  • Schema Registry + Archive/Replay — 진화 관리 + 시간 여행
  • SNS vs EventBridge: 단순 fan-out·고처리량 vs 풍부 필터·다양 target

AppSync + 메시징 (Day 4)

  • AppSync GraphQL: schema-first + direct resolver(Lambda 없이 DDB) + Subscription(WebSocket) + 5 인증
  • SQS Standard(무한 TPS) vs FIFO(300 TPS, 순서+dedup 5분) + High Throughput FIFO
  • Visibility Timeout, Long Polling, DLQ + maxReceiveCount
  • SNS Fan-out + Message Filtering + FIFO Topic(2020)
  • Kinesis Data Streams: 재처리·다중 consumer, Shard + Partition Key, EFO
  • Firehose(60~900초 buffer + Lambda 변환), MSK(Kafka 이식성)
  • Lambda ESM: BatchSize, ReportBatchItemFailures partial batch

Day 5 - Week 8 종합 — 서버리스·이벤트 아키텍처 시나리오 12선

Week 8은 서버리스와 이벤트 기반 아키텍처가 어떻게 협력하는지를 깊이 봤다. Lambda(콜드 스타트·동시성·VPC ENI), Step Functions(상태 머신·Saga·Distributed Map), EventBridge(Bus·Pipes·Scheduler), AppSync(GraphQL + Subscription), SQS/SNS/Kinesis/MSK(메시징·스트리밍) — 여섯 도메인은 각자 독립적으로 보이지만, 실제 production에서는 거의 항상 두세 개가 함께 쓰인다. SAP-C02 시험이 노리는 것도 정확히 이 부분이다. "Lambda만 알아도 안 되고", "Step Functions만 알아도 안 되고", 시나리오의 키워드를 보고 어느 도구의 조합이 가장 적합한지 판단하는 능력이 필요하다.

오늘은 week 8 전체를 종합 시나리오 12문항으로 정리한다. 각 문항은 단일 도구가 아니라 복합 패턴을 묻고, 해설에서 왜 그 답이 맞고 왜 다른 보기가 틀린지를 SAP 시험의 결정 기준으로 풀어낸다. 시험 직전에 이 시나리오들을 다시 읽으면 도메인 전체의 결정 트리가 머릿속에 다시 그려진다.

결정 트리 — 시나리오 키워드 → 도구 매핑

"콜드 스타트 + 비용 없이"            → SnapStart (Java/Python/.NET)
"콜드 스타트 + 예측 가능 트래픽"      → Provisioned Concurrency + Auto Scaling
"Lambda + DB connection too many"   → RDS Proxy
"한 함수가 다른 함수 영향"           → Reserved Concurrency
"Java/Python Lambda 비용 20%↓"      → Graviton2 ARM 전환
"ML 모델 1GB+ Lambda"               → Container Image (10GB 한도)

"장기 워크플로우 + 보상"             → Step Functions Standard + Catch
"고빈도·짧음 워크플로우"             → Step Functions Express
"인간 승인 / 외부 콜백"              → .waitForTaskToken
"ECS/EMR/Glue Job 완료 대기"        → .sync
"S3 100만 객체 병렬"                → Distributed Map + Express child

"100만 사용자 스케줄"                → EventBridge Scheduler
"SaaS partner 이벤트 수신"          → EventBridge Partner Bus
"큐 → 워크플로우, 코드 없이"         → EventBridge Pipes
"이벤트 재처리·재생"                 → EventBridge Archive + Replay
"풍부 필터 + 다양 target"            → EventBridge Custom Bus + Rule

"GraphQL + 실시간 + 모바일 + 인증"  → AppSync + Cognito
"순서 + 중복 제거 결제 큐"           → SQS FIFO
"단순 fan-out + 매우 높은 처리량"    → SNS Topic + SQS subscription
"재처리 + 다중 소비자"               → Kinesis Data Streams + EFO
"S3/Redshift/OpenSearch 자동 저장"   → Kinesis Firehose
"Kafka 표준 + 이식성"                → MSK
"실패 메시지 5회 시도 후 격리"       → DLQ + maxReceiveCount
"배치 처리 부분 실패만 재시도"        → Lambda ESM ReportBatchItemFailures

SAP 시험 함정 정리

  1. Task Role vs Task Execution Role (ECS/Fargate) — 앱 권한은 Task Role, 인프라(ECR Pull, Logs) 권한은 Execution Role
  2. EventBridge DLQ vs Lambda Destinations — EB DLQ는 invoke 실패용, Lambda 비즈니스 로직 실패는 Lambda Destinations
  3. SQS FIFO "exactly-once" — 정확히는 5분 dedup window 안의 idempotency, application 레벨 idempotency 추가 권장
  4. Standard vs Express 비용 — 항상 Express가 싼 것은 아님. 드물게 실행되는 긴 워크플로우는 Standard가 더 저렴
  5. Reserved Concurrency — 격리만이 아니라 상한이기도 함
  6. SNS는 메시지 보존 안 함 — 보존 필요하면 → SQS subscription 또는 EventBridge Archive
  7. Pipes vs Step Functions — 1:1 라우팅은 Pipes, 복잡 워크플로우는 Step Functions, 자주 Pipes→SF 조합
  8. SnapStart의 uniqueness 함정 — init에서 만든 난수·UUID·DB connection state가 모든 복원본에 복사됨

📝 시나리오 12문항

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 글로벌 OTT 서비스가 사용자 시청 이벤트(초당 50,000건)를 받아 (1) 실시간 추천 모델에 즉시 전달 (2) 7일치 raw event를 S3에 보존해 ML 학습용으로 재처리 (3) 분석팀이 시간당 집계로 BI 대시보드 갱신. 세 다운스트림이 서로 latency 영향 없이 동시 처리되어야 한다. 가장 적합한 구성은?

문제 2

Java Spring Boot 기반 Lambda 함수의 콜드 스타트가 평균 4초. 일평균 호출 100만 회, 콜드 비율 5%. 운영팀은 추가 비용 없이 콜드 스타트를 1초 이하로 줄여야 한다. init에서 DB connection pool과 UUID 기반 인스턴스 ID 생성 코드가 있다. 가장 적합한 조합은?

문제 3

결제 → 재고 차감 → 배송 예약 워크플로우가 평균 30초~며칠 사이 걸린다(외부 배송업체 응답 대기 포함). 배송 예약이 실패하면 결제 환불 + 재고 복원이 필요하다. 외부 배송업체는 비동기 webhook으로 결과를 보낸다. 가장 적합한 구성은?

문제 4

100만 사용자 SaaS가 각 사용자의 선호 시간(타임존 + 시각)에 일일 요약 이메일을 발송. 사용자 설정 변경 시 즉시 반영. 가장 적합한 구성은?

문제 5

DynamoDB의 변경 이벤트(DDB Streams)를 필터링해 특정 패턴만 Step Functions 워크플로우로 보낸다. Lambda 코드 작성과 운영을 피하고 싶다. 가장 적합한 구성은?

문제 6

한 e-commerce가 OrderPlaced 이벤트를 분석·배송·CRM·알림·audit 5개 다운스트림에 동일 메시지로 fan-out한다. 처리량은 초당 5,000건. 각 다운스트림은 자체 속도로 처리하고 실패 시 영구 격리 분석. 가장 적합한 구성은?

문제 7

Lambda 함수가 VPC 안의 RDS PostgreSQL에 접속. 동시 실행이 1,500개로 증가하면서 "FATAL: too many connections" 오류. RDS max_connections=200. 가장 적합한 해결책은?

문제 8

모바일 채팅 앱이 GraphQL로 백엔드를 구성하고 메시지 실시간 push를 받는다. Cognito 사용자 인증, DynamoDB 저장, 오프라인 동기화 필요. 가장 적합한 백엔드는?

문제 9

S3에 저장된 100만 개의 CSV 파일을 각각 Lambda로 처리한다. 각 파일당 처리 시간 5~30초. 결과를 다른 S3 버킷에 집계 저장. 가장 적합한 패턴은?

문제 10

블랙프라이데이 세일 시작 시 Lambda 동시 실행이 0에서 5,000으로 5분 안에 폭증. us-east-1 burst 한도는 3,000. throttle 없이 처리해야 하고, 정확한 시작 시각을 알 수 있다. 가장 적합한 구성은?

문제 11

글로벌 SaaS가 Stripe webhook과 Shopify webhook을 동시에 받고, amount > $1,000 이벤트만 Step Functions 워크플로우로, 나머지는 Lambda로 보낸다. Webhook receiver 운영 부담을 피하고 싶다. 가장 적합한 구성은?

문제 12

한 핀테크가 결제 거래를 SQS에 받아 Lambda로 처리. 배치 size=10, 한 메시지가 실패하면 기본 동작은 전체 배치 재시도이지만, idempotent 안 된 다운스트림이라 중복 처리가 문제. 실패한 메시지만 재시도하려면?

📌 Week 8 한눈에

[클라이언트]
   │ GraphQL
   ▼
[AppSync] ──Subscription(WebSocket)── 실시간 모바일/웹
   │ Mutation, direct resolver
   ▼
[DynamoDB] ──Streams──► [EventBridge Pipes]
                          │ Filter
                          ▼
                  [EventBridge Custom Bus]
                          │ Rule
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
  [Step Functions]    [SNS Topic]     [Kinesis Data Streams]
   ├─ Standard (1년)   │ Fan-out       │ 보존 24h~365d
   ├─ Express (5분)    │ Filtering     │ EFO 다중 consumer
   ├─ Saga(Catch)      └─ 5 SQS         │
   ├─ Distributed Map                   ▼
   ├─ .sync (Job 대기)                [Firehose] ──► S3/Redshift
   └─ .waitForTaskToken (외부 콜백)

[Lambda]
 ├─ Concurrency 3종 (계정/Reserved/Provisioned)
 ├─ SnapStart (Java/Python/.NET, 무료)
 ├─ Hyperplane ENI (VPC), RDS Proxy로 connection
 ├─ Destinations (OnSuccess/OnFailure → SNS/SQS/EB/Lambda)
 ├─ Container Image 10GB (block-level lazy loading)
 └─ Graviton2 ARM 20%↓

[EventBridge Scheduler] ──► 100만+ 사용자 스케줄
[EventBridge Partner Bus] ──► Stripe/Shopify/Datadog 직접
[EventBridge Archive + Replay] ──► 이벤트 재처리
[Schema Registry] ──► 진화 관리 + 코드 바인딩

시험 직전 체크리스트

  • Lambda 콜드 스타트 4단계(다운로드/런타임/Init/JIT)를 설명할 수 있다
  • SnapStart 동작 원리(CRaC 스냅샷 + 복원)와 uniqueness 함정을 안다
  • Reserved vs Provisioned vs 계정 한도의 차이를 한 줄로 설명할 수 있다
  • RDS Proxy가 connection 폭증을 어떻게 푸는지 안다
  • Step Functions Standard vs Express의 가격 모델과 분기 기준
  • .sync vs .waitForTaskToken의 사용 시점
  • Distributed Map의 ItemReader/ResultWriter + child Express
  • EventBridge Bus 3종 + Rule + 5 Target 한도
  • Pipes의 Source/Filter/Enrich/Target 4단계
  • Scheduler vs CloudWatch Rule cron의 한도 차이
  • SNS vs EventBridge 선택 기준(단순 fan-out vs 풍부 필터)
  • SQS Standard vs FIFO + High Throughput FIFO
  • Visibility Timeout, Long Polling, DLQ + maxReceiveCount
  • Kinesis Shard + Partition Key + EFO
  • Lambda ESM ReportBatchItemFailures partial batch

다음 주(Week 9): 데이터 아키텍처 — Data Lake (S3 + Lake Formation + Glue), Redshift (RA3 + AQUA + Spectrum), EMR (Spark/Hive on EC2/EKS), Athena (Iceberg + federated query), MSK Connect, Lakeformation 권한 모델, Migration to Data Lakehouse.

이전AppSync GraphQL과 SQS/SNS/Kinesis 메시징의 본질Week 8 · Day 4다음 데이터 레이크 아키텍처: S3, Glue, Athena의 내부 동작과 비용 모델Week 9 · Day 1

참고 공식 자료

  • SAP-C02 공식 시험 안내(새 탭에서 열림)
  • AWS Lambda 공식 문서(새 탭에서 열림)
  • Amazon EventBridge 공식 문서(새 탭에서 열림)
  • AWS Step Functions 공식 문서(새 탭에서 열림)
  • Amazon SQS 공식 문서(새 탭에서 열림)
  • Amazon SNS 공식 문서(새 탭에서 열림)

이 페이지

  • 결정 트리 — 시나리오 키워드 → 도구 매핑
  • SAP 시험 함정 정리
  • 시나리오 12문항
  • Week 8 한눈에
  • 시험 직전 체크리스트