한국어
  • 포스트모템
  • 클라우드 서비스
  • 사고

포스트모템: 사용자 로그인 중 예상치 못한 500 오류 발생

2024년 7월 18일 인증 서비스에서 반환된 예상치 못한 500 오류에 대한 사고 보고서입니다.

Charles
Charles
Developer

요약

2024년 7월 18일, Logto Cloud에서 인증 서비스로 인해 500 Internal server error가 발생하였습니다.

  • 영향받은 사용자: 인증을 시도한 모든 Cloud 사용자
  • 영향받은 지역: 유럽 및 미국
  • 심각도: 치명적, 사용자 로그인 경험에 지장을 줌

Root cause

최근의 Cloud 배포 중, 데이터베이스 스키마에 도입된 치명적인 변경이 스테이징과 운영 환경 간의 전환 시점에서 로그인 경험 API를 실패하게 하였습니다.

타임라인

  • 2024-07-18 08:57 (UTC): Logto Cloud에 업데이트 배포
  • 2024-07-18 09:28 (UTC): 첫 번째 사용자가 500 오류를 보고
  • 2024-07-18 09:31 (UTC): 개발팀이 문제를 인지하고 조사 시작
  • 2024-07-18 09:32 (UTC): 문제가 자동으로 해결됨
  • 2024-07-18 09:40 (UTC): Root cause 파악

사고 분석

데이터베이스 치명적인 변화는 무엇이며, 왜 일어났는가?

우리는 현재 "Bring your UI"라는 새 기능을 개발 중에 있으며, 이 기능은 사용자가 자신만의 웹 페이지로 Logto 로그인 경험을 커스텀할 수 있게 합니다. 이 기능은 sign-in-exp 테이블에 커스텀 UI 구성을 저장하기 위한 새로운 열이 필요합니다.

개발 도중 요구 사항 변경으로 인해 기능의 출시가 지연되었지만, 스키마 변경의 일부가 이미 몇 주 전에 운영 환경에 배포되었으며 아직 사용되지 않았습니다. 데이터베이스 열의 업데이트는 이 PR에서 도입되었습니다.

안타깝게도, 이 변경은 이전 버전과의 호환성이 유지되지 않아, 새로운 데이터베이스와의 통신 중에 이전 코드에서 API 요청이 실패하게 되었습니다.

Logto Cloud의 새 버전은 어떻게 배포됩니까?

Logto Cloud의 새 버전을 배포할 때, 먼저 이를 스테이징 환경에 배포한 후 스테이징 환경과 운영 환경을 교체합니다. 그 과정은 다음과 같습니다:

  1. 데이터베이스 변경 스크립트를 실행하여 데이터베이스를 업데이트합니다.
  2. 새 소스 코드를 스테이징 서버에 배포합니다.
  3. 스테이징 서버를 실행하고 테스트를 수행합니다.
  4. "스테이징"이 "운영"으로 바뀌도록 스테이징과 운영 서버를 교체하여 사용자가 다운타임 없이 새로운 버전에 접근할 수 있게 합니다.

그러나 두 환경은 동일한 데이터베이스를 공유하며, 전체 과정에는 시간이 걸립니다. 따라서 데이터베이스 업데이트와 서버 교체 간의 시간차 동안, 기존 코드를 사용하는 운영 환경에 있는 온라인 사용자는 새로운 데이터베이스와 통신하려고 시도하게 됩니다.

이것이 이번 사고의 원인이며, 35분 만에 자동으로 해결된 이유입니다.

이 문제가 코드 리뷰 과정에서 왜 해결되지 않았는가?

우리는 데이터베이스 변경 사항의 이전 버전과의 호환성을 체크하는 CI 작업을 이미 보유하고 있습니다. 그러나 이전에는 PR 병합 전에 CI 검사가 통과되는 것이 필수사항은 아니었습니다. 이는 대부분의 개발 단계가 몇 가지 스프린트 내에서 짧게 이루어지며, 스키마 변경의 첫 번째와 두 번째 부분이 보통 같은 릴리스 단계에 포함되기 때문입니다.

이번에는 기능 출시가 지연되면서 스키마 변경이 두 번의 릴리스로 나뉘었습니다. 개발자는 CI 실패가 예상된 것이라 생각하고, 리뷰어들에게 이것이 PR 병합을 방해하지 않을 것이라고 알렸습니다.

커뮤니케이션의 격차도 분명히 있었으며, 결국 PR은 필요하지 않은 뒤로호환성 지원 없이 병합되었습니다.

교훈

  • 데이터베이스 스키마에서 치명적인 변경을 할 때는, 이전 버전의 소스 코드와의 호환성을 항상 고려해야 합니다.
  • 데이터베이스 열을 변경할 때는 스키마를 직접 수정하기보다는 단계적 폐기 및 마이그레이션 접근을 사용해야 합니다.
  • 개발자는 릴리스 과정과 타임라인에 대해 더 높아진 인식을 가져야 합니다.

수정 및 예방 조치

  • ✅ 스키마 변경을 포함하는 PR 병합 전에 데이터베이스의 역호환성 CI 검사가 통과해야 함.
  • ✅ 팀 내에서 역호환성의 중요성을 강조함.