웨어하우스 아키텍처
웨어하우스 아키텍처
Amazon Redshift 웨어하우스가 내부에서 어떤 조각들로 이루어져 있는지 살펴볼게요. 분석 쿼리가 빨리 끝나는 이유는 단일 거대 서버가 아니라 여러 노드가 일을 나눠서 처리하는 구조 덕분이에요. 쿼리가 실제로 어디서 실행되는지 알면 성능이 느려졌을 때 어디를 봐야 할지도 감이 잡혀요. 평소에 SQL만 쓰는 분이라도 이 구조를 한 번 알아두면 나중에 튜닝할 때 큰 도움이 돼요.
출처: https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html
핵심 구성 요소
웨어하우스의 기준 단위는 클러스터예요. 클러스터는 하나 이상의 컴퓨트 노드로 이루어져 있고, 컴퓨트 노드가 둘 이상이면 여기에 리더 노드가 하나 늘어나서 전체를 조율해요. 클라이언트 애플리케이션은 리더 노드하고만 직접 대화하고, 컴퓨트 노드는 바깥에서 보이지 않아요.
리더 노드는 클라이언트와의 통신, 그리고 컴퓨트 노드와의 모든 통신을 관리해요. 복잡한 쿼리에서 원하는 결과를 얻기까지 어떤 단계를 거칠지를 정하는 실행 계획을 짜고, 그 계획을 코드로 컴파일해서 각 컴퓨트 노드에 나눠주고 데이터 일부를 할당하는 역할이에요. 다만 모든 쿼리가 컴퓨트 노드로 내려가는 건 아니에요. 쿼리가 컴퓨트 노드에 저장된 테이블을 참조할 때만 배분되고, 나머지는 리더 노드에서만 실행돼요. 리더 노드 전용으로 설계된 일부 SQL 함수를 컴퓨트 노드 테이블과 함께 쓰면 오류가 나기 때문에, 그런 함수를 쓸 때는 주의해야 해요.
컴퓨트 노드는 리더 노드가 할당한 코드를 실제로 돌리고 중간 결과를 다시 리더 노드로 보내는 일을 해요. 각 노드에는 노드 유형에 따라 정해진 CPU와 메모리가 따로 있어서, 워크로드가 늘면 노드 개수를 늘리거나 더 큰 노드 유형으로 올리는 방식으로 컴퓨팅을 키울 수 있어요.
**Redshift Managed Storage(RMS)**는 웨어하우스 데이터를 따로 저장해 두는 스토리지 계층이에요. S3 기반이라 저장소를 페타바이트까지 늘릴 수 있고, 컴퓨팅과 스토리지를 각각 독립적으로 스케일·과금할 수 있어요. 그래서 클러스터는 컴퓨팅 필요량만 보고 크기를 정하면 돼요. 고성능 SSD 기반 로컬 스토리지는 1계층 캐시로 자동 활용되고, 데이터 블록의 온도나 나이, 워크로드 패턴을 반영해 성능을 유지하면서 필요할 때 S3로 자동 확장돼요.
노드 슬라이스는 컴퓨트 노드를 다시 여러 조각으로 나눈 단위예요. 각 슬라이스는 노드 메모리와 디스크의 일부를 배정받아 맡은 일부 워크로드를 처리하고, 여러 슬라이스가 병렬로 일을 끝내요. 노드당 슬라이스 개수는 노드 크기에 따라 정해져요.
테이블을 만들 때 한 컬럼을 분산 키(distribution key)로 지정할 수 있는데, 데이터를 로드하면 그 키 기준으로 행들이 각 슬라이스로 나뉘어 들어가요. 분산 키를 잘 고르면 병렬 처리로 로드와 쿼리를 효율적으로 돌릴 수 있어서, 키 선택이 성능에 꽤 큰 영향을 줘요.
내부 네트워크는 리더 노드와 컴퓨트 노드 사이를 고대역폭·저지연으로 잇는 전용 통신망이고, 컴퓨트 노드는 별도로 격리된 네트워크에서 돌아가서 클라이언트 애플리케이션이 직접 접근할 수 없어요.
데이터베이스는 클러스터 안에 하나 이상 존재해요. 실제 사용자 데이터는 컴퓨트 노드에 저장되고, SQL 클라이언트는 리더 노드를 거쳐 쿼리를 조율해요. Amazon Redshift는 PostgreSQL 기반의 관계형 DBMS(RDBMS)라서 일반 INSERT·DELETE 같은 OLTP 기능도 제공하지만, 아주 큰 데이터셋을 고성능으로 분석하고 리포트하는 쪽에 최적화되어 있어요. PostgreSQL과 SQL 문법이 대부분 겹치지만 설계할 때 꼭 알아둬야 할 차이점도 제법 있으니, 그 부분은 별도로 확인해 두는 게 좋아요.