Amazon SOA-C02: 서버리스 및 애플리케이션 통합 — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

서버리스 및 애플리케이션 통합은 서버 관리 없이 이벤트 기반 애플리케이션을 실행하고 서비스들을 안정적으로 연결하는 것을 다룹니다. 운영상의 중요성은 확장성, 지연 시간, 장애 모드 및 최소 권한 액세스를 관리하면서 비용을 예측 가능하게 유지하는 데 있습니다. 이 도메인은 Lambda 동작(콜드 스타트, 동시성), 안정적인 이벤트 전달(EventBridge, SNS, SQS), 보안 제어(실행 역할 및 권한), 비동기 흐름에 대한 관찰 가능성에 중점을 둡니다.

AWS Lambda 운영 측면 및 동시성

Lambda 성능과 가용성은 콜드 스타트, 동시성 한도, 스로틀링 제어에 따라 결정됩니다. 콜드 스타트는 Lambda가 새로운 실행 환경을 초기화해야 할 때 발생합니다. 지연 시간에 민감한 경로에 대해서는 프로비저닝된 동시성(

undefined

)을 사용하여 영향을 줄이고, 더 가벼운 런타임이나 더 작은 초기화 작업을 선호합니다. 다운스트림 서비스를 보호하고 함수별 할당량을 강제하기 위해 예약된 동시성(

undefined

)으로 동시성을 예약하고 제한합니다. ConcurrentExecutions 및 Throttles CloudWatch 지표를 모니터링하세요.

재시도 및 호출 모델은 모드에 따라 다릅니다. 동기식 호출(API Gateway, 직접 Invoke)은 오류를 즉시 반환합니다. 비동기식 호출(EventBridge, SNS, S3 비동기 알림)은 Lambda의 비동기 재시도 정책(백오프를 사용한 두 번의 재시도)을 사용하며 DLQ 또는 대상으로 보낼 수 있습니다. 이벤트 소스 매핑(SQS, Kinesis, DynamoDB 스트림)의 경우, Lambda 폴러는 메시지가 만료되거나 이벤트 소스의 리드라이브 정책이 데드 레터를 트리거할 때까지 재시도합니다. 타임아웃과 메모리를 보수적으로 구성하고(

undefined

) 중복 처리를 줄이기 위해 SQS 가시성 제한 시간을 함수 제한 시간보다 길게 설정합니다(가시성 제한 시간 >= 함수 제한 시간 * 2 권장).

EventBridge를 사용한 이벤트 기반 아키텍처

EventBridge는 유연한 라우팅, 스키마 레지스트리, 교차 계정 전달, 재시도/DLQ 설정을 갖춘 관리형 이벤트 버스를 제공합니다. 도메인 분리를 위해 사용자 지정 이벤트 버스를, SaaS 통합을 위해 파트너 이벤트 버스를 사용합니다. 패턴으로 규칙을 생성하고(

undefined

) 데드 레터 및 재시도 구성을 사용하여 대상을 연결합니다(targets JSON은 DeadLetterConfig 및 RetryPolicy를 지원). 스키마 레지스트리를 사용하여 이벤트 형태를 발견하고 강제 적용합니다. 생산자가 잘 정의된 경우 스키마를 등록하고, 도움이 되는 경우 코드 바인딩을 사용하여 타입이 지정된 모델을 생성합니다.

다음과 같은 경우 EventBridge를 선택하세요:

• 풍부한 이벤트 패턴 또는 교차 계정/이벤트 버스 격리를 통한 복잡한 라우팅 및 필터링
• 여러 대상(Lambda, Step Functions, Kinesis, SQS, SNS)에 대한 네이티브 지원
• 팀 간 스키마 검색 및 거버넌스

더 간단한 팬아웃 또는 보장된 큐 시맨틱이 필요한 경우 직접 SNS/SQS를 선택하세요:

• SNS: 다수의 구독자에게 팬아웃하고 푸시 시맨틱이 필요할 때
• SQS: 가시성 제한 시간 및 리드라이브 정책을 사용한 영구적인 풀 기반 처리가 필요할 때

SNS 및 SQS를 사용한 메시징 (DLQ, 가시성 제한 시간)

SNS는 pub/sub 푸시 서비스이고, SQS는 풀 시맨틱을 갖춘 영구적인 큐입니다. 고신뢰성 처리를 위해서는 SNS -> SQS -> Lambda 패턴을 선호하여 수집과 처리를 분리하고 재시도 및 가시성에 대한 제어권을 확보하는 것이 좋습니다. SQS 리드라이브 정책(

undefined

)을 구성하여 maxReceiveCount 이후 메시지를 DLQ로 이동시키고, 조기 재전송을 피하기 위해 가시성 제한 시간이 충분히 긴지 확인합니다(가시성 제한 시간 >= 함수 제한 시간 * 2 권장). FIFO가 필요한 경우, SQS FIFO 또는 SNS FIFO를 메시지 그룹 ID와 함께 사용하여 순서를 보존하고, 중복 제거 ID를 사용하여 중복을 방지합니다.

데드 레터 처리 옵션 및 사용 사례:

• Lambda 비동기 호출: 실패를 SQS/SNS로 보내거나 다른 Lambda를 호출하도록 DeadLetterConfig 또는 Destinations(AsyncEventInvokeConfig)를 구성합니다.
• SQS: 포이즌 메시지를 위해 SQS DLQ로 리드라이브 정책을 구성하고 적절한 maxReceiveCount를 설정합니다.
• EventBridge: 전달할 수 없는 이벤트를 캡처하기 위해 규칙 대상에 DeadLetterConfig 및 RetryPolicy를 설정합니다.

멱등성은 필수적입니다. DynamoDB 조건부 쓰기(PutItem에 ConditionExpression attribute_not_exists(pk) 사용), TTL과 함께 저장된 멱등성 토큰, 또는 정확히 한 번(exactly-once) 시맨틱을 위한 SQS FIFO 중복 제거를 사용하여 멱등성 핸들러를 구현합니다.

함수 권한, 역할 및 최소 권한

Lambda 실행 역할 및 함수 리소스 정책에 최소 권한을 적용합니다. CloudWatch Logs를 위해 AWSLambdaBasicExecutionRole으로 시작한 다음, 서비스에 대한 명시적인 리소스 ARN(예: arn:aws:dynamodb:region:acct:table/MyTable에 대한 dynamodb:PutItem)을 부여합니다. 특정 ARN을 사용할 수 있는 경우 Resource: “*“와 같은 와일드카드를 피합니다. 작업 및 리소스별로 범위가 지정된 관리형 또는 사용자 지정 정책을 사용하고, 서비스에 대한 호출 권한을 추가할 때 조건(aws:SourceAccount, aws:SourceArn)을 포함합니다:

• EventBridge에 대한 호출 권한 추가:

undefined

• SNS의 경우: source-arn 조건을 사용하여 함수를 호출할 수 있는 토픽을 제한합니다.

결정 기준:

• 서비스 호출(EventBridge, SNS, CloudWatch Events)을 허용하기 위해 함수 리소스 기반 정책을 사용합니다.
• 런타임 권한(DynamoDB, S3, Secrets Manager)을 위해 IAM 실행 역할을 사용합니다.
• 영향 반경을 줄이기 위해 리소스 수준 권한 및 조건부 제약 조건을 선호합니다.

서버리스의 관측 가능성 및 문제 해결

관측 가능성은 지표, 로그, 추적, 비동기 전송 상태를 모두 포함해야 합니다. 주요 CloudWatch 지표: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (스트림 및 SQS 트리거용). 비동기 실패 가시성을 위해 “AsyncEventInvoke” 지표를 모니터링하고 DeadLetterErrors 및 Throttles에 CloudWatch 경보를 설정하십시오. X-Ray 추적(

undefined

)을 활성화하여 서비스 전반에 걸친 엔드투엔드 추적을 확보하고 콜드 스타트, 다운스트림 지연 시간 및 예외를 시각화하십시오.

구조화된 JSON 로그와 CloudWatch Logs Insights 쿼리를 사용하여 오류 패턴을 신속하게 찾으십시오. 멱등성 검사를 구현하고 로그에 상관관계 ID를 기록하십시오. 분산 추적의 경우, 자동 컨텍스트가 손실되면 EventBridge/SNS 흐름의 이벤트 페이로드에 추적 ID를 명시적으로 전파하십시오. SQS 이벤트 소스 매핑의 경우, ApproximateAgeOfOldestMessage를 모니터링하고 이 값이 증가하면 경보를 설정하십시오. 이는 백프레셔나 스로틀링을 나타냅니다. Lambda Throttles 지표를 캡처하고 경보를 설정하며, 프로비저닝된 동시성의 사용량/비용 트레이드오프를 추적하십시오.

일반적인 함정과 의사결정 기준

• DLQ를 구성하지 않거나 기본 재시도에만 의존: 비동기 Lambda에는 DLQ 또는 Destinations를, SQS 대기열에는 재구동(redrive) 정책을 구성하여 수동 검사를 위해 포이즌 메시지를 캡처하십시오.
• SQS의 잘못된 제한 시간 초과(visibility timeout) 설정으로 인한 중복 처리: 중복을 피하기 위해 제한 시간 초과를 함수 제한 시간 * 2 이상으로 설정하고 재시도 및 다운스트림 호출을 고려하십시오.
• 과도하게 허용적인 Lambda 실행 역할: Resource: “*“를 피하고 호출 및 리소스 정책에 서비스/소스 조건(aws:SourceArn, aws:SourceAccount)을 추가하십시오.
• 동시성 한도를 무시하여 스로틀링 발생: 예약된 동시성을 사용하여 함수 상한을 설정하고, 지연 시간에 민감한 함수에는 프로비저닝된 동시성을 사용하며, ConcurrentExecutions/Throttles를 모니터링하십시오.
• 비동기 경계 간 추적 누락: 이벤트에 상관관계 ID를 추가하고 X-Ray를 활성화하거나 추적 헤더를 전파하여 흐름을 재구성하십시오.
• 내구성이 필요한 경우 SNS에서 Lambda로 직접 연결하는 방식의 오용: 내구성 있는 버퍼링, 가시성 제어, 더 쉬운 DLQ 처리가 필요할 때는 SNS->SQS->Lambda 방식을 선호하십시오.

실용적인 문제: 사용 사례 시나리오

AcmePayments는 EventBridge를 통해 대량의 결제 이벤트를 수신하며, 피크 시간대에 간헐적인 Lambda 스로틀링과 중복 처리를 경험합니다. 이들은 신뢰할 수 있는 처리, 데이터 손실 없음, DynamoDB에 대한 다운스트림 부하 제한이 필요합니다.

1. 결제 이벤트를 매칭하기 위한 EventBridge 사용자 지정 버스와 규칙을 생성합니다. 대상 구성에 DeadLetterConfig 및 RetryPolicy를 포함하여 SQS FIFO 대기열을 내구성 있는 대상으로 추가합니다.
2. 다운스트림 용량에 맞춰 조정된 배치 크기와 함수 제한 시간 * 2 이상으로 설정된 제한 시간 초과(visibility timeout)를 사용하여 Lambda가 SQS 대기열을 폴링하도록(이벤트 소스 매핑) 구성합니다.
3. Lambda에 예약된 동시성(

undefined

)을 설정하여 DynamoDB 쓰기 버스트를 제한합니다. 낮은 지연 시간이 필요한 경우 작은 풀에 프로비저닝된 동시성을 구현합니다. 4. payment-id를 키로 사용하는 DynamoDB 조건부 쓰기를 통해 멱등성을 구현하고, 정리를 위해 TTL이 있는 멱등성 레코드를 저장합니다. 5. X-Ray 추적과 이벤트에 상관관계 ID가 포함된 구조화된 로그를 활성화하여 처리를 추적합니다. ApproximateAgeOfOldestMessage, Throttles, DLQ 지표에 CloudWatch 경보를 설정합니다.

근거: EventBridge와 SQS를 분리하면 내구성 있는 버퍼링과 재시도 의미 체계가 제공됩니다. 예약된 동시성은 다운스트림 DynamoDB를 버스트로부터 보호하고, 멱등성은 중복을 방지하며, 추적/경보는 장애 모드에 대한 운영 가시성을 제공합니다.

← 데이터베이스 및 캐싱 · 모든 도메인 · 비용 관리 및 리소스 태깅 →

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

Amazon 찾아보기 →