중요 비즈니스용 게이트웨이 솔루션 계획, 스케일링 및 유지 관리

이 문서는 중요 비즈니스용 시나리오에서 온-프레미스 데이터 게이트웨이를 배포하려는 모든 사람을 대상으로 합니다. 온-프레미스 데이터 게이트웨이는 비즈니스의 정상적인 운영에 필수적이며 중요 비즈니스용 데이터를 처리하는 중요 비즈니스용입니다.

업무상 중요한 게이트웨이가 제대로 관리되지 않으면 쿼리가 실패하거나 성능이 저하될 수 있습니다. 비즈니스에 중요한 게이트웨이 솔루션을 올바르게 계획, 크기 조정 및 기본 경우 비즈니스에 영향을 미치는 문제의 가능성을 최소화할 수 있습니다.

용어

이 문서 전체에서 다음과 같은 중요한 용어가 사용됩니다.

• 게이트웨이: 컴퓨터에 설치된 온-프레미스 데이터 게이트웨이 애플리케이션.
• 게이트웨이 서버: 온-프레미스 데이터 게이트웨이 애플리케이션이 설치된 Windows 컴퓨터(가상 머신 또는 물리적 컴퓨터/서버).
• 게이트웨이 클러스터: 함께 작동하고 부하 분산될 수 있는 게이트웨이 집합.
• 게이트웨이 멤버: 게이트웨이 클러스터의 일부인 게이트웨이.

다음 이미지는 위에서 정의한 개념 간의 관계를 보여줍니다.

중요 비즈니스용 게이트웨이에 대한 권장 사항

중요 비즈니스용 게이트웨이의 경우 고가용성, 우수한 성능 및 유지 가능한 스케일링 성능을 보장하기 위해 게이트웨이를 적절하게 배포 및 관리해야 합니다. 게이트웨이를 잘못 배포하면 성능이 저하되고 쿼리가 실패하고 잠재적인 문제를 진단하기 어려울 수 있습니다. 또한 사용량이 증가함에 따라 게이트웨이를 스케일링 업과 스케일링 아웃 기능을 방해할 수도 있습니다.

최적의 스케일링 성능, 성능 및 처리량을 보장하려면 다음 섹션의 권장 사항을 따릅니다.

모든 게이트웨이 복구 키 알기

모든 게이트웨이 복구 키를 자신이 인지하고 있는 안전한 장소에 보관합니다. 복구 키가 없으면 게이트웨이를 복구하거나 다운그레이드할 수 없습니다. 이 제한은 의도적으로 적용됩니다. 복구 키를 분실한 경우 유일한 옵션은 새 게이트웨이를 만들고 데이터 원본을 다시 만드는 것입니다. 또한 복구 키가 없으면 클러스터에 새 게이트웨이를 추가할 수 없으므로 향후 스케일링 성능이 제한됩니다.

권한 있는 관리자만 액세스할 수 있는 암호 금고와 같은 관리 자격 증명을 저장하는 것처럼 복구 키를 안전한 장소에 저장합니다.

현재 모든 게이트웨이 복구 키를 모르는 경우 이것은 상당한 비즈니스 위험입니다. 즉시 새 게이트웨이 클러스터를 만들고 게이트웨이 클러스터로 워크로드 마이그레이션을 시작합니다.

개발 워크로드 및 중요 비즈니스용 워크로드

아래에 설명된 대로 하나 이상의 개발 게이트웨이 클러스터와 하나 이상의 프로덕션 게이트웨이 클러스터를 설정하여 중요 비즈니스용 워크로드에서 개발 워크로드를 분리합니다.

개발 게이트웨이 클러스터를 사용하여 새로운 의미 체계 모델, 보고서, 쿼리 등을 테스트합니다. 새 워크로드가 확인되면 중요 비즈니스용 게이트웨이 클러스터로 마이그레이션합니다. 이 프로세스는 새로운, 테스트되지 않은 또는 실험적인 워크로드가 프로덕션 워크로드에 성능 영향을 미치는 것을 방지합니다.

또한 중요 비즈니스용 게이트웨이 클러스터에 업데이트를 적용하기 전에 개발 게이트웨이 클러스터를 사용하여 새 게이트웨이 업데이트를 테스트합니다. 중요 비즈니스용 게이트웨이 클러스터에서 사용하기 전에 새 게이트웨이 업데이트를 개발 게이트웨이 클러스터에서 최소 24시간 동안 배포해야 합니다.

여러 게이트웨이 클러스터 사용

조직에서 많은 수의 사용자를 위한 게이트웨이 클러스터를 만드는 경우 비즈니스 단위 이하를 기반으로 여러 게이트웨이 클러스터를 만들어 잠재적인 성능 영향을 소수의 사용자 하위 집합으로 제한해야 합니다.

작은 회사를 제외하고 회사 전체에 대해 단일 중요 비즈니스용 게이트웨이 클러스터를 사용하지 않는 것이 좋습니다. 단일 게이트웨이 클러스터 시나리오에서 한 사용자는 게이트웨이 전체의 모든 트래픽에 상당한 성능 영향을 미치는 쿼리를 보낼 수 있습니다. 게이트웨이가 회사 전체에서 사용되는 경우 성능 영향이 회사 전체에 영향을 미칠 수 있습니다. 또한 회사 전체에서 게이트웨이 클러스터를 사용하는 경우, 게이트웨이 성능 모니터링 기능 사용 시 성능 문제를 일으킬 수 있는 쿼리를 식별하기가 더 어려울 수 있습니다.

게이트웨이 고가용성 및 부하 분산 기능 사용

모든 중요 비즈니스용 게이트웨이 클러스터에 대해 게이트웨이 고가용성 및 부하 분산 기능을 항상 사용합니다.

• 고가용성: 단일 실패 지점을 제거합니다.
• 부하 분산: 클러스터의 모든 게이트웨이 서버에 워크로드를 자동으로 분산합니다.

어떤 이유로든 게이트웨이가 오프라인 상태가 되는 경우에 대비하여 게이트웨이 클러스터당 최소 2개의 게이트웨이를 설정합니다. 이 설정은 단일 게이트웨이 오류로 인해 전체 게이트웨이 클러스터가 실패하지 않도록 합니다. 또한 CPU, 메모리, 동시성 제한을 게이트웨이에서 사용하도록 설정하여 부하를 게이트웨이 클러스터 전체에 더 잘 분산시킬 수 있습니다.

게이트웨이 클러스터 스케일링 성능 계획 및 유지 관리

권장 하드웨어 및 소프트웨어 지침을 사용하여 게이트웨이 클러스터를 설정하면 클러스터가 우수한 성능으로 실행됩니다. 적절하게 스케일링되지 않은 게이트웨이는 성능이 저하될 수 있습니다. 게이트웨이 클러스터에서 좋은 성능을 얻으려면 고려해야 하는 많은 요소가 있습니다.

게이트웨이 서버 하드웨어 사양 결정

게이트웨이 서버 사양(CPU, 메모리, 디스크 등)은 대부분 Power Query 변환은 게이트웨이 서버의 데이터에 적용되는 경우와 마찬가지로 중요한 요소입니다. 따라서 게이트웨이 서버에는 모든 데이터 변환을 처리할 수 있는 충분한 리소스, 메모리 및 처리 능력이 필요합니다.

서버 크기를 선택해야 할 때 가장 중요한 두 가지 메트릭이 있습니다. 메모리와 CPU입니다. 게이트웨이에서 Power Query 데이터 변환을 처리하려면 충분한 메모리와 CPU 성능이 모두 필요합니다. 게이트웨이 서버가 가장 높은 워크로드를 처리할 수 있을 만큼 강력해야 합니다. 게이트웨이 서버가 워크로드를 처리할 수 없는 경우 직접 쿼리 또는 데이터 새로 고침이 실패합니다. 동시에 얼마나 많은 쿼리가 실행되는지 이해하는 것도 중요합니다.

이러한 다양한 쿼리 옵션은 게이트웨이 서버에 다른 영향을 줍니다.

쿼리 유형	제한 요소
가져오기	메모리
DirectQuery	CPU
LiveConnect	CPU

가져오는 동안 전체 데이터 집합을 쿼리하고 처리해야 하며 이는 메모리 사용량이 많은 작업입니다. 이 가져오기는 시간이 더 오래 걸리는 경우가 많습니다. DirectQueries 및 LiveConnection은 일반적으로 CPU를 많이 사용합니다. 대부분의 경우 직접 쿼리를 여러 번 실행하여 데이터의 작은 부분만 처리합니다. 데이터의 일부만 처리되므로 이러한 직접 쿼리는 일반적으로 메모리가 많은 작업이 아닙니다. 그러나 쿼리는 요청 시 여러 번 실행되기 때문에 CPU를 많이 사용하게 될 수 있습니다.

워크로드에 따라 메모리 또는 CPU에 대한 게이트웨이 서버 최적화를 고려합니다.

게이트웨이 클러스터를 스케일링해야 하는 경우

스케일링은 중요 비즈니스용 게이트웨이 클러스터의 중요한 측면입니다. 게이트웨이 클러스터의 사용량이 증가함에 따라 게이트웨이 클러스터를 스케일 업 또는 스케일 아웃하여 우수한 성능을 보장해야 합니다. 이전에 클러스터에서 게이트웨이를 스케일링한 경우 게이트웨이 클러스터 스케일링을 시작하는 것이 좋습니다.

클러스터 내의 개별 노드에서 트래픽 부하를 스케일링하고 분산하는 것은 각 개별 시나리오에 따라 달라지는 복잡한 프로세스입니다. 모든 게이트웨이 트래픽이 예측 가능한 서비스로 처리되도록 하는 확실한 모델은 없지만 아래에 나열된 제한은 크기 조정이 필요하다는 것을 나타냅니다. 일반적으로 확장(개별 노드의 CPU, RAM 또는 디스크 공간 증가)에 우선적으로 스케일 아웃(클러스터에 노드 추가)을 권장합니다. 스케일 아웃은 시스템 전체에서 추가 트래픽을 처리하는 데 전반적으로 더 효과적인 경향이 있습니다. 스케일 아웃은 클러스터에서 처리할 수 있는 총 대역폭에도 긍정적인 영향을 주지만, 확장은 일반적으로 그렇지 않습니다. 하나 이상의 게이트웨이 노드가 아래에 설명된 임계값에 도달했음을 표시하는 경우 클러스터 확장을 강력하게 고려해야 합니다.

• CPU: CPU가 장시간 80% 이상이지만 CPU 최대값이 비정상적이 아닌 짧은(5분 미만) 급증이 가끔 발생합니다.

• RAM: 사용 가능한 메모리가 정기적으로 20% 미만으로 떨어지게 됩니다.

• 디스크: 사용 가능한 디스크 공간이 5GB 미만으로 자주 감소합니다. 이 급락은 캐싱 또는 스풀링 디렉터리를 보다 전략적으로 구성해야 한다는 것을 나타낼 수도 있습니다.

• 동시성: 단일 노드에서 동시에 40개 이상의 쿼리를 실행합니다.

게이트웨이 노드에 분산된 새로 고침 및 쿼리는 프로필이 크게 다를 수 있으므로 장기 실행 또는 메모리 집약적 작업에 대한 추가 조사를 수행하는 것이 좋습니다. 이러한 경우 쿼리 최적화는 개별 보고서 및 새로 고침뿐만 아니라 시스템 전체에 성능 및 확장성에 큰 영향을 미칠 수 있습니다. 쿼리 계획 진단, 접기 표시기 및 기타 게시된 모든 성능 권장 사항을 사용하여 성능 특성을 평가하고 최적화를 수행하려면 문제의 새로 고침을 단일 전용 게이트웨이 클러스터로 격리하는 것이 좋습니다. 이 격리는 검색된 데이터의 양과 필요한 후처리 양을 최소화합니다. 이러한 격리는 조직 전체의 다른 일반적인 새로 고침과의 경합을 줄이기 위해 장기 실행 ETL 작업을 전용 게이트웨이 클러스터로 격리하는 장기 전략으로 사용할 수도 있습니다.

게이트웨이 스케일 업

스케일 업은 게이트웨이 서버의 사양(CPU, 메모리, 디스크 등)을 늘리는 것입니다.

게이트웨이가 하나 이상의 쿼리를 실행할 때 최대 CPU 또는 메모리에 도달하면 스케일 업이 필요할 수 있습니다. 쿼리는 하나의 게이트웨이 서버에서만 실행할 수 있으므로 게이트웨이 서버에는 결과 데이터와 함께 전체 쿼리를 처리할 수 있는 충분한 리소스가 있어야 합니다.

게이트웨이 스케일 아웃

게이트웨이 서버의 사양이 이미 높거나(즉, 게이트웨이 서버가 이미 스케일 업된 경우) 또는 처리되는 동시 쿼리 수로 인해 단일 게이트웨이 서버가 관리할 수 있는 한도에 도달한 경우 스케일 아웃이 필요합니다. 전체 게이트웨이 멤버 집합에서 광범위한 부하 증가는 노드를 추가하여 클러스터 크기를 조정하는 것이 올바른 작업 과정임을 나타내는 좋은 지표입니다. 게이트웨이 클러스터 의 크기를 조정하는 경우 크기 조정 시점을 나타내는 특정 임계값을 제공합니다. 스케일 아웃에 대한 자세한 내용은 게이트웨이 고가용성 및 부하 분산 기능 사용으로 이동하세요.

새 게이트웨이 클러스터를 만들어 스케일링

게이트웨이 클러스터의 리소스 사용량이 높거나 예외적으로 많은 사용자가 게이트웨이 클러스터에 의존하는 경우 새 게이트웨이 클러스터를 만들 수 있습니다. 그런 다음 워크로드의 하위 집합을 새 게이트웨이 클러스터로 마이그레이션할 수 있습니다. 다수의 사용자가 단일 게이트웨이 클러스터에 의존하는 경우 사용자가 전체 게이트웨이 클러스터에서 상당한 성능 영향을 일으키는 쿼리를 보낼 수 있는 가능성이 크게 높아집니다.

단일 게이트웨이 클러스터에 의존하는 예외적으로 많은 수의 사용자는 새 게이트웨이 클러스터를 만들어야 함을 나타냅니다.

게이트웨이 성능 모니터링 및 문제 해결

게이트웨이 성능 모니터링 기능을 사용하여 중요 비즈니스용 게이트웨이의 전체 성능을 모니터링하는 것이 중요합니다. 또한 이 기능을 사용하여 성능 문제를 해결하고, 병목 현상을 식별하고, 전체 게이트웨이 성능에 영향을 미치는 쿼리를 식별할 수 있습니다. 이 기능은 게이트웨이 클러스터를 스케일링할 시기를 결정하는 데 도움이 되는 중요한 도구이기도 합니다.

쿼리가 게이트웨이에 큰 영향을 미치는 것으로 식별하여 전반적인 성능이 저하된 경우 쿼리를 다시 작성하여 더 효율적으로 만들고 성능에 미치는 영향을 최소화할 수 있습니다.

Microsoft가 게이트웨이 또는 오버로드된 Power BI 프리미엄 용량과 같은 게이트웨이 관련 구성 요소로 인한 성능 저하를 식별한 경우, 과부화된 구성 요소는 반드시 부하를 스케일링하거나 줄여서 해결해야 합니다. Microsoft는 게이트웨이 또는 게이트웨이 관련 구성 요소가 오버로드된 경우 성능 저하를 조사하지 않습니다.