안녕하세요 김범환입니다. 

AWS에서 Re:invent를 맞이해 Redshift의 새로운 기능들을 출시했습니다. Redshift는 꽤 오래된 서비스로 2012년 발표 이후 지금까지 많은 고객이 사용하고 있습니다. 이번 re:invent에서도 그동안 Redshift에 필요로했던 기능들을 몇 가지 발표했습니다. 

1.RA3.xplus 노드 출시

https://aws.amazon.com/ko/about-aws/whats-new/2020/12/amazon-redshift-launches-ra3-xlplus-nodes-managed-storage/

Stop/Restart는 클라우드에서는 기본적인 기능일텐데 왜 Redshift에서만 지원하지 않았던 걸까요? 제 생각에는 Redshift의 Storage와 Computing이 완벽하게 분리되어 있지 않아서 그랬던것 같습니다. 스토리지가 컴퓨팅노드에 결합되어있기 때문에 Stop하는 경우 EC2의 instance store가 보존되지 않듯이 날아가서 stop기능을 지원하지 않았던게 아닐까… 싶습니다. 

그러면 왜 Redshift는 Computing과 Storage를 붙여놓았을까요? 이것도 제 생각이지만, 데이터 분석 워크로드의 특성상 높은 IO성능이 있어야 하는데 이를 네트워크 스토리지로 구현하려면 어마어마한 성능의 네트워크를 구현해야합니다. 그에비해 그냥 한 머신 안에서의 IO 속도는 그다지 큰 비용을 들이지 않아도 네트워크를 이용하는것에 비해서는 매우 높은 성능을 만들어낼 수 있죠. 그래서 Redshift는 하나의 노드에 Computing과 Storage를 결합한 형태를 만들어 놓은 것이 아닌가… 하는것이 제 생각입니다. Redshift는 적어도  RA3 노드가 나오기 전까지는 성능적으로는 우수할 수 있지만 클라우드의 장점인 Computing리소스와 Storage 영역의 분리로 인한 이점을 누릴 수는 없었습니다. 물론 이러한 점을 커버하기위해 Redshift Spectrum이라는 확장판(?)같은게 있지만요.  

RA3라는 노드타입이 출시하면서 드디어 Redshift도 컴퓨팅과 스토리지가 분리되어있는 아키텍쳐로 발전하게 되었습니다. 저렴한 S3를 스토리지로 쓰면서 전용 ssd를 캐시영역으로 쓰는 방식으로 구현이 되었다고 하네요. 기존에 Redshift는 저장용량을 늘리려면 노드를 추가해야 했는데 ra3 노드가 나오면서부터는 그럴 필요가 없어졌습니다. 

그런데 이 RA3 인스턴스가 처음 나올 때는 16xlarge 사이즈로 나왔습니다(2019년 12월). 48개의 vCPU, 384GiB라는 엄청난 크기죠. 그런데 이게 너무 크다보니깐 좀 부담습니다. 그래서 2020년 4월에 4xlarge라는 덜 부담스러운 사이즈를 내놓습니다(12vcpu, 96Gib). 4xlarge도 부담스러운 고객들을 위해 내놓은게 xlplus입니다. 보통 AWS에서는 노드의 사이즈를 정수배로 내놓는데 이번엔 특이하게 1/3 사이즈를 내놨네요. 이렇게 노드사이즈가 작아지면 작아질수록 고객 입장에서는 선택지가 많아져서 좋은것 같습니다. 

2. 클러스터를 AWS 가용 영역(AZ) 간에 쉽게 이동할 수 있는 기능 출시

https://aws.amazon.com/ko/about-aws/whats-new/2020/12/amazon-redshift-launches-ability-easily-move-clusters-between-aws-availability-zones/

그동안에는 Redshift 클러스터를 이전하는게 불가능 했습니다. 스냅샷을 떠서 새로 생성해야만 했던 것에 AZ간 이동기능이 추가되었습니다. 특정 AZ에 문제가 있는경우나, 혹은 비용등의 이슈로 특정 AZ를 사용해야만 하는 일이 있으면 이런 기능이 유용하겠네요. 

3.  Automatic Table Optimization 발표

https://aws.amazon.com/ko/about-aws/whats-new/2020/12/amazon-redshift-announces-automatic-table-optimization/

Redshift는 분석 속도를 높이기 위해구현된 분산 클러스터입니다. Redshift의 성능을 최대로 끌어올리기 위해서는 데이터를 분산된 클러스터에 잘 분포시키는 것이 중요합니다. 그래서 항상 AWS의 세미나에서는 Redshift의 설계 방법에 테이블 분산키를 결정하는 방법을 설명했죠. 하지만 분산 키를 결정하는게 쉽지는 않았는데 이번 기능을 통해 사용자가 직접 분산 방식을 결정하지 않아도 Redshift가 알아서 최적화를 해준다고 합니다. 사용자 입장에서 까다로운일을 하나 덜게 된것 같습니다. 이 기능이 과연 수동으로 최적화하는것과 어느정도의 성능차이를 보여줄지도 궁금하네요.

4. RDS MySQL, Aurora MySQL에 대한 federated query 지원 (프리뷰)

https://aws.amazon.com/ko/about-aws/whats-new/2020/12/amazon-redshift-now-includes-amazon-rds-for-mysql-and-amazon-aurora-mysql-databases-as-new-data-sources-for-federated-querying-preview/

federated query 기능이 점점 데이터 분석시스템의 중요한 요건 중 하나가 되어가는 것 같습니다. 데이터베이스의 종류도 다양해지고 데이터를 원하는 부서도 다양해지다보니 하나의 플랫폼에서 여러가지 커넥터를 이용해 데이터를 조회할 수 있기를 바라게 되는것 같네요. 아직은 preview지만 Athena에도 이런 federated query 기능을 지원하고 redshift도 postgreSQL에 대해서는 federated query 기능을 지원했었는데 이번에 MySQL 도 추가가 되었네요. 

사실 Redshift는 OLAP라는 한계 때문에 실시간성의 데이터를 분석하기에는 어려움이 있었습니다. 이런 federated query 기능이 지원이 되면 실시간으로 변하는 데이터를 굳이 Redshift에 동기화 시키지 않아도 기존에 사용하고 있는 OLTP 데이터베이스에서 데이터를 받아와 분석 데이터를 만들 수 있게 되었습니다. 

5. AWS, Amazon Redshift ML 발표(평가판)

https://aws.amazon.com/ko/blogs/big-data/create-train-and-deploy-machine-learning-models-in-amazon-redshift-using-sql-with-amazon-redshift-ml/

이제는 대용량 데이터베이스에서 ML을 지원하는게 대세가 되어가는 듯 합니다. 머신러닝에는 아무래도 ‘대용량’의 ‘정리된’ 데이터가 필요한데 아무래도 이런 조건에 데이터웨어하우스가 잘 들어맞기 때문에 머신러닝도 데이터웨어하우스에서 돌리려고 하는것 같습니다. 또 한편으론 요즘 분석 업무엔 통계적 분석 뿐만 아니라 기계학습에 의한 분석도 필수가 되어서 어차피 분석을 돌리는 데이터웨어하우스 라는 환경에서 SQL 이라는 인터페이스로 머신러닝까지 마무리하게 되면 효율적이라는 생각인 것 같습니다. 

AWS는 Sagemaker라는 AI/ML 플랫폼이 있습니다. 이번 기능을 통해 이를 Redshift와 통합하여, 명령은 SQL문으로 내리고 Sagemaker에서 기계학습 모델을 생성, 훈련하고 추론할수 있게 되었습니다. 굳이 ML을 위해 따로 인프라를 구성하는 고민을 하지 않아도 되는게 큰 장점으로 보입니다. 아직까지 많은 수요가 있는것 같지는 않지만 기능이 자리잡고 나면 유용하게 쓰일것 같습니다. 

이렇게 살펴보면 사실 Redshift의 이번 업데이트들은 이전에 발표되었던 큰 틀들이 구체화된 것으로 보입니다. 작년 리인벤트에 RA3 노드가 나오면서 컴퓨팅과 스토리지 영역의 분리가 되었고 이번 업데이트에는 RA3 노드의 옵션을 늘려주면서 활용성이 증가했습니다. Federated query 기능도 작년 리인벤트에 지원한다는 방향을 발표하였고 이번에 커넥터를 늘려 점점 기능을 완성시켜가는 모습입니다. 여기에 ML 지원이라는 또 다른 큰 축을 추가한 듯 합니다. 지금은 프리뷰 수준이지만 아마 2021년엔 Redshift ML 기능에 여러가지 디테일이 추가될 것 같네요.