DEVOCEAN

AWS의 Redshift 데이터 웨어하우스를 사용해 보셨나요?

기본적인 Redshift의 기능과 장단점은 다른 글에서 확인이 가능하실 것 같아서,

오늘은 Redshift의 type 및 추천 환경을 공유드릴려고 합니다.

현재 seoul 리전에서 확인할 수 있는 redshift type은 크게 3가지입니다.

1. DC type (dc2)

2. RA type (ra3)

3. 그리고, Serverless

dc2 type은 dc1 type에서 개선되어 나온 것으로 약 2017년 근방에 적용이 된 것 같습니다. (정확한 일자는 중요하지 않아요 ㅋㅋ)

dc2 type은 대략 아래와 같은 구조입니다.

Leader node가 있고, 각 compute node에 storage가 연결되어 있는 구조입니다.

그래서 dc2 type을 사용하실 때, 만약 storage가 부족하시다면, dc2 type의 compute node를 같이 늘리거나, 고성능 type으로 변경을 하셔야 합니다.

저희도 올해 초까지 dc2 type을 사용했는데, 계속 파일을 옮기고 삭제하고... 엄청 불편했습니다.

그렇다고 사용하지도 않는 compute 자원을 늘리자니... 돈이 부족하고...

암튼 오래된 type이다. 그래서, 지금 EOS 시키려고, AWS 프로님들도 열심이시고, 그렇답니다.

그럼 이 문제를 어떻게 해결할까요?

원래 storage가 S3를 활용하는 서비스로 알고 있어서, 그럼 compute와 S3를 분리하면 되려나??

그래서 나온 것이 RA3 type입니다.

ra3 type은 compute와 storage를 분리해서 관리가 가능합니다.

그래서인지 동급의 compute를 사용해도 dc2가 64GB 사용한다면, ra3는 64TB를 사용할 수 있습니다!! 허걱..

물론 storage는 사용한 만큼 비용을 내야하고,

그 storage를 cluster로 관리를 하게 됩니다.

마지막으로 serverless는 뭔가요?

ra3는 프로비저닝되어서 compute를 계속 사용하는 거고, serverless는 사용할 때만 서버가 프로비저닝되어서 서비스가 되고, 사용된 것만 분단위로 비용을 내는 구조입니다.

뭐 간혹 사용하는 서비스에 serverless를 사용하면 되겠죠?

그리고, serverless는 ra3처럼 compute와 storagre가 분리되어서 cpu크기를 필요에 따라 조절이 가능해요.

그럼, 여기서 조금 더 디테일한 것으로 이야기를 해 보겠습니다.

1. ra3가 compute와 storage로 구분되어 있으니, 필요할 때마다 compute를 조절하면 서비스가 가능할까?

   예를 들어 낮에는 2개 compute 사용하고, 밤에는 1개 compute사용하고... 물론 AWS의 이론으로는 가능합니다.

   하지만 서비스에 제약은 반드시 존재합니다.

   AWS이니까요. type에 따라 다를 수 있지만, dc2에서 ra3로 size변경을 했더니, 현재 2개 compute는 반드시 사용해야 하고, 1개로 줄일 수는 없습니다.

   ra3가 compute단위가 커서 dc2보다 많이 비싸거든요... 이 부분은 된다고 했었는데.. 안되서 참... 안타까웠습니다.

   그렇지만 필요 시 4개로 늘렸다가 2개로는 돌아올 수 있지 않을까요? ㅎㅎㅎㅎ 안되면, sanpshot 만들고 다시 생성하는 방법을 사용하면 됩니다. 뭐든 하면 되죠.

   참고로, 해외에는 더 작은 단위 compute가 지원되지만, 서울에서는 안된다는 거...

2. Serverless는 필요할 때만 사용하면 되니, 고객용 webservice 조회용 query로 사용하면 될까요? serverless의 한가지 (??) 한계를 프로비저닝 시간이 존재한다는 것입니다.

   물론 돈은 내가 요청한 query가 수행된 분(min)에 대해서만 돈을 냅니다. (12시 1분 59초에 query날려서 12시 2분 1초에 끝나면 2분치 돈을 냅니다 , 2초가 돌았지만... )

   다시 프로비저닝 시간으로 돌아가서, query가 요청이 왔을 때, 나의 서버가 졸고 있다면 일어나야 하는 시간이 존재합니다. 물론 일어날때까지 나의 query가 날아갈 것 같지는 않습니다...

   물론 테스트 해봐야겠죠. AWS이니까요. 즉 그 시간이 수초에서 수분이 걸릴 수 있기 때문에 고객의 실시간 요청에는 적합하지 않을 수 있습니다.

   소문을 들으면, 이걸 해결 하기 위해 일정 시간당 계속 짧은 query를 날려서 서버를 깨우는 방식으로 만든 곳있다고는 하는데.... 뭐.. 조만간 고치겠죠?아니.. 고치는 게 아니라 update하겠죠? ㅎㅎ

3. serverless는 그럼 저렴하냐... 서울에서는 비쌉니다. 그것도 엄청. serverless의 기본 vCPU단위가 있는데, 해외에서는 4인가 8짜리도 있는데 서울에서는 32로 알고 있습니다.

   잠시 "hello query"를 요청해도 32 vCPU값을 내야 합니다!! 응답 시간은 엄청 빠를 것 같습니다. 용도에 맞게 사용해야 겠어요.

4. 그럼 오늘의 마지막으로, compute와 storage분리한 게, 뭐가 도움이 되는가? dc2에서 용량만 커진 거지... 뭐 사용자 입장에서는 별반 다를 것이 없는디...

   dc2에서 ra3가고 나서 redshift 비용만 2배 더 내는데. 뭐가 좋은 거지? (저희팀 이야기를 하는 것이 아닙니다...)

   바로 data sharing입니다. 라고 저는 생각합니다. data sharing이란, cluster의 db를 다른 cluster에 read권한으로 접근을 허용해 주는 것입니다.

   (현재는 read만 된다고 합니다. write는 아직 기술적으로 불안정해서 인지 적용 시기가 미정으로 알고 있습니다. 이글을 쓰던 중에 적용된 것만 아니면 됩니더)

   예를 들어 RA3 type으로 cluster를 만들고, 지속적으로 사용자의 event를 수집하고, 그 수집된 데이터를 data sharing으로 serverless의 cluster에 연결해 줍니다.

   그럼 servrerless cluster에서 그 데이터를 1주에 한번 정리해서 다른 RDS로 이동 시킵니다.

   이런 producer, comsumer 형태로 데이터 cluster관리가 가능하게 됩니다.

   관련 내용은 아래 AWS re:invent 2023 세션 링크를 걸어놓았습니다. 관심이 있으신 분들은 참고해 주세요

   https://www.youtube.com/watch?v=z9XPLOc-wg0

주저리 주저리 redshift이야기를 하였습니다.

읽어 주셔서 감사합니다.

Timjoo 드림.