용량 계획
이 문서는 XRP Ledger 서버의 성능을 조정하고 최적화 하는데 사용할 수 있는 구성, 네트워크 및 하드웨어 권장 사항을 설명합니다.
XRP Ledger 서버의 부하는 여러 요인에 따라 달라집니다. 하나는 네트워크의 활동입니다. 공유 Ledger의 총 데이터 크기와 전송되는 트랜잭션의 총량은 글로벌 XRP Ledger 커뮤니티 전체의 유기적인 요인에 따라 달라집니다. 또 다른 요인은 API 사용량으로, API 호출 유형에 따라 서버에 가해지는 부하가 달라집니다. 퍼블릭 API를 제공하는 서버, 특정 통합 소프트웨어에 프라이빗 API를 제공하는 서버, 또는 API를 전혀 제공하지 않는 서버 간에 성능 특성이 매우 다를 수 있습니다. 이러한 요소를 고려하여 서버가 현재와 미래의 XRP Ledger 네트워크 활동을 처리할 수 있는 용량을 갖추었는지 확인해야 합니다.
구성 설정
기본 구성 파일에는 광범위한 일반적인 사용 사례에 대한 설정이 포함되어 있습니다. 특정 하드웨어와 의도된 사용 패턴에 맞게 설정을 사용자 지정하여 더 나은 성능을 얻을 수 있습니다.
이 섹션의 설정은 rippled.cfg 파일의 매개변수입니다. 예제 구성 파일인 rippled-example.cfg는 rippled된 GitHub 저장소의 cfg 디렉터리에서 액세스할 수 있습니다. 예제 구성 파일의 설정은 서버와 함께 설치된 기본 구성과 일치합니다.
노드 크기
[node_size] 매개변수는 서버의 전체 하드웨어 용량과 일치해야 합니다. 이 매개 변수를 생략하면 서버가 시스템의 총 RAM 및 CPU 스레드 수에 따라 적절한 설정을 자동으로 선택하도록 할 수 있습니다. 시스템의 RAM 또는 스레드 중 일부를 다른 소프트웨어를 위해 따로 설정해야 하거나 운영 체제에서 보고하는 양이 부정확한 경우 등 자동 설정이 시스템에 맞지 않는 경우 이 값을 명시적으로 설정할 수 있습니다. (일부 컨테이너에서 발생할 수 있습니다.) 
일반적으로 사용 가능한 RAM이 지원할 수 있는 가장 큰 노드 크기를 항상 사용해야 합니다. 권장 설정은 다음 표를 참조하세요.
권장 사항
각 [node_size]에는 사용 가능한 RAM에 대한 해당 요구 사항이 있습니다. 예를 들어, [node_size]를 huge로 설정한 경우, rippled가 원활하게 실행될 수 있도록 최소 32GB의 사용 가능한 RAM이 있어야 합니다. 서버를 조정하려면 사용 사례의 요구 사항을 세분화하면서 작은 크기부터 시작하여 작은 크기, 중간 크기 등으로 크기를 늘리는 것이 유용할 수 있습니다.
사용 가능한 RAM
node_size값
참고
< 8 GB
tiny
권장하지 않습니다. 이 설정이 있는 서버는 사용 중인 네트워크에 동기화되지 않을 수 있습니다.
8 GB
small
가끔씩만 실행해야 하는 테스트 서버에 권장됩니다.
16 GB
medium
rippled-example.cfg 파일은 이 값을 사용합니다.
32 GB
large
권장하지 않습니다. 실제로 이 설정은 대부분의 상황에서 거대보다 성능이 떨어집니다. 안정성을 원한다면 항상 huge를 사용하세요.
64 GB
huge
프로덕션 서버에 권장됩니다.
[node_size] 파라미터를 잘못된 값으로 설정하면 서버가 시작되지 않습니다.
노드 DB 유형
rippled.cfg 파일의 [node_db] 구절에 있는 type 필드는 rippled가ledger 저장소를 보관하는 데 사용하는 키-값 저장소 유형을 설정합니다.
이 설정은 RAM 설정을 직접 구성하지는 않지만, 빠른 조회를 위해 데이터를 캐시하고 인덱싱하는 방식이 다르기 때문에 키-값 저장소 선택은 RAM 사용량에 중요한 영향을 미칩니다.
대부분의 경우 디스크에 많은 양의 데이터가 있어도 성능이 일정하므로 NuDB를 사용하세요. 빠른 SSD가 필요합니다. 자세히 알아보기.
회전식 디스크(권장하지 않음) 또는 비정상적으로 느린 SSD를 사용하는 경우 RocksDB를 사용하세요. 프로덕션 서버에서는 이 설정을 피해야 합니다. 자세히 알아보기.
예제 rippled-example.cfg 파일에는 [node_db] 구절의 유형 필드가 NuDB로 설정되어 있습니다.
RocksDB 사용에 대해 자세히 알아보기
RocksDB는 rippled에 내장된 영구 키-값 저장소입니다.
RocksDB는 솔리드 스테이트 디스크 또는 회전식 디스크에서 작동하도록 설계되었습니다. NuDB보다 디스크 스토리지가 약 1/3 적게 필요하며 더 나은 I/O 지연 시간을 제공합니다. 그러나 더 나은 I/O 레이턴시는 데이터 인덱스를 저장하는 데 많은 양의 RAM이 필요하기 때문에 발생합니다. RocksDB에는 더 많은 트랜잭션 처리량을 위해 조정할 수 있는 성능 관련 구성 옵션이 있습니다. 다음은 RocksDB에 권장되는 [node_db] 구성입니다:
[node_db]
type=RocksDB
path=/var/lib/rippled/db/rocksdb
open_files=512
filter_bits=12
cache_mb=512
file_size_mb=64
file_size_mult=2
online_delete=2000
advisory_delete=0(디스크에 ledger 저장소를 보관할 디렉터리 경로를 조정합니다. online_delete 및 advisory_delete 설정을 구성에 맞게 조정하세요.)
NuDb 사용에 대한 자세한 정보
NuDB는 SSD 드라이브에 최적화된 추가 전용 키-값 저장소입니다. NuDB는 저장되는 데이터의 양에 관계없이 거의 일정한 성능과 메모리 공간을 제공합니다. NuDB는 솔리드 스테이트 드라이브가 필요하지만, 대용량 데이터베이스에 액세스하는 데 RocksDB보다 훨씬 적은 RAM을 사용합니다. 프로덕션 서버는 NuDB를 사용하고 사용 사례에 필요한 만큼의 기록 데이터를 저장하도록 구성해야 합니다. NuDB에는 rippled.cfg에서 사용할 수 있는 성능 관련 구성 옵션이 없습니다. 다음은 NuDB를 사용하는 rippled 서버에 권장되는 [node_db] 구성입니다:
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0(디스크에 장부 저장소를 보관할 디렉터리의 경로를 조정합니다. online_delete 및 advisory_delete 설정을 구성에 맞게 조정합니다.)
로그 수준
예제 rippled-example.cfg 파일은 [rpc_startup] 구절에서 로깅 상세도를 경고로 설정합니다. 이 설정은 더 자세한 로깅에 비해 디스크 공간과 I/O 요구 사항을 크게 줄여줍니다. 그러나 더 자세한 로깅을 사용하면 문제 해결을 위한 가시성이 향상됩니다.
네트워크 및 하드웨어
XRP Ledger 네트워크의 각 서버는 네트워크의 모든 트랜잭션 처리 작업을 수행합니다. 네트워크의 총 활동은 다양하지만 시간이 지남에 따라 대부분 증가하므로 현재 네트워크 활동에 필요한 것보다 더 큰 용량의 하드웨어를 선택해야 합니다.
권장 사항
권장 하드웨어 사양에 대한 요약은 시스템 요구 사항을 참조하세요.
CPU 사용률 및 가상화
베어메탈에서 최상의 성능을 얻을 수 있지만, 호스트 하드웨어의 사양이 충분히 높으면 가상 머신도 거의 동일한 성능을 발휘할 수 있습니다.
디스크 속도
스토리지 속도는 서버 용량에서 가장 중요한 요소 중 하나입니다. 지연 시간이 짧고 랜덤 읽기와 처리량이 높은 고급 SSD(솔리드 스테이트 디스크 드라이브)를 사용하세요. rippled 엔지니어가 관찰한 초당 최대 읽기 및 쓰기 속도는 다음과 같습니다:
초당 10,000회 이상의 읽기(많이 사용되는 퍼블릭 서버 클러스터에서).
초당 7,000건 이상의 쓰기(전용 성능 테스트에서).
디스크 공간
[node_db] 구절은 ledger 기록을 보관하는 서버의 ledger 저장소를 제어합니다. 필요한 디스크 공간의 양은 로컬에서 사용 가능한 기록의 양에 따라 달라집니다. XRP Ledger 서버는 컨센서스 프로세스를 따르고 ledger의 전체 상태를 보고하기 위해 가장 최근 256개 이상의 ledger 버전을 저장할 필요는 없지만, 서버가 로컬에 저장한 ledger 버전에서 실행된 트랜잭션에 대해서만 쿼리할 수 있습니다. 선택한 ledger 저장소 저장 위치를 가리키도록 [node_db]의 경로를 구성합니다.
온라인 삭제를 통해 얼마나 많은 데이터를 보관할지 제어할 수 있으며, 기본 구성 파일에서는 서버가 최신 2000개의 ledger 버전을 보관하도록 설정되어 있습니다. 온라인 삭제 기능을 사용하지 않으면 서버의 디스크 요구 사항이 무한대로 증가합니다.
다음 표는 작성 시점(2018-12-13)을 기준으로 다양한 양의 기록에 대한 요구 사항을 대략적으로 보여줍니다:
2 hours
2,000
250 MB
450 MB
1 day
25,000
8 GB
12 GB
14 days
350,000
112 GB
168 GB
30 days
750,000
240 GB
360 GB
90 days
2,250,000
720 GB
1 TB
1 year
10,000,000
3 TB
4.5 TB
2 years
20,000,000
6 TB
9 TB
전체 기록(2022-12-18 기준)
76,500,000+
(권장하지 않음)
~22.3 TB
이 수치는 추정치입니다. 이 수치는 여러 요인에 따라 달라지며, 가장 중요한 것은 네트워크의 트랜잭션 양입니다. 거래량이 증가함에 따라 각 ledger 버전은 더 많은 고유 데이터를 저장합니다. 향후 증가에 대비해 추가 저장 용량을 프로비저닝해야 합니다.
online_delete 설정은 이전 기록을 삭제한 후 얼마나 많은 ledger 버전을 보관할지 서버에 알려줍니다. 최대 두 배의 ledger 버전을 저장할 수 있는 충분한 디스크 공간을 계획해야 합니다(온라인 삭제가 실행되기 직전).
보관하는 기록의 양을 변경하는 방법에 대한 지침은 온라인 삭제 구성을 참조하세요. [database_path]는 별도의 장부 데이터베이스를 구성합니다. 여기에는 트랜잭션 데이터와 일부 런타임 구성이 포함됩니다.
일반적으로 rippled 서버가 실행 중이 아닐 때 rippled 서버의 데이터베이스 파일(ledger 저장소와 장부 데이터베이스 모두)을 삭제하면 서버에 저장된 ledger 기록은 지워지지만 네트워크에서 해당 데이터를 다시 가져올 수 있습니다. 단, [database_path]에 있는 wallet.db 파일을 삭제하면 수정안 투표 및 피어 예약과 같은 런타임 구성 변경 사항을 수동으로 다시 적용해야 합니다.
ledger 히스토리를 저장하고 싶지만 전체 히스토리를 저장할 디스크 공간이 충분하지 않은 경우, 히스토리 샤딩 기능을 사용하여 무작위 범위의 ledger을 별도의 샤드 저장소에 저장할 수 있습니다. 히스토리 샤딩은 [shard_db] 구절에서 구성됩니다.
아마존 웹 서비스
Amazon Web Services(AWS)는 널리 사용되는 가상화 호스팅 환경입니다. AWS에서 rippled을 실행할 수 있지만, EBS(Elastic Block Storage)는 사용할 수 없습니다. 시스템 요구 사항을 참조하세요.
AWS 인스턴스 저장소(임시 저장소)는 적절한 성능을 제공하지만 인스턴스를 시작/중단할 때 등 일부 상황에서는 데이터가 손실될 수 있습니다. 개별 XRP Ledger 서버는 일반적으로 피어에서 손실된 ledger 기록을 다시 획득할 수 있으므로 이는 허용될 수 있습니다. 구성 설정은 보다 영구적인 저장소에 저장해야 합니다.
[node_db] 구절의 경로와 [database_path]가 모두 적절한 저장소를 가리키는지 확인하시기 바랍니다.
RAM/메모리
메모리 요구 사항은 주로 node_size 구성 설정과 기록 데이터를 검색하는 클라이언트 트래픽의 양에 따라 달라집니다. 메모리 요구 사항에 대한 자세한 내용은 노드 크기를 참조하세요.
네트워크
모든 엔터프라이즈 또는 캐리어급 데이터 센터는 XRP Ledger 서버 실행을 지원하기에 충분한 네트워크 대역폭을 보유해야 합니다. 실제 필요한 대역폭은 네트워크의 현재 트랜잭션 볼륨에 따라 크게 달라집니다. 서버 동작(예: Ledger 기록 백필)도 네트워크 사용에 영향을 미칩니다. 일반적으로 가정용 인터넷은 안정적인 서버를 실행하기에 충분하지 않습니다.
예외적으로 거래량이 많은 기간 동안 일부 운영자는 서버가 100메가비트/s 네트워크 링크를 완전히 포화시켜 안정적인 성능을 위해 기가비트 네트워크 인터페이스가 필요하다는 보고를 한 바 있습니다.
다음은 일반적인 작업에서 관찰된 비압축 네트워크 대역폭 사용의 예입니다:
Process average transaction volumes
2 Mbps up, 2 Mbps down
Process peak transaction volumes
>100 Mbps up
Serve historical ledger and transaction reports
100 Mbps up
Start up rippled
20 Mbps down
P2P 통신에서 압축을 활성화하여 대역폭을 절약할 수 있지만, CPU를 더 많이 사용해야 합니다. 대부분의 하드웨어 구성은 정상적으로 사용하는 동안 여유 CPU 용량이 있으므로 네트워크 대역폭이 제한되어 있는 경우 경제적인 옵션이 될 수 있습니다.
Last updated