log weekly february 2025 step functions lambda

웹훅의 재귀 원인 찾기

2025년 2월 7일 금요일

Today I Learned

날짜

2025년 2월 7일 금요일

내용

재귀의 원인

새로 구축한 웹훅 시스템에서 종종 재귀가 탐지되었다고 알람이 발생하고 있다. 루프를 탈출하지 못하고 계속 빙빙 돌고 있다는 건데.. 분명 내가 구현한 함수중에는 자기 자신을 호출할 일은 없기 때문에 이 문제가 이해되지 않았다… 우선 어떤 경우에 AWS가 재귀라고 판단하는지 알아봤다.

문서에 따르면 16회 정도 이상 호출되면 재귀라고 판단하는데, 이 판단은 헤더에 있는 특정 값으로 판단한다고 한다. 뭐 어찌됐든… 실제로 테스트서버에서 실태를 확인해봤다. 로직을 일부러 실패해서 총 몇번 재시도 하는지를 확인하면 된다. 웹훅을 2회(1번만 하려고 했는데 실수함) 호출하고 SQS 트리거 람다 함수와, Step Functions이 몇번 호출되었는지 확인해봤다.

1

우선 SQS의 트러기 람다 함수는 129번이 호출되었다… 메시지 2개가 다 실패했어도 최대 6번이었어야 했다.

2

Step Functions 상태머신은 감동실화로 총 900번이상 호출되었다…

3

아주 골때리는건 메시지도 1000개 이상 수신되었다.

단 2번의 웹훅을 서버에 보냈을 뿐인데 왜 이렇게 늘어났을까. 원인은 각 요소에 적용되어 있는 재시도 로직이었다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

  "Retry": [
    {
      "ErrorEquals": [
        "Lambda.ServiceException",
        "Lambda.AWSLambdaException",
        "Lambda.SdkClientException",
        "Lambda.TooManyRequestsException"
      ],
      "IntervalSeconds": 1,
      "MaxAttempts": 3,
      "BackoffRate": 2,
      "JitterStrategy": "FULL"
    }
  ],

Step Functions 정의에 각 단계별로 들어가 있는 코드다. 실패할 경우 상태머신을 재시도 한다. 처음 실패하면 1초 후 재시도, 그다음 1+2 후 재시도 해서 총 3번 재시도한다.

4

람다 자체에도 재시도 관련 설정이 있다. 지금은 0으로 설정되어있었지만 기존에는 2였다.

따라서

  1. 메시지가 어떤 이유로 실패한다.
  2. 그 메시지는 내가 설계한 재시도 로직에 따라 기존 큐에 다시 들어간다.
  3. 이때 상태머신이 동작을 실패했으므로 재시도한다
    1. 각 재시도들은 또 실패하면서 기존 큐에 메시지를 또 집어넣는다.
  4. 상태머신에 포함된 람다도 실패했으므로 람다도 재시도한다.
    1. 람다가 재시도하면서 메시지가 늘어난다.
  5. 메시지 한개가 나가서 실패했지만 여러개로 늘어난다.
  6. 각 메시지들은 이 과정을 재귀적으로 반복한다.

이렇게 추정했다.상태머신 정의에서 재시도 관련 로직을 삭제했으니 두고볼 예정이다.

ECR 이미지 생명주기 정책

쇼피파이 알파플러스에 관해 이슈가 들어왔다. 확인해보니 무려 리뷰 서버가 꺼져있다… 뭔일인가 싶어 찾아봤는데 서버 컨테이너를 돌리는데 필요한 ECR이 모두 날아가고 없다. 이게 뭔가 싶어 일단 빨리 복구시켜놓고 원인을 찾았는데..

5

ECR 왼쪽에 Lifecycle Policy가 있다. 여기서 사용하지 않거나 오래된 이미지들이 자동으로 삭제될 수 있도록 정책을 설정할 수 있는데, 이 정책으로인해 실서버가 사용중인 이미지까지 삭제해버렸다….

회고

필요한 데이터를 찾아 csv로 제공하는 기능을 생성 중. 구독과 청구서를 포함해서 알아야 할게 너어무 많다.

CATALOG
    weekly