aws 람다를 이용한 서비스 폭파 후기

사건의 흐름

03.23

테스트 환경을 분리중이었는데, 람다쪽 환경을 어떻게 분리할까 하다가 그냥 테스트용 메서드를 하나 더 만들기로 생각했다. 그렇게 대충 구상만 하며 오전을 뒹굴뒹굴 보냈다.

21:30

# 기존 값
service: mapshot-image-lambda

provider:
  name: aws
  runtime: nodejs14.x
  memorySize: 4096
  timeout: 30
  region: ap-northeast-2
functions:
  start:
    handler: src/index.handler
    events:
      - http:
        path: /lambda
        method: get
        
# 변경되는 값

# ...
functions:
  prod:
    handler: src/index.handler
    events:
      - http:
        path: /lambda
        method: get
  dev:
    handler: src/index-dev.handler
    events:
      - http:
        path: /lambda-dev
        method: get

본격적으로 코드 작업을 시작했다. serverless 툴을 이용해서 배포를 진행중인데 yml 파일 내용들을 좀 변경하고 싶었다. 그런데 한 가지 불안했던게, 혹시나 여기 값들을 바꾸면 도메인 주소가 새로 할당되거나 기존 레이어, 게이트웨이들 설정에 영향이 없는지 걱정되었다. 검색해도 유사한 사례 발견이 힘들어서 우리의 GPT 선생님에게 물어봤다.

얘를 믿은 내가 바보였다. 정확한 맥락 설명을 제대로 못해준 내가 바보인가.

아주 상쾌한 마음으로 serverless deploy를 실행했고, 그대로 모든 설정이 날아감과 동시에 서비스가 터졌다.

람다가 function쪽을 새로 생성하면서 기존에 생성되어 있던 람다는 날려버렸고, 같이 들고있던 API 게이트웨이까지 물고 떠나버렸다. 이때까지 안이하게 생각했던게, 그냥 롤백하면 되겠지 싶어서 콘솔창을 이리저리 찾아다녔다. 그런데 결국 못찾았다. 나중에 찾아보니 미리 설정해놓지 않으면 쉽지 않은 구조인 것 같다.

롤백이 안되면 그냥 예전 설정으로 다시 배포해서 API 게이트웨이만 빨리 새로 붙여주면 되겠다 생각했고, 다시 serverless deploy를 입력하는 순간 이제는 배포도 안된다. node14 버전은 이제 지원을 안한다고 버전을 올려달랜다.

마음도 급해 죽겠는데 부랴부랴 버전 올리고 레이어 호환 설정들 다시 해줬다. 그랬더니 이젠 코드 실행이 안된다. 찾아보니 메인으로 활용하고 있는 라이브러리에서 지원을 종료했댄다. 노드 버전을 낮추라고 한다. 진퇴양난이다.

22:00

일단 공지라도 써놓기로 했다. 사실 안써도 별 상관 없는게 업무 자동화 사이트라서 주말 밤에는 어차피 아무도 안온다. 그래도 혹시 모르니 일단 써놨다. 지금 생각하니 뭔 서비스가 점검 시작 10분전에 공지를 하나 싶다.

본격적으로 로그를 찍어보면서 코드를 수정해나갔다. 일단 기존에 사용하던 라이브러리를 걷어내고 대체할만한 놈을 찾아서 새로 코드를 작성했다. 그랬더니 펑펑 터진다. 내 코드문제라기보다는 버전에 따른 호환성들이 문제였던 것 같다. 이 상황에 내가 버전별로 다 테스트를 해볼 수는 없으니, 해당 라이브러리의 이슈나 PR에서 비슷한 에러들 뒤져보면서 작동한다는 버전으로 라이브러리와 노드의 버전을 맞춰나갔다.

23:00

//   동작 안함
//   await browser.close()
  
  let browserPid = browser.process()?.pid

  if (browserPid) {
      process.kill(browserPid)
  }

이제 거의 다 동작하는데 얘가 응답값 리턴을 안한다. 구간별로 로그를 찍어보니 프로세스가 종료되어야 하는데 종료를 못해서 진도가 안나가고 있다.

뭘로 수정해도 종료가 안되길래, 좋은 방법은 아닐것 같긴한데 프로세스 아이디값 얻어와서 그냥 kill 해버렸다. 그렇게 했더니 드디어 응답값이 정상으로 왔고, 서비스가 정상화되었다.

후기

API 진입점을 날려먹어버렸으니 서비스 규모가 컸으면 대참사였다. 주말에 트래픽이 거의 없는 점이 오히려 나를 너무 안이하게 만들었던 것 같다.

그동안 몇 번 펑펑 터트린 경험이 있어서 그런지 당황하기보다는 빠르게 대처를 한 편인것 같다. 기존에는 평일 낮에 터트려서 아주 다이나믹 했는데, 주말 밤이라 사고회로가 잘 굴러간 것 같기도 하다.

예전에 유튜브 보다가 ‘목표의 크기가 내 방법을 정한다’는 말을 들은 적이 있는데, 목표를 트래픽으로 치환하면 개발이랑 딱 맞을것 같아서 기억이 난다. 배포할때는 최대한 신중하게 다양한 케이스를 생각해서 진행해야겠다.

참고

• 내 경험