Continuing the discussion from Meta is moving to the Cloud 
:
This sounds like a really interesting story. I’d love to hear it.
Have you told it already anywhere?
Our main pain points were two.
1. Instance types
Elasticache didn’t allow you to run HA Redis without Cluster Mode on instance types below M4.large.
Support for cluster mode in Ruby Redis libraries is still being ironed out. MessageBus also does atomic operations on keys using LUA scripts and since that will span multiple servers it’s not allowed in cluster mode. We do host some BIG instances, so we may revisit using distributed writes for databases (Rails 6 is coming with that for PostgreSQL) but we aren’t needing this yet.
We do host sites which need instance types way larger than that. But also host a lot where a t3.small is more than enough.
Moving to running our own Redis allows us to pick and play with any instance types available in the target region.
2. Read only mode
Discourse can keep a connection open with read only nodes with both Discourse and Redis.
That allows people to keep reading on the site when masters go down.
Elasticache wasn’t very straightforward in providing endpoints for the replicas in the main cluster, that updated to current replicas in failover events.
Also … not to forget. This offers us significant cost savings.
When you use ElasticCache you pay for the instances plus a tax for the ElasticCache service. Additionally we get much better control on utilisation since we can run multiple redises if we wish on a single instance.
Falco님, 작성하신 내용을 읽어본 결과 무료 ElastiCache가 Discourse의 Redis 요구사항을 지원하지 않는 것 같습니다. 따라서 Discourse 사이트를 분리하려면 다른 곳에서 Redis 서버를 찾아야 하는 건가요? 제 이해가 맞나요?
그렇지 않습니다. Elasticache는 Discourse에서 문제없이 작동하며, 2019년 이후 AWS는 위에서 언급한 두 가지 문제점에 대해 상당한 진전을 이루었습니다. 이제 AWS는 더 작은 인스턴스 유형을 선택할 수 있게 하고, 리플리카 엔드포인트를 제공합니다.
팔코, 고마워! 한번 시도해 볼게!