현재 GCP의 Kubernetes에서 helm charts를 사용하여 Discourse를 설치하려고 하고 있습니다. 관련 내용은 여기에서 확인하실 수 있습니다.
이는 프로덕션 환경도 포함해야 하므로 Discourse로 가져온 어떤 콘텐츠도 잃어서는 안 됩니다. 물론 GCP의 호스티드 PostgreSQL DB를 사용하겠지만, 여기서도 호스티드 Redis가 필요한지 확신이 서지 않습니다.
만약 Redis의 모든 데이터 손실이 캐시된 데이터만 잃는 경우처럼 Discourse 기능에 영향을 미치지 않는 것이라면, Kubernetes 내의 Redis를 그대로 사용해도 될 것입니다. 그러나 Redis 손실이 더 큰 영향을 미친다면 호스티드 Redis가 필요할 것입니다.
이 부분에 대해 알려 주실 수 있을까요?
여기에서 자세히 설명했습니다: More details on how the Redis cache is utilized? - #2 by Falco
Redis는 다음 용도로 사용됩니다:
캐시
백그라운드 작업 큐
영속적 연결 백로그 및 pub/sub
제가 그 자리에 있다면 GCP의 호스팅 서비스를 선택하겠습니다. 단, 충분히 최신 버전의 Redis를 제공하고 버전을 크게 뒤처지지 않는다는 전제 하에요. AWS는 새 버전을 빠르게 업데이트하는 데 뛰어납니다. 반면 GCP와 Azure는 때때로 업데이트가 지연될 수 있습니다.
@Falco 여기 조언해 주셔서 정말 감사합니다. 그러면 Redis가 손실되면 모든 히스토리 등이 모두 파괴되는 건가요?
여기서 "히스토리"를 어떻게 정의할 수 있을까요?
Redis DB(즉, redis-cli flushall와 동등한 것)를 잃는 것은 Discourse 앱이 큰 문제 없이 복구할 수 있는 상황이지만, 큐에 대기 중이던 이메일과 같은 일부 데이터는 손실됩니다. 따라서 재앙적인 상황은 아니지만, 큰 어려움 없이 피할 수 있다면 피하는 것이 좋습니다.
네, 제가 말하는 히스토리는 지금 우리가 하고 있는 이 대화 같은 모든 주제와 내용을 뜻합니다.
이것들을 잃어버리면 안 되니까 정말 중요해요. 
게시물, 주제, 사용자 등 실제 데이터는 PostgreSQL에 저장됩니다.
따라서 이 솔루션은 덜 중요한 데이터나 더 임시적인 데이터만 다루게 됩니다.
가장 크게 잃게 되는 것은 미래에 실행될 예정으로 대기 중인 작업들입니다. 일반적으로 큰 문제가 되지 않습니다.