하드웨어 플랫폼

이 콘텐츠는 조직이 데이터를 사용하여 영향력을 높이는 방법을 분석 및 개선하는 데 도움을 주는 성숙도 프레임워크인 Tableau Blueprint의 일부입니다. 여정을 시작하려면 평가(링크가 새 창에서 열림)를 수행하십시오.

참고: 이 항목의 내용은 Tableau Server에만 적용됩니다.

Tableau Server는 물리적 또는 가상 컴퓨터에 온프레미스로 설치하거나 클라우드에 설치할 수 있으며, Windows 또는 Linux 운영 체제를 지원합니다. 하드웨어 플랫폼 및 크기를 결정하려면 환경, 데이터 원본 및 셀프 서비스 데이터 액세스를 제공하기 위한 관리, 모든 사용자의 잠재적 워크로드, 실제 사용 현황 데이터 등의 변수를 고려하십시오. Tableau Server를 처음 배포하는 경우에는 환경 표준과 데이터 원본에 중점을 두어야 합니다. 기존에 배포한 경우에는 환경 및 데이터 원본 외에도 Tableau Server 데이터를 분석하여 워크로드 및 사용 현황을 평가합니다.

하드웨어 요구 사항

Tableau Server를 배포하기로 선택한 위치에 관계없이 적절한 크기의 하드웨어를 사용하는 것이 중요합니다. 서버 사용률 및 사용자 참여를 더 자주 평가하고, 더 자주 확장하며, 다른 소프트웨어 응용 프로그램보다 토폴로지를 더 자주 변경함으로써 변화하는 비즈니스 요구 사항에 맞게 계획을 조정해야 합니다. 기업 표준에 맞는 하드웨어 플랫폼에 해당하는 링크를 검토하십시오.

  • Google Compute Engine 가상 컴퓨터 유형 및 크기(Windows | Linux)
  • Microsoft Azure 가상 컴퓨터 유형 및 크기(Windows | Linux)
  • Alibaba Cloud ECS 인스턴스 유형 및 크기(Windows | Linux)

클라우드에 Tableau Server를 배포하는 경우 전용 하드웨어 및 RAM 정적 할당을 사용하면 리소스 경합으로 인한 성능 변동 문제가 해소됩니다. 비용을 고려해야 하는 경우 가상 하드웨어를 사용할 수도 있습니다. 자체 인프라를 테스트하여 요구에 맞는 가장 적합한 구성을 찾는 것이 좋습니다. 그러한 테스트를 수행하는 방법의 예는 EC2 속도의 Tableau 백서를 참조하십시오. (이 실험은 AWS에서 수행되었지만, 테스트 이론은 모든 클라우드 제공업체로 확장 적용됩니다.)

초기 크기 조정

Tableau 계정 팀이 요구 사항을 평가하고 크기 조정을 지원할 수 있습니다. Tableau의 초기 배포에서는, 활성 사용자를 10%라고 가정하면 Explore는 8코어 노드당 600~800명으로 추산해야 합니다(노트북 또는 휴대기기에서 대시보드 소비, 웹 작성, 게시된 데이터 원본에 연결 및 쿼리 등을 포함하여 Tableau Server에 대해 생성된 대화형 동시 요청). 이는 출발점일 뿐이며, 초기 배포 이후의 고정된 크기 조정 규칙으로 간주해서는 안 됩니다. 프로덕션 서버의 메모리는 코어당 최소 8GB RAM이어야 합니다. 40코어 미만 클러스터의 경우에는 8코어 노드를 사용하고, 40코어보다 큰 클러스터에서는 16코어 노드를 사용하십시오. 각 라이선스 유형에 대한 상대적 워크로드는 하드웨어 크기에 반영해야 합니다. Explorer를 1명의 사용자로 가정하면, Creator의 상대적 워크로드는 2.4명의 사용자이고, Viewer의 상대적 워크로드는 0.75명의 사용자입니다. 이러한 워크로드 계수를 사용하여 클러스터의 용량을 추산할 수 있습니다. 다음 테이블은 각 행에서 동등한 워크로드의 예입니다.

 

Creator

Explorer

Viewer

워크로드 1

25

300

586

워크로드 2

50

333

462

워크로드 3

75

234

514

워크로드 4

100

171

518

 

Creator, Explorer 및 Viewer의 실제 워크로드는 데이터 연결 및 웹 작성 빈도, 콘텐츠 보기 및 콘텐츠 상호 작용과 같은 Tableau Server 기능의 사용 현황에 따라 다를 수 있습니다. 사용자가 온보딩하여 콘텐츠를 만들고 소비하기 시작하면, 하드웨어 및 콘텐츠 사용률을 모니터링하고, 하드웨어 모니터링 도구 및 Tableau Server 리포지토리의 데이터를 사용하여 서버 크기에 대해 정보를 기반으로 의사 결정을 내려야 합니다. 자세한 내용은 Tableau 모니터링Tableau 사용자 참여 및 채택 측정을 참조하십시오.

확장성

신규 및 기존 배포 시나리오에서, 목표는 충분한 가용성, 용량 및 여유 공간을 사전에 유지 관리하고 리소스 경합을 최소화하는 것입니다. 다른 엔터프라이즈 플랫폼과 마찬가지로, Tableau Server는 프로세서, 메모리 및/또는 디스크를 추가하여 수직 확장하거나, 더 많은 노드를 클러스터에 추가하여 수평 확장할 수 있습니다. Tableau Server는 기업 고유의 환경, 데이터, 워크로드 및 사용 현황 조합에 따라 하드웨어 리소스를 추가하여 거의 선형으로 확장할 수 있습니다. Tableau 유지 관리에 요약된 대로 로드 테스트 및 용량 계획을 정기적으로 수행해야 합니다.

확장성과 성능은 데이터 원본, 데이터 볼륨, 네트워크 속도, 사용자 워크로드, 통합 문서 디자인과 같은 외부 시스템에 따라 크게 달라지며, 배포가 진행되면서 빠르게 변경될 수 있습니다. 예를 들어, 올바른 크기의 하드웨어 구성이 초기에 배포되었다고 가정하더라도 계획되지 않은 사용자 온보딩, 모니터링되지 않은 사용률, 비효율적인 통합 문서, 최적화되지 않은 데이터 추출 설계 및 피크 시간대 새로 고침 일정은 서버 성능과 사용자 경험에 큰 영향을 미칠 수 있으며 개별 인시던트의 누적된 효과로 성능이 저하될 수 있습니다. 자세한 내용은 Tableau Server 확장성 백서를 참조하십시오.

클라우드에 Tableau Server를 배포할 때 핫 토폴로지를 포함하여 Tableau 플랫폼의 기존 확장 기능을 모두 활용할 수 있습니다. 공용 IP 주소가 바뀌지 않는 한, 서버를 다시 시작하는 것만으로 플랫폼을 지원하는 기본 컴퓨터를 변경할 수도 있습니다.

단일 노드 배포의 경우, 컴퓨터 비용을 줄이기 위해 다운타임 중에 Tableau Server 컴퓨터를 끌 수도 있습니다. 다중 노드 클러스터에서 그렇게 하면 Tableau의 성능이 저하됩니다. 그러나 핫 토폴로지를 활용하면 Tableau Server 프로세스 할당을 즉시 조정하여 컴퓨터 비용과 용량 요구 사항의 균형을 맞출 수 있습니다. 요구에 따라 컴퓨터를 종료하거나 인스턴스화하는 자동 확장 기능은 지원되지 않습니다.

서버 환경

프로덕션 환경 외에도, 업그레이드 및 서버 토폴로지 변경을 테스트하기 위한 하나의 테스트 환경을 갖추는 것이 좋습니다. 프로덕션 환경은 콘텐츠 유효성 검사, 승격 및 인증 프로세스와 함께 프로덕션 및 샌드박스 프로젝트를 사용하여 최신 분석을 모두 하나의 환경에서 지원합니다. 이러한 콘텐츠 관리 프로세스에 대한 자세한 내용은 Tableau 거버넌스를 참조하십시오. 프로덕션 및 테스트 환경은 하드웨어 사양, 서버 토폴로지 및 구성이 동일해야 합니다. 그러면 관리자는 프로덕션 콘텐츠를 복원하여 업그레이드를 테스트하고 테스트 환경에서 베타 프로그램에 참여할 수 있습니다.

몇몇 조직에서는 콘텐츠 개발, 테스트 및 소비에 대한 사용 사례를 별도의 Tableau Server 설치로 분리하기 위해 개발, QA 및 프로덕션의 세 가지 환경을 요구하는 IT 정책을 실시합니다. 이것이 조직에 필요한 사항인 경우, Tableau의 최종 사용자 사용권 계약에 정의된 대로 이를 세 가지 프로덕션 환경으로 간주하여 세 개의 환경 각각에 대해 별도의 라이선스를 부여해야 합니다. 프로덕션 및 QA 환경은 사양, 서버 토폴로지 및 구성이 동일해야 합니다. 별도의 세 가지 개발 환경을 운영해야 하는 경우 최신 분석 플랫폼으로 기존의 하향식 폭포형 개발 주기를 복제하지 마십시오. 사용자가 엄격한 정책을 우회하거나 프로덕션으로 콘텐츠 가져오기의 지연을 피하고자 QA 환경을 선호할 수 있으므로, Tableau Advanced ManagementContent Migration Tool 또는 Tableau의 REST API의 사용자 지정 워크플로우 스크립트를 사용하여 프로덕션 서버로의 콘텐츠 마이그레이션을 자동화함으로써 적절한 균형을 유지하십시오. 개발 환경이 업그레이드 테스트 또는 베타 프로그램 참여에 사용되지 않는 한, 프로덕션 및 QA 환경과 동일한 하드웨어 사양일 필요는 없습니다.

고가용성

가용성 요구 사항에 따라 Tableau를 설치 및 구성해야 하며, 용량 및/또는 고가용성(Windows | Linux)을 지원하기 위해 노드를 추가해야 합니다. 업무상 중요한 사용 사례를 지원하려면, 외부 부하 분산 장치(Windows | Linux)를 사용하여 HA(고가용성) 클러스터 구성을 배포해야 합니다.

Tableau Server의 HA 설치에는 최소 3개의 노드가 사용되며, 노드마다 여러 개의 중복된 주요 프로세스 인스턴스(리포지토리, 파일 저장소/데이터 엔진 및 조정 서비스)가 사용됩니다. 목표는 단일 장애 지점을 제거하고 가능한 경우 장애 조치로 장애를 감지함으로써 시스템 다운타임을 최소화하는 것입니다. 자세한 내용은 Tableau Server 고가용성 백서를 참조하십시오.

HA 클러스터를 구축하려면 아래 패턴을 참조하십시오.

  1. 초기 노드를 설치하고 아키텍처 인식 스마트 설치 프로그램을 통해 프로세스를 구성합니다(Windows | Linux). 활성 리포지토리는 노드 1에 있습니다.
  2. 프로세스 구성을 다른 VizQL 노드로 복제하여 중복성을 확인합니다(Windows | Linux). 비활성 리포지토리는 노드 2에 있습니다. 노드 3 프로세스는 리포지토리 프로세스가 없을 경우를 제외하고 노드 1 및 2를 미러링합니다.
  3. 조정 서비스 집합 및 클라이언트 파일 서비스를 추가합니다(Windows | Linux).
  4. 외부 부하 분산 장치를 추가합니다(Windows | Linux).

3개의 노드로 Tableau Server HA 배포(참고: 조정 서비스 및 클라이언트 파일 서비스는 명시적으로 표시되지 않음)

시간이 흐르면서 특수 노드에 대한 필요성이 커집니다. 추출이 많고 추출 빈도가 높은 추출 새로 고침 워크로드는 대화형 데이터 시각화 렌더링 워크로드와 분리해야 합니다. 추출이 많은 환경에서는 데이터 원본의 대부분을 추출합니다. 소수의 대규모 추출은 여러 개의 소규모 추출과 같이 이 카테고리에서 배포할 수 있습니다. 추출 새로 고침이 빈번한(하루 업무 시간 중 여러 번) 배포의 경우 특수 백그라운더 노드에서 분리해야 합니다. 백그라운더 프로세스의 워크로드를 분리하려면, 아래 노드 4 및 노드 5에 표시된 대로 특수 백그라운더 노드를 추가하여 중복성을 보장해야 합니다. 노드 역할을 사용하면 Tableau Server 설치에서 특정 유형의 워크로드가 처리되는 위치를 구성할 수 있습니다. 노드 역할 기능을 사용하면 리소스를 특정 워크로드 전용으로 할당하거나 확장할 수 있습니다. 백그라운더 및 파일 저장소의 노드 역할 구성에 대한 자세한 내용은 노드 역할을 통한 워크로드 관리를 참조하십시오.

5개의 노드로 Tableau Server HA 배포(참고: 조정 서비스 및 클라이언트 파일 서비스는 명시적으로 표시되지 않음)

 

2019.3부터 Tableau Server 리포지토리를 Amazon RDS(Relational Database Service)에 배포할 수 있습니다. Tableau Server 리포지토리는 모든 사용자 상호 작용, 추출 새로 고침 및 기타 항목에 대한 데이터를 저장하는 PostgreSQL 데이터베이스입니다. Amazon RDS는 PostgreSQL에 내장된 확장성, 안정성, 고가용성 및 보안 기능을 제공합니다. AWS와 통합하여 Tableau Server 외부 리포지토리를 구성하면 이러한 클라우드 배포에 따른 추가적인 이점을 활용할 수 있습니다. 자세한 내용은 Tableau Server 외부 리포지토리를 참조하십시오.

Tableau Server를 퍼블릭 클라우드에 배포할 때 다운타임의 위험을 더 완화하기 위한 몇 가지 옵션이 있습니다. 예를 들어 Tableau Server의 각 노드를 자체 가상 네트워크에 배포하거나 다른 가용 영역 또는 영역에 배포하는 것이 모두 지원됩니다. 그러나 환경을 분리하면 시스템 전체에서 대기 시간이 길어질 수 있습니다. 데이터 커뮤니티를 위해 적절한 균형을 유지하려면 환경을 최종 결정하기 전에 성능과 가용성을 모두 테스트하는 것이 좋습니다. Tableau Server는 하나의 멀티 노드 클러스터를 서로 다른 지역에 배포하는 것을 지원하지 않습니다.

재해 복구

Tableau 환경의 DR(재해 복구) 계획에서는 다음의 두 가지 요인, 즉 RTO(목표 복구 시간)와 RPO(목표 복구 시점)를 고려해야 합니다. RTO는 전체 복구 전에 비즈니스에서 얼마나 많은 다운타임을 수용할 수 있는지를 측정하는 것으로, 백업을 대체 클러스터로 복원하는 빈도와 인프라 투자 비용에 영향을 줍니다. RPO는 비즈니스에서 허용할 수 있는 데이터 손실 정도를 측정하는 것으로, 시스템 백업을 수행해야 하는 빈도에 영향을 줍니다. Tableau Server에서 RPO는 서버의 전체 백업을 완료하는 데 소요되는 시간보다 짧을 수 없습니다. 아래의 테이블은 RTO 요구 사항 범위를 계획하는 방법을 보여줍니다.

 

높은 RTO

중간 RTO

낮은 RTO

작동 중단 시 새로운 하드웨어/VM 확보

컴퓨터가 프로비저닝되지만 실행되지 않음

프로덕션과 동일한 구성 및 토폴로지로 항상 실행되는 전용 하드웨어

Tableau Server 설치

Tableau Server 설치됨

DR 환경으로 정기적인 백업 복원

새로운 환경으로 백업 복원

수동 대기 환경에 최신 백업 복원

DR 환경을 가리키도록 업데이트할 수 있는 외부 부하 분산 장치/DNS 라우팅

몇 시간 또는 며칠

두세 시간

몇 분

 

Tableau Server를 온프레미스에 호스팅하든 클라우드에 호스팅하든 백업 프로세스는 동일합니다. Tableau Server의 백업을 생성하고 새 컴퓨터에서 이 백업을 복원하려면 TSM Backup 명령을 사용하십시오. Tableau Server 컴퓨터의 스냅샷을 만들어 새 컴퓨터에서 복원하는 것은 지원되지 않습니다. 자세한 내용은, 고가용성 및 재해 복구의 개념에 대한 업무상 중요한 안정성과 백서를 참조하십시오.

피드백을 제공해 주셔서 감사합니다!귀하의 피드백이 제출되었습니다. 감사합니다!