Oracle Cloud Infrastructure 에 Hadoop 배포 시 고려 사항
Hadoop를 실행하는 여러 고객은 클라우드로 마이그레이션을 탐색할 때 다음과 같은 질문이 있습니다.
- Hadoop를 클라우드에 배치 또는 이전하려면 어떻게 해야 합니까?
- 클라우드에서 Hadoop를 보호하려면 어떻게 해야 합니까?
- 클라우드에서 Hadoop에 대한 HA 및 DR은 어떻게 구현합니까?
- 온프레미스와 비교하여 클라우드에서 Hadoop 배포와 유사한 성능을 어떻게 실현합니까?
- 여러 환경을 배포하는 동안 비용을 추적하고 관리하려면 어떻게 해야 합니까?
이 기사는 이러한 질문에 대한 Oracle Cloud Infrastructure 의 답변을 제공합니다.
배치
Oracle의 IaaS(서비스형 기반 구조) 에 가입할 경우 연관된 모든 컴퓨트, 스토리지 및 네트워크 서비스에 액세스할 수 있습니다. Oracle Cloud Infrastructure 의 배치는 각 Hadoop 배포에서 동일한 버전 및 기능을 사용할 수 있다는 점에서 온-프레미스 배포와 비슷합니다.
Teraform 및 리소스 관리자
Oracle Cloud Infrastructure 엔지니어링 팀은 각 Hadoop ISV와 협력하여 Terraform를 활용하는 배포를 사용으로 설정했습니다. Terraform를 사용하면 기반구조를 코드(IaC) 로 배치할 수 있으며, 네트워킹에서 Hadoop 생태계의 모든 요소(가상 클라우드 네트워크, 서브넷, vnic) 및 보안 액세스 제어 목록을 포함하여 컴퓨트 및 스토리지 프로비전을 수행할 수 있습니다. Terraform는 유연성 있고 확장성이 높고 여러 클라우드 제공업체의 표준입니다.
이러한 템플리트를 Oracle Cloud Infrastructure 에 Hadoop을 배포하기 위한 프레임워크로 사용할지 또는 온프레미스에서 사용한 기존 배포 툴링으로 유지할지 선택할 수 있습니다. 두 가지 방법이 모두 적합합니다.
Terraform를 사용하여 Hadoop를 배치하려면 Oracle Resource Manager 사용을 고려하십시오. 리소스 관리자를 사용할 때 얻을 수 있는 주요 이점은 다음과 같습니다.
- Terraform 상태 메타 데이터는 가용성이 높은 위치에 보관됩니다.
- 다른 Oracle Cloud Infrastructure 서비스에 포함된 동일한 보안 및 감사 도구로 리소스 관리자에 대한 액세스를 관리할 수 있습니다.
- 리소스 관리자는 Oracle Cloud Infrastructure 에 배치하기 위해 Terraform 구성과 연관된 복잡성을 제거합니다.
리소스 관리자 인터페이스는 스택 변수에 필요한 값으로 채워진 Aml 기반 스키마 파일을 지원합니다. 이를 통해 스택의 각 변수에 허용되는 구성, 소프트웨어 버전 및 기타 매개변수를 정의할 수 있습니다.

Resource-manager-ui.png에 대한 설명
스키마 파일이 채워지면 값이 사용하기 쉬운 UI에 표시됩니다. 스키마 파일을 사용하면 사용자가 입력을 입력하거나 붙여 넣을 수 있는 사용자 정의 입력 필드뿐만 아니라 이러한 값이 있는 드롭다운 목록이 제공됩니다.
스키마 파일의 필드도 종속성을 가질 수 있으므로 사용자가 한 필드에서 값을 선택하면 해당 선택 사항에 따라 다른 필드가 표시되거나 숨겨집니다.
클러스터 서비스 토폴로지
Hadoop을 배치할 때는 클러스터 서비스 토폴로지를 노드 롤에 매핑하는 것이 좋습니다.
노드 유형 | Hadoop 역할 | Hadoop 서비스 |
---|---|---|
에지 | Perimiter에서 사용자 액세스 | 클라이언트 라이브러리, Oozie |
유틸리티 | 클러스터 관리 | Cloudera Manager, Ambari, 메타데이터 데이터베이스 |
마스터 | 코어 클러스터 서비스 | Zookeeper, NameNode, JournalNode, HIVE, HBase Master, Spark History, Job History, Resource Manager, HTTPFS, SOLR |
작업자 | 작업 로드 실행, 데이터 저장 영역 | HDFS, NodeManager, Region Server, Kafka Broker, Spark Executor, Map/Reduce |
해당 롤에 사용할 컴퓨트 구성을 선택할 때 이 솔루션의 뒷부분에 모범 사례가 설명되어 있습니다. 또한 다음 조건을 고려하십시오.
- 클러스터를 사용할 동시 사용자 수는 몇 개입니까?
동시 사용자 수를 기준으로 수량 및 OCPU에서 모두 모서리 노드를 확장해야 합니다. OCPU당 두 개의 동시 사용자가 적합한 지침으로 사용자당 하나의 스레드를 허용합니다. 결함 도메인에 대한 추가 모서리 노드도 중복성을 제공합니다.
- 특정 Spark 또는 HBase 영역 서버 메모리 요구 사항이 있습니까?
이러한 요구사항은 근로자 노드의 수량 및 작성에 직접 영향을 줍니다. HBase의 크기를 조정하려면 기본 애플리케이션에 대한 이해가 필요하며, 이는 다양합니다. 대부분의 고객은 HBase 배치 요구 사항을 이미 알고 있습니다. 특히 서버당 할당된 영역 서버 및 메모리 수입니다. Spark 작업 로드에는 작업자 노드 수에 작업자당 사용 가능한 메모리를 곱하여 달성된 집계 메모리 대상이 있습니다.
- 특정 HDFS 용량 요구 사항이 있습니까?
대부분의 고객에게는 이 요구 사항이 적용됩니다. 그러나 많은 수의 베어메탈 DenseIO 작업자 노드에서 확장 전에 이 솔루션에서 나중에 설명된 대로 블록 볼륨에 의해 NVMe 기반 HDFS를 보완하여 필요한 HDFS 밀도를 달성하는 것이 좋습니다. Oracle은 HDFS 요구사항을 이해할 것을 권장합니다. 또한 비용을 최소화하면서 두 대상을 모두 적중하기 위해 클러스터를 "올바른 크기” 할 수 있습니다.
마이그레이션
Hadoop를 실행하는 고객이 Oracle Cloud Infrastructure 에 배포할 수 있는 경우 일반적으로 마이그레이션할 대량의 데이터가 있습니다. 이 데이터는 데이터베이스에 있는 지원 클러스터 메타데이터와 함께 HDFS에 대량으로 존재합니다.
인터넷을 통해 직접 HDFS 데이터를 복사하면 다음과 같은 여러 가지 이유로 인해 문제가 발생할 수 있습니다.
- 데이터 볼륨이 너무 크거나 사용 가능한 대역폭이 너무 제한적이어서 의미 있는 시간 프레임 동안 회선 중인 데이터 복사본을 지원할 수 없습니다.
- 데이터가 중요하며 인터넷을 통한 복사가 거버넌스 또는 규정 요구사항에 의해 허용되지 않을 수 있습니다.
- 온-프레미스 클러스터 리소스에는 제한이 있으며 데이터 복사는 진행 중인 작업 로드에 영향을 줍니다.
데이터 마이그레이션에 대한 여러 접근법이 지원됩니다. 데이터 링크는 마이그레이션되는 데이터 유형으로 정의됩니다.
HDFS 데이터 이전
Oracle Cloud Infrastructure 에 HDFS 데이터를 복사하는 세 가지 일반적인 방법은 다음과 같습니다.
- 인터넷이나 FastConnect를 통해 VPN을 사용하여 온프레미스 클러스터에서 Oracle Cloud Infrastructure 영역의 오브젝트 스토리지로 직접 데이터를 복사합니다. 이 프로세스가 완료되면 Oracle Cloud Infrastructure 클러스터가 Object Storage의 데이터로 리하이드레이션될 수 있습니다.
- 인터넷을 통해 또는 FastConnect를 사용하여 온-프레미스 클러스터에서 Oracle Cloud Infrastructure 클러스터로 직접 데이터를 복사합니다.
- 데이터를 고객 데이터 센터에 배포하고, 데이터로 채워진 후 Oracle에 배송하고 오브젝트 스토리지로 업로드된 데이터 전송 어플라이언스에 복사합니다. 그러면 Oracle Cloud Infrastructure 클러스터를 이 데이터로 리하이드레이션할 수 있습니다.
이러한 각 방법에 대한 기술 세부 정보는 이 솔루션 후반에 설명되어 있습니다.
메타데이터 마이그레이션
클러스터 메타 데이터는 대체로 HDFS 데이터보다 훨씬 작으며 온-프레미스 클러스터의 데이터베이스에 존재합니다.
클러스터 메타 데이터 이전은 소스 클러스터의 Hadoop 배포와 메타 데이터를 저장하는 데 사용되는 데이터베이스의 두 요인에 따라 달라집니다. 이 데이터의 전송은 단순하고 각 Hadoop 배포에 관련됩니다.
이 솔루션에서 각 Hadoop 분포에 대한 사양이 나중에 표시됩니다.
보안
클라우드의 보안은 Hadoop에서 특히 중요합니다. Oracle Cloud Infrastructure 의 배포가 보안 상태로 유지되도록 하기 위한 여러 가지 방법이 있습니다.
먼저 다음과 같은 일부 Oracle Cloud Infrastructure 관련 보안 제어를 고려합니다.
- IAM(Identity and Access Management) 를 활용하여 클라우드 리소스에 액세스할 수 있는 사용자, 사용자 그룹이 보유한 액세스 유형 및 특정 리소스를 제어합니다. 이 아키텍처는 다음 결과를 제공할 수 있습니다.
- 조직 구조를 기준으로 클라우드 리소스를 안전하게 격리
- 브라우저 인터페이스, REST API, SDK 또는 CLI를 통해 클라우드 서비스에 액세스하도록 사용자를 인증합니다.
- 사용자 그룹에 적절한 클라우드 리소스에 대한 작업을 수행할 수 있는 권한을 부여합니다.
- 기존 Id 제공자와 통합
- 관리자가 리소스에 액세스할 수 있도록 하는 동시에 관리 서비스 제공자(MSP) 또는 SI(시스템 통합기) 가 기반 구조 자산을 관리할 수 있도록 설정합니다.
- 클라우드 서비스에 대해 API 호출을 수행할 수 있도록 애플리케이션 인스턴스에 권한을 부여합니다.
- 가상 클라우드 네트워크(VCN) 의 모든 네트워크에 대한 감사 보안 목록입니다. 이러한 규칙을 가능한 한 제한적으로 만들고 신뢰할 수 있는 트래픽만 인터넷 연결 서브넷으로 허용합니다.
- 인터넷 연결 호스트에서 호스트 방화벽을 사용으로 설정하고 필요한 트래픽만 허용합니다.
- 정기적으로 보안 감사를 사용하는 것이 좋습니다.
암호화는 유휴 상태 데이터와 이동 중인 데이터 모두에 대해 올바른 옵션입니다. 다음 리소스를 고려하십시오.
- Cloudera 암호화 방식
- Hortonworks
- HDFS 암호화 유휴 상태
- 전송 암호화
- MapR 암호화
기타 Hadoop 관련 보안 고려 사항은 다음과 같습니다.
- 전용 IP 주소를 사용하는 서브넷에 클러스터를 배치하여 필요한 api 또는 ui만 인터넷 연결 서브넷에 노출합니다.
- 클러스터 보안을 사용하여 Hadoop 실행
- 에지 노드를 사용하여 SSH 터널링을 통해 클러스터 서비스에 액세스합니다. 이 기능은 Mac 또는 Linux 에도 보다 편리합니다.
- Apache Knox를 활용하여 API 엔드포인트를 보호합니다.
- 클러스터 데이터 및 메타데이터에 대한 역할 기반 접근용 Apache Sentry 또는 Cloudera Navigator를 활용할 수 있습니다.
네트워크 보안
Hadoop의 개방형 특성과 보안 고려 사항으로 인해 대부분의 고객은 전용 서브넷에서 Hadoop 클러스터를 배포하려고 합니다. 그런 다음 에지 노드를 사용하거나, Ui, api 및 서비스 대시보드에 대한 로드 밸런싱 액세스를 사용하거나, 에지 프록시를 통해 FastConnect VPN 또는 SSH 터널링을 통해 직접 액세스하여 클러스터 서비스에 액세스할 수 있습니다.
공용 서브넷은 인터넷 연결 서비스(예: Cloudera Manager 또는 Ambari) 를 실행하는 에지 노드 및 유틸리티 노드에 대해 클러스터 배치를 보완합니다. 전적으로 선택 사항입니다. FastConnect VPN을 활용하고 전체 배포를 온프레미스 네트워크 토폴로지의 확장으로 실행하도록 선택할 수 있습니다. 이렇게 하려면 VCN 레벨에서 연결된 고객 경로 지정 가능 개인 IP 세그먼트만 필요한 다음 Oracle Cloud Infrastructure 에서 적합한 서브넷으로 분할해야 합니다. 액세스는 서브넷 레벨에서 적용되는 보안 목록을 사용하여 제어됩니다. 최적의 방법은 동일한 서브넷에 비슷한 액세스 요구 사항이 있는 리소스를 그룹화하는 것입니다.
서브넷 토폴로지
VCN는 선택한 단일 연속 IPv4 CIDR 블록에 대해 다룹니다. VCN 내에서 클러스터 호스트에 대해 개별 IPv4 서브넷을 배치할 수 있습니다. 각 서브넷에 대한 액세스는 보안 목록에 의해 제어됩니다. 추가 보안은 방화벽의 호스트 레벨에서 제어됩니다.
최적의 방법은 인터넷에서 직접 액세스할 수 없는 전용 서브넷으로 Hadoop 클러스터 리소스를 분리하는 것입니다. 클러스터에 대한 액세스는 공용 서브넷 서브넷의 추가 호스트를 통해 제어되고, 공용 네트워크 세그먼트와 전용 네트워크 세그먼트 간의 트래픽을 제어하는 적절한 보안 목록 규칙을 사용하여 보호되어야 합니다. 이 모델은 Hadoop 클러스터에 가장 적합한 보안을 제공합니다.
- 공용 서브넷은 외부 액세스를 위해 UI 또는 API(예: Cloudera Manager 또는 Ambari) 를 표시해야 하는 에지 노드(사용자 액세스) 및 서비스에 사용할 수 있습니다.
- 전용 서브넷은 클러스터 호스트(마스터, 작업자) 에 사용해야 하며 인터넷에서 직접 액세스할 수 없습니다. 대신 이 경우 공용 서브넷의 중간 호스트가 액세스하려면 공용 서브넷에 있어야 하며, 로드 밸런서는 VPN, FastConnect 또는 SSH 프록시가 직접 액세스해야 합니다.
보안 목록
보안 에는 서브넷 레벨에서 제어 수신 및 송신 트래픽이 나열됩니다. Hadoop의 경우 TCP 및 UDP 트래픽 모두에 대해 클러스터 호스트가 있는 서브넷 간에 무제한 양방향 액세스를 사용하는 것이 좋습니다. 공용 서브넷은 Api 및 ui에 액세스하기 위해 신뢰할 수 있는 포트(및 소스 IP 주소도 가능) 만 허용하도록 매우 제한적인 보안 목록을 가져야 합니다.
고가용성
Hadoop 에는 HA(고가용성) 에 대한 내장 메소드가 있으며 여기에는 포함되지 않습니다. Hadoop 용 Oracle Cloud Infrastructure 를 활용하여 HA 달성을 위한 최적의 방법은 다음과 같습니다.
지역 선택
Oracle Cloud Infrastructure 의 각 영역은 1 ~ 3개의 가용성 도메인으로 구성됩니다. 각 가용성 도메인은 3개의 결함 도메인으로 구성됩니다. 현재 및 비즈니스 리소스(예: 데이터 센터) 에 가까운 홈 영역을 선택하십시오. 선택한 영역의 조합에 따라 단일 가용성 도메인 배치 또는 다중 가용성 도메인 배치를 사용할 수 있는지 여부가 결정됩니다.
단일 가용성 도메인 배치
Oracle은 Oracle Cloud Infrastructure 의 Hadoop 배치에 대해 단일 가용성 도메인 배치를 권장합니다. MapR 배치에서는 이 구조만 지원됩니다. 클러스터 내 트래픽은 낮은 대기 시간과 높은 처리량을 유지 관리하는 로컬 네트워크 세그먼트에 포함되어 있기 때문에 이 배치 모델은 네트워크 측면에서 가장 좋습니다. 가용성 도메인의 리소스는 결함 도메인 간에 스트라이프되어 물리적 기반구조의 HA를 얻습니다.
결함 도메인은 가용성 도메인 내의 하드웨어 및 기반구조에 대한 그룹화입니다. 각 가용성 도메인에는 3개의 결함 도메인이 포함되어 있습니다. 장애 도메인을 사용하면 단일 가용성 도메인 내의 동일한 물리적 하드웨어에 있지 않도록 인스턴스를 배포할 수 있습니다. 한 결함 도메인에 영향을 주는 하드웨어 장애 또는 컴퓨트 하드웨어 유지 관리는 다른 결함 도메인의 인스턴스에 영향을 주지 않습니다.
다중 가용성 도메인 배치
다중 도메인 배치(가용성 도메인 확장) 는 Cloudera 및 Hortonworks 에서만 지원되지만 Apache Hadoop를 사용할 수도 있습니다.
그러나 가용성 도메인에 대한 다음 주의 사항은 다음과 같습니다.
- 클러스터 내 연결은 WAN 세그먼트를 순회해야 하며, 이렇게 하면 대기 시간이 늘어나고 최적의 처리량이 감소합니다. 특히 베어메탈 작업자 노드에서 성능에 대한 측정 가능한 영향을 제공합니다. 더 작은 VM 작업자 노드의 경우 성능에 미치는 영향이 줄어듭니다.
- 모든 Oracle Cloud Infrastructure 영역에서 이 모델을 지원하는 것은 아닙니다.
다음 다이어그램은 작업자 노드 5개와 마스터 노드 3개로 구성된 클러스터를 기준으로 단일 가용성 도메인에서 10Tb TeraSort를 사용할 경우 측정된 성능 영향을 보여 줍니다.

그림 comparison-availability-domain-spanning.png에 대한 설명
가용성 도메인 확장은 단일 영역에 클러스터 서비스의 추가 중복성을 제공합니다. 클러스터 리소스는 각 가용성 도메인에서 결함 도메인을 활용하여 추가 논리적 “랙 토폴로지” 를 수행할 수도 있습니다. 각 결함 도메인은 랙 인식을 위해 “랙” 으로 간주됩니다. 이러한 이점은 다음 다이어그램에 나와 있습니다.

아키텍처 다중 가용성 domains.png에 대한 설명
재해 복구
Oracle Cloud Infrastructure 의 DR(재해 복구) 은 RPO(복구 지점 목표) 및 RTO(복구 시간 목표) 요구 사항에 따라 직접 달라집니다.
RPO 또는 RTO가 실시간으로 근접한 경우 Hadoop의 유일한 옵션은 다른 가용성 도메인 또는 영역에 DR 클러스터를 생성한 다음 프로덕션 및 DR 클러스터 간에 데이터를 복제하는 것입니다. RPO 및 RTO 요구사항이 더욱 유연한 경우 Object Storage를 HDFS 및 클러스터 메타데이터의 백업 대상으로 활용하는 것이 좋습니다. RPO 대상을 충족하기 위해 필요한 만큼 복사 프로세스를 스케줄링하여 DistCp(배포 복사본) 등의 도구를 사용하여 데이터를 Object Storage로 푸시합니다. 데이터베이스(Oracle, MySQL) 를 오브젝트 스토리지 버킷으로 백업하거나 다른 가용성 도메인이나 지역의 추가 데이터베이스 인스턴스에 복제할 수도 있습니다.
DR 요구사항에 따라 단일 지역에서 제공할 수 없는 데이터에 대한 지리적 중복성이 지정되면 영역 간에 오브젝트 스토리지의 데이터도 복사할 수 있습니다. 재해가 발생하는 경우 Terraform를 사용하여 다른 가용성 도메인(동일한 지역 또는 다른 지역) 에 있는 리소스를 빠르게 프로비저닝하고 오브젝트 스토리지의 데이터에서 DR 클러스터를 리하이드레이션합니다.
원가 관리
이 솔루션의 나머지 부분에서도 인프라 비용을 줄이기 위해 컴퓨트 및 스토리지 요구사항을 “오른쪽 크기” 하는 여러 가지 방법이 있습니다. Oracle Cloud Infrastructure 는 Hadoop 배치와 연관된 비용을 관리할 수 있는 추가 툴을 제공합니다.
- 배치 태그 지정을 활용하여 사용을 쉽게 추적할 수 있습니다.
- 구획 레벨에서 할당량을 설정하여 여러 업무 라인에 의한 사용을 제한할 수 있습니다. 여러 구획을 사용하여 운용, QA 및 개발 환경을 관리하고 필요에 따라 할당량을 제한합니다.
클라우드의 동적 특성을 활용하는 것도 지속적이지 않은 환경에 매우 중요합니다. 오브젝트 스토리지를 데이터에 백업(또는 데이터 레이크) 으로 사용 중인 경우 Terraform를 사용하여 환경을 만들고 오브젝트 스토리지의 데이터로 HDFS를 리하이드레이션한 다음, 더 이상 필요하지 않은 경우 환경을 삭제합니다.
블록 볼륨이 있는 VM 환경에서는 컴퓨트 청구를 중지하기 위해 일시 중지할 수도 있으며, 스토리지 소비에만 비용이 청구됩니다.