Spark · Trino 같은 연산 워크로드를 올리지 않고 저장소로만 쓰는 HDFS 를 가정한다. 이 경우 병목은 CPU 가 아니라 디스크 I/O 와 네트워크다. 3~10 노드 규모를 기준으로 정리한다.
| 구분 | 최소 | 권장 |
|---|---|---|
| CPU | 4 vCPU | 8~16 vCPU |
| 메모리 | 16GB | 32~64GB |
| OS 디스크 | 50GB SSD | 100GB SSD |
| 데이터 디스크 | 2~4TB × 2~4 | 4~12TB × 6~12, JBOD |
| 네트워크 | 1Gbps | 10Gbps 이상 |
데이터 디스크는 RAID 로 묶지 않고 개별 볼륨(JBOD)으로 붙여 dfs.datanode.data.dir 에 나열한다. HDFS 가 이미 블록 복제로 내구성을 확보하므로 RAID 는 용량만 깎고 쓰기 성능을 떨어뜨린다.
디스크 수가 많을수록 동시 I/O 가 늘어 처리량이 올라간다. 같은 용량이면 큰 디스크 적게보다 작은 디스크 여러 개가 유리하다. 다만 디스크가 늘면 블록 수도 늘어 DataNode 의 메모리와 파일 디스크립터 사용량이 함께 증가한다.
NameNode 는 네임스페이스 전체를 힙에 올린다. 파일과 블록 수가 늘면 힙을 키워야 하며, 디스크 용량과는 직접 관계가 없다. 메타데이터 디렉터리는 SSD 에 두고 최소 두 곳 이상으로 복제한다. HA 구성이면 JournalNode 를 홀수(보통 3대)로 둔다.
노드 3대에 NameNode 2 · JournalNode 3 · DataNode 3 을 올리고 ZooKeeper 는 별도 3대를 쓰는 구성이다.
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://ns1</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>zk01:2181,zk02:2181,zk03:2181</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/data/hadoop/tmp</value>
</property>
</configuration>
<configuration>
<property>
<name>dfs.nameservices</name>
<value>ns1</value>
</property>
<property>
<name>dfs.ha.namenodes.ns1</name>
<value>nn1,nn2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns1.nn1</name>
<value>hadoop01:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns1.nn2</name>
<value>hadoop02:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.ns1.nn1</name>
<value>hadoop01:9870</value>
</property>
<property>
<name>dfs.namenode.http-address.ns1.nn2</name>
<value>hadoop02:9870</value>
</property>
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://hadoop01:8485;hadoop02:8485;hadoop03:8485/ns1</value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/hadoop/jn</value>
</property>
<property>
<name>dfs.client.failover.proxy.provider.ns1</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/hadoop/.ssh/id_rsa</value>
</property>
</configuration>
dfs.ha.fencing.methods 를 생략하면 스플릿 브레인 위험이 있다. sshfence 를 쓰려면 NameNode 사이에 비밀번호 없는 SSH 가 되어야 하고, 불가능하면 shell(/bin/true) 대신 실제로 동작하는 펜싱 방법을 마련한다.
같은 하드웨어에 S3 호환 오브젝트 스토리지를 올리는 구성을 비교하는 경우가 많다. 판단 기준은 접근 패턴이다. 대용량 순차 읽기와 배치 분석이 중심이고 기존 Hadoop 생태계 도구를 그대로 쓴다면 HDFS 가 유리하다. 외부 애플리케이션이 S3 API 로 접근하고 파일 수가 매우 많다면 오브젝트 스토리지가 운영이 단순하다.
라이선스도 함께 본다. MinIO 는 과거 Apache 2.0 이었으나 이후 AGPLv3 로 전환했다. 전환 시점과 마지막 Apache 2.0 릴리스 태그는 자료마다 달라 확인 필요하며, 외부에 서비스 형태로 제공할 계획이라면 도입 전에 법무 검토를 거친다.