이 문서는 중요 비즈니스용 시나리오에서 온-프레미스 데이터 게이트웨이를 배포하려는 모든 사용자를 위한 것입니다. 온-프레미스 데이터 게이트웨이는 비즈니스의 정상적인 운영에 매우 중요하고 중요 비즈니스용 데이터를 처리하는 경우 비즈니스에 중요합니다.
중요 비즈니스용 게이트웨이가 제대로 관리되지 않으면 쿼리가 실패하거나 성능이 저하될 수 있습니다. 비즈니스에 중요한 게이트웨이 솔루션을 적절히 계획, 크기 조정 및 유지 관리하는 경우 비즈니스에 영향을 미치는 문제의 가능성을 최소화할 수 있습니다.
용어
이 문서 전체에서 사용되는 중요한 용어는 다음과 같습니다.
- 게이트웨이: 컴퓨터에 설치된 온-프레미스 데이터 게이트웨이 애플리케이션입니다.
- 게이트웨이 서버: 온-프레미스 데이터 게이트웨이 애플리케이션이 설치된 Windows 컴퓨터(가상 머신 또는 물리적 컴퓨터/서버)입니다.
- 게이트웨이 클러스터: 함께 작동하고 부하가 분산될 수 있는 게이트웨이 집합입니다.
- 게이트웨이 멤버: 게이트웨이 클러스터의 일부인 게이트웨이입니다.
다음 이미지는 위에서 정의한 개념 간의 관계를 보여 줍니다.
중요 비즈니스용 게이트웨이에 대한 권장 사항
중요 비즈니스용 게이트웨이의 경우 고가용성, 우수한 성능 및 유지 관리 가능한 확장성을 보장하기 위해 게이트웨이를 적절하게 배포하고 관리해야 합니다. 게이트웨이를 잘못 배포하면 성능 저하, 쿼리 실패 및 잠재적인 문제 진단에 어려움이 발생할 수 있습니다. 사용량이 증가함에 따라 게이트웨이를 확장하고 늘리는 기능을 방해할 수도 있습니다.
최적의 확장성, 성능 및 처리량을 보장하려면 다음 섹션의 권장 사항을 따르세요.
모든 게이트웨이 복구 키 파악
모든 게이트웨이 복구 키를 알고 안전한 장소에 보관해야 합니다. 복구 키가 없으면 게이트웨이를 복구하거나 다운그레이드할 수 없습니다. 이 제한은 의도적으로 적용됩니다. 복구 키를 분실한 경우 유일한 옵션은 새 게이트웨이를 만들고 데이터 원본을 다시 만드는 것입니다. 또한 복구 키가 없으면 클러스터에 새 게이트웨이를 추가할 수 없으므로 향후 확장성이 제한됩니다.
권한 있는 관리자만 액세스할 수 있는 암호 안전과 같은 관리 자격 증명을 저장하는 것처럼 복구 키를 안전한 위치에 저장합니다.
현재 모든 게이트웨이 복구 키를 모르는 경우 이는 중요한 비즈니스 위험입니다. 즉시 새 게이트웨이 클러스터를 만들고 워크로드를 새 게이트웨이 클러스터로 마이그레이션하기 시작합니다.
개발 워크로드 및 중요 비즈니스용 워크로드
하나 이상의 개발 게이트웨이 클러스터와 하나 이상의 프로덕션 게이트웨이 클러스터를 설정하여 중요 비즈니스용 워크로드와 개발 워크로드를 분리합니다.
개발 게이트웨이 클러스터를 사용하여 새로운 의미 체계 모델, 보고서, 쿼리 등을 테스트합니다. 새 워크로드가 확인되면 중요 비즈니스용 게이트웨이 클러스터로 마이그레이션합니다. 이 프로세스는 새 워크로드, 테스트되지 않은 또는 실험적 워크로드가 프로덕션 워크로드에 성능에 영향을 주지 않도록 방지합니다.
또한 중요 비즈니스용 게이트웨이 클러스터에 업데이트를 적용하기 전에 개발 게이트웨이 클러스터를 사용하여 새 게이트웨이 업데이트를 테스트합니다. 새 게이트웨이 업데이트는 중요 비즈니스용 게이트웨이 클러스터에서 사용되기 전에 개발 게이트웨이 클러스터에서 최소 24시간 동안 배포해야 합니다.
여러 게이트웨이 클러스터 사용
조직에서 많은 수의 사용자에 대한 게이트웨이 클러스터를 만드는 경우 비즈니스 단위를 기반으로 여러 게이트웨이 클러스터를 만들거나 더 작게 만들어 잠재적인 성능 영향을 소수의 사용자로 제한해야 합니다.
회사가 작지 않은 경우 전체 회사에 단일 비즈니스용 게이트웨이 클러스터를 사용하지 않는 것이 좋습니다. 단일 게이트웨이 클러스터 시나리오에서 한 사용자는 게이트웨이 전체의 모든 트래픽에 상당한 성능 영향을 주는 쿼리를 보낼 수 있습니다. 게이트웨이가 회사 전체에서 사용되는 경우 성능 영향이 회사 전체에 영향을 줄 수 있습니다. 또한 게이트웨이 클러스터가 회사 전체에서 사용되는 경우 게이트웨이 성능 모니터링 기능을 사용할 때 성능 문제를 일으킬 수 있는 쿼리를 식별하기가 더 어려울 수 있습니다.
게이트웨이 고가용성 및 부하 분산 기능 사용
항상 중요 비즈니스용 게이트웨이 클러스터에 게이트웨이 고가용성 및 부하 분산 기능을 사용합니다.
- 고가용성: 단일 실패 지점을 제거합니다.
- 부하 분산: 클러스터의 모든 게이트웨이 서버에 워크로드를 자동으로 분산합니다.
어떤 이유로든 게이트웨이가 오프라인 상태가 될 경우 게이트웨이 클러스터당 최소 2개의 게이트웨이를 설정합니다. 이 설정을 사용하면 단일 게이트웨이 오류로 인해 전체 게이트웨이 클러스터가 실패하지 않습니다. 또한 게이트웨이 클러스터에 부하를 더 효율적으로 분산하기 위해 게이트웨이에서 CPU, 메모리, 동시성 제한을 사용하도록 설정할 수 있습니다.
게이트웨이 클러스터 확장성 계획 및 유지 관리
권장되는 하드웨어 및 소프트웨어 지침을 사용하여 게이트웨이 클러스터를 설정하면 클러스터가 좋은 성능으로 실행되도록 보장합니다. 제대로 확장되지 않은 게이트웨이는 성능 저하를 초래할 수 있습니다. 게이트웨이 클러스터에서 좋은 성능을 갖도록 고려해야 하는 여러 가지 요인이 있습니다.
게이트웨이 서버 하드웨어 사양 확인
게이트웨이 서버 사양(CPU, 메모리, 디스크 등)은 대부분의 경우 파워 쿼리 변환이 게이트웨이 서버의 데이터에 적용되므로 중요한 요소입니다. 따라서 게이트웨이 서버에는 모든 데이터 변환을 처리할 수 있는 충분한 리소스, 메모리 및 처리 능력이 있어야 합니다.
서버 크기를 선택해야 하는 경우 가장 중요한 두 가지 메트릭인 메모리와 CPU가 있습니다. 게이트웨이에서 파워 쿼리 데이터 변환 단계를 처리하려면 충분한 메모리와 CPU 전원이 모두 필요합니다. 게이트웨이 서버가 가장 높은 워크로드를 처리할 수 있을 만큼 강력해야 합니다. 게이트웨이 서버가 워크로드를 처리할 수 없는 경우 직접 쿼리 또는 데이터 새로 고침이 실패합니다. 동시에 실행되는 쿼리 수를 이해하는 것도 중요합니다.
이러한 다양한 쿼리 옵션은 게이트웨이 서버에 다른 영향을 줍니다.
| 쿼리 유형 | 제한 요소 |
|---|---|
| 수입 | 메모리 |
| 다이렉트쿼리 | CPU (중앙 처리 장치) |
| LiveConnect | CPU (중앙 처리 장치) |
가져오는 동안 전체 데이터 집합을 쿼리하고 처리해야 합니다. 이는 메모리가 많은 작업입니다. 이 가져오기는 시간이 더 오래 걸리는 경우가 많습니다. DirectQueries 및 LiveConnections는 일반적으로 CPU가 많습니다. 대부분의 경우 직접 쿼리는 데이터의 작은 부분만 처리하기 위해 여러 번 실행됩니다. 데이터의 일부만 처리되므로 이러한 직접 쿼리는 일반적으로 메모리가 많은 작업이 아닙니다. 그러나 쿼리가 요청 시 여러 번 실행되므로 CPU를 많이 사용할 수 있습니다.
워크로드에 따라 메모리 또는 CPU에 대해 게이트웨이 서버를 최적화하는 것이 좋습니다.
게이트웨이 클러스터의 크기를 조정하는 경우
크기 조정은 중요 비즈니스용 게이트웨이 클러스터의 중요한 측면입니다. 게이트웨이 클러스터 사용량이 증가함에 따라 우수한 성능을 보장하기 위해 게이트웨이 클러스터를 규모 확장 및/또는 확장해야 합니다. 이전에 클러스터에서 게이트웨이를 확장한 경우 게이트웨이 클러스터 확장을 시작하는 것이 좋습니다.
클러스터 내의 개별 노드에서 트래픽 부하를 스케일링하고 분산하는 것은 각 개별 시나리오에 따라 달라지는 복잡한 프로세스입니다. 모든 게이트웨이 트래픽이 예측 가능한 서비스로 처리되도록 하는 확실한 모델은 없지만 아래 나열된 제한은 크기 조정이 필요하다는 것을 나타냅니다. 일반적으로 확장(개별 노드의 CPU, RAM 또는 디스크 공간 증가)에 우선적으로 스케일 아웃(클러스터에 노드 추가)을 권장합니다. 스케일 아웃은 시스템 전체에서 추가 트래픽을 처리하는 데 전반적으로 더 효과적인 경향이 있습니다. 스케일 아웃은 클러스터에서 처리할 수 있는 총 대역폭에도 긍정적인 영향을 주지만, 확장은 일반적으로 그렇지 않습니다. 하나 이상의 게이트웨이 노드가 다음 임계값에 도달했음을 표시하는 경우 클러스터 스케일 아웃을 강력하게 고려해야 합니다.
CPU: CPU가 장시간 동안 80% 초과되지만 CPU 최대 출력이 비정상적이지 않은 짧은(5분 미만) 스파이크가 가끔 발생합니다.
RAM: 사용 가능한 메모리가 정기적으로 20% 아래로 떨어지게 됩니다.
디스크: 사용 가능한 디스크 공간이 5GB 미만으로 자주 감소합니다. 이 급락은 캐싱 또는 스풀링 디렉터리를 보다 전략적으로 구성해야 한다는 것을 나타낼 수도 있습니다.
동시성: 단일 노드에서 동시에 40개 이상의 쿼리를 실행합니다.
게이트웨이 노드에 분산된 새로 고침 및 쿼리는 프로필이 크게 다를 수 있으므로 장기 실행 또는 메모리 집약적 작업에 대한 추가 조사를 수행하는 것이 좋습니다. 이러한 경우 쿼리 최적화는 개별 보고서 및 새로 고침뿐만 아니라 시스템 전체에 성능 및 확장성에 큰 영향을 미칠 수 있습니다. 쿼리 계획 진단, 접기 표시기 및 기타 게시된 모든 성능 권장 사항을 사용하여 성능 특성을 평가하고 최적화를 수행하려면 문제의 새로 고침을 단일 전용 게이트웨이 클러스터로 격리하는 것이 좋습니다. 이 격리는 검색된 데이터의 양과 필요한 후처리 양을 최소화합니다. 이러한 격리는 조직 전체의 다른 일반적인 새로 고침과의 경합을 줄이기 위해 장기 실행 ETL 작업을 전용 게이트웨이 클러스터로 격리하는 장기 전략으로 사용할 수도 있습니다.
게이트웨이 클러스터 확장
스케일 업은 게이트웨이 서버의 사양(CPU, 메모리, 디스크 등)을 늘릴 때입니다.
게이트웨이가 하나 이상의 쿼리를 실행할 때 최대 CPU 또는 메모리에 도달하는 경우 스케일 업이 필요할 수 있습니다. 쿼리는 하나의 게이트웨이 서버에서만 실행할 수 있으므로 게이트웨이 서버에는 결과 데이터와 함께 전체 쿼리를 처리할 수 있는 충분한 리소스가 있어야 합니다.
게이트웨이 클러스터 확장
게이트웨이 서버의 사양이 이미 높거나(즉, 게이트웨이 서버가 이미 확장되고 있음) 실행 중인 동시 쿼리 수로 인해 단일 게이트웨이 서버가 관리할 수 있는 제한에 도달한 경우 스케일 아웃이 필요합니다. 전체 게이트웨이 멤버 집합에서 광범위한 부하 증가는 노드를 추가하여 클러스터 크기를 조정하는 것이 올바른 작업 과정임을 나타내는 좋은 지표입니다. 게이트웨이 클러스터의 크기를 조정하는 경우 크기 조정 시점을 나타내는 특정 임계값을 제공합니다. 스케일 아웃에 대한 자세한 내용은 게이트웨이 고가용성 및 부하 분산 기능을 사용하세요.
새 게이트웨이 클러스터를 만들어 크기 조정
게이트웨이 클러스터의 리소스 사용량이 높거나 매우 많은 사용자가 게이트웨이 클러스터를 사용하는 경우 새 게이트웨이 클러스터를 만들 수 있습니다. 그런 다음 워크로드의 하위 집합을 새 게이트웨이 클러스터로 마이그레이션할 수 있습니다. 많은 사용자가 단일 게이트웨이 클러스터를 사용하는 경우 사용자가 전체 게이트웨이 클러스터에서 상당한 성능 영향을 주는 쿼리를 보낼 가능성이 크게 증가합니다.
단일 게이트웨이 클러스터를 사용하는 사용자 수가 매우 많은 것은 새 게이트웨이 클러스터를 만들어야 한다는 지표입니다.
게이트웨이 성능 모니터링 및 문제 해결
게이트웨이 성능 모니터링 기능을 사용하여 중요 비즈니스용 게이트웨이의 전반적인 성능을 모니터링하는 것이 중요합니다. 이 기능을 사용하여 성능 문제를 해결하고, 병목 상태를 식별하고, 전반적인 게이트웨이 성능에 영향을 주는 쿼리를 식별할 수도 있습니다. 이 기능은 게이트웨이 클러스터의 크기를 조정할 시기를 결정하는 데 도움이 되는 중요한 도구이기도 합니다.
쿼리가 게이트웨이에 큰 영향을 미치면 전반적인 성능이 저하되는 것으로 확인되면 쿼리를 다시 작성하여 더 효율적으로 수행하고 성능 영향을 최소화할 수 있습니다.
Microsoft가 게이트웨이 또는 게이트웨이 관련 구성 요소(예: 오버로드된 Power BI Premium 용량)로 인한 성능 저하를 식별하는 경우 오버로드된 구성 요소는 부하를 확장하거나 줄여서 해결해야 합니다. Microsoft는 게이트웨이 또는 게이트웨이 관련 구성 요소가 오버로드될 때 성능 저하를 조사하지 않습니다.