GCP의 SAS Viya 아키텍처 디자인: 기본 사항

[#1]

GCP(Google Cloud Platform)에 대한 관심이 점점 높아짐에 따라 구글 퍼블릭 클라우드에서 SAS Viya를 실행하는 방법을 프랑스 고객들에게 전달한 내용 중 몇 가지 기본 권장 사항을 이 포스팅을 통해 공유하고자 합니다.

대부분의 권장 사항은 Margaret Crevar가 작성한 3개의 주요 퍼블릭 클라우드 공급업체에 관한 SAS의 훌륭한 문서인  SAS Paper 1866-2018: Important Performance Considerations When Moving SAS® to a Public Cloud를 기반으로 합니다.(SAS 9과 SAS Viya 모두 해당)

구글 클라우드에 대하여 완벽히 정리되어 있으므로 별도의 언급없이 넘어가도록 하며 필요한 경우 파일을 통해 확인하시기 바랍니다.

일부 GCP 특성을 강조하고, SGF 문서의 주요 권장 사항에 대한 인식을 높이고, 설계 결정에 영향을 미칠 수 있는 사실 및 관심거리를 공유하여 고객과 아키텍처에 대한 논의를 순조로이 진행할 수 있도록 하고자 합니다.

고객과 관련해서는 고객이 사용하고 있는 클라우드에 대한 이해도가 어느 정도인지를 파악해야 합니다. 전문가 수준이 아니더라도 팀과 적극적으로 소통하는 것이 훨씬 좋은 편이라 하겠습니다. 고객의 예상을 웃도는 비용 청구나 혹은 더 심한 경우 IT 정책을 위반하지 않아야 합니다. IT에 대해 협상 및 토론한 경우가 전무하다면 관련 이슈를 파악하기 어려울 수도 있습니다.

포스팅의 내용이 의도한 것보다 훨씬 더 길어져서 관심 주제로 바로 이동할 수 있도록 목차를 작성했습니다.

• 구글 컴퓨트 엔진(GCE)
• 머신 유형
• 코어는 코어가 아니다
• 사이징
• 네트워크 고려 사항
• 송신 및 수신 트래픽
• 기본 권장 사항
• 보안
• GCP의 스토리지
• 가능한 솔루션
• 처리량
• SAS Viya에 대한 스토리지 권장 사항
• 결론

구글 컴퓨트 엔진(GCE)

구글 문서에 따르면 “컴퓨트 엔진 인스턴스는 Google이 제공하는 Linux 및 Windows Server용 공개 이미지와 기존 시스템에서 만들거나 가져올 수 있는 비공개 맞춤 이미지를 실행할 수 있습니다."

GCE는 AWS의 EC2 서비스에 해당하는 구글 클라우드입니다. 현재 IaaS(Infrastructure as a Service)에 대해 이야기 나누고 있다는 점을 유념하시기 바랍니다. 이점은 OS가 있는 가상 서버라 이에 연결하여 운영 체제 수준에서 준하는 작업을 수행할 수 있습니다. (예: 바이너리 설치, 파일 편집, 명령 및 시스템 서비스 실행 등)

구글은 또한 완전한 머신 대신 컨테이너를 프로비저닝 할 수 있는  HTTP load-balancers, Managed Instance 그룹(자동 복구 및 자동 크기 조정 기능 포함), ODBC 호환 데이터베이스 및 GKE(Google용 Kubernetes Engine)  등에 사용이 가능한 다른 서비와 메커니즘을 제공합니다. 그러나 이번 포스팅에서는 다루지 않겠습니다.

머신 유형

GCE 인스턴스의 머신 속성을 선택할 수 있습니다. 머신 유형은 기본적으로 고정된 수의 "vCPU"와 지정된 양의 RAM으로 사전 정의로 구성된 가상 머신입니다.

크게 보시려면 이미지를 클릭하시기 바랍니다. 모바일 버전: 이미지를 보시려면 페이지 하단의 풀 버전을 선택하세요.

GCE에는 현재 표준, 고성능 메모리, 고성능 CPU, 공유 코어 및 메모리 최적화의 5가지 사전 정의된 머신 유형 제품군이 존재합니다.

머신 유형 제품군의 주요 차이점은 CPU-RAM 비율(vCPU당 0.9~24GB)이며 물론 머신 유형에 따라 가격이 차이납니다.

AWS와 달리 GCP를 사용하는 경우 이 CPU/RAM 비율을 사용자 지정 및 조정 가능하며 GPU 프로세서를 추가할 수도 있습니다.

사전 정의된 머신 유형에는 이미 정해진 가상화된 하드웨어 속성과 그에 맞는 가격이 있는 반면 사용자가 조율이 가능한 커스텀 머신 유형은 가상 머신 인스턴스가 사용하는 vCPU 및 메모리 수에 따라 가격이 책정됩니다.

여기에서 머신 유형에 대한 세부정보를 찾을 수 있으며 Viya의 경우 Viya 배포 내 머신 역할에 따라 몇 가지 권장 사항이 존재합니다.

• SAS Programming Run-time(SAS PRE 및 관련 서비스): 방대한 양의 분석 처리가 CAS에서 수행되는 경우 일반적으로 표준 시리즈 시스템이 적합합니다. 그렇지 않을 경우 더 많은 리소스가 있는 인스턴스가 필요합니다. SAS PRE는 워크로드 유형에 따라 높은 CPU 및 메모리 리소스를 요구할 수 있다는 점을 유념해야 합니다.

• SAS Viya Services: 고성능 메모리 시리즈는 Viya 서비스들이 수많은 마이크로서비스 및 웹 애플리케이션을 실행하기 위해 더 많은 양의 메모리를 필요로 하기 때문에 좋은 선택이 될 수 있습니다. 이러한 머신에는 vCPU당 6.5GB의 시스템 메모리를 내장하고 있습니다. 모든 SAS Viya 서비스가 동일한 호스트에 있을 예정이라면 최소한 n1-highmem-16 머신 유형이 필요합니다(104GB RAM 포함).
  
  • CAS 노드: 이러한 서버에는 데이터 처리를 위한 빠른 CPU와 동시에 SAS Viya를 사용하는 모든 사용자가 분석할 모든 데이터 파일을 보관할 수 있는 충분한 물리적 RAM이 필요하다는 것을 알고 있습니다. CAS는 인메모리 분석 엔진입니다. 따라서 고성능 메모리(n1-highmem-16에서) 또는 새로운 메모리 최적화 시리즈(물리적 코어당 최대 48GB RAM)가 적합합니다*
    
    

    (*) 참고: "ultramem" 및 "megamem" 인스턴스는 일부 Google Cloud 영역에서 사용할 수 없으므로 주의하시기 바랍니다.

코어는 코어가 아니다

또한 반드시 짚고 넘어가야 할 중요한 사항은 GCP가 처리 능력을 vCPU(가상 CPU의 약자)로 표현한다는 것입니다. GCP 머신은 Hyper-Threading(물리적 CPU 코어당 2개의 스레드)으로 구성됩니다. 즉, 상단의 테이블에 나열된 vCPU는 실제 코어가 아닌 스레드입니다.

요약하자면 GCP의 vCPU 1개 = 물리적 CPU 코어 0,5개에 해당합니다.

따라서 GCP 인스턴스 vCPU 수는 SAS 라이선스 모델에 사용된 코어 수와 일치하도록 2로 나누어야 계산해야 합니다. 호스트에서 HT 정보를 확인할 수 있으며 CAS 라이선스 제어 알고리즘이 제대로 적용될 수 있습니다.

"lscpu" 명령은 많은 정보를 제공합니다. n1-standard-8(vCPU 8개, 메모리 30GB) 인스턴스에 대한 출력은 하단의 내용을 참조하시기 바랍니다.

코어당 스레드 수 값이 2이면 Hyper-threading이 활성화된 것을 볼 수 있습니다.

한 가지 흥미로운 사실은 AWS와 달리 GCP가 기본 호스트에서 사용되는 정확한 CPU 칩셋을 노출하지 않는다는 것입니다. (VM 호스트가 2.3GHz Intel Xeon 프로세서를 실행하는 것으로만 확인됨)

GCP에서 제공하는 NUMA 정보는 특정 상황에서 부정확할 수 있습니다. GCP에 64vCPU 인스턴스를 설정한 테스트에서 물리적 코어 수는 32개로 보고되었지만 소켓 수는 1개로 보고되었습니다. 하지만 인텔 페이지 검색에서 GEL 팀은 현재 켓당 28개 이상의 물리적 코어가 있는 Xeon E5/E7 프로세서가 누락된 것을 확인했습니다. 자세한 내용은 이 Intel 페이지를 통해 확인하실 수 있습니다.

사이징

마지막으로, 일반적으로 GCE 머신 유형 선택 조건은 다음과 같습니다.

• EEC 사이징: EEC 크기에서 CPU/RAM 비율 및 메모리 양
• CAS 세계에서 메모리의 양은 작업하려는 데이터의 양과 직접적인 관련이 있습니다
• 라이선스 코어 수
• 이상적으로는 EEC 사이징에 제공된 숫자를 뜻합니다. 그러나 항상 그렇지만은 않습니다.

먼저 하셔야 할 일은 사이징 권장 사항 및 라이선스가 부여된 코어 수를 GCE 인스턴스 유형에 매핑하는 것입니다.

다른 응용 프로그램이 Viya 배포 시스템과 같은 위치에 있는 경우 해당 응용 프로그램 또한 고려사항이 됩니다.

예를 들어 CAS 노드가 Hadoop 클러스터와 같은 위치에 있는 경우에는 CAS 라이선스에 표시된 것보다 더 많은 리소스 RAM, 디스크 및 CPU 코어를 프로비저닝해야 합니다. (CAS는 자체 사용률을 라이선스가 부여된 코어 수로 제한할 수 있습니다.)

네트워크 고려 사항

송신 및 수신 트래픽

Google Cloud 네트워크 문서에서는 다음과 같은 개념 또는 '수신' 및 '송신' 트래픽을 사용합니다.

• 수신: Google Cloud Platform에 들어오거나 업로드한 트래픽
• 송신: Google Cloud Platform에서 나가거나 다운로드한 트래픽

수신 트래픽은 무료며 반면에 송신 트래픽은 해당 트래픽의 소스 및 대상에 따라 요금이 부과됩니다. 해당 문서를 읽어보시기를 추천합니다.

GCP에서 송신 트래픽 대역폭은 vCPU의 갯수로 제한됩니다. 각 vCPU에는 최대 성능을 위해 2Gbps로 상한선이 정해져있습니다. 코어를 추가할 때마다 가상 머신에 대해 이론상 최대 16Gbps까지 네트워크 상한선을 늘려줍니다.

따라서 vCPU가 8개 미만인 GCP 머신의 경우 더 큰 인스턴스 유형에 비해 최대 네트워크 대역폭이 제한됩니다.

여기에서 다룬 바 있듯이 GCP에는 수신 트래픽에 대한 제한이 없습니다. VM이 처리할 수 있는 트래픽량은 머신 유형 및 운영 체제에 따라 상이할 수 있습니다. 수신 데이터 속도는 VM에 있는 네트워크 인터페이스 개수 또는 VM이 ​​사용하는 별칭 IP 주소 등으로 부터 영향을 받지 않습니다.

CAS MPP 환경 성능를 위한 중요한 매개변수는 네트워크 속도입니다. CAS 인프라의 네트워크 처리량과 대기 시간을 측정하기 위해서는 Viya 설치 전에 "iperf" 또는 "qperf"와 같은 도구를 설치하여 사용하는 것이 추천합니다.

기본 권장 사항

일반적으로 네트워크에 관한 몇 가지 권장 사항은 다음과 같습니다.

• 통신에는 항상 내부 IP를 사용합니다
  • Viya 내부 (모든 Viya 머신 간 – 특히 CAS 노드 간)
  • CAS와 데이터 소스 머신 간(GCP에도 있는 경우)
• 인스턴스를 적정한 영역에 배치
  • Viya 플랫폼을 호스팅하는 GCP 영역과 Data Lake 사이에 물리적 거리가 멀면 성능에 영향을 미칩니다.
  • 사용자에게 큰 영향을 미치지는 않지만 Viya 환경으로부터 거리가 먼 경우 추가 대기 시간으로 인해 웹 액세스가 느려질 수 있습니다.(GCP 내 가상 데스크톱 인프라를 사용하는 소규모 사용자 그룹의 경우 흥미로운 옵션이 될 수 있습니다.).
• 올바른 코어 수 선택
  • CAS 노드의 경우 vCPU가 8개 미만의 인스턴스를 사용하지 않아야 합니다. 그렇지 않을 경우 인스턴스 간의 네트워크 대역폭이 제한됩니다.

물리적인 기기를 사용한다면 ethtoo과 같은 명령어를 실행하는 NIC(Network Card Interface) 속도를 확인해야 합니다. 그러나 다른 가상화 혹은 클라우드 환경과 마찬가지로 GCP에서 인스턴스는 가상 NIC(네트워크 인터페이스 카드)를 사용합니다. 물리적 NIC는 VM에 직접 연결되지 않더라도 KVM 하이퍼바이저 호스트에서 실행되는 가상 스위치에 대한 업링크를 제공합니다.

마지막으로 특정 물리적 NIC(네트워크 카드 인터페이스)를 연결하도록 선택할 수는 없지만 단일 GCE 인스턴스에 여러 NIC를 연결하여 가능한 기술이 있다면 통신을 위한 특정 네트워크 인터페이스를 사용하도록 애플리케이션을 구성할 수 있습니다.

그러나 GCP에서는 16Gbps의 네트워크 속도 제한이 인스턴스 내에서 결정되므로 다수의 NIC는 그닥 도움이 되지 않을 수도 있습니다.

보안

기본적으로 모든 GCP 인스턴스에는 내부 IP 주소와 임시 외부 IP가 각각 하나씩 있습니다. 물론 Viya 배포의 경우 공개 서비스(예: HTTP Apache 서버)를 호스팅하는 컴퓨터의 IP 주소를 생성하여 필요한 포트를 여는 방화벽 규칙을 추가합니다.

SAS 컨설턴트의 주업무는 아니지만 사이트 간 VPN이 액세스 측면에서 가장 중요한 표준이라는 사실을 알고 있어야 합니다.

• 기업 환경부터 클라우드까지
• 클라우드 자산의 온프레미스 동시 접근 가능성

혹은 인터넷의 랜덤 시스템으로 AD 또는 데이터베이스와 통신할 수 있습니다.

마지막으로, 모든 VPC에는 기본적으로 네트워크에서 송수신 되는 트래픽 모두에 적용되는 묵시적 방화벽 규칙이 함께 제공됩니다.

기본적으로 외부에서는 SSH 및 RDP 액세스만 허용되며 동일한 서브넷에 있는 인스턴스 간의 내부 통신은 제한 없이 허용됩니다.

묵시적인 기본 규칙을 사용하여 모든 송신 트래픽이 허용되므로 임의로 변경할 수 없습니다.  제한적으로 이를 재정의할 수 있습니다.

또한 GCP는 방화벽 규칙에 관계없이 항상 일부 트래픽을 차단합니다.

GCP의 스토리지

사용 가능한 솔루션

CAS 성능의 다른 중추 영역은 I/O 속도입니다. SAS 런타임은 항상 I/O 디스크 집약적인 애플리케이션이었고 Viya SPRE 및 CAS에서도 여전히 그렇습니다. SAS가 데이터를 읽고 쓸 수 있는 속도가 개선될 수록 분석 처리 소요시간 또한 단축됩니다.

현재 GCP에는 Compute Engine 인스턴스에 사용할 수 있는 4가지 스토리지 솔루션이 있습니다.

• 영역 내 표준 영구 디스크 및 영역 내 SSD 영구 디스크: 효율적이고 안정적인 블록 스토리지
• 지역 영구 디스크 및 지역 SSD 영구 디스크: 두 영역 내 복제된 지역 블록 저장소
• 로컬 SSD: 고성능 임시 로컬 블록 스토리지
• 클라우드 스토리지 버킷: 저렴한 객체 스토리지

출처: https://cloud.google.com/compute/docs/disks/

SAS 배포의 경우 표준 영구 디스크, SSD 영구 디스크 및 로컬 SSD를 유심히 살펴보아야 합니다. 지역 영구 디스크는 특정 DR 요구 사항을 충족하도록 설계되었으며 클라우드 스토리지 버킷(AWS S3 상당)은 아직 SAS 또는 Viya가 지원되지 않습니다.

처리량

SAS의 I/O 패턴은 대규모 읽기 및 쓰기에 속하며 제한 요소는 처리량입니다.

영구 디스크 작업에는 vCPU 수에 따라 송신 네트워크 트래픽이 제한됩니다. 그러므로 영구 디스크 쓰기 작업은 인스턴스의 네트워크 송신 한도로 제한됩니다. SSD 영구 디스크는 vCPU 수가 많은 인스턴스에서 IOPS 및 처리량의 더 높은 성능을 보입니다.

또한 처리 성능은 특히 대용량 읽기 및 쓰기의 경우 디스크 크기에 따라 상이합니다. 예를 들어 7200RPM SATA 드라이브와(일반적으로 120MB/s 달성) 동일한 성능을 보유하려면 최소 1TB의 표준 영구 디스크 또는 SSD 영구 디스크용 250GB가 필요합니다.

하단 테이블은 GCP 문서에서 발췌하였으며 최대 지속 처리량에 대한 아이디어를 제공합니다(.큰 볼륨 크기 및 가장 높은 인스턴스 유형 사용)

CAS는 디스크 I/O에 덜 민감하지만(데이터 로드 단계 중 CAS 디스크 캐시 상호 작용, 중간 테이블 생성 또는 메모리가 과도하게 커밋될 때 페이징을 제외하고 대부분 메모리에서 작동함) 이러한 값은 분명 한계점을 만들 수 있습니다. SAS 9 I/O 집약적 솔루션의 경우 코어당 100 또는 150MB/s에 해당하는 가본 요구 사항이 충족되지 않을 가능성이 높습니다.

로컬 SSD 드라이브는 가상 머신 인스턴스를 호스팅하는 서버에 물리적으로 연결됩니다. 표준 영구 디스크 또는 SSD 영구 디스크보다 처리량이 높고 지연 시간이 짧습니다.

각 로컬 SSD의 크기는 375GB이지만 인스턴스당 총 로컬 SSD 스토리지 공간 3TB에 대해 최대 8개의 로컬 SSD 장치를 연결할 수 있습니다. 디스크 인터페이스는 SCSI(기본값) 또는 NVMe(신규)일 수 있습니다. NVMe는 일반적으로 더 빠르나 모든 이미지에 최적화된 드라이버가 있지 않을 수 있습니다.

따라서 로컬 SSD 드라이브는 SASWORK/SASUTIL 및 잠재적으로 CAS_DISK_CACHE와 같이 높은 I/O 처리량이 필요한 임시 저장 위치에 적합합니다. 비록 시스템이 재부팅될 때마다 임시 드라이브를 포맷, 스트라이프, 및 마운트 역할을 위한 스크립트를 작성해야 할지라도 말입니다.

그러나 현재 GCP에는 로컬 SSD 드라이브를 사용할 때 큰 단점이 있습니다. 문서에 명확하게 명시된 바와 같이 로컬 SSD가 있는 인스턴스를 중지하고 다시 시작할 수 없습니다. 따라서 클라우드 비용을 절약하기 위해 야간이나 가동 중지 시간에 컴퓨터를 중지할 계획이 있었다면 이는 불가능합니다.. 머신을 삭제해야만 중지가 가능합니다.

머신을 삭제하는 경우, SSD 드라이브 콘텐츠뿐 아니라 컴퓨터 설정, IP 주소 및 부팅 디스크 콘텐츠도 잃게 됩니다.

임시 스토리지일 뿐만 아니라 전체 인스턴스를 임시로 설정하도록 만듭니다. 고객에게 큰 데미지가 될 수 있습니다.

빠른 SSD 드라이브를 사용하는 방법은 (사용하지 않을 때 비용을 절감할 수 있는 유연성을 유지하면서) 재구축/재배포를 완전히 자동화하는 것입니다. Ansible 배포 플레이북 덕분에 CAS 작업자와 같은 작업에서는 가능하지만 SPRE 또는 SAS 9 서버와 같은 작업에서는 쉽지 않습니다.

(해당 내용에 대해 알려주신 Ekaitz Goienola에게 감사드립니다)

SAS Viya에 대한 스토리지 권장 사항

일반적으로 스토리지 선택은 필요한 공간과 애플리케이션에 필요한 성능 특성에 따라 결정됩니다.

다음은 I/O 프로필 환경에 따라 SAS Viya 배포를 위한 SAS Viya의 다양한 스토리지 권장 사항입니다.

스토리지 공간	머신	GCP 스토리지 솔루션	참고
SAS 바이너리 및 구성 (/opt/sas/viya)	모두	영역 내 표준 영구 디스크	빠른 저장은 필요하지 않고 지속성은 필요한 경우
SASDATA 위치	SAS Programming Runtime (SPRE)	영역 내 SSD 영구 디스크	디스크 및 vCPU가 추가 된 vCPU를 자긴 인스턴스는 최대 처리량 또한 증가합니다.
CAS Data directory	CAS Controller	영역 내 SSD 영구 디스크
SASWORK, SASUTIL	SAS Programming Runtime (SPRE)	로컬 내 SSD / 영역 내 Zonal SSD 영구 디스	로컬 SSD의 경우 각 인스턴스에 대한 IO 처리량을 얻으려면 최소 4개, 가급적이면 8개를 함께 스트라이프해야 합니다.* 스트라이프 SSD에 배치할 때 SAS WORK 및 SAS UTILLOC는 단일 파일 시스템을 공유해야 합니다.
CAS 디스크 캐시	CAS Nodes	로컬 SSD

(*) 로컬 SSD 디바이스에서 패리티를 사용하거나 RAID 수준을 미러링하는 것은 실질적인 안정성이나 중복성에 따른 장점을 가져오지 않기 때문에 RAID0을 사용합니다. 자세한 사항은 여기를 클릭하여 확인하실 수 있습니다.

마지막으로, 인프라가 SAS IO 테스트 도구를 실행하는 SAS I/O 처리량 요구 사항을 충족하는지 확인하거나 CAS 작업자의 병렬 IO 읽기 및 쓰기를 실제로 벤치마킹하는 더 나은 ansibilized 버전인지 항상 확인하는 것이 좋습니다.

결론

고객이 구글 클라우드에 SAS Viya를 배포할 계획인 경우 이 포스팅이 도움이 되었기를 바랍니다.

클라우드 세계의 좋은 점 중 하나는 도전할 과제가 있다는 것입니다.

예를 들어, 잘못된 머신 유형을 선택한 것은 큰 문제가 아니며 머신을 폐기하거나 고객에게 새 머신을 주문하도록 요청하고 데이터 센터에서 배송되어 케이블로 연결될 때까지 기다릴 필요가 없습니다. 이미 설치된 Viya 서비스를 중지한 다음 VM을 멈춘 후에 인스턴스 유형을 변경한 다음 재시작하면 됩니다.

(특히 GCP에서) 할 수 있는 쉬우면서도 멋진 작업은 전체 배포 프로세스를 자동화하는 것입니다. 머신 프로비저닝('gcloud' 명령, Cloud Deployment Manager 또는 ansible 'gce' 모듈 사용), 배포(예: 사전 요구 사항 및 Viya 설치의 경우 Viya ARK 포함), 최대 데이터 로드 및 "콘텐츠" 전달 단계까지 전부말입니다.

자동화된 프로세스 구현은 인프라 유연성을 크게 개선하고 다음과 같은 클라우드 모델의 이점을 누릴 수 있습니다.

• 다양한 사이징 조정 옵션을 벤치마킹합니다. 예를 들어 제품 및 사용 사례에 따라 CAS 작업자는 적지만 더 강력할 수 있습니다. CAS 셔플 작업 중 네트워크 데이터 전송량을 줄일 수 있습니다
• 필요하지 않은 경우 전체 인프라를 삭제하고, 필요할 때만 자동으로 재구축하여 인프라 비용을 줄입니다 (예: 많은 작업자에 대한 월간 예측 실행)
• SAS Viya 요구 사항과 일치하는 새 인스턴스 유형이 출시되면 이를 쉽게 활용할 수 있습니다
• 기타 등등
• 긴 글을 읽어주셔서 감사드리며 리뷰 및 귀중한 말씀을 나눠주신 Erwan Granger, Mike Goddard, Simon Williams, Margaret Crevar, Mark Schneider께 특별한 감사 인사 드립니다.