ERPC

erpc worker로 앱을 실행하고 확인하고 비용 지불하기

erpc worker status는 앱이 실행 중인지와 시간당 비용을 보여 줍니다. 무언가를 시작할 때는 항상 가격을 먼저 보여 주며, erpc worker delete --release-server는 앱이 시간별 과금으로 사용하는 gRPC, Shreds, Unlimited RPC를 종료한 다음 시간별 과금 서버를 종료합니다.
이 페이지는 프리릴리스인 ERPC CLI v0.1.0-rc.4를 설명합니다.

앱 확인

$ erpc worker status --env prod
api-prod on 203.0.113.10: running, release 20261101T093000Z-1a2b3c4d, pid 4217, up 2h 14m
  current 20261101T093000Z-1a2b3c4d, previous 20261028T171500Z-9f8e7d6c, 2 releases kept
  WAF: listening on port 8080, forwarding to 127.0.0.1:3000, since 2026-11-01T09:30:12Z; requests 5120, forwarded 5043, blocked 71, connections refused 12, app errors 6, addresses banned now 1
  `erpc worker delete --release-server --env prod` ends what this app is charged for.
status는 앱이 잠긴 상태인지 실행 중인지, 어떤 릴리스인지, 언제부터인지를 보여 줍니다. 로그인되어 있으면 환경의 시간당 비용도 보여 주는데, 각 항목에는 계정에 청구되는 가격이 함께 표시되고, 계정의 Credit과 그 Credit이 얼마나 유지되는지도 표시됩니다. --json은 같은 내용을 hourly.charged 아래에 담습니다.
계정의 청구 항목에 없는 항목은 종료되었다고 하지 않고 청구 항목에 없다고 표시합니다. 그 목록이 시작보다 일 분 늦을 수 있기 때문입니다. 세션이 없거나 계정의 청구 항목을 읽을 수 없으면, status는 기록에 있는 내용을 보여 줍니다.

앱 제어

명령하는 일
erpc worker logs -n 200, logs -f앱과 에이전트의 로그. 줄 안의 제어 문자는 ?로 출력됩니다
erpc worker start앱을 실행합니다. worker가 잠긴 상태이면 키를 보냅니다
erpc worker stop, stop --lock앱을 중지합니다. --lock은 메모리에서 키도 지웁니다
erpc worker restart앱을 중지한 뒤 다시 시작합니다
erpc worker releases서버에 보관된 릴리스(deploy.keep_releases)
erpc worker rollback, rollback --to <release>이전 릴리스 또는 지정한 릴리스로 돌아갑니다. 그 릴리스의 헬스 체크 포트를 지금 실행 중인 다른 worker가 쓰고 있으면 거부되며, 사용 중인 릴리스는 그대로 남습니다
erpc worker api <PATH>이 머신에서 앱의 API를 읽습니다. API는 계속 서버의 loopback에 있습니다(변경하려면 -X POST, -d '{...}')
erpc worker trades [--profit]서버에서 앱이 한 거래
erpc worker list이 머신에 있는 앱과 각 앱이 배포된 곳. --prune은 erpc.toml이 사라진 앱을 목록에서 뺍니다
앱의 API_TOKEN은 여기서 읽혀 표준 입력으로 서버에 전달되며, 명령줄에도 저널에도 남지 않습니다. 모든 worker 명령은 --env <name>(기본값 default)과 --json을 받습니다. 단, 앱이 아니라 이 머신의 키스토어에 관한 secret unlock과 secret lock은 --env를 받지 않습니다. 어디서 실행하든 명령은 erpc가 알고 있는 이름으로 앱을 찾습니다. secret put, secret rm, key import, firewall allow, firewall deny는 --dir로만 앱을 지정합니다.

시간별 과금의 작동 방식

  • 무언가를 시작할 때는 항상 가격을 먼저 보여 줍니다. 터미널에서는 yes로 답한 뒤에만 시작하며, --yes를 쓰면 시작할 대상을 지정한 명령줄 자체가 yes 응답이 됩니다.
  • 시간별 과금 상품은 ERPC Credit으로 결제되며, ERPC Credit은 미리 구매합니다. Credit으로 충당되지 않는 시작은 거부됩니다. 가격은 요금제와 ERPC Web Dashboard에 나와 있습니다.
  • 새 VPS는 이름이 정해지는 즉시, 준비되기 전에 기록에 남습니다. 다음 배포는 VPS를 새로 사지 않고 그 VPS를 이어받습니다.
  • deploy에서 응답을 받지 못한 시작은 다시 보내지며, 새 요청으로 보내지는 일은 없습니다. 요청 키가 기록에 남으므로([env.<name>.starting]), 같은 명령을 다시 실행하면 같은 요청을 보냅니다. 응답에 따라서는 직접 제거할 때까지 요청 키가 남아 있습니다(erpc가 기록하지 못한 구매). erpc worker run은 기록을 남기지 않으므로, 다음 실행에서는 새 요청을 만듭니다.
  • 환경은 한 번에 하나씩 배포하세요. 같은 환경의 배포 두 개를 동시에 시작하면 두 개를 구매하게 될 수 있으며, 이는 지원되지 않습니다.
  • 회선이 아직 존재하는지는 계정에 청구되는 항목으로 판단합니다. 시간별 과금이 아닌 회선은 erpc가 절대 종료하지 않습니다. 대시보드에서 종료하세요.

앱 제거

erpc worker delete는 worker를 제거합니다. erpc worker delete --release-server는 회선도 종료한 다음 시간별 과금 서버를 종료합니다. 종료하지 못한 것은 기록에 남으며, 시간별 과금이 아닌 회선은 대시보드에서 종료하도록 이름이 표시됩니다.
  • 옵션 없는 삭제는 구매했지만 한 번도 접속하지 못한 VPS에 대해서는 거부됩니다. 과금 중인 VPS를 기록에서 잊게 되기 때문입니다. 접속한 적이 있는 시간별 과금 VPS를 옵션 없이 삭제하면, 아직 과금 중인데도 기록에서 빠지며 이에 대해 경고합니다.
  • --forget은 더 이상 접속할 수 없는 서버에 접속을 시도하지 않고 그대로 두며, --forget-line <id>는 erpc 밖에서 종료된 회선을 기록에서 뺍니다.

서버에서 RPC 지연 시간 측정

erpc worker bench는 환경의 서버에서 RPC 호출 시간을 잽니다. ERPC의 공유 RPC, ERPC의 Unlimited RPC, 그리고 그 밖의 RPC를 나란히 비교합니다. 서버의 에이전트가 각 호출 시간을 재므로, 수치는 앱이 실제로 얻는 값입니다.
bash
erpc worker bench                                  # getSlot: shared RPC vs the Unlimited RPC
erpc worker bench --rounds 300 --interval 150      # for a plan that limits calls per second
erpc worker bench --url other=op://<vault-id>/<item-id>/url   # another provider's RPC
  • --method는 getSlot, getBlockHeight, getLatestBlockhash, getHealth 중 하나를 받습니다.
  • --no-shared는 공유 RPC를 제외합니다. --url 값은 URL 자체, op://…, keychain:…, keystore:… 참조(키가 들어 있는 URL을 보관한 곳을 가리킴. 트레이딩 키의 항목을 가리키는 참조는 절대 허용되지 않으며 거부됨), 또는 -(표준 입력에서 읽거나, 화면에 보이지 않게 입력받음)일 수 있습니다. 엔드포인트가 여섯 개를 넘으면 거부됩니다.
  • 벤치는 p50, p90, p99, 최솟값, 최댓값, 첫 번째 사유가 포함된 실패, 그리고 각 응답이 같은 라운드에서 가장 최신인 응답보다 몇 슬롯 뒤처졌는지를 출력합니다.
  • 키는 표준 입력으로만 서버에 전달되며, 표에는 스킴, 호스트, 포트가 표시됩니다.

앱의 상태 데이터 백업

erpc worker backup on은 앱의 상태 데이터를 restic으로 암호화해 매일 ERPC Global Storage에 백업합니다. 백업은 서버 시간 기준으로 --at에 지정한 시각부터 30분 이내에 실행됩니다. 스토리지 요금제가 필요합니다(erpc storage buy 5).
  • 백업 대상은 앱의 상태 데이터인 /var/lib/private/erpc-worker-<id>입니다. 릴리스는 배포가 다시 넣어 주므로 백업하지 않습니다. Redis와 PostgreSQL 데이터는 포함되지 않습니다.
  • 서버는 스냅샷을 삭제할 수 없습니다. 서버는 erpc 세션, 계정의 관리자 키, 마스터 비밀번호를 절대 갖지 않습니다.
  • 탈취된 서버는 이 머신을 포함해 계정에 있는 모든 머신의 스냅샷을 읽을 수 있고, restic이 절대 바꾸지 않는 리포지토리 키를 off 이후에도 보관할 수 있으며, 다른 머신의 이름으로 스냅샷을 추가할 수 있으므로 그런 일이 있었다면 restore latest가 무엇을 고르는지 확인하세요. 또한 계정의 스토리지를 가득 채워 모든 머신의 백업을 멈추게 할 수 있습니다. erpc worker backup off는 서버가 응답하든 하지 않든 먼저 서버의 액세스 키를 폐기합니다.
  • worker가 실행되는 동안 restic은 파일을 있는 그대로 복사하므로, 데이터베이스를 일관된 상태로 복원하려면 별도의 덤프가 필요할 수 있습니다. 서버가 꺼져 있는 동안 놓친 실행은 서버가 다시 켜지면 실행됩니다.
  • erpc worker backup off, status, now는 각각 백업을 중지하고, 상태를 보고하고, 백업을 실행합니다. 스냅샷은 off 이후에도 남으며, erpc backup prune --host는 오래된 스냅샷을 솎아 냅니다.
이 머신에서 erpc backup init을 실행한 뒤 복원하세요.
bash
erpc backup restore latest --from-host erpc-worker-<id>-<tag> --path /var/lib/private/erpc-worker-<id> --target ./restored

여러 환경과 머신

  • 한 서버의 여러 worker는 각자 자체 유닛으로 실행되고, 서버의 방화벽 테이블을 공유하며, 각자 자기 포트만 엽니다.
  • 앱 하나에 여러 환경([env.staging], [env.prod])을 둘 수 있으며, 환경마다 자체 서버와 회선을 갖습니다.
  • 환경은 서버 정보를 erpc.toml 대신 1Password에 둘 수 있습니다. 그러면 그 보관함에 로그인되어 있고 앱의 리포지토리가 있는 머신이라면 어느 머신에서든 모든 명령을 실행할 수 있습니다. 이런 앱의 keychain:과 keystore: 참조는 다른 머신이 읽을 수 없으므로 경고가 표시됩니다. erpc login이 세션을 1Password에 보관하면 새 환경은 정보를 그곳에 둡니다. deploy --vault <vault-id>는 다른 보관함을 지정하고, deploy --inline은 정보를 erpc.toml에 둡니다.
이전방화벽 및 WAF다음실패했을 때