미국 동부시간 9시 9분에 AWS CloudWatch 경보가 도착했고, 몇몇 친구들로부터 "디스코스가 다운된 건가?"라는 문자도 함께 왔습니다.
AWS Lightsail 인스턴스에 SSH로 접속할 수 없었고, 모든 메트릭이 멈춰 있거나 보고되지 않았습니다.
결국 포기하고 Lightsail 인스턴스를 중지/재시작했습니다.
서비스가 복구되었습니다.
복구 후 로그를 확인하며 원인을 파악해 보았습니다.
저는 Discourse를 단일 인스턴스로 운영하고 있으므로, 9시 5분에 발생한 Redis 네트워크 연결 오류가 이해가 가지 않습니다.
"무언가"가 "어떤 이유"로 인해 멈추거나 실패했다는 것 외에는 무슨 일이 있었는지 파악할 수 없습니다.
상황을 설명해 주거나 단서를 남겨 주실 수 있는 분을 찾고 있습니다.
감사합니다!
서버 사양이 어떻게 되나요? 리소스가 부족해지는 것 같습니다. 가장 가능성이 높은 것은 CPU입니다. 해당 시간에 일일 작업이 실행되고 있는 건 아닌가요?
1 vCPU, 1GB RAM, 40 GB SSD 사양의 lightsail 인스턴스입니다.
스토리지 사용량이 약 60%이고, 정리 작업을 하면 사용량이 꽤 줄어듭니다.
AWS에서는 버스타블 CPU 크레딧이 소진되었다고 표시하는데, 다른 지표들은 이를 뒷받침하지 않아 다소 이상합니다.
커뮤니티 규모가 그리 크지 않아(활성 참여자 20~30명) 실제 CPU나 RAM에 병목 현상이 발생한다고 생각하기 어렵습니다.
discourse가 기본적으로 예약할 수 있는 작업을 제외하고는 일일 태스크로 인식하는 것이 없습니다.
스왑 포함 1GB는 디스코urs를 실행하는 데 필요한 절대 최소 사양입니다.
이 인스턴스가 얼마나 오랫동안 실행되어 왔나요? 데이터베이스 크기는 얼마나 되나요?
DB 크기를 확인해 보겠습니다. 백업이 약 57MB 정도이므로 크기가 크지 않을 것으로 예상합니다.
복구를 위해 가상 서버를 중지하고 재시작해야 했기 때문에 인스턴트 업타임이 아직 10시간이 채 되지 않습니다. 셸이나 콘솔 연결을 할 수 없었습니다.
이 인스턴스 유형으로 구축한 이후(대략 2021년 2월)부터 문제없이 잘 작동해 왔습니다.
AWS가 VM을 한 호스트에서 다른 호스트로 이동시킨 후 그로 인해 VM이 이상한 상태에 놓이는 경우처럼 들립니다. 보통 재부팅으로 해결됩니다.
전체 DB 크기는 423MB입니다.
가장 큰 테이블은 다음과 같습니다.
Posts 66MB
Post_timings 60MB
비슷한 “고 부하” 장애가 두 번째로 발생했습니다.
리소스 경합일 것으로 추정됩니다.
Lightsail 스냅샷을 사용하여 인스턴스를 스냅샷하고, 이를 더 큰 인스턴스로 복원하는 방식으로 업그레이드를 시도해 보신 분이 계신가요?
AWS 인스턴스를 재부팅해 보시면 많은 문제를 해결할 수 있습니다.
Lightsail 스냅샷을 사용하여 1 CPU, 1GB RAM, 40GB SSD 환경에서 2 CPU, 4GB RAM, 80GB SSD 환경으로 마이그레이션을 완료했습니다.
공개 IP를 분리했다가 다시 연결하는 과정은 비교적 간단했지만, 나머지 궁금한 점은 "무엇을 놓쳤을까"입니다.
업그레이드된 리소스를 활용하기 위해 확인해야 할 사항(백업, 이메일, S3 버킷 설정 등)이 있거나, 초기 설치 매개변수를 다시 실행해야 하는 경우가 있을까요?
이 링크를 참고하면 db_shared_buffer를 최소 1GB까지 늘릴 수 있을 것 같습니다.
현재 app.yml에는 128MB로 설정되어 있으며, 부팅 시 자동으로 조정된다는 내용도 명시되어 있습니다.
4GB 시스템이라면 1GB로 충분합니다. unicorn_workers도 4로 업데이트했는지 확인하세요.
서버 간 이동을 하는 경우의 일반적인 권장 사항은 discourse-setup을 다시 실행하는 것입니다. 이렇게 하면 위에서 언급한 사항들이 자동으로 처리됩니다.
고마워요. 이제 프로메테우스의 토끼굴에 빠져들고 있어요.
좋은 내용이었어요.
