최소 다운타임으로 주요 Discourse 유지보수를 수행하는 방법?

지원 자체 호스팅
1

Discourse 인스턴스에서 핵심 유지보수 작업을 수행할 때 다운타임을 최소화하거나 없애는 방법에 대한 모범 사례에 대해 논의하고 싶습니다.

UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL과 같은 중요한 리소스 설정을 변경하거나 주요 업데이트를 적용하는 작업은 일반적으로 launcher rebuild app을 필요로 하며, 이는 상당한 시간, 때로는 30분 이상을 소요될 수 있습니다.

제 질문은 다음과 같습니다:
시스템 관리자가 이러한 필수 업데이트와 설정 변경을 사용자 체감 다운타임이 최소가 되도록 수행하기 위한 권장 전략은 무엇입니까?

블루/그린 배포나 기타 제로 다운타임 배포 전략과 같은 고급 기법이 Discourse에서 지원되거나 권장됩니까? 아니면 표준 rebuild 프로세스가 유일한 지원되는 방법이며, 재빌드 시간 자체를 최적화하는 데 초점을 맞춰야 하는 것입니까?

대규모 또는 트래픽이 많은 인스턴스를 관리해 본 경험이 있는 분들의 워크플로우에 대해 듣고 싶습니다.

고견 부탁드립니다!

2

두 개의 컨테이너로 설치한 경우, 기존 컨테이너가 실행되는 동안 새 컨테이너가 빌드됩니다. 다운타임은 새 컨테이너를 시작하는 데 걸리는 시간만큼만 발생합니다. 유일한 문제는 다른 컨테이너가 실행되는 동안 컨테이너를 빌드할 수 있을 만큼 충분한 RAM이 필요하다는 것입니다.

스탠드얼론 컨테이너에서 웹 및 데이터 컨테이너 분리 환경으로 이전 방법을 참고할 수 있지만, 저는 보통 새 VM으로 이전합니다.

다운타임을 전혀 원하지 않는다면, 새 컨테이너가 완전히 시작될 때까지 기존 컨테이너를 실행 상태로 유지하는 로드 밸런서가 필요합니다. 그런 다음 기존 컨테이너를 종료하고 업데이트 후 마이그레이션을 수행합니다.

3

페일오버에서 데이터 컨테이너를 두 개 사용할 수 있나요?

보통 데이터를 위해 별도의 VM을 사용하나요?

4

Discourse는 매우 안정적이어서 대부분의 설치 환경에서는 이것이 거의 필요하지 않습니다(다만, 매우 높은 가용성이 요구되거나 다른 사람들을 호스팅하는 경우라면 고려해 볼 수 있겠죠!)

저는 7년 동안 프로덕션 환경의 "글리치"로 인해 단 한 번의 장애도 겪은 적이 없습니다 …

Discourse의 수명 주기에서 가장 위험한 순간은 항상 리빌드(rebuild)할 때입니다.

두 개의 컨테이너 구성을 사용하면 새로운 빌드를 확정하기 전에 부트스트랩할 수 있는 장점이 있지만, 물론 런타임 오류의 일부는 잡아내지 못합니다.

문제는 마이그레이션이 이미 실행된 경우, 새로운 빌드를 확정해야 할 수 있다는 점입니다. 따라서 보통은 롤백하기보다는 그 오류의 원인을 찾아 수정하려고 합니다.

일반적으로 사람들은 롤백을 시도하지 않습니다 …

5

대규모 재구성을 수행할 때는 새로운 VM으로 이동합니다.

PostgreSQL 미러를 실행하는 것은 가능하지만, 많은 작업이 필요합니다.

6

읽기 전용 레플리카가 더 좋지 않을까요?

7

그래! 레플리카! 그게 바로 그들이 쓰는 말이지. 그리고 다른 쪽이 죽으면 레플리카로 핫스왑할 수 있어.