우리는 앞서 1편에서 Asynchronous Lambda + SQS (Dead Letter Queue)를 통해 쓰로틀링 발생시 재시도하는 매커니즘을 구현해냈다.
애석하게도, 동기적 람다 호출에서는 재시도 매커니즘이 존재하지 않으므로 스스로 구현해 내야한다.
이 글에서, 그 해법에 대한 실마리를 찾아가보자.
동기적 람다호출의 맹점은 쓰로틀링이 발생 했을 때, Cloudwatch logs 에 로그도 남지 않고, DLQ에 보내지지도 않는다는 것이다.
람다호출에 에러 발생시 CloudWatch Logs 를 남길 수 있는 방법이 있다.
Cloudwatch Logs로부터 다른 서비스로 실시간으로 스트리밍을 할 수 있게하는 서비스다.
정식 명칭은 'Amazon Kinesis Data Firehose stream'이다.
If the destination service returns a retryable error such as a throttling exception or a retryable service exception (HTTP 5xx for example), CloudWatch Logs continues to retry delivery for up to 24 hours.
-AWS Document
이런 효자가 어디있나?, 한마디로 요약하면, 재시도 할만한 것들은 24시간 동안 재시도하고 어차피 해도 안될 요청은 곧바로 버린다는 것이다.
gzip으로 압축된다
다음과 같은 흐름을 갖는다.
Buffer size limit (default: 1 MB)
대상 S3 Bucket도 같이 설정한다.
Event rule pattern 에 따라 필터링할 수 있다.
This is because the only events for
logs
available are AWS API Call via CloudTrail.
👉🏻 애석하게도aws.logs
는 AWS API Call via CloudTrail 만을 가리킨다. 따라서, CloudWatch Logs는 이벤트를 발생시키지 못한다.
순조롭게 '스트리밍 시작'버튼을 누르면
흔히 다음과 같은 에러메시지를 마주하게된다.
아니.. 켜져있는데 왜 안되는거야?"Could not deliver test message to specified Firehose stream. Check if the given Firehose stream is in ACTIVE state.
보통 IAM Role 권한 설정 때문이다.
Firehose는 Cloudwatch logs 데이터를 S3 로 '연결'시켜준다.
이를 위해 크게 2가지 권한설정이 필요하다.
Firehose 모든 권한 허용 정책에 역할 연결
Firehose: *
스트리밍된 데이터가 S3에 써지기위해.
신뢰관계는 IAM Role을 맡을 수 있는 '개체'를 정의한다.
sts:AssumeRole
이 신뢰관계를 갖는 권한을 의미한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
다음과 같은 순서로 서비스가 흘러간다.
429 Too Many Requests
)S3에 로깅된 데이터를 SQS로 옮기는 것은 다음 편에서