[AWS] 개별 EC2 아키텍처 + DB 이중화(feat. Multi-AZ)

이 포스팅에서는 아키텍처 버전3을 구축하는 과정을 다룬다.

---

아키텍처 버전3으로 분류하긴 했지만 아키텍처2에서 DB만 이중화한 것이다.

AWS에서 Multi-AZ라는 메뉴를 이용하면 간단하다.

Multi-AZ는 Master/Slave로 DB 환경을 구성하고 Active - StandBy로 운영된다.

평소에는 Master 인스턴스가 서비스 되다가 장애 발생 시 Slave 인스턴스가 Master로 승격되서 서비스를 지속한다.

승격하는 과정은 서버, 네트워트 등 환경에 따라 다르지만 AWS 측에 따르면 60초 내외로 전환된다고 한다.

https://aws.amazon.com/ko/rds/features/multi-az/

AWS에서 마우스 몇번 클릭하면 이 모든게 설정된다.

AWS에서 DB 이중화 방식은 2가지가 있다.

방식	Multi-AZ	읽기 전용 복제
장점	데이터 정합성(동기식 복제), 고가용성 제공(자동 장애 조치), 장애 발생 시 자동전환	읽기 성능 향상(읽기 부하 분산)
단점	Slave가 Master로 승격되는데 일정 시간 소요, 읽기 성능 향상 없음	데이터 정합성 나쁠 수 있음(비동기식 복제로 인해 데이터 지연 가능성 O), 장애 발생 시 자동 전환 X

이번엔 이 중 첫번 째 방식을 구축했다.

이 방식은 성능보다는 데이터의 정합성과 고가용성(안정적인 운영) 측면에서 유리하다.

Multi AZ

DB 인스턴스 수정을 들어가서 가용성 및 내구성 부분의 다중AZ 배포에서 대기 인스턴스 생성(생산 사용량에 권장)에 체크 후 즉시 적용으로 수정하면 된다.

또는 인스턴스 목록화면에서 작업 > 빠른 작업 > 다중 AZ 배포로 변환을 누르면 된다.

얼마 뒤 다중 AZ가 아래처럼 변경된다.

처음엔 당연히 인스턴스 목록에 하나가 더 추가되서 2개가 보일 줄 알았는데 한개만 보인다.

테스트

테스트 주요사항은 2가지다.

Master에서 Slave로 데이터 동기화가 되는지, 애플리케이션 에러 후 얼마만에 다시 복구되는지다.

DB 테이블

Master DB 장애 전 시점의 데이터로 복구할 수 있는지 테스트 해보기 위함이다.

테스트를 위해 임시 테이블(미리 생성 필요)에 테스트 데이터를 추가로 넣은 후 현재 인스턴스의 카운트를 체크한다.

데이터를 5건 추가해서 현재 카운트는 510건이다.

서버 로그

데이터 동기화 테스트를 위해 서버 로그로 임시 테이블의 카운트를 출력하도록 해놨다.

DB 인스턴스 재부팅

인스턴스 재부팅을 클릭한다.

재부팅 시 장애 조치로 재부팅하시겠습니까? 옵션에 체크를 해야 Slave가 Master로 전환된다.

확인을 누른다.

재부팅 한 다음 바로 재부팅 되는게 아니라 일정시간 후에 재부팅이 이루어지기 때문에 20초 정도 후에

브라우저를 새로고침 해보자.

브라우저에서 로딩이 계속 되면 재부팅이 시작된 것이고 서버 로그를 보면 아래처럼 DB 연결이 끊긴 것을 볼 수 있다.

브라우저 로딩 시작 되었을 때부터 스탑워치로 초를 제보니 애플리케이션 다시 살아나는데 36초가 걸렸다.

물론 테스트 애플리케이션은 로그만 찍은 정말 간단한 애플리케이션이고 외부 트래픽이 전혀 없다.

일정 시간 후에 서버 로그에 테이블 카운트가 510건이 찍힌걸 보니 데이터 동기화가 제대로 되었다고 할 수 있다.

당연히 Tomcat 2번도 제대로 510건이 찍힌다.

실제로 DB 이중화 인프라를 해본 적은 없지만 AWS의 RDS 옵션이 아니고 직접 서버에서 DB 이중화를 위해서는 정말 많은 작업이 필요할 것으로 추정되는데 위처럼 이 구조를 구축하기 위해 내가 한 것은 마우스 클릭이 전부다.

이로써 아키텍처 버전3도 끝이 났다.

---

개인 스터디 기록을 메모하는 공간이라 틀린점이 있을 수 있습니다.

틀린 점 있을 경우 댓글 부탁드립니다.