[AWS] RDS_Multi AZ, Read Replicas

# Multi AZ (Multi-Availability Zone)

• 원래 존재하는 RDS DB에 어떠한 변화가 생길 때(ex. write) 다른 AZ에 현재 DB와 같은 복제본이 만들어진다.
  • Synchronize하게 일어나므로 생성으로 인한 delay는 매우 적다고 볼 수 있다.
  • ex) 어떠한 record에 insert 하게 되는 경우

• AWS에 의해서 자동으로 관리가 이루어진다.
  • 관리자의 개입이 필요 없다.

• Main RDS DB에 문제가 생겼을 경우 자동으로 다른 AZ의 복제본이 사용된다.

• ★ Disaster Recovery Only
  • Multi AZ에서 성능 개선을 위해 복제본을 많이 만든다는 것은 옳지 않는 경우이다.
  • 성능 개선을 기대하기 위해서는 Read Relica를 사용해야 한다.

---

• 위의 그림과 같이 3개의 EC2 인스턴스가 하나의 production RDS DB에 연결되어 write 기능이 실행되고 있다고 가정하자

• 현재 RDS의 end point는 A지만 write 기능이 실행 된 후 복제된 RDS DB에는 다른 end point 값을 갖게 된다.
  • 편의를 위해 현재 RDS의 end point는 가상으로 표시 한다.

• 만약 Main으로 작동하고 있는 end point가 A인 DB에 문제가 발생할 경우 RDS 는 복제된 DB로 fell over 한다.

---

- Multi-AZ의 장점

• 새로 만들거나 head worker가 필요 없기 때문에 문제 발생 시 Diaster recovery 시간이 현저히 줄어든다.

---

# Read Replica

• Production DB의 읽기 전용 복제본이 생성된다. (당연히 write 불가)

• 주로 읽기 작업의 요구가 많은(Read-heavy) DB 작업 시 효율성을 극대화 하기 위해 사용된다.
  • Scaling이 주 목적
  • ex) 많은 사용자가 하나의 웹 사이트에 접속하였을 때 서버 다운 같은 경우를 방지하기 위해서 사용.

• Disaster Recovery 용도가 아니다!!

• 하나의 RDS RB에 대하여 최대 5개의 Read Replica DB를 허용한다.
  • Read Replica 에서 Read Replica를 생성할 수 있다.
  • 그러나 Latency가 발생
  • Read Replica의 Read Replica는 다른 AZ에 만들 수도 있고 같은 AZ에 만들 수도 있다.

• 각각의 Read Raplica는 자기만의 고유 End Point가 존재한다.
  • RDS DB는 IP주소가 아닌 end point로 구분 가능하다.

---

위와 동일한 상황에서 EC2 인스턴스로부터 write 작업 요청이 Main DB로 들어오면

Read Replica에 의해 똑같은 RDS 복제본이 생성된다. 물론 완료된 write 작업 또한 복제본에 쓰여있다.

---

?? 왜 복제가 필요한가?

• 상황을 예를 들어 설명하도록 하겠다.
  • 대부분의 incoming traffic이 read traffic이라고 할 때 주어진 traffic 모두를 Main production DV로 연결시키는 것이 아니라,
  • 하나의 EC2 인스턴스를 각각 복제된 Read Replica로 연결시킨다.
  • 이는 Main DB의 workload를 현저히 낮출 수 있음을 보이고 성능 개선이 가능하다고 볼 수 있다.

---

야.. 구론데.... 까르보나라가 넘무 먹고시퍼....