포럼

안녕하세요. 이번 사건의 근본 원인을 파악하여 항목별로 답변드립니다.

1. 13:52–14:01 사이에 노드 유지보수/드레인이 있었나요? 왜 설정된 시간 외에 재시작되었나요? 네, 맞습니다. 당일 13:38–13:52(UTC)에 ap-east-2(AWS) 클러스터에서 노드 교체가 진행되었습니다. 다수의 하위 노드가 종료되었고(이벤트 로그에는 "클라우드 공급자에 노드가 존재하지 않음"으로 기록됨), 동시에 새 노드가 시작되어 작업을 이어받았습니다. 고객님의 앱과 PostgreSQL Pod는 기존 노드가 제거됨에 따라 새로 추가된 노드로 재스케줄링되었습니다. 따라서 이번 재시작은 고객님이 설정하신 06:00 정기 재시작과는 무관하며, 플랫폼 노드 교체로 인해 발생한 예상치 못한 재스케줄링입니다.

2. DB 복구에 약 68분이 걸린 이유는 무엇인가요? aws-cni IP 할당 실패와 관련이 있나요? 네, 두 가지 주요 원인이 있으며 서로 관련이 있습니다.

• 새 노드가 막 합류했을 때 aws-cni가 네트워크(ENI/IP 풀)를 준비하지 못한 상태에서, 재스케줄링된 수많은 Pod가 동시에 몰려들었습니다(클러스터 내 수십 개의 서비스에서 동시에 "failed to assign an IP address" 발생). 이로 인해 IP 할당에 병목 현상이 발생하여 Pod가 네트워크를 구축하지 못한 채 멈춰 있었습니다.
• 새 노드는 이미지 캐시가 없는 "콜드 노드"였기 때문에 이미지를 다시 가져와야 했습니다. PostgreSQL(postgres:18) 이미지는 기록상 가져오는 데 약 1시간 7분(대기 시간 포함), 앱 이미지는 약 24분(대기 시간 포함)이 소요되었습니다. 이 두 번의 대기 시간이 중단 시간이 약 68분까지 길어진 주된 원인입니다.

즉, 이는 DB 자체의 문제가 아니며(제공해주신 CPU/메모리 지표로 보아 OOM도 발생하지 않았음), "재스케줄링 + 네트워크 할당 + 이미지 재다운로드"라는 복구 과정이 너무 길어진 것이 원인입니다.

3. PostgreSQL에 플랫폼 측의 설정이나 잘못된 설정으로 인한 정기 재시작이 있나요? 없습니다. 이번 DB 재시작은 앞서 언급한 노드 교체로 인한 Pod 재스케줄링(Pod 이름 변경, 이미지 재다운로드)이며, 인플레이스(in-place) 정기 재시작이 아닙니다. 고객님의 서비스에는 플랫폼 측의 정기 재시작 설정이 없으므로 해제할 필요가 없습니다.

4. 향후 이러한 유지보수에 대한 사전 알림이나 구독 가능한 상태 페이지가 있나요? 플랫폼 이벤트는 상태 페이지(https://status.zeabur.com)에서 확인할 수 있으며, 현재 RSS 구독(https://status.zeabur.com/feed, RSS 리더기나 자동 알림 도구에 추가 가능)을 제공하고 있습니다. 또한, 이번 노드 교체로 인한 aws-cni IP 할당 병목 현상과 콜드 노드의 이미지 재다운로드로 인한 복구 지연 문제를 인프라 팀에 보고했습니다. 노드 교체 시의 드레인 및 IP 프리워밍 프로세스를 개선하여 향후 유사한 상황 발생 시 중단 시간을 줄일 예정입니다.

추가 제안: 이번 중단 사태의 근본 원인은 "공유 클러스터"의 노드가 플랫폼 유지보수에 따라 교체되면서 고객님의 Pod가 막 켜진 새 노드로 강제 재스케줄링되었기 때문입니다. 서비스의 연결 안정성이 중요하다면 전용 서버(Dedicated Server) 사용을 고려해보시기 바랍니다. 전용 서버는 단일 테넌트 독립 노드이므로 공유 클러스터의 전체 노드 교체 대상에 포함되지 않아, 이러한 예상치 못한 재스케줄링과 복구 지연의 영향을 크게 줄일 수 있습니다. 또한 노드에 이미지 캐시가 이미 존재하므로 재시작 후 복구도 훨씬 빠릅니다. 관심이 있으시다면 적절한 사양을 평가하는 것을 도와드리겠습니다.