[CLOUD-008][중급] 이벤트로 서버리스 함수 실행하기
페이지 정보
본문
[이번 수업]
서버리스 함수는 이벤트가 올 때 코드를 실행하고 기반 운영을 서비스가 맡는 방식입니다. 서버가 사라진다는 뜻은 아닙니다. 이벤트 구조, 처리 흐름, 재시도와 중복에 대비하는 멱등성을 배웁니다.
[선수지식]
CLOUD-007의 컨테이너와 오케스트레이션, JSON과 함수 입력·출력을 알아야 합니다.
[학습목표]
1. 이벤트 생산자, 전달자, 소비자의 역할을 설명할 수 있습니다.
2. 사건 식별자와 종류를 검증하는 함수를 작성할 수 있습니다.
3. 같은 이벤트가 다시 와도 결과가 한 번만 생기게 설계할 수 있습니다.
[핵심개념]
이벤트는 ‘주문이 생성됨’처럼 일어난 사건입니다. 생산자는 만들고, 전달자는 큐나 브로커로 옮기며, 소비자인 함수는 작업합니다. 서로 주소를 몰라도 되지만 이벤트 형식과 실패 규칙은 정해야 합니다.
CloudEvents는 사건을 공통 형식으로 설명하는 사양입니다. 필수 속성은 `specversion`, `id`, `source`, `type`입니다. 같은 `source`와 `id`는 중복 판정 키로 쓸 수 있습니다. `data`는 업무 자료이며 `time`은 선택 속성입니다. 형식이 맞아도 발신자가 신뢰된다는 뜻은 아닙니다.
함수는 이벤트를 검증하고 결과를 외부 저장소나 다른 이벤트로 남깁니다. 실행 환경은 사라질 수 있어 메모리는 영구 저장소가 아닙니다. 비동기 전달은 실패 시 재시도될 수 있습니다. 멱등성은 같은 입력을 거듭 처리해도 첫 처리 뒤 결과가 더 바뀌지 않는 성질입니다. 사건 키를 원자적으로 기록하고, 계속 실패한 이벤트는 제한된 재시도 뒤 별도 보관소에서 조사합니다.
[따라하기]
아래를 event_handler.py로 저장하세요. 같은 사건의 두 번째 처리를 건너뜁니다.
```python
processed = set()
def handler(event):
required = {"specversion", "id", "source", "type", "data"}
if required - event.keys():
return "invalid event"
key = (event["source"], event["id"])
if key in processed:
return f"duplicate skipped: {event['id']}"
if event["type"] != "order.created":
return "unsupported type"
order_id = event["data"].get("order_id")
if not isinstance(order_id, str) or not order_id:
return "invalid order_id"
processed.add(key)
return f"processed: {order_id}"
event = {
"specversion": "1.0", "id": "evt-100",
"source": "/local/orders", "type": "order.created",
"data": {"order_id": "o-100"},
}
print(handler(event))
print(handler(event))
```
Windows는 `py event_handler.py`, macOS와 Linux는 `python3 event_handler.py`로 실행합니다. 예상 결과입니다.
```text
processed: o-100
duplicate skipped: evt-100
```
set은 한 프로세스에서만 유지됩니다. 운영에서는 여러 함수가 함께 쓰는 영구 저장소에 `source + id`를 조건부 쓰기로 기록해야 합니다.
[흔한 실수]
첫째, 재시도를 고려하지 않아 결제·메일 같은 효과가 중복됩니다. 둘째, 함수 메모리나 임시 파일에 중요 상태를 둡니다. 셋째, 실패 보관소와 경보가 없어 재시도가 끝난 이벤트를 잃습니다. 실행시간, 동시 실행 수, 이벤트 크기 제한도 확인해야 합니다.
[보안 주의]
본인 소유의 로컬·격리 환경에서만 실습하세요. 전송 경로를 인증·암호화하고 `source` 문자열만으로 발신자를 믿지 않습니다. 허용한 type만 처리하며 자료형, 길이, 중첩 깊이를 제한하세요. 이벤트와 로그에 비밀번호, 접근 토큰, 불필요한 개인정보를 넣지 않습니다. 함수 권한은 필요한 큐와 저장소 작업만 허용합니다.
[직접 해볼 과제]
`order.cancelled`를 허용 목록에 추가하세요. id가 같고 data만 다른 중복 이벤트를 넣어 건너뛰는지 확인하고, 영구 저장소에서 원자적 조건부 쓰기가 필요한 이유를 설명하세요.
[확인문제]
1. CloudEvents에서 사건을 중복 판정할 때 함께 쓰는 두 속성은 무엇인가요?
2. 함수의 메모리를 영구 저장소로 쓰면 안 되는 이유는 무엇인가요?
3. 실패 이벤트를 무한 재시도하지 않고 따로 보관하는 이유는 무엇인가요?
[다음 학습]
다음 DEVOPS-008에서는 로그·메트릭·트레이스를 연결해 시스템 상태를 관찰합니다.
[공식 참고 자료]
서버리스 개요 백서: https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf
CloudEvents 1.0.2 핵심 사양: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md
함수의 멱등성 공식 권고: https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
이벤트 재시도와 실패 보관 공식 문서: https://knative.dev/docs/eventing/event-delivery/
서버리스 함수는 이벤트가 올 때 코드를 실행하고 기반 운영을 서비스가 맡는 방식입니다. 서버가 사라진다는 뜻은 아닙니다. 이벤트 구조, 처리 흐름, 재시도와 중복에 대비하는 멱등성을 배웁니다.
[선수지식]
CLOUD-007의 컨테이너와 오케스트레이션, JSON과 함수 입력·출력을 알아야 합니다.
[학습목표]
1. 이벤트 생산자, 전달자, 소비자의 역할을 설명할 수 있습니다.
2. 사건 식별자와 종류를 검증하는 함수를 작성할 수 있습니다.
3. 같은 이벤트가 다시 와도 결과가 한 번만 생기게 설계할 수 있습니다.
[핵심개념]
이벤트는 ‘주문이 생성됨’처럼 일어난 사건입니다. 생산자는 만들고, 전달자는 큐나 브로커로 옮기며, 소비자인 함수는 작업합니다. 서로 주소를 몰라도 되지만 이벤트 형식과 실패 규칙은 정해야 합니다.
CloudEvents는 사건을 공통 형식으로 설명하는 사양입니다. 필수 속성은 `specversion`, `id`, `source`, `type`입니다. 같은 `source`와 `id`는 중복 판정 키로 쓸 수 있습니다. `data`는 업무 자료이며 `time`은 선택 속성입니다. 형식이 맞아도 발신자가 신뢰된다는 뜻은 아닙니다.
함수는 이벤트를 검증하고 결과를 외부 저장소나 다른 이벤트로 남깁니다. 실행 환경은 사라질 수 있어 메모리는 영구 저장소가 아닙니다. 비동기 전달은 실패 시 재시도될 수 있습니다. 멱등성은 같은 입력을 거듭 처리해도 첫 처리 뒤 결과가 더 바뀌지 않는 성질입니다. 사건 키를 원자적으로 기록하고, 계속 실패한 이벤트는 제한된 재시도 뒤 별도 보관소에서 조사합니다.
[따라하기]
아래를 event_handler.py로 저장하세요. 같은 사건의 두 번째 처리를 건너뜁니다.
```python
processed = set()
def handler(event):
required = {"specversion", "id", "source", "type", "data"}
if required - event.keys():
return "invalid event"
key = (event["source"], event["id"])
if key in processed:
return f"duplicate skipped: {event['id']}"
if event["type"] != "order.created":
return "unsupported type"
order_id = event["data"].get("order_id")
if not isinstance(order_id, str) or not order_id:
return "invalid order_id"
processed.add(key)
return f"processed: {order_id}"
event = {
"specversion": "1.0", "id": "evt-100",
"source": "/local/orders", "type": "order.created",
"data": {"order_id": "o-100"},
}
print(handler(event))
print(handler(event))
```
Windows는 `py event_handler.py`, macOS와 Linux는 `python3 event_handler.py`로 실행합니다. 예상 결과입니다.
```text
processed: o-100
duplicate skipped: evt-100
```
set은 한 프로세스에서만 유지됩니다. 운영에서는 여러 함수가 함께 쓰는 영구 저장소에 `source + id`를 조건부 쓰기로 기록해야 합니다.
[흔한 실수]
첫째, 재시도를 고려하지 않아 결제·메일 같은 효과가 중복됩니다. 둘째, 함수 메모리나 임시 파일에 중요 상태를 둡니다. 셋째, 실패 보관소와 경보가 없어 재시도가 끝난 이벤트를 잃습니다. 실행시간, 동시 실행 수, 이벤트 크기 제한도 확인해야 합니다.
[보안 주의]
본인 소유의 로컬·격리 환경에서만 실습하세요. 전송 경로를 인증·암호화하고 `source` 문자열만으로 발신자를 믿지 않습니다. 허용한 type만 처리하며 자료형, 길이, 중첩 깊이를 제한하세요. 이벤트와 로그에 비밀번호, 접근 토큰, 불필요한 개인정보를 넣지 않습니다. 함수 권한은 필요한 큐와 저장소 작업만 허용합니다.
[직접 해볼 과제]
`order.cancelled`를 허용 목록에 추가하세요. id가 같고 data만 다른 중복 이벤트를 넣어 건너뛰는지 확인하고, 영구 저장소에서 원자적 조건부 쓰기가 필요한 이유를 설명하세요.
[확인문제]
1. CloudEvents에서 사건을 중복 판정할 때 함께 쓰는 두 속성은 무엇인가요?
2. 함수의 메모리를 영구 저장소로 쓰면 안 되는 이유는 무엇인가요?
3. 실패 이벤트를 무한 재시도하지 않고 따로 보관하는 이유는 무엇인가요?
[다음 학습]
다음 DEVOPS-008에서는 로그·메트릭·트레이스를 연결해 시스템 상태를 관찰합니다.
[공식 참고 자료]
서버리스 개요 백서: https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf
CloudEvents 1.0.2 핵심 사양: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md
함수의 멱등성 공식 권고: https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
이벤트 재시도와 실패 보관 공식 문서: https://knative.dev/docs/eventing/event-delivery/
- 이전글[DEVOPS-008][중급] 세 가지 관측 신호 연결하기 26.09.03
- 다음글[NET-008][중급] 프록시와 로드밸런서 흐름 이해하기 26.09.03
댓글목록
등록된 댓글이 없습니다.