AWS RDS Failover, Scale-in, Serverless

HYEONG HWAN, MUN/ 12월 25, 2019/ 미분류/ 0 comments

https://blog.lael.be/post/9834

Database writer-reader 모델에서 Master node 에 장애가 발생했을시 조치하는 방법에 tier failover 가 있다.

(writer-reader, master-slave 라는 단어를 혼용해서 사용하겠다.)

Master node 에 장애가 발생하면, Reader 중에서 가장 적합한 것을 찾아 Master 로 승격시켜야 한다.
이 경우 모든 Reader 에 tier 를 정하고 가장 순위가 높은 tier 를 찾으면 master 로 승격시킨다.

 

AWS RDS 에서 failover 인스턴스를 고르는법

  • tier 가 가장 높은 것 (1이 가장 높고 15가 가장 낮다.)
  • 같은 tier 에 2개 이상의 instance 가 있는 경우, 현재의 master 와 동일한 instance type 의 장치를 고른다.
  • tier 도 같고 instance type 도 같다면 무작위로 하나를 선택한다.

 

내가 해보고 싶었던 것은

Reader(slave)의 어느 하나의 instance 를 Master 로 승격시키고 싶어졌다.

현재의 Master 는 트래픽을 전혀 받고 있지 않았다. (모든 트래픽은 reader group 이 받음)
아무런 장애가 없이 Master 노드를 변경할 수 있을까?

과정 : Master 가 되기를 바라는 인스턴스의 tier 를 높게 설정했다.
다른 reader node tier 는 15 이었고, 원하는 reader node tier 는 10, 현재의 master node tier 는 1로 설정했다.

Tier 변경 후 Master node 에 Failover 를 걸었다.

 

결과 : 원하는대로 다 동작하였는데(1 tier master 는 reader 가 되었고, 10 tier reader 는 master 가 되었다.), 장애가 발생했다.
Reader 노드의 그 instance가, Master 가 되기 전에 network 를 20초간 단절시키더라. 다른 reader node 는 그 동안 정상 동작했다.
reader 가 된 기존의 master 도 장애없이 정상적으로 동작했다.

다만, 20초 동안 master 가 될 reader node 로 들어오는 트래픽이 db connection refused 오류를 발생시키며 장애가 일어났다.

 

나의 결론 : RDS 무장애 failover 는 불가능하다. 이번 reinvent 2019 에서  RDS HA PROXY 라는걸 발표하긴 했는데, 아직 preview 단계이더라.
현재 상황에서, 최대한의 노력으로 master-reader 교체를 하고 싶으면 reader 를 15개 만들어라. 그 다음 failover 를 걸면 장애확률이 줄어들 것이다. (서비스는 20초 동안 1/15 확률로 장애가 일어날 것이다.)

 


RDS Writer - Reader 모델에서 장애없이 Reader 를 제거할 수 있을까?

참고로 EC2 Autoscaling 은 무장애가 된다. draining 이 있기 때문에.
또는 수동으로 제거하려면 Load balancer 에서 인스턴스를 빼고 작업처리 하면, 무장애가 가능하다.

RDS 도 Autoscaling 기능이 있지만 크게 조정할 수 있는 부분은 없다.

 

아무튼 1 Master - 8 Reader 환경에서 4 Reader 를 수동으로(손으로) 삭제해 보았다.

과정 : 4개의 Reader node 삭제.

결과 : 매우 오랜 시간(10분정도) 후, 장애 없이 reader instance node 가 제거되었다.
아마 draining 과 dns update 등 충분한 조치 후 제거 되는 것 같다. 무장애 가능.


RDS Serverless 의 성능은 얼마나 좋을까?

우와! 말만 들어도 좋은 기능이다. RDS Serverless.

Pre-defined 된 규칙에 따라서 성능이 자동으로 조절된다.

1 CPU core - 2GB RAM 에서 256 CPU core - 488GB RAM 까지 자동으로 조정된다.

테스트 결과만 말하자면, 기능동작이 신기하고 좋긴했는데, 민첩하지는 않았다.

즉, 위 그래프와 같이 일반적인 천천히 변화하는 서비스 트래픽에 대해서는 아주 잘 동작할 것이다.

다만, black friday 를 기다리는 쇼핑몰, 포털사이트 메인광고를 준비하는 사이트 등에서는 부적합했다. 적절한 크기를 찾아가는데 시간이 조금 걸리더라.

나의 결론 : 트래픽 변화가 서서히 이루어지면 serverless 는 좋은 선택, 그러나 급격한 트래픽이 예상된다면 처음부터 고정된 높은 사양의 인스턴스로 준비하는 것이 좋다. 정적인 성능 보장이 필요할 경우, serverless 사용하지 말것.

글 작성에 참고한 문서 : https://www.jeremydaly.com/aurora-serverless-the-good-the-bad-and-the-scalable/ 

 

생각해 볼 것 : large 성능에서 4초가 걸리는 쿼리가 있다. small 성능에서 10초가 걸린다면, 이 instance 의 성능은 무엇으로 설정해야할까?
적절한 인스턴스 성능을 찾는 것은 시간이 오래 걸리는 작업이다. 또한 타협가능한 적절한 성능을 찾는 노하우도 필요하다.

 

Leave a Comment

작성하신 댓글은 관리자의 수동 승인 후 게시됩니다.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*