사례17건

17건 중 5~9번째

1. IL-0242 primary 와 secondary PostgreSQL 데이터베이스를 모두 잃어 matrix.org homeserver 가 약 24시간 동안 멈췄다

   Matrix.org Foundation2025

   증상

   2025년 9월 2일 디스크 용량을 늘리는 작업 중 11:17 UTC 에 primary 데이터베이스 서버 db-02 의 RAID 배열에서 기존 드라이브 하나가 사라졌고 모니터링 알림이 울렸다. RAID 10 이라 데이터는 잃지 않았고 배열은 degraded 모드로 계속 동작했지만, 드라이브가 하나 더 고장 나면 버티지 못할 수 있었다.

   서비스 중단데이터 유실

   촉발

   디스크 용량을 늘리는 정기 작업 중 primary 데이터베이스 서버 db-02 의 RAID 배열에서 드라이브가 빠져 secondary 인 db-01 로 장애 조치를 했다. 그 뒤 db-02 를 복원하던 운영자가 실패한 복원의 흔적을 지우려다 db-01 에 있던 새 primary 의 데이터 디렉터리를 지웠다.

   원인

   운영 실수

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏데이터베이스 복제

   기여 요인

   장애 중첩수동 조치 악화미패치 알려진 버그파괴적 변경 보호 장치 부재

   감지

   11:17 UTC 에 db-02 의 RAID 배열에서 드라이브가 빠지자 모니터링 알림이 울렸고 Mythic Beasts 가 문제를 확인했다. 운영자가 db-01 의 데이터 디렉터리를 지운 것을 스스로 알아챘다. 그 뒤 백엔드 팀을 호출하고, 장애 대응을 시작하며 비상 상황을 선언했다.

   조치

   • 16:11 UTC 에 새로 만든 RAID 10 배열로 db-02 서버를 다시 올렸다.
   • 16:50 UTC 에 db-01 에 있던 primary 에서 막혀 있던 WAL 의 S3 보관을 다시 돌아가게 했다. 그래서 db-01 이 쌓인 WAL 을 지울 수 있게 됐다.
   • 17:30 UTC 에 S3 에서 백업을 가져오는 wal-g 로 db-02 에 데이터베이스 복원을 시작했다.
   • 알 수 없는 데이터베이스 상태를 피하려고 Synapse 와 db-01 의 primary 데이터베이스를 모두 내렸다.
   • 18:06 UTC 에 db-01 의 데이터 파티션을 읽기 전용으로 다시 마운트해, 나중에 살릴 경우에 대비해 데이터베이스가 더 망가지지 않게 했다.
   • S3 로 보관되지 못한 WAL 을 db-01 에서 db-02 로 복사해, S3 백업 복원이 끝나면 바로 재생할 수 있게 준비했다.
   • wal-g 를 같은 메이저 버전의 최신 릴리스로 올린 뒤, 전체 백업이 이미 들어 있는 비어 있지 않은 데이터 디렉터리를 받아들이도록 wal-g 를 고쳐 빌드했다. 09:23 UTC 에 이 wal-g 를 db-02 에 써서 S3 에서 다시 받지 않고 증분 백업을 복원했다.
   • S3 와 db-01 에서 옮겨 온 파일 시스템 양쪽에서 WAL 을 가져오는 래퍼 스크립트로 restore_command 를 설정하고 Postgres 를 standby 모드로 띄웠다. 11:00 UTC 부터 WAL 을 재생했다.
   • 16:45 UTC 에 db-02 를 primary 데이터베이스로 승격하고, Synapse 시험 worker 를 띄워 새 WAL 이 S3 에 올라오는 것을 확인한 뒤 16:54 에 Synapse 를 시작했다. 18:00 에 모든 worker 가 안정됐다.
   • WAL 재생이 느렸기 때문에, 없어진 복제본 대신 primary 데이터베이스에서 백업을 받도록 다시 설정했다. 03:26 UTC 에 새 증분 백업이 끝났다.
   • db-01 에 NVMe 디스크 두 개를 RAID 배열과 LVM 볼륨 그룹에 넣었다. 배열 재구성 중 재부팅해 서버가 올라오지 않자 배열을 부팅할 수 있는 상태로 고쳤고, db-02 의 basebackup 을 복사해 db-01 을 다시 복제 상태로 두었다.

   후속 조치

   • 저장 공간이 늘어난 지금 pg_repack 을 돌려 빈 공간을 되찾는다.
   • 증분 백업은 WAL 재생보다 훨씬 빨리 복원되므로 증분 백업을 더 자주 받도록 이미 바꿨다.
   • Synapse 가 데이터를 저장하는 방식을 고쳐 앞으로 필요한 저장 공간을 크게 줄인다.
   • 데이터베이스가 클러스터에서 맡은 역할에 따라 터미널 배경색을 바꾸는 방법을 검토한다. 데이터 디렉터리에 standby.signal 파일이 있는지 보고 primary 인지 secondary 인지 판단해 배경색을 바꾸는 안이 나왔다.
   • rm 의 alias 처럼 위험한 명령을 감싸는 래퍼 스크립트를 두거나, primary 에서 secondary 로 base backup 을 시작하는 일 같은 작업을 자동화하는 방법을 논의했다.
   • 복구 목표 시간을 줄인다. 더 쉽고 빠르게 복구할 수 있는 무료 인프라를 얻으려고 서비스 제공자들과 이야기하고 있다.
   • 재해 복구 서버뿐 아니라 모든 서버의 wal-g 를 올렸고, 올린 wal-g 로 재해 복구 시험을 한 차례 했다. 재해 복구 서버와 운영 서버를 계속 같게 유지하는 방법은 아직 찾지 않았다.
   • 다음 하드웨어 교체 때 ZFS 를 검토해, 엉뚱한 데이터베이스를 지우는 사고에서도 로컬 스냅숏으로 훨씬 빨리 복구할 수 있게 한다.
   • 장애 대응 절차에 status.matrix.org 를 장애 중 공식 정보원으로 갱신하는 단계를 넣고, advocacy 팀과 함께 소셜 미디어도 계속 갱신한다.

   교훈

   이번 장애가 이렇게 힘들었던 데에는 데이터베이스가 너무 크다는 점이 크게 작용했다. 엉뚱한 서버에서 파괴적인 명령을 실행한 것이 결정적인 순간이었다. 하지만 팀은 개인을 탓하지 않고, 사람이 쓰는 도구와 절차를 고쳐 같은 일이 다시 일어날 가능성을 줄여야 한다고 보았다. 세 사람이 함께 작업했지만 급박한 상황에서는 실수를 잡지 못했다. db-01 은 primary, db-02 는 secondary 처럼 읽히지만 실제 역할은 서로 바뀔 수 있으므로, 뜻이 담긴 서버 이름은 혼란을 부른다. primary 와 secondary 를 모두 잃고도 데이터를 잃지 않은 것은 정기적으로 시험한 특정 시점 복구 절차 덕분이었다. 다만 복구 목표 시간은 줄여야 한다. 재해 복구 시험에서 찾은 wal-g 수정이 운영 서버에 빠져 있었으므로, 재해 복구 서버와 운영 서버를 같게 맞춰야 한다.

   사례 보기
2. IL-0371 PITR 을 켠 Render Postgres 데이터베이스에서 백업이 도는 동안 새 연결의 절반이 실패했다

   Render2023

   증상

   특정 시점 복구 기능인 PITR 을 켠 Render Postgres 데이터베이스에 새 연결을 맺으면, PITR 백업 작업이 도는 동안 50% 확률로 실패했다. 커넥션 풀링처럼 이미 맺어 둔 연결은 영향이 없었다.

   간헐적 연결 실패요청 오라우팅

   촉발

   Render 는 2023년 4월 21일 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. 이 기능의 백업 작업은 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다.

   원인

   배포 결함

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏서비스 디스커버리

   기여 요인

   –

   조치

   • 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약할 수 있을 때까지 껐다.
   • 백업 작업의 네트워크 레이블 설정을 고쳐, 라우팅 계층이 백업 작업을 연결 대상 서비스로 잡지 않게 했다.

   후속 조치

   • 장애 업데이트를 공유하는 절차를 엄격하게 바꿔, 문제가 실제로 끝나기 전에 해결됐다고 알리지 않게 한다.
   • 데이터베이스 라우팅 계층에 더 구체적인 네트워크 레이블 설정을 둬, 연결 대상이 아닌 IP 가 서비스 설정에 들어가지 않게 한다.
   • 비동기 작업을 건너뛰었을 때 곧바로 실행하지 않고 다음 예약 시간대로 다시 예약한다.
   • 오픈소스 벤치마크 도구로 시스템을 측정하고, 고객이 알아챈 문제를 재현한다.

   사례 보기
3. IL-0453 하쿠나의 API latency 가 매일 ElastiCache Redis 백업 시간마다 치솟았다

   Hyperconnect2022

   증상

   하쿠나 서비스의 API latency 가 특정 시간에 주기적으로 치솟았다. APM 의 Dependency 별 Latency 분석에서 병목은 Redis 였다.

   지연 시간 증가메모리 압박

   촉발

   가용 메모리가 부족한 상태에서, 하루 한 번 primary 노드에서 도는 ElastiCache 백업이 forkless 방식으로 실행됐다.

   원인

   용량 한계

   구성 요소

   인메모리 캐시데이터베이스 백업과 스냅숏

   기여 요인

   한계 경보 부재

   감지

   특정 시간에 주기적으로 치솟는 API latency 를 그래프에서 보았고, APM 의 Dependency 별 Latency 분석으로 병목이 Redis 임을 알아냈다.

   조치

   • ElastiCache 백업을 primary 노드가 아니라 secondary 노드에서 실행하도록 바꿨다.
   • TTL 없이 저장되던 데이터에 TTL 을 걸어 저장하도록 코드를 고쳤다.
   • Redis Hash CrudRepository 를 쓰던 곳을 RedisTemplate 으로 다시 구현한 CustomRepository 로 바꿨다.
   • 이미 쌓여 있던 필요 없는 데이터를 지우는 스크립트를 실행했다.

   교훈

   백엔드 팀은 Redis 운영과 모니터링에 미흡한 부분이 있었다고 돌아봤다. 데이터 사이에 관계가 있거나 값으로 검색해야 하면 관계형 데이터베이스를 쓰고, 영속성이 필요한 데이터는 되도록 Redis 가 아닌 on-disk 기반 저장소에 둔다. ElastiCache Snapshot 을 만들어야 하면 가용 메모리를 50% 이상으로 유지한다. DEL collection 처럼 O(n) 인 명령 때문에 운영 Redis 가 멈추지 않게 조심한다. 애플리케이션과 데이터베이스 사이에 불필요한 I/O 가 없는지도 주기적으로 확인한다. Spring Data Redis Repository 는 secondary index 를 프레임워크가 관리해 주므로, TTL 이 필요 없고 쿼리 성능이 많이 요구되는 업무에서는 좋은 선택지가 될 수 있다.

   사례 보기
4. IL-0311 주 PostgreSQL 데이터베이스가 트랜잭션 ID wraparound 보호로 읽기 전용이 되어 웹사이트와 백엔드 서비스가 멈췄다

   BattleMetrics2022

   증상

   2022-03-27 3:23 UTC 에 계정, 서버, 플레이어 정보를 담는 주 PostgreSQL 데이터베이스가 쓰기를 받지 않았다. 처음 보인 증상은 사용자가 웹사이트를 불러오지 못하는 것이었다.

   쓰기 거부서비스 중단

   촉발

   플레이어 식별자 테이블의 인덱스가 알 수 없는 이유로 손상돼 vacuum 작업이 모두 오류로 끝났다. 로그로 보아 손상은 약 한 달 전인 2022-02-26 에 생긴 것으로 추정했고, 그동안 트랜잭션 ID 가 계속 쌓여 2022-03-27 에 wraparound 보호가 작동했다.

   원인

   데이터 손상

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 백업과 스냅숏

   기여 요인

   모니터링 사각지대장애 중첩여유 용량 부재

   감지

   처음 들어온 것은 웹사이트를 불러오지 못한다는 사용자 신고였다. 팀은 30분쯤 전에 작동한 DDoS 방어 탓으로 보았다가, RCON 업데이트와 쿼리가 실패하는 것을 보고 더 살펴본 끝에 주 데이터베이스가 쓰기를 받지 않는 것을 찾았다.

   조치

   • 데이터베이스를 내리고 single-user mode 로 들어가 손상된 인덱스를 지운 뒤 데이터베이스를 다시 올렸다.
   • vacuum 을 다시 돌렸고, 이번에는 성공해 데이터베이스가 다시 쓰기를 받았다.
   • 지운 플레이어 식별자 인덱스를 약 두 시간에 걸쳐 다시 만들었다.
   • 데이터베이스가 돌아온 뒤 쿼리 워커를 모두 멈추고 RCON 업데이트를 우선했다.
   • 인덱스가 돌아오자 서비스가 새 Postgres primary 를 가리키게 했다.
   • replica 를 더 부트스트랩해 하나 올라올 때마다 primary 부하를 덜었고, 16:30 UTC 에 RCON 업데이트를 따라잡았다.
   • RCON 업데이트가 늦어지지 않게 쿼리를 제한해서 다시 돌렸고, 쿼리의 우선순위는 서버의 현재 접속 인원과 순위로 매겼다.

   후속 조치

   • Postgres 로그의 오류를 모니터링한다.
   • 트랜잭션 ID 를 모니터링하고 알림을 건다.
   • 물리 복제에 더해 논리 replica 를 둔다.
   • 장애에서 더 빨리 복구하도록 더 빠른 네트워크를 갖춘다.

   교훈

   BattleMetrics 는 Postgres 의 트랜잭션 ID 크기를 확인하는 헬스 체크를 두지 않은 것을 결정적인 실수로 보았다. 인덱스 손상은 사이트 성능에 영향이 없어 한 달 동안 드러나지 않았고, 그동안 vacuum 이 계속 실패하며 데이터베이스가 wraparound 에 다가갔다. 손상은 replica 에도 복제돼 있어 장애 조치가 소용없었고, 백업 서버와 내려받기용 백업도 같은 손상을 안고 있었다. 오류 문구와 달리 wraparound 보호에 들어간 서버에서도 single-user mode 없이 전체 vacuum 을 돌릴 수 있었다.

   사례 보기
5. IL-0331 RDS MySQL Multi-AZ 장애 조치 뒤 읽기 복제본 다섯 대의 복제가 모두 깨지고 데이터 5초 분량이 사라졌다

   Razorpay2020

   증상

   2019년 12월 어느 금요일 저녁, 내부 모니터링 도구가 시스템에서 5xx 오류가 평소보다 훨씬 많이 난다고 알렸다. SRE 팀은 주요 애플리케이션인 API 가 RDS MySQL 데이터베이스에 접속하지 못한다는 것을 알아챘다. 원인을 파악하기도 전에 애플리케이션이 스스로 살아났고 알림이 멈췄다.

   오류율 상승복제 지연데이터 유실

   촉발

   API 애플리케이션의 RDS MySQL 마스터 인스턴스가 Multi-AZ 장애 조치를 거쳐 다른 AZ 의 대기 인스턴스로 넘어갔다.

   원인

   설정 변경

   구성 요소

   데이터베이스데이터베이스 복제데이터베이스 백업과 스냅숏

   기여 요인

   –

   감지

   내부 모니터링 도구가 5xx 오류가 평소보다 훨씬 많다고 알렸다. 복제 실패는 그 뒤 다른 알림으로 왔다. 데이터 손실은 다음 날 데이터베이스와 애플리케이션 트레이스 로그를 맞춰 보다가 찾았다.

   조치

   • 오래된 데이터가 사용자에게 보이지 않도록 복제본으로 가던 트래픽을 모두 마스터 인스턴스로 옮겼다.
   • 새 장비의 전체 스냅샷이 끝나기를 여섯 시간 기다린 뒤 복제본 다섯 대를 다시 만들고 트래픽을 복제본으로 되돌렸다.
   • 바이너리 로그에서 정확한 쿼리를 찾고 애플리케이션 트레이스 로그로 사건 순서를 따라가 8시간 회의 끝에 RDS 에 저장된 데이터를 바로잡았다.
   • 마스터 인스턴스의 innodb_flush_log_at_trx_commit 값을 2 에서 1 로 바꿨다.

   교훈

   잘못 설정한 변수 하나 때문에 Razorpay 는 처음부터 데이터 손실 위험을 안고 있었다. 팀은 장애를 끝까지 파고들어 근본 원인을 찾았고, 그 과정에서 RDS 가 Multi-AZ 구성과 장애 조치를 어떻게 다루는지 많이 배웠다.

   사례 보기

원인별8