synchronous Lambda Retry (1) (feat. CloudWatch, Firehose)

Falcon·2021년 8월 13일
2

aws

목록 보기
15/35
post-thumbnail

🎯 Goal

  • Kinesis Firehose 의 용도를 알 수 있다.
  • Cloudwatch logs 의 구독 필터를 사용하여 '에러'로그만 남길 수 있다.
  • CloudWatch logs + Firehose 에 필요한 IAM Role 설정을 할 수 있다.
  • 최종적으로, 동기적 람다함수에 대한 재시도 매커니즘을 구현해낸다.

우리는 앞서 1편에서 Asynchronous Lambda + SQS (Dead Letter Queue)를 통해 쓰로틀링 발생시 재시도하는 매커니즘을 구현해냈다.

애석하게도, 동기적 람다 호출에서는 재시도 매커니즘이 존재하지 않으므로 스스로 구현해 내야한다.

이 글에서, 그 해법에 대한 실마리를 찾아가보자.


CloudWatch Logs

동기적 람다호출의 맹점은 쓰로틀링이 발생 했을 때, Cloudwatch logs 에 로그도 남지 않고, DLQ에 보내지지도 않는다는 것이다.

람다호출에 에러 발생시 CloudWatch Logs 를 남길 수 있는 방법이 있다.

Kinesis Firehose

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으로 압축된다

다음과 같은 흐름을 갖는다.

  1. CloudWatch Logs to S3 using Filtering
  2. connect logs to S3 by Kinesis Firehose
  3. S3 to SQS

Buffer size limit (default: 1 MB)

Architecture Overview


1. Kinesis Firehose 생성

대상 S3 Bucket도 같이 설정한다.

2. CloudWatch Logs 구독 필터 생성

❌ Event Rule Pattern Filter ❌

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는 이벤트를 발생시키지 못한다.

👌 Subscription Filter 👌

순조롭게 '스트리밍 시작'버튼을 누르면
흔히 다음과 같은 에러메시지를 마주하게된다.

Could not deliver test message to specified Firehose stream. Check if the given Firehose stream is in ACTIVE state.

Firehose State Active      아니.. 켜져있는데 왜 안되는거야?"

보통 IAM Role 권한 설정 때문이다.

3. IAM Role 설정

Firehose는 Cloudwatch logs 데이터를 S3 로 '연결'시켜준다.
이를 위해 크게 2가지 권한설정이 필요하다.

(1) CloudWatch Logs to Firehose

Firehose 모든 권한 허용 정책에 역할 연결
Firehose: *

(2) Firehose to S3

  • GetBucketLocation
  • GetBucketObjectLockConfiguration
  • GetObjectAcl
  • PutObject

스트리밍된 데이터가 S3에 써지기위해.

CloudWatch Logs to Firehose 신뢰관계 설정

신뢰관계는 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"
    }
  ]
}

구독필터 생성 완료

Test

다음과 같은 순서로 서비스가 흘러간다.

  1. Lambda의 예약 동시성 (Reserved Concurrency) 을 0으로 설정
  2. lambda 호출
  3. CloudWatch Logs 에 에러 로그 생성됨 (Throttling, 429 Too Many Requests)
  4. 에러 로그가 구독 필터에 의해 자동으로 Firehose를 타고 S3로 넘어감.
  5. S3에 에러 로그파일 오브젝트가 생성됨.




S3에 로깅된 데이터를 SQS로 옮기는 것은 다음 편에서


🔗 Reference

profile
I'm still hungry

0개의 댓글