DigitalOcean VPS를 통해 약 6개월 동안 Discourse 사이트를 운영해 왔는데, 큰 문제 없이 잘 돌아가고 있었습니다. 관리자 페이지를 보면 현재 버전이 2.5.0.beta4로 표시되고 있습니다. 그런데 어젯밤부터 사이트의 대부분 페이지 콘텐츠가 로드되지 않거나, 부자연스러울 정도로 긴 시간이 소요되는 현상이 발생했습니다. 예를 들어, 홈페이지나 /admin과 같은 페이지로 이동은 가능하지만, 해당 페이지의 실제 콘텐츠(게시물, 관리자 그래프/다른 탭 등)는 로드되지 않는 것처럼 보입니다. 시스템 상태를 확인해 보니 CPU 사용률은 유휴 상태일 때 약 2% 수준이며, 트래픽이나 디스크 사용량도 최소 수준입니다. 사이트를 테스트하고 설정하는 단계이므로 사용자 수는 약 10명 정도입니다. 이러한 상황을 고려하면 이런 현상은 매우 이상해 보입니다.
app.yml에 따르면 설치된 플러그인은 docker_manager와 discourse-signatures 두 가지뿐입니다. 유일한 관리자 사용자인 제가 확인한 바로도, 사이트 설정에 변경 사항이 꽤 오랫동안 없었습니다.
처음에는 머신을 재시작하는 것이 도움이 될 것 같아 시도해 보았으며, git pull과 ./launcher rebuild app을 수동으로 실행하여 업데이트도 시도했습니다. 이 과정에서 어떤 오류가 발생하고 있는지 판단할 수 있는 단서를 찾지 못했지만, 리빌드는 완료되는 것처럼 보였고 이후에도 사이트에 접근은 가능했으나 여전히 2.5.0.beta4 버전으로 남아 있었습니다. 마찬가지로 /admin/update 페이지에 접근을 시도하면 결국 타임아웃이 발생합니다. 사이트가 엄밀히 말하면 '동작’은 하고 있기 때문에 이 모든 상황이 꽤 이상해 보입니다. 사이트가 어떻게 작동하는지에 대해 충분히 알지 못해 정확한 진단을 내리기 어렵습니다. discourse-doctor를 찾아 실행해 보았는데, 이것이 정확히 어떤 역할을 하는지(예: 이메일을 성공적으로 보내는 등) 잘 모르겠습니다.
문제를 시사할 수 있는 한 가지 단서는, 어젯밤 포럼에서 게시물에 대한 답변 알림 이메일을 받았는데, ‘최근 게시물’ 카테고리로 이동했을 때(결국 로드가 된 후) 해당 게시물이 존재한다는 표시가 보이지 않는다는 점입니다. ‘최근’ 목록의 스레드 개요에 해당 사용자가 마지막으로 게시물을 남긴 것으로 표시되지 않기 때문입니다. 어떤 게시물의 콘텐츠도 로드할 수 없어 확실하게 확인하는 방법이 없습니다. 따라서 데이터베이스에 어떤 오류나 불일치가 있는 것일까요? 이런 문제가 사이트 전체의 일부가 로드되지 않도록 확대되는 방식이 궁금하고, 이것이 추적할 가치가 있는 문제인지도 잘 모르겠습니다.
이런 유형의 문제를 해결하기 위해 어디부터 시작해야 할지 조언을 구합니다. 시간을 내어 읽어 주셔서 감사합니다 : )
/dev/vda1에 마운트된 드라이브(/에 마운트됨)의 사용 가능한 공간이 약 7.9GB로 표시됩니다. Ubuntu에서 다른 파티션이 어떻게 사용되는지, 또는 실행에 어떤 영향을 미칠 수 있는지에 대해서는 크게 파악하고 있지 않습니다. (Discourse는 컨테이너에서 실행되는 것이 맞죠?) 나머지는 부팅 파티션 등으로 보입니다. 테스트 중 포럼에 총 30~40개의 게시글만 있으므로, 그곳에서는 (겉보기에) 위험하지 않은 것 같습니다. 클린업 작업을 통해 약 4GB의 추가 공간을 확보할 수 있었습니다.
앱 재구축에 관해서는, 실제로 몇 번 실행해 봤습니다. 처리 과정에서 눈에 띄는 경고 메시지는 보이지 않지만, 완료 후에도 '성공’을 알리는 메시지는 보이지 않습니다. 어떤 오류/경고 라인을 찾아봐야 하는지 모르겠습니다. 기존 컨테이너를 제거한 후 Docker 컨테이너를 실행하고 나면 끝납니다. 방금 한 번 더 실행해 봤는데, 사이트에 접속하면 여전히 업데이트가 가능하다고 표시되지만, 현재 사용 중인 버전(여전히 2.5.0.beta4)과 업데이트 대상 버전을 보고하는 데 incredibly 오랜 시간이 걸립니다.
문제의 일부는 응답 시간 문제나 로딩 실패로 인해 관리자 도구를 제대로 사용할 수 없는 것 같습니다. 예를 들어, 백업 탭으로 이동하면 로딩 애니메이션이 무한정 표시됩니다. 호기심에 백업 탭에서 콘솔을 열었는데, 브라우저가 JavaScript 파일을 가져오려 시도하지만 하나씩 천천히 모두 실패하고 있습니다.
저는 DigitalOcean을 사용하고 있습니다. 아마 그런 일이 일어나고 있을 수도 있지만, 그것이 이 문제처럼 이렇게 일관되게, 그리고 이렇게 오랫동안 지속되는 원인이 될지는 확실하지 않습니다. 사이트의 문제를 더 잘 설명하자면, 보통 페이지는 템플레이팅이나 페이지의 '셸’은 로드할 수 있지만, 그 이상으로 페이지의 실제 콘텐츠를 가져오는 과정은 계속 로딩 상태로 남아있는 것 같습니다.
리빌드/버전 변경에 대해서는, 그런 오류가 발생하고 있을 수 있지만, 이를 파싱하는 좋은 방법을 모르며, 무엇을 찾아야 할지도 정확히 알지 못합니다. 방금 다시 리빌드를 실행하면서 출력이 스크롤되는 것을 보았을 때, 'postgres installed’라는 문구가 한 줄 보였다가 사라지는 것을 보았습니다. 이것이 컨테이너 내부에서 진행 중인 작업 때문인지 아닌지는 모르겠지만, 예를 들어 ./launcher rebuild app | grep 'postgres'를 실행해도 아무것도 필터링되지 않고, ./launcher rebuild app > output.txt && grep 'postgres' output.txt도 마찬가지입니다. output.txt 파일에는 정보가 포함되어 있지만, 모든 것이 담긴 것은 아닌 것 같습니다? 적어도 실제 콘솔 출력과 동일한 방식으로 끝나지는 않습니다.
안녕하세요, 번(bump) 관련 규정이나 규칙에 어긋나는 것이 아닌지 걱정되지만, 그래도 이 문제에 대한 도움이 필요합니다. 지난주 어언 상황이 더 나빠진 것 같습니다? 정확히 언제 이런 일이 발생했는지는 확실히 말할 수 없는데, 지난주 연휴 기간 동안 이 작업을 하지 않았기 때문입니다. 하지만 지금은 사이트에 전혀 접속할 수 없습니다.
IP 주소를 핑(ping)하면 여전히 성공적으로 응답을 받으며, 해당 IP 주소가 올바른 도메인으로 연결되므로 네임서버 문제도 아닌 것 같습니다.
지금 파이어폭스(Firefox)로 사이트에 접속하면 다음과 같은 메시지가 표시됩니다:
The site at https://aregames.art/ has experienced a network protocol violation that cannot be repaired.
The page you are trying to view cannot be shown because an error in the data transmission was detected.
브라우저 인스펙터에서 유용한 정보를 거의 찾을 수 없는데, GET 요청에 대한 응답이 없는 것 같습니다.
이 새로운 문제를 발견한 이후 저는 다음 조치들을 취했습니다:
rebuild를 여러 번 실행
ubuntu를 20.04로 업데이트
다시 rebuild 실행
해당 사이트 자체는 플랫폼 테스트 목적으로 약 한 달간만 사용되었을 뿐이며, 소프트웨어를 최신 상태로 유지하지 않은 것이 좋은 아이디어가 아니었을 수 있다는 점은 받아들일 수 있습니다. Discourse를 처음부터 다시 설치하는 것도 마다하지 않습니다. 물론 사이트 설정, 사용자, 게시글을 보존하면서 이 문제를 해결하는 방법을 찾는 것이 더 좋겠지만, 제가 정말로 유지해야 할 것은 테마 에디터에서 작성한 커스텀 CSS 일부뿐입니다. 만약 이 정보가 저장되어 있는 위치가 있다면 이를 새로운 설정으로 복사할 수 있는 방법을 알려주시면 도움이 될 것입니다. 저는 (무책임하게도) 로컬 어딘가에 최신 버전으로 저장해 두지 않았습니다..
그리고 다시 한번 rebuild 과정에 대해 말씀드리자면, 여전히 이 과정에서 어떤 문제가 있는지 어떻게 파악해야 하는지 정확히 모르겠습니다. 제 판단으로는 rebuild가 실행되어 완료되며 입력을 요구하지 않고, 완료된 후 마지막 줄들은 yaml의 설정으로 docker 컨테이너를 시작하는 것과 관련이 있습니다. rebuild가 완료된 것과 성공적으로 완료된 것에는 차이가 있다는 점을 이해하고 있지만, 이 과정에서 무언가 잘못될 경우 무엇을 찾아봐야 하는지, 어디서 진단해야 하는지 확실하지 않습니다.
네, SSH로 정상적으로 접속할 수 있고, 그동안 재빌드도 매번 이렇게 실행해 왔습니다. 그리고 아니요, 재빌드 후에도 여전히 접속이 안 됩니다. 재빌드 후에도 ifconfig에서 도커 컨테이너가 서버 IP와 다른 IP를 가지고 있는 것을 볼 수 있는데, 제 시스템의 웹 브라우저로는 이 IP에 접속할 수 없습니다. 이게 의도된 동작인지 아니면 아닌지 확실하지 않습니다. ./launcher rebuild app > output.txt 명령은 실제 콘솔 출력의 일부만 기록하는 것 같지만, 이 내용도 첨부할 수 있습니다.
host aregames.art
aregames.art has address 198.54.117.200
aregames.art has address 198.54.117.199
aregames.art has address 198.54.117.198
aregames.art has address 198.54.117.197
와, 정말 눈이 뜨이는 경험이었네요. 사실 제 도메인 만료 기한이 지나버렸는데, 우연히도 바로 그날부터 이런 문제들이 발생하기 시작했더라고요. 원래 제공업체를 바꿀 계획이었기 때문에 자동 결제를 꺼두었는데, 날짜를 놓치고 말았나 봅니다. 그래서 그 IP들이 도메인 파킹 서비스와 관련이 있는 것 같네요. 방금 갱신을 마쳤으니, 이제 올바른 레코드가 다시 적용되지 않을까 싶습니다. 보통 얼마나 걸리는지 정확히 모르겠고, 호스팅 쪽에서는 여전히 그 IP들을 보고 있더라고요. 문서에 따르면 IP로 직접 접속할 수 없어야 하므로, 이게 제대로 작동했는지 확인하려면 조금 기다려야 할 것 같습니다. 이 문제를 짚어주셔서 감사합니다.
그렇다고 해도, 처음 겪었던 문제들에 대해서는 여전히 조금 혼란스럽습니다. 캐시된 버전의 페이지에 접근한 건가요? 그리고 네임서버 문제 때문에 콘텐츠 요청이 제대로 전달되지 않은 건가요? 스레드 안의 게시글이나 ‘최신 게시글’ 목록 같은 것들은 결국에는 로드되긴 했는데, 아주 오랜 시간이 걸렸거든요.
업데이트: 위에서 말씀하신 대로 host aregames.art를 확인해보니 이제 다시 올바른 IP와 메일 서버로 해석되고 있습니다. discourse-setup 스크립트로 확인해보니 DNS가 해당 IP로 가도록 설정되어 있음을 인정하더군요. 설정 스크립트가 재구축(rebuild)도 실행한 것 같습니다. 하지만 URL로 이동하면 '서버를 찾을 수 없음’이라는 오류가 납니다. 포트 443에서 IP에 직접 접속하면 nginx 400 bad request 오류가 나오는데, 이건 일종의 진전인 것 같습니다.
다시 수정: 브라우저 캐시를 비워야 했네요. 시크릿 탭에서 사이트를 완전히 정상적으로 로드할 수 있었습니다. 이제 모든 것이 다시 정상적으로 작동하는 것 같습니다! 아마도… 제 웹사이트 비용을 지불하는 것이 여기 사이트 문제를 해결하는 답이었나 봅니다.