저는 EC2 인스턴스에서 Discourse를 호스팅하고 있으며, CDN의 과거 데이터에 따르면 커뮤니티의 월평균 요청량이 약 2,003만 건으로 예상됩니다. 필요한 인스턴스의 대수와 크기, 그리고 오토스케일링이 필요한지에 대한 조언을 구합니다.
음, Discourse를 하나의 머신에서 실행하는 것은 가능하고, 이를 위해 Docker 컨테이너를 하나 또는 두 개 사용할 수 있습니다. 하지만 여러 인스턴스에 분산하여 배포하는 방법에 대해서는 본 적이 없는 것 같습니다. 일반적인 방식은 인스턴스를 더 큰 규모로 확장하는 것입니다: CPU와 RAM을 더 많이 사용하는 것이죠. 그리고 업로드된 자산에는 로컬 저장소나 클라우드 저장소를 사용할 수 있습니다.
하지만 해당 수준의 트래픽은 초당 1~2건의 요청에 불과하므로, 생각보다 많지 않은 양입니다.
일반적인 권장 사항은 작은 인스턴스로 시작하여 메모리 사용량과 CPU 부하에 따라 필요할 때 크기를 조정하는 것입니다. 예산이 충분하다면 처음부터 더 큰 인스턴스를 사용하는 것도 좋습니다.
죄송합니다. 월 2,000만 건의 요청이 발생합니다. 현재 웹사이트는 7개의 t3a.medium 인스턴스와 1개의 t3a.large 인스턴스를 사용하여 오토스케일링을 적용하고 있으며, 이 웹사이트를 Discourse 플랫폼으로 이전할 예정입니다. 필요한 인스턴스의 수와 크기에 대한 조언, 그리고 오토스케일링이 필요한지에 대한 의견을 부탁드립니다.
정확히 어떤 환경이 필요한지 추측하기는 어렵습니다. 월 350만 페이지뷰를 8GB 4CPU VM에서 처리하는 사이트가 있다는 것을 알고 있습니다. 이를 기준으로 삼을 수 있습니다. 해당 사이트는 자체적으로 이미지를 서빙하고 있는데, 여러 인스턴스를 사용하는 경우(쉽게?) 이를 수행할 수 없습니다. 아마도 사이트와 S3 버킷에 대해 S3와 CDN에 자산을 둘 것입니다.
"요청(request)"과 "페이지뷰"가 동일한 개념일 가능성은 다소 낮습니다.
스케일링이 필요한지는 트래픽 패턴에 따라 달라집니다. 이전에 스케일링이 필요했다면, Discourse를 사용해도 여전히 필요할 가능성이 높습니다. 트래픽이 비교적 일정하고 스케일링이 필요하지 않다면, 쉬운 해결책은 단일 대형 VM과 아마도 RDS, 그리고 Elasticache를 사용하는 것입니다. 또한 팀이 선호하는 도구와 방법, 예산 등에도 따라 달라집니다.
Discourse를 호스팅하는 단일 대형 EC2 인스턴스가 장애를 일으키면 사이트 전체가 중단됩니다. 이에 대한 해결책을 제시해 주세요. 데이터베이스에는 RDS를, 캐시에는 ElastiCache를 사용할 계획입니다.
그렇다면 로드 밸런서와 함께 ECS나 다른 선호하는 솔루션을 사용하세요.