감사합니다. 즉, ./launcher rebuild app 대신 ./launcher rebuild web_only(또는 rebuild data)를 사용해야 하고, postgres나 redis가 업데이트될 때 수동으로 업데이트해야 하는지 확인하려면 업데이트 내용을 꼼꼼히 읽어야 한다는 뜻이군요. 그리고 스탠드얼론 방식보다 큰 장점은 재빌드 시 데이터베이스가 종료된 후 다시 시작되기를 기다릴 필요가 없다는 점인데, 만약 프로세스가 강제로 종료되면 트랜잭션이 롤백되니까요.
하지만 Falco의 최신 변경 사항에 따르면, 데이터베이스는 종료에 10분 이상이 걸리는 경우를 제외하고는 절대 강제로 종료되지 않을 것이며, 사용자가 엄청나게(수백만 명 이상) 늘지 않는 한 그런 일은 절대 일어나지 않을 겁니다. 따라서 업데이트가 그 문제로 인해 실패하지는 않을 것이고, 주요 영향은 업데이트 시간이 몇 분 더 걸린다는 정도일 것입니다.
제 생각에는 결국 이 변경 사항은 아주 적은 이점을 위해 상당한 복잡성과 인지적 부담을 추가하는 것 같습니다. 만약 제 생각이 틀렸다면 바로잡아 주세요. 비꼬는 의도는 아닙니다.
배경 설명을 조금 드리자면, 이 변경 사항이 그 부담을 감당할 만큼 실질적인 이점을 제공해야 합니다. 왜냐하면 이것은 제 일이 아니라 제가 자발적으로 도와주고 있는 일(이미 15년 넘게 이어져 온 일이긴 하지만)이기 때문이죠. 물론 사람마다 상황이 다를 수 있습니다.
많은 사람들이 그런 의견을 가지고 있으며, 저는 여전히 그것이 놀랍습니다. Postgres 업그레이드는 연 1회 미만으로 이루어지며, 초기 변경 후 몇 달 동안 업그레이드를 지연시켜도 일반적으로 불이익이 없습니다. 2컨테이너 설정을 사용하면 단일 컨테이너를 사용하는 경우보다 Postgres 업그레이드를 더 쉽게 지연시킬 수 있는데, 이는 저에게 또 다른 이점으로 보입니다.
Postgres 업그레이드를 지연시키는 것은 과거에는 단순한 config yaml 변경으로 충분했습니다. 다만, 그 지원 계획을 중단할 계획이 아니라면 말입니다. 업그레이드를 위해 몇 분 정도의 추가 다운타임을 감수할 수 있으며, 제 눈에는 표준에서 벗어나 더 복잡한 설정을 한 사람(바로 저!)이 제대로 관리하도록 의존하는 것보다 리스크가 낮아 보입니다.
제 관점에서, 두 개의 컨테이너를 사용하는 가장 큰 이점은 가동 중단 시간의 감소입니다. 당신과 마찬가지로, 저는 2~3개월에 한 번씩 20~30분 정도의 가동 중단 시간은 괜찮다고 생각합니다. 하지만 일부 포럼에서는 그 시간이 너무 길 수 있다는 것을 쉽게 알 수 있습니다.
완전 동의해. 90분짜리 단독 다운타임이든 5분짜리 분리된 다운타임이든, 그 정도 시간이라면 그 변경이 가치 있다고 보긴 어려울 것 같아. 물론 그렇게 오래 걸린다면, 낮 시간대에 편하게 진행하기보다는 새벽에 업그레이드를 할 것 같긴 해. 우리는 실시간 주식 거래 플랫폼이 아니라, 비디오 게임에 관한 무료 포럼이니까.