- Published on
Redshift를 사용하지 않기로 결정한 이유
- Authors
- Name
- Yumi Yang
Amazon Redshift는 클라우드에서 완벽하게 관리되는 페타바이트급 데이터 웨어하우스 서비스이다. 작게는 수백 기가바이트부터 시작하여 페타바이트 이상까지 데이터 확장 가능하며, 데이터를 사용하여 비즈니스 및 고객에 대한 새로운 인사이트를 확보할 수 있다고 소개되어 있다.
데이터 삽입 및 삭제와 같은 온라인 트랜잭션(OLTP) 기능을 포함하여 일반적인 RDBMS와 동일한 기능을 제공하기는 하지만, 특히 매우 큰 데이터 세트의 분석을 위해 최적화 되어있다. 예를 들어, 727개의 Thing 데이터를 불러올 때 처음 쿼리할 때는 느리지만, 캐싱 처리 되어 이후부터는 빠르게 결과를 준다.
이렇게 이론적인 내용을 인지한 후에, 콜드체인 프로젝트에서 데이터가 너무 많아 Redshift를 사용하기로 하였다. 개발을 했는데, 중간 중간 앗? 하는 포인트들이 있었다.
우선, 쿼리를 처음 날리면 데이터가 많은 경우 응답은 엄청 느리게 오는 경우가 있었다. 동일 쿼리를 반복해서 날리면 속도가 엄청 빨라지는데, Redshift의 결과 캐싱 덕분이다. 하지만 캐싱이 작동하려면 테이블 수정 여부, 쿼리에 사용된 함수 등 몇 가지 조건이 충족되어야 한다. 조건이 충족되지 않으면 캐싱이 적용되지 않으므로, 성능 차이가 발생할 수 있습니다.
쿼리 실행 시간을 줄이고 시스템 성능을 향상시키기 위해 특정 형식의 쿼리 결과를 리더 노드의 메모리에 캐시한다. 쿼리 결과의 유효한 캐시 된 복사본을 확인하고, 결과 캐시에서 일치 항목이 발견되면 캐시된 결과를 사용하고 쿼리를 실행하지 않는다. 결과 캐싱은 기본적으로 설정되어 있다. (현재 세션에 대해 결과 캐싱을 해제하려면 enable_result_cache_for_session 파라미터를 off로 설정)
Amazon Redshift는 다음 조건이 모두 충족될 때 캐시된 결과를 새 쿼리에 사용합니다.
- 쿼리를 제출하는 사용자가 쿼리에 사용되는 객체에 대한 액세스 권한을 보유합니다.
- 쿼리 내 테이블 또는 보기가 수정되지 않았습니다.
- 쿼리는 실행 시마다 평가되어야 하는 함수(예: GETDATE)를 사용하지 않습니다.
- 쿼리는 Amazon Redshift Spectrum 외부 테이블을 참조하지 않습니다.
- 쿼리 결과에 영향을 미칠 수 있는 구성 파라미터가 변경되지 않았습니다.
- 구문상 쿼리가 캐시된 쿼리와 일치합니다.
이런 캐싱 때문에 속도에 대해 기대했는데, 결론적으로 Redshift는 OLAP(대규모 데이터 분석 및 병렬 처리)에 최적화된 데이터 웨어하우스 서비스로, OLTP(온라인 트랜잭션 처리)가 요구되는 실시간 웹 서비스에는 적합하지 않다고 판단했다. DB를 Redshift만 사용하면서 설정 등도 모두 Redshift로만 처리했더니, 캐싱된 데이터보다 그렇지 않은 경우를 더 많이 호출하기 때문에 전반적으로 속도가 느리다고 느껴지게 됐다. Redshift는 데이터를 읽고 쓰는 처리 시간이 길고, 쿼리 결과 캐싱이 모든 시나리오에서 작동하지 않아 실시간 응답성을 요구하는 웹 서비스의 요구를 충족시키기 어려웠다.
그래서 데이터가 많은 부분, 대규모 데이터 분석이 필요한 센서 데이터가 있는 부분만 Redshift를 사용하고, 트랜잭션 성격이 강하거나 실시간 처리 요구가 있는 부분은 postgresql로 변경하고 있는중. Redshift는 동일한 쿼리를 반복해서 결과를 볼 때 속도와 데이터 처리 부분에 장점이 있다. 찾아보면 데이터 분석이나 대용량 병렬 처리를 사용할 때가 적합하다. 이렇게 데이터 특성과 사용 목적에 따라 데이터베이스를 구분하여 사용하는 것으로 성능을 최적화 하고 있다.
다음에는 Redshift를 대규모 데이터를 분석하거나 변경 추이를 시각화하는 반복적인 쿼리 작업(예: 대시보드에서 주기적으로 갱신되는 그래프 제공, 데이터 변화 추이 분석)에서 활용할 계획이다.