우리는 앞서 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로 옮기는 것은 다음 편에서