RDS for Performance

RDS에서 높은 트래픽이 발생하는 경우 read/write에 대한 요청 양상이 다를 수 있다. 예를 들어 read 요청이 write 요청보다 3배 많다고 하자. 이 요청들을 하나의 인스턴스에서 다 해결하려다 보면 가장 큰 인스턴스를 사용한다 하더라도 여러 문제가 발생할 수 있다.

이 때 readrepilca라고 부르는 읽기 전용 복제본 인스턴스 클러스터를 생성하면 read/write 요청을 분할함으로써 각각의 트래픽에 대한 스케일링이 용이해지며 read 요청에서 많이 발생하는 커넥션 문제를 완화시킬 수 있다. wirte 전용 인스턴스는 master가 되며 나머지 read 전용 인스턴스들은 그에 대한 slaves라고 볼 수 있다. 하지만 failover용만으로 사용하는 것이 아니라 read 트래픽을 처리한다는 점에서 기존의 master-slave 모델과는 차이를 보이며, write용 인스턴스가 문제가 생길 경우 readreplica 클러스터 중 하나의 인스턴스가 master로 승격한다는 점에서는 failover의 성격도 갖고 있다고 볼 수 있다.

rds는 인스턴스 타입을 올릴수록 그 성능도 같이 올라간다. 하지만 올릴 수 있는 한계와 가격의 문제가 있기 때문에 적절한 인스턴스의 성능을 최대한 끌어올려서 사용할 수 있도록 튜닝을 하는 것이 중요하다. 튜닝할 수 있는 요소 중 집중해서 볼 곳은 커넥션과 메모리 문제가 있다.

간단하게 rds로의 최소 커넥션을 유지하려면 클라이언트 레벨에서의 connection_pool 사용, in-memory 캐싱이 우선적이다. 그리고 rds의 tcp keepalive 파라미터를 설정함으로써 tcp handshake를 반복적으로 하는 것에 대한 성능 하락을 막고 좀비 커넥션을 방지할 수 있다. rds에 접속하는 서버의 댓수와 각각의 connection_pool 사이즈를 알고 나면 rds에 최대로 생성 가능한 연결을 유추해볼 수 있다. 이와 스케일링을 같이 고려해 최악의 상황에서 연결 지연이 생기지 않도록 조심해야 한다. 이 이상으로 사용할 수 있는 방법에는 서비스당 DB 분리, 샤딩 등이 있다.

comments powered by Disqus