> ## Documentation Index
> Fetch the complete documentation index at: https://injectivelabs-mintlify-25e241d4.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 하드웨어 요구 사항
> Injective 노드 운영을 위한 최소 및 권장 하드웨어 사양
Injective의 1초 미만 블록 타임과 높은 처리량의 트랜잭션 처리는 하드웨어에 상당한 부담을 줍니다. 사양이 부족한 노드는 체인 팁(tip)에서 뒤처지거나, 블록을 놓치거나(검증자), 오래된 데이터를 제공하게 됩니다(RPC 노드).
## 검증자 노드
검증자 노드는 합의에 참여하며 감금(jailing)을 피하기 위해 일관된 성능을 유지해야 합니다. 베어메탈 서버를 강력히 권장합니다.
| *최소* | *권장* |
| :--------------: | :--------------: |
| RAM 메모리 128GB | RAM 메모리 128GB |
| CPU 12 코어 | CPU 16 코어 |
| CPU 기본 클럭 3.7GHz | CPU 기본 클럭 4.2GHz |
| 스토리지 2TB NVMe | 스토리지 2TB NVMe |
| 네트워크 1Gbps+ | 네트워크 1Gbps+ |
### 프로덕션 검증자 참고 사양
참고로, Injective 메인넷의 프로덕션 검증자들은 일반적으로 다음 범위의 하드웨어를 운영합니다:
| 구성 요소 | 일반적인 구성 |
| -------- | ----------------------------------------------------------------- |
| **CPU** | AMD EPYC 4585PX 또는 AMD Ryzen 9 9950X (16코어 / 32스레드, 5.75 GHz 부스트) |
| **RAM** | 128 GB DDR5 @ 3600 MT/s |
| **스토리지** | 2x \~2 TB NVMe RAID0 구성, 약 3.5 TiB 사용 가능 |
| **네트워크** | 10-25 Gbps |
블록 처리에는 코어 수보다 높은 싱글 스레드 성능(부스트 클럭)이 더 중요합니다. 네트워크 요구 사항은 사양 표에 명시된 최소 1 Gbps를 훨씬 상회합니다. 프로덕션 검증자는 일관된 피어 연결성과 빠른 블록 전파를 위해 10 Gbps 이상의 회선에서 이점을 얻습니다.
## RPC 노드
실시간 체인 데이터를 제공하는 비검증자 노드도 비슷한 요구 사항을 갖습니다. 슬래싱 위험은 없지만, 성능이 부족한 노드는 체인 팁에서 뒤처지고 신뢰할 수 없는 데이터를 제공하게 됩니다.
| *최소* | *권장* |
| :---------------: | :---------------: |
| RAM 메모리 64GB | RAM 메모리 128GB |
| CPU 8 코어 | CPU 16 코어 |
| CPU 기본 클럭 3.4GHz | CPU 기본 클럭 4.0GHz+ |
| 스토리지 1TB NVMe/SSD | 스토리지 2TB NVMe |
| 네트워크 1Gbps+ | 네트워크 1Gbps+ |
**CPU 클럭 속도가 코어 수보다 더 중요합니다.** Injective의 블록 처리는 실행 중 대부분 싱글 스레드로 이루어집니다. 낮은 클럭의 CPU(예: 2.6GHz 클라우드 인스턴스)에서 실행되는 노드는 코어 수와 관계없이 지속적으로 체인 팁에서 뒤처집니다.
## 스토리지
### 디스크 I/O 요구 사항
디스크 처리량은 Injective 노드에서 가장 흔한 병목 지점입니다. 체인은 잠재적으로 큰 트랜잭션 페이로드와 함께 약 650ms마다 블록을 생성하므로 지속적으로 높은 IOPS가 필요합니다.
* **베어메탈:** 로컬 NVMe 드라이브가 이상적입니다. 여러 NVMe 드라이브에 걸친 RAID0이 최고의 처리량을 제공합니다.
* **클라우드 (GCP):** 표준 영구 디스크(`pd-balanced`, `pd-ssd`)는 종종 필요한 IOPS를 유지할 수 없습니다. 체인 데이터 디렉터리에는 **RAID0 구성의 로컬 SSD**를 사용하세요. 로컬 SSD는 휘발성이지만 체인 상태는 [스냅샷](https://chain-portal.injective.network/snapshots)에서 쉽게 복구할 수 있습니다. 또는 IOPS와 처리량을 명시적으로 프로비저닝한 `hyperdisk-balanced` 또는 `hyperdisk-extreme`을 프로비저닝하세요.
* **클라우드 (AWS):** 프로비저닝된 IOPS와 함께 `io2` 또는 `gp3` 볼륨을 사용하세요. 인스턴스 스토어 NVMe(예: `i3`, `i4i` 인스턴스)가 최고의 성능을 제공합니다.
### 체인 데이터 증가
Injective 체인 데이터는 하루에 약 10-15 GB씩 증가합니다. 프루닝된 노드의 경우 디스크 공간을 회수하고 성능을 유지하기 위해 300-400 GB마다 새 스냅샷에서 복원하는 것이 좋습니다. 스냅샷 다운로드 링크는 [Chain Portal의 스냅샷 페이지](https://portal.injective.network/snapshots)를 참조하세요.
### 프루닝 구성
프루닝은 디스크 공간 절약을 위해 오래된 상태를 제거하지만, 그 자체로 CPU와 I/O를 많이 사용합니다. 성능이 부족한 하드웨어에서는 프루닝 프로세스로 인해 노드가 체인 팁에서 뒤처질 수 있습니다.
노드가 지연되고 하드웨어 제한이 의심되는 경우:
* 프루닝 오버헤드를 없애기 위해 `app.toml`에서 `pruning = "nothing"` 설정을 고려하세요
* 대신 주기적으로 노드를 중지하고 스냅샷에서 복원하여 디스크 사용량을 관리하세요
* 무중단 운영을 위해서는 두 개의 노드를 운영하며 롤링 방식으로 스냅샷 복구를 수행하세요
### 스토리지 레이아웃
프로덕션 검증자는 일반적으로 두 개의 NVMe 드라이브를 다음 구성 중 하나로 운영합니다:
| 레이아웃 | 작동 방식 | 트레이드오프 |
| -------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **RAID0** | 데이터를 고정 청크 단위로 두 드라이브에 스트라이핑합니다. 두 드라이브를 병렬로 읽고 써서 잠재적인 IOPS와 처리량이 두 배가 됩니다. | 이중화 없음. 어느 한 드라이브라도 고장 나면 어레이가 손실됩니다. 전체 스냅샷 복구가 필요합니다. |
| **LVM linear** | 드라이브를 하나의 볼륨으로 연결합니다. 한 드라이브를 먼저 채우고 다음 드라이브로 넘어갑니다. 병렬 I/O 속도 향상이 없습니다. | 이중화 없음. 어느 한 드라이브라도 고장 나면 전체 Volume Group이 깨지고 데이터베이스가 손상됩니다. 성능이 단일 드라이브 속도로 제한됩니다. |
두 레이아웃 모두 이중화를 제공하지 않지만, 체인 상태에는 이중화가 필요하지 않습니다. Injective의 1초 미만 블록 타임 요구 사항을 충족하려면 RAID0을 권장합니다. 드라이브가 고장 나면 [스냅샷](https://chain-portal.injective.network/snapshots)에서 복구하세요.
## 베어메탈 vs 클라우드
검증자 노드에는 베어메탈 서버를 강력히 권장합니다. 1초 미만 블록 타임에 필요한 일관된 CPU 클럭 속도와 저지연 NVMe 스토리지는 공유 클라우드 인프라에서 보장하기 어렵습니다.
클라우드 배포는 올바르게 프로비저닝된 경우(위의 스토리지 안내 참조) 비검증자 노드에서 작동할 수 있지만, 운영자는 신뢰성을 유지하기 위해 모니터링과 운영 도구에 더 많은 투자를 해야 합니다.
### 참고 클라우드 인스턴스 유형
다음 인스턴스 유형은 Injective 노드에서 검증되었습니다. 프로비저닝 시 시작점으로 사용하세요.
| 제공자 | 인스턴스 | vCPU | RAM | 디스크 | 적합한 용도 |
| ------- | --------------------- | -------------------------------------------- | ------ | --------------------- | ------------------- |
| **GCP** | `c4-standard-16-lssd` | 16 vCPU (Emerald Rapids) | 64 GB | 로컬 SSD (NVMe) | 센트리, RPC 노드 |
| **OVH** | `b3-32` | 8 vCPU | 32 GB | 로컬 SSD | 센트리 (검증자용으로는 사양 부족) |
| **OVH** | 전용 서버 (예: Advance-1) | 12 vCPU (Xeon E-2386G @3.5GHz 또는 EPYC 4244P) | 128 GB | 물리 NVMe (RAID0/RAID1) | 검증자, 풀 노드 |
성능을 위해서는 (영구 디스크가 아닌) 로컬 SSD가 있는 클라우드 인스턴스가 필수적입니다. 표준 영구 디스크(`pd-balanced`, `pd-ssd`)는 Injective의 블록 처리량에 필요한 IOPS를 유지할 수 없습니다. 로컬 SSD는 휘발성이지만 체인 상태는 스냅샷에서 복구할 수 있습니다.
## 네트워킹 및 피어링
노드가 동기화를 유지하려면 건강한 피어 세트가 필요합니다. 피어링이 부족하면, 특히 검증자 세트 대다수와 멀리 떨어진 리전에서는 간헐적인 동기화 지연이 발생할 수 있습니다.
* 최소 **15-25개의 활성 피어**를 유지하세요. `curl -s localhost:26657/net_info | jq '.result.n_peers'`로 확인하세요
* 노드가 항상 신뢰할 수 있는 연결을 유지하도록 `config.toml`에 **persistent peers**를 구성하세요. 커뮤니티가 유지 관리하는 피어 목록은 [피어 검색](/ko/infra/join-a-network#피어-검색)을 참조하세요
* Injective 피어가 적은 리전(예: 아시아-태평양)의 노드는 일관된 동기화를 유지하기 위해 추가 persistent peers가 필요할 수 있습니다
* 더 낮은 지연 시간과 더 일관된 라우팅을 위해 클라우드 제공자의 **Premium Tier 네트워킹**을 사용하세요