[aws 패턴] 인메모리 캐시 & 고속 RDB를 활용하여 성능 요구사항 만족하기

개인 aws study note입니다.

수정이 필요하거나 다른 의견은 댓글로 남겨주세요.

(무단 복제 및 배포를 금함)

성능 확보하기

 

성능을 향상(혹은 안정적으로 제공) 시키기 위한 다양한 애플리케이션 서비스들이 있다.

온라인 트랜잭션이 많은 인트라 웹을 운영 할 때, 혹은 트랜잭션이 업무 특성 상 특정 시기(월말/분기 등등)에만 증가하는 케이스,

리소스 상황에 맞게 처리 능력을 가져가는 것을 목표로 할 경우 등등에서 성능을 안정적으로 가져갈 수 있도록 하는 방법을 알아보자.

 

---

 

온라인 트랜잭션 처리의 경우, 리소스를 차지하는 대부분의 시간은 '데이터 액세스' 시간이다.

트랜잭션이 폭발적으로 급증할 경우, 병목현상이 발생하여, 서비스 중단 사태(가용성 훼손)가 발생 할 수 있다. 

데이터 액세스 시간을 줄이기 위한 방법에 대해 알아보자. 

 

1.  인메모리 캐시

자주 호출되는 데이터를 인메모리 캐시 서비스인 아마존 엘라스틱캐시(Amazon ElasticCache)에 캐시하여 빠르게 액세스 할 수 있도록 하는 방법이다. 엘라스틱캐시는 인메모리 데이터 캐시의 관리형 서비스로, 온프레미스에서도 많이 사용되는 엔진인 Memcached**와 Redis**를 지원한다. 앞서 말했듯 관리형 서비스에 속하기 때문에 장애 시 클러스터 재구성, 패치 적용 등이 자동화 되어 있는 것이 특징이다. 별도의 API로 액세스하여 RDS의 데이터를 캐시할 수 있다.

 

 

 1-1. Memcached와 Redis

두 캐시 엔진 모두 인메모리로 Key-Value 저장소로, 고유한 키 값에 액세스할 수 있는 정적 데이터 구조에 적합하다. 데이터를 메모리에 저장하고 프로그램이 캐시를 참조하여 데이터 액세스를 고속화 하는 것이 기본 골자다.

제한된 메모리 용량을 효율적으로 사용할 수 있도록 크기가 작으면서도 참조 빈도가 높은 데이터와 세션 정도 등을 저장하는데 적합하다.

두 엔진 모두 메모리에서 데이터를 처리하기 때문에 속도가 빠른 장점이 있는 반면, 장애로 인한 데이터 유실에 대비해야 한다.

두 엔진은 세션의 정합성 이슈를 해결하기 위한 것으로 비슷한 듯하지만 차이점이 있으므로, 적절한 엔진을 선택하여 사용하는 것이 중요하다. 

 

Memcached

-멀티 스레드의 경우

-scale out에 용이하지만, 캐시된 데이터 일부/전체를 유실할 가능성 높음

-상대적으로 작고 정적인 데이터를 캐싱하는 경우(파일/사진 등)

 

Redis

-싱글 스레드(한 번에 하나의 명령만 수행 가능): read/write 작업 시, Master에서만 동작하여 아무리 여러개의 Replica가 있다고 하더라도 성능측면에서는 도움이 안됨. 지연 발생 가능성 높음

-인메모리 데이터 세트 정렬/우선순위 필요 시

 -String, Sets, Sorted Sets등 복잡한 데이터 유형이 필요한 경우

-백업 및 복원 필요 시

-여러 데이터베이스 지원 필요 시 

(메인 메모리가 부족할 경우, 하드디스크에 SWAP을 임시적으로 만들어 사용하게 되는데, SWAP하는 동안 latency가 발생하는 치명적인 담점이 있다. 따라서 고가용성, 연속성을 위해 클러스터링 방식을 사용한다. 

 -Redis Replication, Redis cluster, Redis Sentinel, Redis Topology, Redis Sharding, Redis Failover 등등)

>읽기 전용 복제본을 추가하여 처리 능력과 데이터 복원력을 확보 할 수 있음

 

 

 

2. 빠른 RDS이용하기

RDB의 관리형 서비스인 RDS(Amazon Relational Database Service)에서 제공하는 다양한 DB엔진(AWS-Architecture-Icons) 중, 선택하여 사용하는 방법이다.

AWS-Architecture-Icons

 

오로라는 로그 구조 저장소(Log Structured Storage) 저장소 시스템으로 구성되어 있어, 추가 확장이 자유로운 최대 장점이 있다. 

MySQL과 비교하였을 때, MySQL은 데이터를 업데이트할 경우, 데이터 신뢰성/일관성을 위해 Lock상태 즉 잠금이 발생하게 되고, 이는 처리량 저하로 이어질 수 있다. 또한 AZ 내 RDS에 업로드 후, AZ 내 Replica RDS까지 각자 업로드후, Replica AZ로 전달하여 같은 과정을 반복하게 된다. 하지만 오로라는 잠금으로 인한 대기가 발생하지 않아 읽기 속도가 빠르고, 연속해서 데이터를 추가하는 방식으로 쓰기 속도도 빠르다. 또한 Master에서만 업로드를 하고, 읽을 때는 Shared Storage에서 각자 읽어올 수 있어 읽기 성능이 높다. 또한 대부분의 데이터를 인메모리 캐시로부터 읽어서 속도가 더욱 빨라 동시 실행 수가 많으면서, 데이터 크기가 클 수록, 읽기 처리가 많을수록 상대적 성능이 매우 높다.

 

 

2-1. 오로라 데이터 읽기/쓰기

MySQL과 Aurora의 가장 큰 차이점은 스토리지 구조에서 온다. 위 그림과 같이, 오로라의 로그 구조 저장소는 3개의 가용영영과 총 6개의 쿼럼(디스크)로 구성되어 있다. 간편하게 읽기 전용 복제본을 증설하여, DB를 수평적으로 확장할 수 있다. 

앞서 말한 데이터 업데이트 시 잠금이 발생하는 MySQL과 달리 오로라는 원본 인스턴스에서만 실행되며, 스토리지 끝 부분에 추가되는 형식으로 빠른 속도를 제공할 수 있는 것이다.

 

아마존 쿼럼(Amazon Quorum)모델을 더 자세히 살펴보자.

총 여섯개의 복사본 쿼럼을 사용하게 되는데, 6개 중 4개의 복사본에 쓰기 완료/ 3개의 복사본에서 읽기 완료 응답을 받으면, 해당 쓰기가 완료된 것으로 확인한다. 읽기와 쓰기 모두 6개의 쿼럼 중 빠른 응답순으로 선정되게 된다.

또한 쓰기/읽기 응답 완료는 IncomminㅂQueue를 지나, UpdateQueue에 쌓이면 바로 ACK를 전달하기 때문에 응답을 미수신하여 딜레이가 발생하는 경우는 거의 없다고 보면 된다.

 

aws 공식 docs

 

aws 리전을 AZ로 분리해서 가져가는 이유는 연속성을 보장하기 위한 다중화 구조이다. 다양한 이유로 인한 데이터 유실 시, 오류에 대한 격리 영역을 만들어, 가용성을 잃지 않고, 내결함성을 유지할 수 있도록 해주는 장치 마련으로 볼 수 있다.

쿼럼에 대한 자세한 내용은 이곳에서 확인 가능하다.

 

 

 

 

 

 

 

-참고

https://wildeveloperetrain.tistory.com/21  

https://docs.aws.amazon.com/rds/index.html?nc2=h_ql_doc_rds