트래픽 증가에 대비해 DB 용량을 검토했다. 부하 테스트에서 평소보다 두 배 많은 요청을 처리한 뒤 여유가 있다고 봤다.
운영에서는 DB 장애가 났다. 공개된 메트릭에는 한계에 도달했다는 신호가 없었다. 장애 후 벤더의 내부 메트릭에서 포화 상태를 확인했다.
우리가 확인할 수 있는 정보만으로는 남은 용량을 알기 어려웠다.
부하 테스트 결과는 재현한 조건 안에서 유효하다. 요청량이 같아도 일정한 트래픽과 짧은 시간에 집중되는 트래픽은 DB에 다른 부하를 만든다.
운영 환경에서는 마이크로 버스팅(Micro-burst)이 발생했다. 평균 처리량에는 여유가 있었지만 짧은 구간에는 DB의 한계를 넘었다.
테스트에서 처리한 요청량을 운영 환경의 남은 용량으로 해석했다.
그 뒤로는 처리한 요청량과 트래픽이 들어오는 형태를 함께 봤다. 짧은 구간의 최대 부하도 확인했다.
관리형 DB는 네트워크 송수신량과 CPU 같은 메트릭을 제공한다. 사용량이 낮게 보인다는 이유만으로 내부 한계까지 여유가 있다고 판단할 수는 없었다.
AWS는 Aurora의 NetworkThroughput과 StorageNetworkThroughput을 더해 인스턴스 클래스의 네트워크 한도와 비교하도록 안내한다. 공개된 값을 조합해야 한계에 가까운지를 추정할 수 있다. Aurora DB 인스턴스 사용량 확인 방법
벤더는 포화 상태를 보여주는 내부 메트릭을 가지고 있었다. 이 메트릭은 사용자에게 공개되지 않아 대시보드와 경보에 넣을 수 없었다.
보이지 않는 메트릭에는 경보를 만들 수 없다. 공개된 지표가 정상 범위에 있어도 남은 용량을 보장하지는 않았다.
관리형 DB는 기반 시설을 운영하는 부담을 줄여준다. 조직 규모와 비용을 고려하면 자체 DB 장비를 운영하기 어려웠다.
운영 가시성은 벤더가 공개하는 범위로 제한된다. 내부 상태를 확인할 수 없으면 벤더의 지원이 필요하다.
이 제약을 용량 판단에 반영해야 했다. 중요한 트래픽을 앞두고 공개되지 않은 한계가 무엇인지 벤더에 확인할 필요가 있었다.
장애 후 스케일아웃 기준을 다시 봤다. 평균 CPU나 처리량을 기준으로 삼으면 마이크로 버스팅을 놓칠 수 있다.
DB 메트릭과 같은 시간대의 애플리케이션 지연과 요청 실패를 함께 봐야 했다. 내부 한계가 메트릭에 드러나지 않아도 요청이 느려지거나 실패할 수 있기 때문이다.
관리형 서비스는 모든 내부 상태를 공개하지 않는다. 보이는 숫자만으로 용량을 판단하면 같은 문제가 반복될 수 있다.
같은 시간대의 애플리케이션 지연과 요청 실패도 더 세밀하게 확인하기 시작했다.