장애 회고 | 새로운 테이블 생성

장애 회고를 시작합니다...!

이번이 첫 번째 장애 회고입니다.

되도록 장애가 일어나는 일은 없어야겠지만 사람인지라 실수가 있을 것입니다. 안타깝게도...
따라서 저는, 장애 회고록을 통해 같은 실수를 반복하지 않고 실수가 있더라도 빠르게 극복하는 방안을 찾고자 합니다.

간단하게 우리 서비스에 사용되는 백엔드 기술 스택을 소개하면 이렇습니다(제가 백엔드 개발자이기 때문에 백엔드를 소개하며 채용 공고에 나와 있던 정도의 스택만 소개합니다).

• 백엔드: 장고,
• 서버: AWS lambda,
• DBMS: PostgreSQL

장애 내용

우리 서비스에서는 사용자 알림 설정에서 기존에 마케팅 동의 정보를 포함해 4개의 테이블을 통해 해당 정보를 수집하고 있었습니다.
편의상 A, B, C, 그리고 마케팅 테이블이라 부르겠습니다.

그런데 이를 나누어 정보를 받는 것은 불필요 하다 여겨져 A, B, C를 정보 알림으로 통합하고 정보 알림과 마케팅 알림 두 가지 정보만을 알림 테이블이라는 새로운 테이블에 담아 저장하기로 결정했습니다.

새로운 알림 테이블에 들어가는 필드는 다음과 같습니다.

• 유저 id
• 정보 알림 동의 시각(동의 하지 않는다면 NULL)
• 마케팅 알림 동의 시각(동의 하지 않는다면 NULL)

이를 위해서는 기존 테이블 데이터를 새로운 테이블로 마이그레이션 하는 과정이 필요했습니다.
일단 A, B, C 테이블에서 하나라도 동의하지 않는 경우가 있다면 정보 알림 동의 시각을 NULL로 저장하기로 했습니다.

그리고 앱의 버전을 업데이트 하기 전까지는 기존 api와 새로운 api를 모두 사용해 데이터를 저장하다가 업데이트 후 api v1은 제거할 예정이었습니다.

그럼 이제 해야 되는 일은 정해졌습니다.

1. 알림 테이블을 생성한다.
2. api v2에 새로운 알림 동의 정보를 저장한다.
3. 기존에 사용하던 api v1에서도 새로운 테이블에 사용자 알림 동의 정보를 저장할 수 있는 로직을 생성한다.
4. 시간이 지난 후 api v1을 삭제한다(강제 업데이트).
5. 기존 4개의 테이블에 들어가던 데이터들을 규칙에 따라 알림 테이블로 마이그레이션 한다.
6. 배포 한다.

장애 원인

위의 방법대로만 잘 되었다면 좋았을 것입니다. 배포 전에 개발 환경에서 모든 테스트를 끝냈고, 잘 되는걸 확인한 뒤 운영 환경에 배포를 진행하려 했습니다.
그러려면 로컬에서 prod DB에 테이블 생성 -> 데이터 마이그레이션 -> 운영 서버에 배포 의 과정을 거쳐야 했습니다.

하지만 저는 순간적으로 배포 후 테이블을 생성 하고 마이그레이션을 하면 될 것이라는 생각이 들었습니다.
그래서 바로 운영 서버에 배포하기 위한 스크립트를 실행했고, 실행 후 운영 서버 업데이트 알림이 오자마자 부랴부랴 배포 환경에 테이블을 생성(zappa manage prod migrate)하고 마이그레이션(마이그레이션 스크립트 실행)을 시도했습니다.
그러나, 센트리가 마구 울리기 시작했습니다.

운영 서버에는 조회할 테이블이 없으니 당연히 500 에러가 난 것입니다...

저의 배포 순서가 잘못 됐습니다.

해결 방안

아주 초보적인 실수라고 생각했습니다(실제로도 현업 2개월차 주니어이긴 합니다만 그래도 너무 바보 같은 실수라 자괴감이 들었습니다). 그래서 바로 주변에 도움을 청했고 아래의 과정을 거쳐 해결했습니다.

1. 가장 마지막 배포 커밋을 head가 가리키도록 한다(detatch head).
2. 그 상태에서 다시 배포한다(최신 배포 상태로 되돌린다).
3. 그 전에 실행되던 마이그레이션을 중단하고 테이블을 삭제한다.
4. 새롭게 다시 알림 동의 관련 테이블을 생성한다.
5. 마이그레이션을 진행한다.
6. 운영 서버에 배포한다.

해결 방안은 아주 간단했습니다. 배포 순서만 바꾸면 되니까요.

여기에 더해, 마이그레이션 후 운영 서버에 배포하는 동안 새로 가입한 유저들이 있다면 새로운 테이블이 없게 되기 때문에 에러가 날 수 있습니다. 따라서, 새로 가입한 회원들을 조회해 해당 회원들의 알림 동의 테이블(A, B, C + 마케팅)의 데이터를 마이그레이션 합니다.

신규 회원 조회가 되지 않을 때까지 마이그레이션을 진행하고 신규 회원이 더이상 조회되지 않으면 마이그레이션은 끝이 납니다(이는 회원 가입부터 배포까지의 시간이 신규 회원에 대한 마이그레이션을 진행할 수 있을 정도의 시간이었기 때문에 가능했습니다. 실제 테스트 했을 때 마이그레이션에 걸리는 시간이 그리 길지 않았습니다).

이번 일을 통해 깨달은 바는 이렇습니다.

• 개발 서버에서(일반적으로 dev 혹은 stage일 것입니다) 실제 운영 환경에서와 같이 순서도 포함해 테스트를 진행해야 한다.
• 장고는 django_migrations 테이블에 migration 정보에 해당하는 테이블이 없다면 에러가 난다.

너무 당연한 이야기들이지만 순간의 판단이 잘못된 결과를 가져다 줄 수 있었습니다.

제가 배포를 진행했던 10분(?) 남짓한 시간 동안 로그인을 시도했던 유저들은 그 시간 동안 앱에 접속할 수 없었고, 매일 우리 앱을 이용하던 고객들에게는 큰 불편함의 시간이었을 것입니다.

실제로 이런 장애가 났던 며칠 뒤 고객 리뷰에 불편함을 경험했다는 글이 올라왔고, 사용자의 경험을 고려해 배포에 정말 신중해야 함을 깨달은 계기였습니다.

(저는 차라리 컴퓨터가 되고 싶었습니다....)

이번 계기를 통해 마이그레이션을 다시 공부하면서 포스팅한 글을 함께 올리며 글을 마칩니다.
장고-마이그레이션