DAY? AWS를 활용한 웹 3Tier Architecture_2

 

이어서 DB 쪽을 보면, Aurora라는 DB를 사용하기 전에 ElasticCache를 위치 시켰다.

ElasticCache는 인메모리 DB로, Reids와 Memcached라는 두 가지 캐시 엔진을 지원한다.

이러한 ElasticCache는 Aurora DB 클러스터에 접근하는 횟수를 줄여 DB의 부하를 줄일 수 있다.

둘 다 key-value 저장소인 NoSQL DB로 볼 수 있는데, 차이점이 있다.

간단하게 보면, 

Memcached는 상대적으로 간단한 데이터(string만 지원), 작고 정적인 데이터를 캐싱할 때 사용된다. 멀티스레드, 멀티프로세스코어를 지원하기 때문에 스케일업을 통해 많은 작업처리가 필요할 때 적합하다.

이에 반해, Redis는 String, set, sorted set, hash, bit 리스트 등 다양한 데이터 타입을 지원하고(데이터 세트를 정렬하거나 순위 지정한 데이터 등을 활용하여 다양한 활용 가능), 데이터 저장이 memory 뿐만 아니라 disk에도 저장하기 때문에 백업이 필요하다면 백업도 가능하다. 또한 트랜젝션을 지원하여 ACID(원자성, 일관성, 독립성, 지속성)의 특징을 가진다. 또한 master-slave 구조로 복제가 가능하여, 장애 조치가 가능하고, 고가용성을 확보할 수 있다. 

Redis가 Memcached에 비해 많은 장점을 가지고는 있지만, 싱글 쓰레드이기 때문에 1번에 1개의 명령어만 실행 할 수 있어 많은 양을 다루는 명령어(모든 데이터 삭제, 모든 저장 된 키 조회)를 수행할 때 Memcached에 비해서 상대적으로 많은 시간이 소요된다. 그리고 Redis는 특정 간격마다 데이터를 디스크에 저장하게 되는데, 이때 시간이 많이 소요 된다.

따라서 다양한 데이터 타입을 지원할 필요가 없거나, 백업 및 복구, 고가용성 등이 필요가 없고, 트랙젝션이 필요하지 않다면, memcached를 사용하는 것이 간단하고 빠를 수 있다.

 

데이터베이스는 오로라, Aurora를 사용했다. 오라라는 RDBMS로, Mysql보다 최대 5배, postgre 보다 최대 3배 빠른 고성능 DB이다. 성능에 대해 얘기하기전에, Read Replica로 오로라 DB 인스턴스를 복제하였다. 이와 같은 구조는 읽기 작업에 대한 분산 처리가 가능하며, Read Replica 간의 LB은 Aurora가 자체적으로 지원한다. 그림에서는 Master라고 했지만, 기본 인스턴스라고 하며, Read Replica를 읽기 전용 오로라 복제본이라고 하는데, 만약 기본 인스턴스에서 문제가 발생하면, 리더 인스턴스 중 하나가 기본 인스턴스 역할을 인수하는데 이를 failover라고 하며 이는 자동적으로 이뤄진다.

오로라는 AWS RDS(Mysql, PostGRE)와 차이점을 가지는데 가장 큰 차이는 스토리지로 볼 수 있다. RDS는 인스턴스 밑에 EBS가 있고, 이 EBS를 백업하는 EBS가 있다. 그러다보니, ReadReplica를 읽기 작업 분산 처리를 위해 두거나 고가용성을 위해서 복제본을 두었을 때, DB 인스턴스 1 -> EBS 쓰기 -> 백업 EBS 쓰기 -> 복제 DB 인스턴스로 데이터 복제 -> 복제 DB EBS 쓰기 -> 복제 DB 백업 EBS 쓰기 와 같은 작업을 거친다. 쓰기에 많은 리소스를 할애해야 하는데, 이에 반해 오로라의 경우 스토리지가 3개의 가용영역에 6개(각 2개 씩)가 있으며, 이 6개의 저장소는 특정 오로라 DB 인스턴스와 단독으로 연결된 것이 아니라 기본 DB 인스턴스와 리더 인스턴스와 공용으로 사용하는 공용스토리지 이다. 따라서 RDS는 Binlog를 받아 ReadReplica도 쓰기 작업을 수행해야하지만, 오로라의 ReadReplica의 경우 Redo log만 받아 동기화 하기 때문에 읽기 작업에 리소스를 집중 할 수 있다.

또한 오로라는 4/6 쿼럼와 3/6 쿼럼 방식으로 쓰기와 읽기방식을 지원하는데, 이는 쓰기 과정은 4개의 스토리지에서 응답연락이 오면 완료, 읽기는 3개의 노드가 동일한 값을 주면 완료 된다는 뜻이다. 여기서 완료가 된다는 것이 사용자가 완료 될때까지 기다리는 것과는 다르다. 쓰기가 발생하면, Incoming Queue라는 곳에 쌓이고, 이는 update queue에 쌓이게 된다. update queue에 쌓이면 ACK를 보내고, DB 인스턴스는 다음 작업을 수행하게 된다. 그리고 스토리지는 4개의 스토리지에 쓰기 작업을 진행하고 완료 응답을 보낸다. 완료 응답을 보내면 VCL이라는 값을 가지는데, 쓰기가 완료되었다는 것으로 Volume Complete LSN(Log Sequence Number)의 약자이다. 이 VCL을 기준으로 쓰기 작업에 문제가 생겼을 때 복구 작업을 진행할 수 있다.(Consistency point LSN을 Volume durable LSN로 정의, CPL 이후 값을 다 지우고 복구 진행,ACID확보를 위한 작업)

VCL 값을 가지면 Backgroud의 작업이 일환으로 나머지 2개의 스토리지에 카피를 한다. 우선적으로 진행되지는 않지만, 결과적으로는 6 스토리지 모두 동일하게 데이터를 가지고 있다.

추가적으로 오로라는 최대 15개의 읽기 복제본을 지원하고, 공용스토리진느 64TB까지 자동확장된다.

그림에서 보면, 읽기는 양쪽에서 진행되지만 쓰기는 MASTER(기본, Prime)에서 진행되기 때문에, 쓰기의 경우는 한쪽을 점선으로 해두었다.