알파리뷰 서비스를 micro architecture를 채택하고 있었다. 크게 shop과 review 두 부분으로 나누어 각각의 기능을 하고, 최소한의 데이터 교환을 http로 요청하는 구조이다. 두 부분으로 나눴기 때문에 한곳에서 장애가 발생해도 다른 서버로 파급이 적다.
aurora는 애플리케이션의 요구사항에 맞게 자동으로 확장하고 축소하기 때문에 인스턴스 크기가 유동적이고 실제 사용량에 따라 청구되기 때문에 경제적이다.
동일한 데이터를 수정할 때 발생하는 충돌을 최소화 하는 방안으로 DB인스턴스 간 쓰기 작업과 읽기 작업을 나누어 멀티 마스터 클러스터로 만들었다. write 요청과 read 요청을 나누어 각각이 EndPoint 로 로드밸런싱 하고 있기 때문에 쓰기 또는 읽기 작업의 비중이 눈에 띄게 다를 경우 효율적이다.
알파리뷰에서도 aurora를 쓰고 있다. 갑자기 거물 업체가 등장해 리뷰 수가 급증해도 그에 유연하게 대처 가능할 것 같다. 데이터 베이스에서의 쓰기 작업보다 읽기 작업이 많은 리뷰의 특성상 읽기전용 클러스터의 수를 늘려 동시에 쓰기작업을 하는 것을 막고 조회의 성능은 유지할 수 있을 것 같다.
이전에 aws에서 제공하는 RDS를 통해 원격 mysql 데이터베이스로 서버를 연결 한 적이 있다. 단순히 RDS는 분명히 자동 장애조치, 백업 등과 같은 기능을 제공하고 있다. EC2와 RDS로 배포를 했을 때 RDS 가격이 엄청 비쌌다. 매우 큰 트래픽이 아니라면 EC2에 데이터베이스 엔진을 설치하는 것이 낫다는 생각도 했었다.
만약 이용한 성능 만큼의 비용을 청구하며, 자동으로 로드밸런싱 해 주는 aurora를 알고 있었다면 rds보다는 aurora를 이용했을 것 같다.
