api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
수정해 주실 수 있을까요?
경험이 많은 개발자가 아니라서(사실상 초급 수준이라고 할 수 있습니다), nginx 솔루션을 사용하여 유지보수 페이지를 표시하는 것은 좀처럼 쉬운 일이 아니었습니다. 오늘 이 아이디어가 떠올라, 다른 웹사이트와 애플리케이션에 Railway를 사용 중이므로 이것이 가능한지 Claude에게 물어보기로 결정했습니다:
"Discourse가 Docker를 사용하므로, nginx가 필요하다는 점에서 유지보수 메시지를 표시하는 것이 매우 복잡해 보입니다. 저에게는 복잡한 과정이죠. Railway나 다른 서비스를 통해 트래픽을 한 서버에서 다른 서버로 빠르게 전환하는 '스위치’를 만들 수 있을까요? 예를 들어, 현재 Cloudflare는 example.com을 Discourse가 설치된 Hetzner 서버로 리디렉션하고 있습니다. Cloudflare를 해당 '스위치’가 구현된 Railway 프로젝트/환경/서비스로 보내고, 변수 값을 "maintenance"에서 “live"로 변경하면 트래픽이 유지보수 페이지용 다른 Railway 서비스나 Hetzner로 전환되도록 할 수 있을까요?”
그리고 Claude의 답변은 다음과 같았습니다:
네, 기술적으로는 작동하지만, 이 스위치를 Railway를 통해 실행하는 것은 이 경우 잘못된 레이어입니다. Discourse가 라이브 상태일 때 모든 개별 요청마다 두 번째 네트워크 홉(Cloudflare → Railway → Hetzner)을 추가하게 되며, 이는 다음을 의미합니다:
- 유지보수 기간이 아닌, 모든 요청에 대해 영구적으로 추가 지연 시간이 발생합니다. - 새로운 단일 장애점이 생성됩니다(Railway 서비스가 다운되면 Discourse가 정상이어도 다운됩니다). - 유지보수 창이 아닌, 모든 일반 트래픽에 대해 Railway의 이GRESS 비용이 발생합니다.
더 나은 접근법: Cloudflare Worker에서 스위칭을 수행하세요. Worker는 엣지(300개 이상의 PoP)에서 실행되므로 “live” 모드일 때 추가 왕복이 없고, 토글링은 즉시 이루어집니다.
예를 들어 플러그인을 설치하는 것처럼 중요한 변경 사항을 할 때마다, 때로는 20분까지 걸리곤 했습니다.
이런 작업은 매주, 아니 매월도 하지 않으므로 큰 문제는 아닙니다. 하지만 새로운 방문자에게 뭔가 제대로 작동하지 않는다는 것을 알리는 그 못생긴 페이지는 좋은 첫인상을 주지 못합니다. 웹사이트가 다운될 것이라는 사실을 모르는 기존 방문자에게도 마찬가지입니다. 그들은 커뮤니티 전체가 종료되었거나 뭔가 큰 일이 생긴 줄 알고 "패닉 모드"에 빠질 수 있으며, 일부는 무슨 일이 일어나고 있는지 물으며 바로 이메일을 보낼 수도 있습니다.
새로운 방문자든 기존 방문자든, 현재 무슨 일이 일어나고 있는지 알려주는 것은 좋은 배려라고 생각합니다.
클로드가 제안한 이 방식이 몇 분밖에 걸리지 않고, 한 번 설정해두면 다시 건드릴 필요가 없는 것이라면, 그 시간은 잘 쓴 시간이라고 생각합니다.
저는 Cloudflare CDN 뒤에 dual container build를 사용하고 있습니다. 듀얼 컨테이너는 다운타임을 최소화해 주며, 제 두 개의 주요 프로덕션 포럼 모두 재빌드 시 최대 30초만 오프라인 상태가 됩니다. 웹 서버의 기본 다운 페이지는 미관상 좋지 않고 오프라인 상태가 얼마나 지속될지 알 수 없어 유지보수 페이지를 사용하는 것을 선호합니다.
와! 정말 상세한 설명 감사드립니다!
곧 다시 Discourse를 설치할 때를 대비해서 답변을 노트에 저장해 두었습니다. 설치를 완료하면 반드시 결과를 알려드릴게요. 설치를 마치는 데 시간이 좀 걸리더라도요. 지금은 코딩 작업을 마무리하고 있고, 그 후에 다시 Discourse에 집중할 예정입니다.
그리고 "웹 서버가 다운되었습니다"라는 페이지가 별로라고 동의합니다. 경험 없는 사용자들에게는 그 메시지가 큰 의미가 없으니까요. 설정하는 데 시간이 걸리더라도, 커스텀 메시지가 포함된 간단한 유지보수 페이지를 사용하는 것이 항상 더 좋습니다.
다시 한번, 이렇게 시간을 내어 공유해 주셔서 정말 감사드립니다. 다른 분들도 이 정보가 유용하게 활용되길 바랍니다
두 개의 컨테이너를 사용하는 설정(우리의 두 게시물에 링크되어 있으며, 필수적인 의존성입니다)에서는 ./launcher bootstrap web_only 명령을 사용하여 새 빌드를 부트스트랩합니다(이 과정 동안에도 사이트는 100% 정상 작동합니다). 그런 다음 기존 컨테이너를 파괴하고 이미 빌드된 새 컨테이너를 즉시 시작합니다(이 과정은 몇 초밖에 걸리지 않습니다).
네, 컨테이너 빌드에는 여전히 시간이 좀 걸립니다. 참고로 해당 프로세스가 커뮤니티를 정상적으로 서비스하는 동안 병렬로 실행될 수 있도록 서버가 충분히 강력한지 확인해야 합니다(가장 중요한 것은 초기에 충분한 메모리를 확보하는 것입니다 - SWAP 용량이 충분한지 꼭 확인하세요). 또한 빌드 과정에서 최소 1개의 코어가 점유되므로, 코어가 1~2개 더 많은 서버를 사용하는 것을 고려해 보세요.
저는 동의하지 않으며, 유지보수 페이지를 만드는 것이 가치가 있다고 생각합니다. 제 경험상, 사람들이 Discourse 오류 페이지를 처음 보면 가장 먼저 새로고침을 누릅니다. 그러면 컨테이너 스왑이 완료될 때까지 자동으로 사이트를 다시 로드하는 짧은 유지보수 페이지가 표시됩니다. 설정하는 데 큰 노력은 들지 않으며, 한 번만 하면 됩니다. 이중 컨테이너 구성으로 재빌드하는 동안 부트스트랩 부분은 백그라운드에서 수행되며 사용자는 사이트를 계속 사용할 수 있습니다. 짧은 다운타임은 컨테이너 전환 시에만 발생하며(표준 단일 컨테이너 구성과 다름), 재빌드 과정 자체에서는 발생하지 않습니다.
서버 비용과 선택은 완전히 별개의 논의 사항이며, 유지보수 페이지 설정과는 다른 별도 주제에서 다뤄져야 합니다.
지금 저는 중간 정도 위치에 있는 것 같습니다. @merefield님의 의견도 이해합니다. 이런 기능이 있는 건 좋은 점이고, 딱 한 번만 설정하면 되는 거라면 큰 문제가 아닐까요?
그런데 만약 정말로 최악의 경우 60초까지 걸린다면, 모든 사람이 웹사이트를 0초 시점에 정확히 방문해서 60초를 기다리는 것은 아닙니다. 어떤 사람은 5초, 어떤 사람은 20초, 어떤 사람은 60초 동안 추한 페이지를 보게 될 것입니다. 또한 어떤 사람은 아예 보지 못할 수도 있습니다(제 생각에는?). 예를 들어 답글을 읽거나 작성 중이라면, 전송(SEND) 버튼을 누르기 전에, 또는 토픽을 읽다가 답글(REPLY) 버튼을 누르기 전에, 혹은 다른 페이지로 이동하기 전에 그 전환이 일어날 수 있으니까요.
nginx 경로를 제안할 때 제가 가진 문제는 1컨테이너 구성에서 20분 동안 서비스가 중단되는 것과 더 관련이 있었습니다. 2컨테이너 구성 옵션이 있고, 20분에서 최대 60초로 단축된다면, 정말로 중요한 문제인지 궁금합니다. 특히 트래픽이 적은 시간대에 몇 초간 서비스가 중단될 것이라는 공지사항을 상단에 추가할 수 있다면, 이는 큰 문제가 되지 않을 것 같습니다.
이어서 생각해보겠습니다. 좋은 서버 딜을 찾게 된다면, 2컨테이너 구성은 definitely 구현할 계획입니다.
이 내용을 제가 이해할 수 있도록, 초보자도 알기 쉽게 설명해 주실 수 있을까요? 저는 아직 워커에 대해 잘 익숙하지가 않습니다…
그냥 그대로 두는 데 문제가 없다면, 왜 워커의 라우트 페이지를 추가하고 삭제하는 건가요? 즉, 제가 유지보수 페이지를 추가한다면, 정말로 한 번만 설정해 두고 그 이후로는 클라우드플레어(Cloudflare)에 갈 필요 없이 터미널을 통해 SSH로 서버에 접속해서 싱글 컨테이너를 다룰 때처럼 모든 작업을 수행할 수 있을까요?
@merefield 님은 이것(유지보수 페이지, 워커 등)도 유지보수가 필요한 것이라고 언급했는데, 그래서 이것이 정말로 한 번 설정하면 잊어도 되는(set and forget) 것인지, 아니면 가끔씩 해야 할 일이 있는지 궁금합니다.
그리고 서버 성능이 더 떨어지는 것 같은데…?
) 업그레이드하는 수밖에 없겠네요.