📖 학습 주제
- Redshift 권한과 보안
- Redshift 백업 & 테이블 복구
- Redshift 관련 기타 서비스
- Redshift Spectrum
- 실습 - Redshift Spectrum 사용해보기
✏️ 주요 메모 사항 소개
Redshift 권한과 보안
Redshift에서 권한을 설정할 때는 AWS IAM을 이용하여 역할(Role)별로 접근 권한을 지정하고 역할을 부여해주는 방식으로 하는 것이 일반적이다. 모든 사용자가 모든 테이블에 접근 가능하는 것은 바람직하지 않기 때문에 적절한 권한 분배를 통해 보안을 지키는 것이 중요하다.
사용자 별 테이블 권한 설정
일반적으로 사용자별 테이블별 권한 설정은 하지 않는다. 너무 복잡하고 실수의 가능성이 높기 때문이다. 보통은 역할(Role) 혹은 그룹(Group) 별로 스키마별 접근 권한을 주는 것이 일반적이다.
- RBAC(Role Based Access Control)가 새로운 트렌드로 그룹보다 더 편리하다.
- 여러 역할에 속한 사용자의 경우는 각 역할의 권한을 모두 갖게 된다 (Inclusive)
개인정보와 관련한 테이블이라면 별도의 스키마를 설정하고 극히 일부 사람만 속한 역할에 접근 권한을 주게 된다.
예를들어 저번 시간에 우리가 만들었던 그룹과 테이블들에 대한 접근권한 설정을 다음과 같이 하고싶다고 가정해보자. (그룹을 역할로 바꿔도 그대로 적용 됨)
이럴 경우 SQL로 접근 권한을 설정해주면 다음과 같다.
- analytics_authors 그룹
GRANT ALL ON SCHEMA analytics TO GROUP analytics_authors;
GRANT ALL ON ALL TABLES IN SCHEMA analytics TO GROUP analytics_authors;
GRANT ALL ON SCHEMA adhoc to GROUP analytics_authors;
GRANT ALL ON ALL TABLES IN SCHEMA adhoc TO GROUP analytics_authors;
GRANT USAGE ON SCHEMA raw_data TO GROUP analytics_authors;
GRANT SELECT ON ALL TABLES IN SCHEMA raw_data TO GROUP analytics_authors;- analytics_users 그룹
GRANT USAGE ON SCHEMA analytics TO GROUP analytics_users;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO GROUP analytics_users;
GRANT ALL ON SCHEMA adhoc to GROUP analytics_users;
GRANT ALL ON ALL TABLES IN SCHEMA adhoc TO GROUP analytics_users;
GRANT USAGE ON SCHEMA raw_data TO GROUP analytics_users;
GRANT SELECT ON ALL TABLES IN SCHEMA raw_data TO GROUP analytics_users;- pii_users 그룹
GRANT USAGE ON SCHEMA pii TO GROUP pii_users;
GRANT SELECT ON ALL TABLES IN SCHEMA pii TO GROUP pii_users;이렇게 권한을 설정한 것을 체크하기 위해 admin이 아닌 전에 만들었던 sangwon이라는 유저로 재접속을 한 뒤 테이블을 변경해 보자.
postgresql://'생성한 유저ID':'유저 비밀번호'@'Redshift 엔드포인트'
DELETE FROM raw_data.user_session_channel;
앞서 설정한 그룹의 권한에 해당 테이블을 삭제할 수 있는 권한이 없기 때문에 permission denied가 뜨게 된다.
Redshift 백업 & 테이블 복구
Redshift는 자체적으로 제공하는 Snapshot이라는 백업 기능이 있다. Snapshot이란 마지막 백업으로부터 바뀐 것들만 저장하는 방식을 말한다. 백업을 통해 과거로 돌아가 그 시점의 내용으로 특정 테이블을 복구하는 것이 가능하다. (Table Restore) 또한 과거 시점의 내용으로 Redshift 클러스터를 새로 생성하는 것도 가능하다.
Redshift에서의 데이터 백업은 고정비용 클러스터를 생성하여 이용하는 경우와 Redshift Serverless를 이용하는 경우가 다르다.
- 고정 비용 Redshift
-
[자동 백업]
기본적으로 하루 동안 백업을 저장하지만 최대 과거 35일까지의 변경을 백업하게 할 수 있다. 이 경우, 백업은 같은 지역에 있는 S3에 이뤄진다. 다른 지역의 S3에 백업을 하려면 Cross-regional snapshot copy를 설정해야 한다. 이는 보통 재난 시 데이터 복구에 유용하다. 관련 Redshift 클러스터의 Maintenance 탭에서 Backup details -> Edit으로 설정을 변경할 수 있다. -
[매뉴얼 백업]
Maintenance 탭에서 Create snapshot을 통해 스냅샷을 생성하면 수동적으로 백업을 저장할 수 있다. -
이렇게 생성된 snapshot들을 이용해서 Redshift 클러스터에서 Restore table 메뉴를 통해 복구 대상이 있는 백업(Snapshot)을 선택하고 원본 테이블 (Source table)을 선택한 뒤 어디로 복구될지 타겟 테이블을 선택하면 복구 작업이 완료된다.
- 가변 비용 Redshift (Redshift Serverless)
- 고정비용 Redshift에 비하면 제한적이고 조금더 복잡한 부분이 있다. Snapshot 이전에 Recovery Points라는 것이 존재한다.
- Recovery Point를 Snapshot으로 바꾼 다음에 여기서 테이블 복구를 하거나 이것으로 새로운 Redshift 클러스터 등을 생성하는 것이 가능하다.
- 하지만 Recovery Points는 과거 24시간에 대해서만 유지된다.
Redshift 관련 기타 서비스
Redshift Spectrum
Redshift의 확장 기능으로 S3에 있는 파일들을 마치 테이블처럼 SQL로 처리 가능하게 해주는 기능이다. 이를 사용하기 위해선 Redshift 클러스터가 필요하고 S3와 Redshift 클러스터는 같은 region에 있어야한다.
- S3 파일들을 외부 테이블들(external table)로 처리하면서 Redshift 테이블과 조인 가능
- S3 외부 테이블들은 보통 Fact 테이블들이 되고 Redshift 테이블들은 Dimension 테이블
- 1TB를 스캔할 때마다 5$ 비용이 생긴다.
AWS Athena
AWS의 Presto 서비스로 사실 상 Redshift Spectrum과 비슷한 기능을 제공. S3에 있는 데이터들을 기반으로 SQL 쿼리 기능 제공, 이 경우 S3를 데이터 레이크라고 볼 수 있다.
Redshift ML
SQL만 사용하여 머신러닝 모델을 훈련하고 사용할 수 있게 해주는 Redshift 기능. 이 기능은 AWS SageMaker에 의해 지원된다. SageMaker의 Auto Pilot이라는 기능으로 최적화된 모델을 자동 생성해준다. 만약 이미 모델이 만들어져 있다면 이를 사용하는 것도 가능하다. (BYOM : Bring Your Own Model)
Redshift Spectrum 상세
Fact 테이블 : 분석의 초점이 도는 양적 정보를 포함하는 중앙 테이블
- 일반적으로 매출 수익, 판매량 또는 이익과 같은 사실 또는 측정 항목을 포함하여 비즈니스 결정에 사용
- 일반적으로 외래 키를 통해 여러 Dimension 테이블과 연결
- 보통 Fact 테이블의 크기가 훨씬 더 큼
Dimension 테이블 : Fact 테이블에 대한 상세 정보를 제공하는 테이블
- 고객, 제품과 같은 테이블로 Fact 테이블에 대한 상세 정보 제공
- Fact 테이블의 데이터에 맥락을 제공하여 사용자가 다양한 방식으로 데이터를 조각내고 분석 가능하게 해줌
- Dimension 테이블은 일반적으로 primary key를 가지며, fact 테이블의 foreign key에서 참조
보통 Dimension 테이블의 크기는 훨씬 더 작음
예를들어 앞서 우리가 만든 user_session_channel이 Fact 테이블이라면, 만들진 않았지만 위의 테이블에 사용된 사용자나 채널에 대한 정보를 담은 User, Channel 과같은 테이블이 Dimension 테이블이라할 수 있다.
또 다른 예로 Order라는 사용자들의 상품 주문에 대한 정보가 들어간 테이블을 Fact 테이블이라 한다면 상품에 대한 정보나 상품 주문을 한 사용자에 대한 정보를 담은 Product나 User 테이블을 Dimension 테이블이라할 수 있다.
이를 실제로 사용한 유스 케이스로 살펴보면
- S3에 대용량 Fact 테이블이 파일로 존재
- Redshift에 소규모 Dimension 테이블이 존재
- Fact 테이블을 Redshift로 적재하지 않고 위의 두 테이블을 조인하고 싶다면?
이 때 사용할 수 있는 것이 Redshift Spectrum이다.
외부 테이블(External Table)
데이터베이스 엔진이 외부에 저장된 데이터를 마치 내부 테이블처럼 사용하는 방법으로, 데이터베이스 내부로 복사하고 사용하는 것이 아니라 임시 목적으로 사용하는 방식을 말한다.
SQL 명령어로 데이터베이스에 외부 테이블을 생성 가능하다. 이 경우 데이터를 새로 만들거나 하는 것이 아니라 참조만 하게 된다. 이를 사용하여 데이터 처리 후 결과를 데이터베이스에 적재하는데 사용 가능하다.
하지만 외부 테이블은 보안 및 성능 문제에 대한 신중한 고려가 필요하다.
AWS Glue
AWS의 Serverless ETL 서비스로 아래와 같은 기능을 제공한다. Airflow를 사용하는 경우가 많지만 AWS와 밀접한 서비스를 구축한다면 AWS Glue를 고려해볼 만 하다.
실습 - Redshift Spectrum
1. IAM 권한 편집
저번 시간에 만든 redshift.read.s3 역할에 'AWSGlueConsoleFullAccess' 정책을 추가해주자
2. S3 버킷에 업로드
데이터 용량이 매우 크다고 가정하고 S3 버킷에 새로운 폴더를 만들고 저번에 이용한 user_session_channel CSV 파일을 업로드하자.
3. 외부 스키마 생성
s3에서 불러올 외부 테이블을 사용할 때 필요한 External Schema를 생성하자.
-- AWSGlueConsoleFullAccess
CREATE EXTERNAL SCHEMA external_schema
from data catalog
database 'myspectrum_db'
iam_role 'IAM 역할의 ARN'
create external database if not exists;4. 임시 테이블 생성
외부 테이블과 함께 조인할 테이블을 하나 만들어보자. userid를 기반으로 랜덤하게 성별과 나이를 추가한 user_property 테이블을 만들었다.
CREATE TABLE raw_data.user_property AS
SELECT
userid,
CASE WHEN cast (random() * 2 as int) = 0 THEN 'male' ELSE 'female' END gender,
(CAST(random() * 50 as int)+18) age
FROM (
SELECT DISTINCT userid
FROM raw_data.user_session_channel
);5. 외부 테이블 생성
SQL을 이용하여 s3 버킷에 들어있는 파일을 외부 테이블로 만들어주자.
CREATE EXTERNAL TABLE external_schema.user_session_channel(
userid integer ,
sessionid varchar(32),
channel varchar(32)
)
row format delimited
fields terminated by ','
stored as textfile
location 's3 URI, 파일명은 제외하고 폴더까지만 입력';6. JOIN 하기
우리가 만든 redshift 내부의 user_property 테이블과 외부 테이블인 external_schema.user_session_channel을 join하여 출력해보자.
SELECT gender, COUNT(1)
FROM external_schema.user_session_channel usc
JOIN raw_data.user_property up ON usc.userid = up.userid
GROUP BY 1;
Redshift 중지 / 제거하기
Redshift Serverless와 같은 가변 비용 클러스터는 중지가 없지만 고정 비용 클러스터로 생성하게 되면 필요하지 않을 때 중지를 해줘야 추가적인 과금이나 리소스 낭비를 예방할 수 있다.
1. 고정비용 Redshift인 경우
- Redshift가 당분간 필요없다면 Redshift 콘솔에서 해당 Redshift 클러스터를 선택하고 상단 메뉴에서 Stop을 선택하면 된다.
- 이 경우 Redshift 클러스터의 스토리지 비용만 부담하게 되고 SQL 실행이 불가능해진다. 만약 다시 필요해지게 되면 Resume을 선택하면 된다.
2. 가변비용 Redshift인 경우 (Redshift Serverless)
- 먼저 모든 Workgroup들을 삭제한다.
- 다음으로 모든 Namespace들을 삭제하면 된다.
VACUUM 명령어
추가적으로 SQL 커맨드인 VACUUM 명령어로 테이블 청소와 최적화 작업이 가능하다.
