나는 50,000개 이상의 세션을 가진 약 30,000명의 일일 사용자를 보유한 전자상거래 웹사이트를 운영하고 있습니다. 우리는 RDS m5.xlarge 인스턴스를 사용하고 있습니다. 일상적인 읽기 또는 쓰기 작업과 같은 문제는 발생하지 않습니다. 그러나 때때로 우리는 다음과 같은 어려움에 직면합니다.
- 어떤 날은 세일이나 공격적인 마케팅으로 인해 사용자가 두 배 이상 늘어나는 경우가 있는데, 그런 경우에는 하루 종일 CPU가 여러 번 100%에 도달하는 경우가 있습니다.
- 매우 가끔 쓰기 작업이 진행되는 동안 읽기 속도가 느려지는 경우가 있습니다.
이것을 보면 RDS 인스턴스를 수직으로 더 확장해야 할지, 읽기 전용 복제본을 스핀업해야 할지 판단할 수 없습니다. 이 결정을 내릴 때 고려하고 싶은 두 가지 사항은 다음과 같습니다.
- 읽기 전용 복제본이 있으면 트래픽이 많은 날 DB를 수직으로 배치할 필요성을 없애는 데 도움이 됩니까?
- 확장성을 높이면서 읽기 전용 복제본을 사용하여 비용을 낮추거나 동일하게 유지할 수 있습니까?
m5.xlarge 인스턴스에서는 평균적으로 다음과 같은 사용량을 사용합니다.
- CPU 사용량 40%
- DB 연결 100
- RAM 6GB 사용됨
- 125 쓰기 IOPS
- 3 IOPS 읽기
CPU를 제외하면 사용량이 매우 낮은 것 같은데, 읽기 전용 복제본이 비용 증가 없이 더 큰 확장성을 달성할 수 있는 방법인가요?
답변1
안타깝게도 컴퓨팅에는 존재하지 않는 자동 크기 조정 RDS가 필요한 것 같습니다.
RDS 크기 늘리기
인스턴스 크기를 늘리면 연중무휴로 더 많은 비용을 지불하게 됩니다. 이는 가장 간단한 솔루션이며 많은 문제를 줄여줍니다. 비용이 문제가 되지 않는다면 이것이 아마도 가장 좋은 문제일 것입니다.
복제본 읽기
다른 주요 옵션은 읽기 전용 복제본입니다. 읽기 전용 복제본을 사용하려면 기본 데이터베이스 URL과 엔드포인트가 다르기 때문에 소프트웨어를 수정해야 합니다. 예를 들어 모든 쓰기를 기본 데이터베이스로 보내고 모든 읽기를 읽기 전용 복제본으로 보낼 수 있습니다. 읽기 전용 복제본은 마스터의 업데이트보다 약간 늦을 수 있습니다. 기본 데이터베이스의 크기를 줄일 수도 있지만 접근 방식을 벤치마킹하거나 보수적으로 접근해야 합니다.
예상되는 주요 이벤트가 발생하기 전에 읽기 전용 복제본을 수동으로 가동하는 것을 고려할 수 있습니다. 이 작업은 수동으로 수행되고 시간이 좀 걸리며, 애플리케이션은 항상 그런 것은 아니지만 가끔 존재하는 데이터베이스를 처리해야 합니다.
캐싱
액세스 패턴에 따라 Redis/Memcached에서 데이터를 캐싱하면 데이터베이스를 업데이트할 필요가 없을 만큼 데이터베이스 로드가 잠재적으로 줄어들 수 있습니다. 물론 이는 동일한 데이터를 두 번 이상 읽어야 하고 충분한 캐시 저장 공간이 있어야 한다는 점에 달려 있습니다.
오로라
당신은 고려할 수 있습니다MySQL용 Amazon Aurora. 나는 그것을 직접 사용하지는 않았지만 확장성이 매우 뛰어나도록 고안되었습니다. 그러나 각 개별 트랜잭션은 표준 RDS만큼 빠르지 않을 수 있습니다.
데이터베이스 최적화
또 다른 옵션은 무엇이 데이터베이스 용량을 차지하고 "비싼" 쿼리 또는 인덱스를 최적화하는지 살펴보는 것입니다. 간단한 쿼리가 있고 부하가 높으면 도움이 되지 않을 수 있습니다.