성능 및 구성 고려 사항

비교 분석

Oracle Cloud Infrastructure 는 Oracle Cloud에서 Hadoop 클러스터를 실행하는 데 관심이 있는 기업용 성능과 비용 이점을 모두 제공합니다.

TeraSort는 Hadoop의 일반적인 벤치마크로서, 클러스터의 모든 요소(컴퓨트, 메모리, 스토리지, 네트워크) 를 활용하여 무작위 데이터 세트를 생성, 매핑/축소 및 검증하기 때문입니다.

300 OCPU 및 HDFS 스토리지에 대해 사용된 블록 볼륨에 정규화된 Oracle Cloud Infrastructure 클러스터 1개 특정 분석에서는 Oracle Cloud Infrastructure 이 3배 더 빠른 시간을 실행했으며 경쟁사의 클라우드에서 현재 배포보다 비용 80% 이상 제공한다는 것을 발견했습니다.

다음 차트는 이 10Tb TeraSort를 정규화된 클러스터 크기로 실행할 때 다양한 Oracle Cloud Infrastructure 구성의 전반적인 성능을 보여줍니다.

다음은 comparison-terasort-phase-cpu.png에 대한 설명입니다.

Comparison-terasort-phase-cpu.png 그림에 대한 설명

Oracle Cloud Infrastructure 는 Intel 및 AMD cpu와 함께 표준 베어메탈 컴퓨트 인스턴스뿐만 아니라 특수한 HPC 옵션을 제공합니다. 차트에 표시되는 특수 HPC 클러스터는 이러한 인스턴스의 코어 수가 더 적더라도 Intel 및 AMD 카운터보다 더 빠르게 실행되었습니다. 이 클러스터는 더 많은 노드를 사용하여 전체 HDFS 집계 처리량에 직접 영향을 미치는 동일한 정규화된 OCPU 수를 달성하기 때문에 주로 발생합니다.

또한 HPC 구성은 100 GBps 네트워크 기능을 활용하여 클러스터 내 데이터 전송 속도를 높일 수 있습니다.

다음 그림은 Cloudera를 실행하고 클러스터의 10개 작업자 노드로 정규화되는, 블록 볼륨 및 베어메탈 NVMe와 VM-based 근로자의 성능을 비교합니다.

다음은 comparison-terasort-vm-bm-performance.png에 대한 설명입니다.

그림 comparison-terasort-vm-bm-performance.png에 대한 설명

작업자 VM 크기를 8개에서 16코어 사이로 늘리는 성능이 더욱 효율적이므로 VM 네트워크 처리량이 기본 물리적 NIC의 분명한 공유이기 때문입니다. 로컬 NVMe를 사용한 베어메탈 이점도 분명합니다. 클러스터는 25GB 네트워크 인터페이스와 결합된 로컬 NVMe 저장소의 고속을 활용합니다.

Hadoop 클러스터에서 계산에 활용할 구성을 결정하면 Hadoop isv 간에 일관성을 유지할 수 있습니다.

컴퓨트 인스턴스 선택

이 섹션에서는 각 노드 롤에 대한 모양을 선택할 때 최적의 방법을 제공합니다.

마스터 노드

마스터 노드는 Cloudera, Hortonworks 및 Apache Hadoop 배포에만 적용할 수 있습니다. 기본적으로 MapR는 클러스터 서비스를 작업자 노드와 분리하지 않습니다. Oracle은 클러스터 및 서비스 관리의 오버헤드를 지원하기 위해 마스터 노드에 적합한 메모리 밀도를 사용할 것을 권장합니다. 마스터 노드는 Zookeeper, NameNode, JournalNode, Resource Manager, HBase, Spark 및 클러스터 관리(Cloudera Manager 및 주황색) 서비스를 실행합니다.

최소 구성: VM.Standard2.8
권장 구성: VM.Standard2.24

작업자 노드

작업자 노드는 모든 Hadoop isv와 Apache 간에 일치합니다. 작업 로드 요구 사항을 충족하기에 적합한 경우 근로자 노드에 대한 모양을 조정하십시오. 이 기능은 많은 고객이 Spark 기반 작업 부하에서 사용할 합산 메모리를 찾고 있기 때문에 컴퓨트 및 메모리 요구 사항에 모두 적용할 수 있습니다. 기존 맵/작업 부하를 줄이면 작업자 노드의 메모리 풋 프린트가 늘어날 수도 있습니다.

최소 구성: VM.Standard2.8
권장 구성: BM.DenseIO2.52

지원 노드

지원 기반 구조에는 보조 클러스터 서비스나 사용자정의 애플리케이션 코드를 실행할 수 있는 모서리 노드나 다른 노드가 포함됩니다. 이러한 노드에 대한 요구 사항은 배율 및 사용 사례에 따라 다릅니다. 모서리 노드의 경우 최소 VM.Standard2.2. 크기를 권장합니다. 모서리 노드당 사용자 수에 따라 이 값을 확대합니다. 사용자가 클러스터와 상호 작용할 수 있도록 결함 도메인 간에 HA를 위한 다중 에지 노드를 만드는 것이 좋습니다.

네트워크 고려 사항

Hadoop는 클러스터 내 트래픽의 네트워크에 크게 종속됩니다. 따라서 클러스터 토폴로지의 각 역할에 대해 배포하도록 선택한 구성은 클러스터 내 연결에 직접적인 영향을 미칩니다.

베어메탈 구성을 사용할 때 컴퓨트 호스트는 전체 25Gb의 vnic(가상 네트워크 인터페이스 카드) 를 사용할 수 있습니다. VM 구성은 컴퓨트 크기에 맞게 크기가 조정됩니다.

HDFS 용량에 대해 블록 볼륨을 사용할 때는 블록 볼륨에 대한 i/o 트래픽이 응용 프로그램 트래픽과 동일한 VNIC를 공유한다는 점에 유의하십시오(기본값). 베어메탈 구성을 사용할 때 이를 최적화하는 한 가지 방법은 두번째 물리적 인터페이스에서 클러스터 연결에 사용할 보조 VNIC를 만드는 것입니다. 이렇게 하면 블록 볼륨 트래픽만을 위해 기본 VNIC를 예약하므로 네트워크 사용률이 최적화됩니다.

다음 다이어그램은 이 개념을 보여줍니다.

그림 architecture e-vnic.png에 대한 설명

블록 볼륨을 사용할 때 각 작업자 노드와 연관된 블록 볼륨의 수량 및 크기와 직접 연관된 HDFS i/o 집계도 고려합니다. 필요한 HDFS 용량을 얻기 위해 Oracle은 적은 수의 대형 볼륨이 아닌 작업자당 더 많은 수의 볼륨을 확장할 것을 권장합니다.

스토리지 고려 사항

Hadoop 배포의 경우 두 가지 유형의 스토리지를 HDFS 용량으로 사용할 수 있습니다(로컬 NVMe 및 블록 볼륨을 포함하는 DenseIO 구성). MapR 배포의 경우 데이터 계층에 대한 라이센스가 없으면 근로자 노드(동종) 에 대해 단일 스토리지 유형을 선택해야 합니다. 다른 Hadoop isv는 추가적인 라이센스 비용 없이 중요한 스토리지(DenseIO NVMe 및 블록 볼륨 혼합) 를 지원합니다.

지원되는 업체 저장 영역 구성

Cloudera 및 Horton은 Hadoop와 함께 사용할 수 있도록 Oracle Cloud Infrastructure 상에서 모든 형태의 스토리지를 지원합니다.

DenseIO 상의 로컬 NVMe
블록 볼륨
오브젝트 스토리지(S3 호환성 사용)

Cloudera는 로컬 NVMe 및 HDFS에 대한 블록 볼륨으로 구성된 배치에 대한 데이터 계층화(유형이 다른 스토리지) 를 지원합니다.

MapR 배포는 DenseIO 모양의 로컬 NVMe 또는 배포를 위해 블록 볼륨을 활용할 수 있습니다.

오브젝트 스토리지: MapR XD 객체 계층화 를 참조하십시오.
MapR는 추가 라이센스 없이 유형이 다른 스토리지를 지원하지 않습니다.

Oracle Cloud Infrastructure 의 모든 스토리지 형식은 HDFS 커넥터를 활용하는 Object Storage를 비롯한 Apache Hadoop에서 사용할 수 있습니다.

DenseIO NVMe

DenseIO NVMe는 Oracle Cloud Infrastructure 의 Hadoop에 대해 가장 우수한 저장 영역 옵션입니다. HDFS에서 사용할 수 있는 고속 로컬 NVMe 드라이브는 베어메탈 및 가상 머신 구성에서 모두 사용할 수 있습니다.

로컬 NVMe를 사용할 경우 Oracle은 데이터 중복성을 위해 DFS 복제를 세 개의 복제본으로 설정할 것을 권장합니다.

또는 Cloudera 클러스터의 경우, 구체화 해제를 사용하여 특정 유형의 데이터에 대한 스토리지 효율성을 높이는 것이 좋습니다.

블록 볼륨

Oracle Cloud Infrastructure 의 블록 볼륨은 뛰어난 성능 옵션으로, HDFS 용량에 대한 유연한 구성을 제공합니다. 블록 볼륨은 네트워크에 연결된 스토리지로, I/o에 대해 VNIC 대역폭을 사용합니다. 또한 블록 볼륨은 구성된 크기(GB당) 를 기준으로 IOPS 및 MB/초 단위로 확장됩니다. 개별 블록 볼륨 처리량은 최대 320Mb/s(700gb 이상 볼륨) 에 기록됩니다.

다음 표에서는 700Gb 볼륨을 사용하는 단일 작업자 노드에 대한 처리량 확장을 보여줍니다.

블록 볼륨	집계 처리량(GB/s)
3	0.94
4	1.25
5	1.56
6	1.88
7	2.19
8	2.50
9	2.81
10	3.13
11	3.44

Oracle는 11개 블록 볼륨 뒤에 추가 블록 볼륨을 추가하는 작업으로 인해 처리량이 발생하는 것을 발견했습니다.

Vm을 작업자 로 사용하는 경우 블록 볼륨 트래픽이 Hadoop(응용 프로그램) 트래픽과 동일한 VNIC를 공유한다는 점에 유념하십시오. 다음 표는 Oracle Cloud Infrastructure 구성을 선택할 수 있도록 권장 최대 블록 볼륨 및 측정된 VNIC 대역폭을 보여 줍니다. 여기에는 디스크 i/o 상단에 애플리케이션 트래픽을 지원할 수 있는 충분한 추가 대역폭을 제공합니다.

Oracle Cloud Infrastructure 구성	VNIC 대역폭	HDFS에 대해 제안된 최대 블록 볼륨
BM.DenseIO2.52	25Gbps	11
BM.Standard2.52	25Gbps	11
VM.Standard2.24	24.6Gbps	6
VM.Standard2.16	16.4Gbps	4
VM.Standard2.8	8.2Gbps	3

HDFS 용량에 블록 볼륨을 사용하는 경우 HDFS 대상 용량을 얻기 위해 근로자당 적은 수의 대형 블록 볼륨이 아닌 더 많은 수의 작은 블록 볼륨을 사용하는 것이 좋습니다.

HDFS에 대해 최소 3개의 작업자 노드를 700gb 블록 볼륨 크기로 사용하는 예는 다음과 같습니다.

다음은 block-volume-hdfs-capacity-chart.png에 대한 설명입니다.

Block-volume-hdfs-capacity ty-chart.png 그림에 대한 설명

근로자당 세 개의 블록 볼륨이 최소 요구사항입니다. Oracle은 필요한 HDFS 용량에 맞게 블록 볼륨 수량 및 크기를 확장할 것을 권장합니다. 작업자당 블록 볼륨을 더 많이 이해하면 사용 가능한 전체 집계 HDFS 대역폭이 증가합니다. 이 작업은 클러스터에서 더 많은 집계 I/o를 필요로 하는 처리량이 많은 작업량에 특히 중요합니다.

또한 영구 클러스터에서 성장 또는 리팩토링에 대한 추가 오버헤드를 남는 것이 중요합니다.

로깅 및 응용 프로그램 데이터

HDFS에 대한 블록 볼륨을 사용할 때 Hadoop 로그 및 애플리케이션 데이터(Cloudera Parcels, NameNode 및 Journal 메타데이터) 에서 사용할 일부 블록 볼륨을 예약해야 합니다. 이 데이터를 수용하도록 OS 볼륨을 확장할 수 있지만 이 용도로 전용 블록 볼륨을 사용하는 것이 더 좋습니다. 블록 볼륨은 마스터 노드에 대한 인스턴스 유형을 변경하려는 경우 이동성을 높이고, 특정 데이터 위치에 대한 I/o 성능이 더 필요한 경우 유연성을 향상시킵니다. 인스턴스에 몇 개의 블록 볼륨을 추가하고, RAID 배열을 만들며, 기존 데이터를 마이그레이션하면 예비 볼륨 연결을 사용할 수 있을 때 훨씬 더 쉽습니다.

HDFS의 경우에도 마찬가지입니다. 더 많은 블록 볼륨을 추가하는 오버헤드가 필요한 경우 작업자를 압축 해제하고, 더 큰 디스크로 이러한 볼륨을 재생성하고, 클러스터에 다시 추가하고, HDFS의 균형을 조정하는 것보다 훨씬 쉽습니다. 두 방법 모두 적합합니다. 즉, 클러스터 작업 부하에서 데이터 처리량을 지원하기 위해 블록 볼륨을 완전히 보완해야 하는지 여부는 됩니다. 이 경우 보다 빠른 NVMe 스토리지로 근로자를 베어메탈 고밀도 IO 구성으로 전환하고, 데이터 계층화를 통해 종종 저장소 모델을 사용하는 것이 좋습니다.

객체 스토리지

객체 스토리지 통합은 Apache Hadoop를 비롯한 모든 Hadoop isv에서 가능합니다. Oracle Cloud Infrastructure 에는 Apache Hadoop과 호환되는 고유 HDFS Connector가 있습니다. Hadoop ISVs(Cloudera, Hortonworks 및 MapR) 목록에는 오브젝트 스토리지 통합에 대한 외부 엔드포인트가 허용되며 오브젝트 스토리지 통합을 위한 S3 호환성 사용이 올바르게 수행되어야 합니다.

한 가지 주의 사항은 S3 호환성이 테넌시 홈 영역에서만 작동한다는 것입니다. 즉, 오브젝트 스토리지와 통합한 경우 Hadoop 클러스터는 동일한(홈) 영역에도 배치되어야 합니다.

또 다른 경고는 오브젝트 스토리지를 사용하여 클러스터에 데이터를 푸시하거나 가져올 때 HDFS가 캐싱 계층으로 사용되지 않는다는 것입니다. 실제로 OS 파일 시스템은 오브젝트 스토리지와 HDFS 간에 데이터가 캐시되는 위치입니다. 대용량 데이터가 클러스터 HDFS와 오브젝트 스토리지 간에 앞뒤로 이동하는 경우 이 데이터 이동을 지원하기 위해 OS에서 블록 볼륨 캐싱 계층을 만드는 것이 좋습니다.

다음 그림은 작업자 노드에 대한 데이터 계층과 함께 S3 데이터 이동을 지원하는 일반적인 분할 영역 다이어그램을 보여줍니다.

다음은 object-storage-partitioning-throughput.png에 대한 설명입니다.

그림 object-storage-partitioning-throughput.png에 대한 설명

데이터 계층

Apache Hadoop, Cloudera 또는 Hortonworks를 사용하여 강력한 데이터 계층화(이종) 저장소 모델을 만들 때 앞의 모든 저장소 옵션을 결합할 수 있습니다. 또한 데이터 라이프사이클 관리를 사용하여 데이터 중단으로 한 스토리지 계층의 데이터를 푸시하고 HDFS 스토리지 비용을 최적화할 수 있습니다.

다음 링크를 누르면 데이터 수명 주기 계층 png에 대한 설명을 볼 수 있습니다.

그림 data-lifecycle-tiering.png에 대한 설명

방화 제작

Hadoop 3.0에서는 HDFS 배치에서 EC(지우기 코딩) 가 지원됩니다. EC는 패리티 셀에 의해 강화된 단일 복사본으로 데이터를 저장하여 로컬 HDFS 데이터에 대한 스토리지 요구사항을 줄입니다. HDFS 토폴로지에서는 해당 태그가 지정된 위치에 저장된 모든 데이터에 대해 이 기능을 사용으로 설정하는 EC 태그가 지정될 수 있습니다. 이를 통해 EC-tagged HDFS 데이터에 대한 원시 스토리지 요구사항을 효율적으로 줄여 스토리지 효율성을 높일 수 있습니다.

EC 관련 몇 가지 경고가 있습니다.

EC를 사용하려면 최소 작업자 노드 수가 필요합니다.
EC 태그가 지정된 데이터에 대해 데이터 지역성이 손실되었습니다.
EC는 자주 액세스되지 않는 중간 크기의 파일에 적합합니다. 소규모 파일과 자주 액세스하는 파일에는 효과가 없습니다.
EC는 기존(3x) 복제와 유사한 데이터에 비해 이름 노드 메타데이터에 있는 블록 객체 수를 늘립니다.
EC 데이터 복구에는 클러스터에서 계산이 필요합니다(패리티 재구축). 이 복구 시간은 기존(3x) 복제된 데이터보다 깁니다.

성능 모니터링

Oracle Cloud Infrastructure Monitoring 서비스를 사용하면 측정 단위 및 알람 기능을 사용하여 클라우드 리소스를 적극적으로 모니터링할 수 있습니다. 성능 또는 용량 임계값을 적중할 때 알람을 설정하면 Oracle Cloud Infrastructure 기본 툴을 활용하여 기반구조를 관리하는 것이 매우 좋습니다.

참조 아키텍처

이 항목에서는 각 Hadoop ISV에 대한 참조 자료를 제공합니다. 다음 참조 아키텍처 및 Bom은 Oracle Cloud Infrastructure 에서 Hadoop의 공급업체 지원 배치에 필요한 최소 풋 프린트를 반영합니다.

오픈 소스 프로젝트인 Apache Hadoop 배치에는 공급업체에서 제공한 최소 필수 풋 프린트가 없습니다. Oracle은 최소 Apache 배치에 적합한 안내로 여기에 표시된 Hortonworks 배치를 사용할 것을 권장합니다.

Cloudera

그림 architecture e-cloudera.png에 대한 설명

Cloudera를 사용한 Hadoop 배치에 대한 최소 요구 사항은 다음과 같습니다.

롤	수량	권장 컴퓨트 구성
에지	1	VM.Standard2.4
Cloudera Manager	1	VM.Standard2.16
마스터 노드	2	VM.Standard2.16
작업자 노드	3	BM.DenselO2.52

이 최소 배치에서는 Cloudera Manager 노드도 마스터 서비스를 실행합니다.

Oracle Cloud Infrastructure 에 Cloudera를 배치하려면 자체 라이센스가 있어야 합니다. 모든 소프트웨어 지원은 Cloudera를 통해 수행됩니다.

Hortonworks

그림 architecture e-hortonworks.png에 대한 설명

Hortonworks를 사용하는 Hadoop 배치를 위한 최소 요구 사항은 다음과 같습니다.

롤	수량	권장 컴퓨트 구성
에지	1	VM.Standard2.4
주황색	1	VM.Standard2.16
마스터 노드	2	VM.Standard2.16
작업자 노드	3	BM.DenselO2.52

이 최소 배치에서는 주황색 노드도 마스터 서비스를 실행합니다.

Oracle Cloud Infrastructure 에서 Hortonworks 배치를 위해서는 자체 라이센스를 가져와야 합니다. 모든 소프트웨어 지원은 Hortonworks를 통해 수행됩니다.

MapR

그림 architecture e-mapr.png에 대한 설명

MapR를 사용한 Hadoop 배포에 대한 최소 요구사항은 다음과 같습니다.

롤	수량	권장 컴퓨트 구성
에지	1	VM.Standard2.4
데이터 노드	3	BM.DenselO2.52

Oracle Cloud Infrastructure 에 MapR를 배포하려면 자체 라이센스를 가져와야 합니다. 모든 소프트웨어 지원은 MapR를 통해 수행됩니다.

Terraform 배치

이 솔루션의 [다운로드 코드] 섹션에서 각 Hadoop ISV에 대한 Terraform 템플리트를 찾을 수 있습니다.

Cloudera 및 Hortonworks 저장소에는 Oracle Resource Manager 호환 템플리트가 있습니다. 리소스 관리자에만 해당됩니다. 기본(마스터) 분기에는 독립형 Terraform 템플리트가 포함되어 있습니다. Cloudera 및 Hortonworks 리소스 관리자 템플리트에는 각 템플리트에 대한 Terraform 변수를 쉽게 채우는 YAML 스키마도 포함되어 있습니다. 이는 사용 사례에 대해 사용자가 정의할 수 있는 드롭다운 UI 선택을 제공하며, 기본적으로 각 템플리트를 허용 가능한 모양 옵션 및 보안/구성 설정으로 채울 수 있습니다.