Amazon DOP-C02: 이벤트 기반 아키텍처 및 자동화 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS DevOps Engineer Professional DOP-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

라우팅, 오케스트레이션, 스케줄링: EventBridge와 Step Functions

Amazon EventBridge는 라우팅, 거버넌스, 계정 간/이벤트 도메인 간 통합을 위한 중앙 이벤트 버스입니다. AWS 서비스 이벤트에는 기본 버스를, 도메인을 분할하고 권한을 적용하려면 사용자 지정 버스를, SaaS 통합에는 파트너 버스를 사용합니다. 규칙은 콘텐츠 기반 패턴을 통해 이벤트를 매칭하고 200개 이상의 AWS 서비스를 대상으로 지정할 수 있습니다. 입력 변환기를 사용하여 페이로드의 형태를 바꾸고, 아카이브/재생 기능을 사용하여 복구 중이거나 새로운 소비자를 온보딩할 때 과거 이벤트를 재처리할 수 있습니다. 리소스 정책을 통해 계정 간 이벤트 라우팅을 활성화하여 플랫폼 계정에서 거버넌스를 통합할 수 있습니다. EventBridge Pipes는 이벤트 소스(SQS, Kinesis, DynamoDB Streams, Amazon MSK 기반의 자체 관리형 Apache Kafka 등)에서 대상으로 향하는 지점 간(point-to-point)의 설정 가능한 흐름을 제공하며, 필터링, 배치, 변환 및 Lambda나 Step Functions를 통한 보강 기능이 내장되어 있습니다. 이는 전체 소비자 애플리케이션을 관리하고 싶지는 않지만 가벼운 중재가 필요할 때 이상적입니다. EventBridge Scheduler는 일회성 및 cron 스케줄을 제공하여 실행 역할, 시간대 지원, 그리고 ‘썬더링 허드(thundering herd)’ 현상을 줄이기 위한 선택적 유연한 시간 창(flexible time window)을 통해 대상을 호출합니다.

AWS Step Functions는 Amazon States Language로 정의된 분산 워크플로를 오케스트레이션하며, Task, Choice, Parallel, Map(분산 Map 포함), Wait, Pass, Succeed/Fail 상태와 강력한 Retry/Catch 패턴을 제공합니다. 서비스 통합이 깊어 AWS API를 호출하기 위한 글루 코드(glue code)가 필요 없으며, 동기식(.sync) 및 작업 토큰(task token)을 사용한 콜백 패턴도 포함됩니다. 장기 실행되고, 감사가 중요하며, 상태가 정확히 한 번(exactly-once) 진행되어야 하는 오케스트레이션에는 Standard 워크플로를 선택하세요. 최대 1년까지 실행되며 상태 전환당 비용이 부과됩니다. 실행 기록이 보존되고 가시성이 높으며 X-Ray 추적이 내장되어 있습니다. 처리량이 많고 수명이 짧은(수 초에서 수 분) 오케스트레이션에는 Express 워크플로를 선택하세요. 대규모 확장을 위해 요청당+기간별 요금과 최소 한 번(at-least-once) 실행 시맨틱을 감수할 수 있는 경우에 적합합니다. 스트리밍 수집 데이터 보강, 이벤트 라우터, 태스크를 멱등성 있게 만들 수 있는 마이크로 오케스트레이션에 사용됩니다. 보상 트랜잭션(compensating task)을 사용하는 사가(saga) 패턴이나 중앙 집중식 오류 처리와 같은 패턴을 적용하세요. 상태 머신에서 재시도/타임아웃을 외부화하여 태스크 코드를 단순화하세요.

컴퓨팅 트리거와 백프레셔: Lambda 이벤트 소스 매핑

Lambda 이벤트 소스 매핑(ESM)은 폴링 기반 소스를 Lambda에 연결하고 동시성, 배치 처리, 오류 처리를 제어합니다.

• SQS: Lambda는 큐를 폴링하여 수평적으로 확장되며, 함수를 배치(최대 10개 메시지, 최대 배치 기간 300초)로 호출합니다. Standard 큐에서는 큐 깊이와 메시지 처리량에 따라 공격적으로 확장됩니다. FIFO 큐에서는 Lambda가 메시지 그룹별 순서를 유지하며 그룹당 한 번에 하나의 배치만 처리합니다. ESM에서 최대 동시성을 구성하여 워커 확장을 제한하고 다운스트림 시스템을 보호하세요. 예약/프로비저닝된 동시성과 결합하여 용량을 보장할 수 있습니다. 부분 배치 응답(partial batch response)을 사용하여 성공한 레코드만 확인(acknowledge)하고 실패한 레코드는 다시 큐에 넣음으로써 전체 배치가 재처리되는 것을 방지하세요. 큐의 가시성 제한 시간(visibility timeout)을 최악의 경우 재시도 시간을 모두 합친 것보다 길게 설정하세요. DLQ와 재전송 정책(redrive policy)으로 포이즌 메시지(poison message)를 격리합니다.

• Kinesis Data Streams: 기본적으로 샤드당 하나의 동시 Lambda 호출이 발생하여 샤드별 순서를 보장합니다. 하위 시퀀스 간의 순서가 중요하지 않은 경우, ParallelizationFactor를 최대 10까지 늘려 샤드당 여러 배치를 동시에 처리할 수 있습니다. 최대 10,000개 레코드(6MB)의 배치 크기와 최대 5분의 배치 기간을 통해 비용을 분산시키고 처리량을 높일 수 있습니다. 함수 오류 시 배치 분할(bisect on function error)을 사용하여 배치 내의 잘못된 레코드를 이진 검색으로 찾아내고, 실패 시 대상(on-failure destination)이나 최대 재시도/레코드 수명을 사용하여 처리할 수 없는 레코드를 폐기하거나 다른 곳으로 라우팅하세요. IteratorAge를 모니터링하여 소비자 지연(consumer lag)을 감지하고 그에 따라 샤드를 재분할하거나 병렬 처리 수준을 높이세요.

• DynamoDB Streams: 시맨틱 측면에서 Kinesis와 유사하며, 배치 크기는 최대 1,000개 레코드(6MB)이고 파티션 키당 샤드 모델을 사용합니다. 소비자는 순서가 보장된 아이템 레벨 변경 사항(INSERT, MODIFY, REMOVE)을 받습니다. 동일한 오류 처리 방식(오류 시 분할, 최대 재시도 횟수, 레코드 수명)과 필터링을 적용하세요. 소비자에게 필요한 속성을 포함하는 스트림 뷰 유형(NewImage, OldImage, NewAndOldImages, 또는 KeysOnly)을 사용하여 페이로드 크기를 최적화하세요.

ESM의 이벤트 필터링은 폴러(poller) 단계에서 관련 없는 이벤트를 버려 호출 횟수를 줄여줍니다. Lambda에서 스트림에 텀블링 윈도우(tumbling window) 집계를 사용하여 시간 경과에 따른 레코드를 집계함으로써 미니 배치 처리 패턴을 구현할 수 있습니다.

운영 자동화 및 해결: Systems Manager Automation 및 OpsCenter

AWS Systems Manager Automation은 JSON/YAML로 작성된 런북(Automation 유형의 문서)을 제공하며, 이 런북에는 aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack, aws:executeAutomation과 같은 단계가 포함됩니다. Automation은 파라미터를 입력받고, 출력을 내보내며, 변경 이력과 함께 버전을 관리하고, 최소 권한 및 교차 계정/리전 작업을 위해 전용 AutomationAssumeRole로 실행됩니다. 플릿 전체의 동시성 및 오류 임계값을 제어하고, 승인 및 Change Calendar 기간을 요구하며, SNS를 통해 알림과 통합할 수 있습니다. Automation은 일정에 따라, EventBridge 규칙(AWS Health, CloudWatch 또는 API 이벤트에 대한 거의 실시간 해결용), 정책을 적용하기 위한 AWS Config 해결 규칙(예: EBS 볼륨에 기본 태그 적용 또는 EC2 인스턴스에 기본 인스턴스 프로파일 연결), 그리고 OpsCenter에서 호출할 수 있습니다.

OpsCenter는 CloudWatch 경보, AWS Config, Health 이벤트 또는 사용자 지정 소스에서 발생하는 운영 문제를 OpsItems로 집계합니다. 각 OpsItem은 상태, 우선순위, 중복 제거, 관련 리소스 및 런북 링크를 추적합니다. 표준 해결을 위해 원클릭 런북을 연결하고, OpsItem이 생성되거나 특정 조건(예: SSH에 0.0.0.0/0을 허용하는 보안 그룹, 패치 규정 준수 드리프트, 백업 실패)과 일치하도록 업데이트될 때 특정 Automation을 시작하도록 EventBridge 또는 Config 규칙을 연결하여 자동 해결을 활성화할 수 있습니다. Systems Manager Explorer를 사용하여 여러 계정 및 리전에 걸쳐 플릿 상태와 열려 있는 OpsItems를 시각화할 수 있습니다. 영구 레코드로서의 OpsItems와 코드화된 해결 방법으로서의 Automation 런북의 이러한 조합은 대규모 환경에서 감사 가능하고 일관된 운영을 가능하게 합니다.

설계 및 운영 지침

최소 한 번(at-least-once) 전송이 일반적이므로 모든 컨슈머에 걸쳐 멱등성(idempotency)을 고려하여 설계해야 합니다. 지연 시간이 짧은 병렬 반응을 위해서는 SNS 또는 EventBridge 규칙을 통한 이벤트 기반 팬아웃(fan-out)을 선호합니다. 워크로드를 버퍼링하고 컨슈머의 느린 처리 속도로부터 프로듀서를 보호하려면 SQS를 선호합니다. 분석을 위해 샤드별 엄격한 순서 보장과 재생 가능한 스트림이 필요한 경우에는 Kinesis를 선호합니다. 맞춤형 컨슈머가 과도한 경우, 소스와 타겟 간의 가볍고 관리되는 통합을 위해 EventBridge Pipes를 사용하고, cron 인프라를 유지 관리할 필요 없이 시간 기반 트리거를 사용하려면 EventBridge Scheduler를 사용합니다.

타임아웃과 재시도 횟수를 적절하게 조정합니다. SQS의 경우, 가시성 제한 시간(visibility timeout)은 최대 처리 시간과 재시도 시간을 더한 것보다 길어야 합니다. 스트림의 경우, 재시도 횟수에 상한을 두고 MaximumRecordAgeInSeconds를 설정하여 잘못된 레코드가 무한정 재처리되는 것을 방지합니다. DLQ 또는 실패 시 대상을 체계적으로 사용하고 SQS ApproximateAgeOfOldestMessage, Lambda ConcurrentExecutions/Throttles/Errors, IteratorAge, Step Functions ExecutionFailed/TimedOut, EventBridge FailedInvocations에 대한 대시보드와 경보를 추가합니다. 트래픽 급증을 피할 수 없지만 지연 시간 SLA가 엄격한 경우, Lambda 프로비저닝된 동시성(provisioned concurrency)을 사용하여 용량을 미리 준비(pre-warm)합니다. 거버넌스를 위해서는 리소스 정책을 사용하는 EventBridge를 선호하여 교차 계정 라우팅과 아카이브/재생 기능을 통해 컨슈머의 발전과 인시던트 복구를 지원합니다.

실제 문제 시나리오

Shopify는 플래시 세일(flash-sale) 이벤트를 위한 주문 처리를 현대화하는 동시에, 다운스트림 서비스가 느려지거나 실패할 경우 실시간 분석 및 자동화된 해결 조치를 추가해야 합니다.

1. 주문 이벤트 수집 및 팬아웃

• 결제 시스템에서 SNS FIFO 주제를 사용하여 OrderPlaced 이벤트를 게시하여 OrderId별로 순서가 보장되고 중복이 제거된 알림을 보장합니다. 구독 대상은 다음과 같습니다:
  • 주문 처리를 위한 SQS FIFO 대기열(Order-Workers)로, 순서를 보존합니다.
  • 거버넌스 및 추가 라우팅을 위한 EventBridge 사용자 지정 이벤트 버스(CommerceBus).
  • 분석을 위해 주문 데이터를 GZIP 압축하여 S3로 거의 실시간으로 전송하기 위한 Kinesis Data Firehose 전송 스트림. SNS FIFO를 사용하는 이유: 게시자와 컨슈머를 분리(decoupling)하면서 여러 구독자에게 확장 가능한 팬아웃으로 순서가 보장되고 정확히 한 번(exactly-once) 처리되는 시맨틱을 제공합니다.

2. 주문 처리 버퍼링 및 이행

• Lambda는 이벤트 소스 매핑을 통해 SQS FIFO 대기열에서 메시지를 소비하며, 배치 크기는 10, 부분 배치 응답은 활성화하고, 다운스트림 웨어하우스 API를 보호하기 위해 최대 동시 실행 수를 제한합니다. 대기열의 가시성 제한 시간은 재시도를 고려하여 Lambda 제한 시간의 6배로 설정합니다. DLQ는 maxReceiveCount=3으로 설정하여 포이즌 메시지를 캡처하며, 나중에 재실행(redrive) 워크플로를 통해 수정된 메시지를 재처리합니다. SQS FIFO + Lambda ESM을 사용하는 이유: 주문별 순서를 강제하고, 버퍼링을 통해 다운스트림 지연을 격리하며, 세분화된 오류 처리를 제공합니다.

3. 다단계 사가(Saga) 오케스트레이션

• Step Functions 표준 워크플로는 결제, 재고 예약, 사기 탐지, 배송 예약 과정을 오케스트레이션하며, 실패 경로에 대한 재시도, 타임아웃, 보상 트랜잭션(환불, 재고 복구)을 포함합니다. 첫 번째 Task는 SQS 컨슈머로부터 호출된 Lambda에 의해 트리거됩니다. 표준 워크플로를 사용하는 이유: 외부 시스템 전반에 걸쳐 장기 실행되고, 감사 가능하며, 풍부한 오류 처리 기능을 갖춘 정확히 한 번(exactly-once) 상태 전환을 보장합니다.

4. 도메인 이벤트를 기능별로 라우팅

• CommerceBus는 프로듀서 서비스의 PutEvents 호출과 SNS 구독을 통해 Order* 이벤트를 수신합니다. EventBridge 규칙:
  • OrderPlaced와 일치하는 경우, 고가치 고객이 주문하면 마케팅팀(Lambda)에 알리고 지원 케이스(AWS Support API 통합)를 생성합니다.
  • OrderFailed 이벤트는 리소스 정책을 사용하여 교차 계정 거버넌스를 위해 중앙 운영 계정의 이벤트 버스로 전달합니다. EventBridge를 사용하는 이유: 중앙 집중식 라우팅, 필터링, 교차 계정 전송이 가능하며, 프로듀서를 변경하지 않고도 새로운 컨슈머를 추가할 수 있습니다.

5. 파트너 피드를 보강(enrichment) 단계로 파이핑

• EventBridge Pipes는 파트너의 SQS 표준 대기열(백오더된 SKU)을 Step Functions Express 워크플로에 연결합니다. 이 워크플로는 Lambda 함수를 통해 항목을 보강하고 결과를 내부 SQS 대기열로 푸시하여 재입고를 처리합니다. Pipes + Express를 사용하는 이유: 높은 처리량과 낮은 비용으로 가벼운 보강 작업을 수행하는, 오버헤드가 적은 관리형 통합입니다.

6. 실시간 분석 및 검색

• Kinesis Data Stream은 클릭스트림과 운영 이벤트를 수집합니다. Lambda(향상된 팬아웃 컨슈머)는 세션화를 수행하고, Kinesis Data Analytics는 KPI를 집계합니다. Firehose는 변환된 주문 및 분석 데이터를 S3 데이터 레이크와 Amazon OpenSearch Service로 전송하며, 효율적인 쿼리를 위해 날짜/마켓별로 동적 파티셔닝을 적용합니다. Streams + Firehose를 사용하는 이유: 분석을 위한 순서 보장 및 저지연 처리가 가능하며, 스토리지 및 검색 서비스로의 전송과 변환이 관리형으로 제공됩니다.

7. 시간 기반 자동화

• EventBridge Scheduler는 매분 cron 작업을 실행하여 CommerceBus에 InventorySnapshotRequested를 게시하고, 이는 Step Functions Express 워크플로를 트리거하여 여러 웨어하우스의 스냅샷을 취합함으로써 거의 실시간으로 재고 정확성을 유지합니다. Scheduler를 사용하는 이유: 사용자 지정 인프라 없이 네이티브하고 복원력 있는 cron 기능을 제공합니다.

8. 자동화된 해결 조치 및 운영

• AWS Config 규칙은 주문 처리 VPC에서 열려 있는 SSH 포트나 퍼블릭 S3 ACL을 탐지합니다. 관리형 해결 조치는 Systems Manager Automation 실행서(runbook)를 호출하여 구성 드리프트(drift)를 수정합니다. SQS ApproximateAgeOfOldestMessage 및 Lambda IteratorAge에 대한 CloudWatch 경보는 OpsCenter에 OpsItem을 생성합니다. 연관된 실행서는 특정 Lambda의 프로비저닝된 동시성을 확장하거나, Step Functions 예약 용량을 늘리거나, 일시적으로 배치 창을 넓힙니다. AWS Health의 EC2 유지 관리 이벤트에 대한 EventBridge 규칙은 SSM Automation 문서를 대상으로 하여 유지 관리 기간 동안 영향을 받는 인스턴스를 정상적으로 재시작합니다. OpsCenter + Automation을 사용하는 이유: 클릭 한 번 또는 자동으로 최소 권한 해결 조치를 실행하여 중앙에서 감사 가능한 이슈 추적을 제공하며, 여러 계정/리전에서 안전하게 실행됩니다.

이 설계는 버퍼링과 팬아웃을 통해 플래시 세일 트래픽 급증을 견디고, 오케스트레이션을 통해 비즈니스 불변성(invariant)을 보존하며, 몇 초 내에 분석 결과를 제공하고, 정책 기반의 자동화된 해결 조치로 전체 프로세스 루프를 완성합니다.

← 고가용성 · 모든 도메인 · 스토리지 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →