AWS RDS 스케일 업

일을 시작한지 어언 9개월이 지나가고 있는데 사용자의 요청이 몰리는 시점에 DB의 cpu 사용률이 90% 이상을 도달하며 간당간당한 상황이 이어지고 있었습니다. 부하를 줄이기 위해 읽기 복제본도 두고 있지만 당장의 문제를 해결하기에는 역부족이었습니다. 따라서 스케일업 혹은 스케일 아웃을 통해 이 문제를 해결해야 했습니다. 현실적으로 스케일 아웃을 하기에는 쿼리 튜닝과 샤딩 등도 고려가 필요하기에 당장 적용하기에는 무리라고 판단하여 스케일업을 진행하게 되었습니다.

그래서 어떻게 할건데?

운(?)이 좋게 스케일업에 대한 조사와 테스트, 실제 적용도 담당하게 되었습니다. 다른 많은 서비스 처럼 AWS RDS를 사용중이기에 레퍼런스를 찾아보는 것부터 시작하였습니다. 공식문서와 실제 적용 사례들을 찾아보며 적용해볼만한 방법을 추려보았습니다.

• Multi AZ Cluster - 서울지역 미지원
• Multi AZ Instance
• RDS proxy

추가로 DBA께서 추천한 방법은 아래와 같습니다.

• Multi AZ Instance + 서비스 점검 시간 
  
  • 점검 시간을 두어 트랜잭션이 0인 상태에서 장애조치를 통한 스케일업
• Aurora DB로의 마이그레이션
  • 읽기 복제본이 장애조치에 활용되어 금액적인 이득과 HA 구성이 가능
  • 예약 인스턴스와의 호환도 고려가 필요
• DMS를 이용한 마이그레이션
• 읽기복제본의 승격
  • endpoint를 직접 수정해야 함

각각의 방법에 대한 자세한 내용은 따로 생략합니다.

Multi AZ Instance에 대한 내용을 따로 정리하기에 앞서 간단하게만 정리하면 아래와 같습니다.

• 다른 AZ에 대기 인스턴스를 두어 장애조치를 자동으로 진행할 수 있어 고가용성 구성을 도모할 수 있다.
• 읽기 복제본을 두는 것과는 무관하다.
• 하지만 대기 인스턴스는 서비스에 직접 사용할 수는 없고 어디까지나 문제가 있는 경우 장애 조치용으로 존재하기에 사용하게 되는 비용이 다소 증가할 수 있다.

테스트와 실제 반영

실제 live 환경에 적용하기에 앞서 실제와 비슷한 환경에서의 테스트를 진행하려 했습니다. live DB의 스냅샷을 다른 지역에 전송하여 이를 가지고 인스턴스를 생성하여 Multi AZ 설정과 장애조치로 대략 걸리는 시간이나 과정에 익숙해지려고 했습니다. 체크리스트를 만들어 점검할 부분과 결과를 기록하였습니다. 테스트에서 아쉬웠던 점은 실제로는 서비스 점검 시간 없이 진행할 것이라 locust로 요청을 만들면서 그 사이에 진행하였는데 RPS(초당 요청 수) 가 충분하지 못해 테스트에서 소요된 시간보다 실제에서 더 걸릴 것으로 예상하였습니다.

 

테스트 이후 새벽 시간에 요청이 적은 시간을 골라 실제 스케일 업을 진행하였습니다. 예상대로 테스트보다 시간이 더 걸리기는 하였으나 multi az 설정과 원하던 크기의 인스턴스로 변경하여 큰 문제없이 스케일 업을 마무리하였습니다.

결과

피크 시간에 문제가 되었던 RDS의 CPU 사용률은 크게 줄어들어 현재 안정적인 모습을 보여죽고 있습니다.

하지만 live DB의 읽기 지연시간이 크게 증가하였고 이에 대한 여러 추측을 해보았지만 명확한 이유는 알 수 없었습니다. 일주일 정도가 지난 후에는 기존과 비슷한 수준의 지연시간을 보여 일시적인 현상으로 보이기도 합니다.