멀티 에이전트 배포가 Redshift DDL 배포 속도를 늦출 수 있는 이유

Azure DevOps를 통해 500개 이상의 테이블과 관련 업데이트를 AWS Redshift에 배포하는 것은 상당한 과제였습니다. 팀은 처음에는 단일 순차 실행이 60분 에이전트 시간 초과 제한을 초과할 것이므로 배포 속도를 높이기 위해 Azure DevOps의 다중 에이전트 기능을 고려했습니다. 그러나 Classic 및 YAML 파이프라인 모두에서 Azure DevOps의 다중 에이전트 기능은 작업을 자동으로 분산하는 대신 전체 작업을 복제한다는 것을 발견했습니다. 이는 작업을 분할하는 명시적인 로직이 없으면 각 에이전트가 500개의 모든 테이블 배포를 시도하여 대량의 중복과 오류를 발생시킨다는 것을 의미합니다. 수동으로 작업을 분산하더라도 Redshift의 아키텍처는 DDL 작업에 병목 현상을 만듭니다. CREATE TABLE 및 CREATE VIEW와 같은 모든 DDL(Data Definition Language) 문은 리더 노드에서 처리되며 시스템 카탈로그 테이블에 대한 독점 잠금이 필요합니다. 이러한 잠금은 진정한 병렬 DDL 실행을 방지하여 모든 에이전트가 서로 대기하도록 강제합니다. 마찬가지로 공유 제어 테이블에 대한 업데이트도 독점 잠금을 포함하여 해당 작업을 직렬화합니다. 따라서 Redshift에서 DDL이 많은 워크로드에 여러 에이전트를 사용하는 것은 작업 분배가 올바르게 이루어지더라도 성능을 향상시키지 못하고 오히려 오버헤드를 추가할 수 있습니다. 최적의 전략은 단일 에이전트 순차 배포이며, 시간 초과 위험을 관리하기 위해 여러 개의 작은 배포로 분할할 수 있습니다. 단일 트랜잭션 내에서 DDL 문을 일괄 처리하는 것도 도움이 될 수 있습니다. Redshift의 리더 노드 직렬화와 같은 기본 데이터베이스 아키텍처의 제약 조건을 이해하는 것이 성능 향상을 위해 CI/CD 도구를 활용하는 것보다 더 중요합니다.