데이터 분석 스택을 다루다 보면 데이터 웨어하우스(Data Warehouse), 데이터 레이크(Data Lake), 레이크하우스(Data Lakehouse) 라는 용어가 자주 등장합니다. 셋 다 “데이터를 모아 분석한다”는 점은 같지만, 어디에 어떻게 저장하고 언제 스키마를 적용하느냐가 다릅니다. 이 차이를 모르면, 어떤 저장 방식을 택해야 하는지, ...

이 글은 AWS 데이터 분석 스택 시리즈의 마지막 편입니다. 앞선 AWS Lake Formation 글에서 Lake Formation이 IAM 위에 얹히는 별도의 데이터 권한 게이트라는 점과 grant 모델, credential vending을 정리했습니다. 이번 글에서는 그 개념을 실제 트러블슈팅에 적용합니다. 상황은 이렇습니다. S3 Tables...

앞선 S3 Tables & Catalog Federation 글에서 관리형 Iceberg 레이크하우스가 s3tablescatalog 아래에 어떻게 중첩되는지, 그래서 ARN이 왜 깊어지는지를 정리했습니다. 이번 글에서는 이 federated 데이터에 한 겹 더 얹히는 권한 계층, AWS Lake Formation을 알아봅니다. Lake For...

앞선 Amazon Athena & Glue Data Catalog 글에서 일반 Glue 테이블(S3 + Glue Catalog)을 기준으로 쿼리 흐름과 권한을 정리했습니다. 이번 글에서는 한 단계 더 들어가, 데이터 레이크하우스의 핵심인 Amazon S3 Tables와, 그것이 Glue Data Catalog에 연결되는 방식인 Catalog F...

앞선 AWS 데이터 분석 스택 Overview에서 분석 스택의 큰 그림과, 쿼리 한 번이 엔진과 메타스토어, 저장소를 지나는 흐름을 살펴봤습니다. 이번 글에서는 그 중심에 있는 두 구성요소, Amazon Athena와 AWS Glue Data Catalog를 자세히 알아봅니다. 이 둘은 한 쌍으로 움직입니다. Athena는 SQL을 실행하는 엔진이고...

S3 버킷에는 로그, 이벤트, 각종 추출 데이터가 끊임없이 쌓입니다. 그런데 막상 “이 데이터를 SQL로 한 번 들여다보자”고 하면, 어디서부터 손대야 할지 막막할 때가 많습니다. 별도 DB로 적재(ETL)해야 하나? 권한은 어디서 거나? 카탈로그는 또 뭔가? AWS는 이 “S3에 쌓인 데이터를 분석하는 일”을 여러 서비스의 조합으로 풉니다. Ath...

앞선 리소스 계층 글에서 Organization -> Folder -> Project로 이어지는 리소스 계층과, 권한/정책이 위에서 아래로 상속된다는 점을 알아보았습니다. 이번에는 그 권한 체계의 핵심인 GCP IAM(Identity and Access Management)에 대해 알아보겠습니다. GCP IAM은 결국 “누가(Principa...

GCP를 처음 공부하기 시작하면서 가장 먼저 마주친 개념이 리소스 계층(Resource Hierarchy)이었습니다. 클라우드 콘솔에 들어가 프로젝트를 만들려는 순간부터 Organization, Folder, Project라는 단어가 등장하는데, 이 구조를 이해하지 못하면 IAM 권한이나 결제(Billing), 조직 정책이 어디에 어떻게 적용되는지 감...

GCP를 처음부터 공부해 보기로 마음먹고 가장 먼저 정리한 것은 “GCP가 도대체 무엇인가”였습니다. 개별 서비스나 명령어를 외우기 전에, 이 플랫폼이 어떤 성격을 가졌고 무엇을 잘하는지 큰 그림을 그려두면 이후 학습이 훨씬 수월하기 때문입니다. 이번 포스트는 GCP 학습 시리즈의 출발점으로, GCP가 무엇이고 어떤 특징이 있으며 어떤 서비스들로 구성...

CloudFront를 ALB나 EC2 앞단에 두려고 하면, 정작 오리진(origin)은 퍼블릭 서브넷에 두고 퍼블릭 IP를 부여해야 했습니다. 그러면서도 “CloudFront만 들어오게” 하려고 Security Group에 CloudFront managed prefix list를 걸거나, 커스텀 헤더를 검증하는 등 추가 작업이 필요했고, 결국 오리진이...