대시보드를 벗어나지 않고 처리량(Throughput) 용량 늘리기

런칭, 민팅, 또는 인덱싱 백필은 1분도 채 안 되는 시간에 앱을 처리량 한도 이상으로 밀어붙일 수 있습니다. 다행히 유료 플랜에서는 이제 저희와 대화할 필요 없이 팀이 직접 그 한도를 올릴 수 있습니다. 대시보드의 Usage 페이지를 열고, 필요한 추가 용량을 선택한 다음 확인하면 됩니다. 새로운 기본 용량은 몇 초 안에 적용됩니다.

애드온은 언제든 대시보드에서 취소할 수 있습니다. 추가된 용량은 현재 결제 주기 동안 유지되며, 이후 팀은 기본 처리량 한도로 돌아갑니다.

처리량 한도란 무엇인가요?

처리량은 초당 컴퓨트 유닛(CU/s)으로 측정되는, 요청을 저희 쪽으로 보낼 수 있는 속도입니다. 각 RPC 메서드는 처리하는 데 필요한 작업량에 따라 고유한 컴퓨트 유닛 비용을 가지기 때문에, 원시 요청 수가 아니라 요청의 총 비용을 기준으로 측정합니다.

필요한 용량을 산정하는 일은 이 비용들을 단순히 더하는 것보다 조금 더 복잡합니다. 비용 표에는 CU 열과 별도의 Throughput CU 열이 있으며, 일부 메서드는 두 값이 다릅니다. 즉, 월간 사용량 기준으로는 저렴한 호출이 처리량 기준으로는 비쌀 수 있습니다. 용량을 산정할 때는 Throughput CU 열을 기준으로 하세요.

• 용량은 앱 단위가 아니라 계정 단위로 할당됩니다. 처리량은 예전에는 앱별로 설정되었지만, 이제는 계정 전체에 걸쳐 구성되므로 팀 내 모든 앱의 사용량 합계가 하나의 숫자에 반영됩니다. 앱을 하나 더 생성한다고 해서 여유가 더 생기지 않습니다.
• 10초 롤링 윈도우로 측정합니다. 처리량 문서에서 설명하듯, 10초 동안 평가되는 토큰 버킷 방식이므로 10,000 CU/s 한도라면 어떤 10초 구간에서든 100,000 컴퓨트 유닛을 사용할 수 있습니다. 짧은 버스트는 통과되지만, 한도를 계속 초과하는 트래픽은 저희 엣지 레이어에서 HTTP 429(too many requests)로 반환됩니다.

숫자 자체보다 윈도우가 더 중요합니다. 평균적으로는 한도 아래에서 여유 있게 유지되는 워크로드도 피크 시점에는 쓰로틀링될 수 있습니다. 429를 받은 팀이 대개 놀라는 이유가 바로 여기에 있습니다.

처리량 업그레이드는 어떻게 작동하나요?

대시보드의 Usage 페이지를 열고 처리량 섹션을 찾은 다음 _Upgrade limit_을 선택하세요. 이 컨트롤을 보려면 팀의 billing admin이어야 합니다. 용량 드롭다운에는 각 증분 단위와 그에 따른 월 요금이 함께 표시되므로, 결정을 내리기 전에 비용을 확인할 수 있습니다. 같은 페이지에서는 최근 팀 사용량이 현재 처리량 한도를 초과했을 때 배너를 표시하며, 이를 클릭하면 업그레이드 플로우로 이동합니다.

확인 후 일어나는 일은 다음과 같습니다:

• 업그레이드는 즉시 적용되며 매달 갱신됩니다. 확인 후 몇 초 안에 새로운 용량이 적용됩니다.
• 다운그레이드는 결제 주기가 끝날 때 적용됩니다. 취소하더라도 추가 용량은 그때까지 유지되므로, 백필이 예상보다 길어져도 갑자기 끊기지 않습니다.
• 셀프서브로 남은 전체 증분 단위가 없으면, 대시보드는 영업팀에 문의하도록 안내합니다. 저희 팀은 대시보드에서 셀프서브로 제공하는 것보다 더 높은 처리량 한도를 구성할 수 있습니다.

얼마나 올릴 수 있는지는 플랜에 따라 다릅니다:

Pay-as-you-go 팀은 10,000 CU/s에서 시작해 Enterprise 계약이나 주문서 없이도 직접 30,000 CU/s까지 도달할 수 있습니다. Enterprise의 시작 용량은 계약별로 설정되므로 계정마다 기준선이 다릅니다. 업그레이드 모달에는 팀의 정확한 최대치가 표시되며, 전체 증분 단위가 그 아래에 들어맞는 한 고정된 증분 단위로 그 최대치를 향해 올라갈 수 있습니다.

즉, 플랜의 셀프서브 최대 업그레이드 용량 이하라면, billing admin 권한을 가진 사람이 1분도 안 되는 시간에 저희 없이 팀 자체적으로 내릴 수 있는 결정입니다.

실제로 얼마나 많은 처리량이 필요한가요?

Usage 페이지의 평균이 아니라 피크 처리량 카드와 차트부터 확인하세요. 평균은 스파이크를 눈에 띄지 않게 평탄화하며, 다음 런칭에서 실패할 수 있는 한도를 선택하게 만듭니다.

그 피크를 정확한 수치가 아니라 최소 기준선으로 취급하세요. 한도는 10초 단위로 적용되지만 차트는 1분 평균을 표시하므로, 실제로 429를 유발한 버스트는 주변 1분에 걸쳐 평탄화되어 실제보다 낮게 나타납니다. 그 스파이크들이 실제로 요청 손실을 일으켰는지, 아니면 근접했을 뿐인지 확인하려면 Request Logs를 429 응답으로 필터링하세요.

두 윈도우 사이의 이 격차가 피크에 딱 맞추는 대신 피크보다 여유 있게 구매해야 하는 주된 이유입니다. 한 번 12,000 CU/s를 찍은 트래픽은 언젠가 더 높은 피크를 찍게 되고, 여유 용량은 장애보다 저렴합니다.

재시도와 추가 처리량은 서로 다른 문제를 해결하므로, 자신이 어떤 문제를 겪고 있는지 파악하는 것이 도움이 됩니다:

• 재시도는 429의 일부에 적합하며 추가 지연을 감내할 수 있는 워크플로우에 맞습니다. 저희 문서에서는 바로 이런 경우를 위한 Retry-After 헤더와 지수 백오프를 다룹니다.
• 지연에 민감한 경로에는 더 많은 처리량이 답이며, 잠깐 초과하는 게 아니라 한도를 지속적으로 초과하는 트래픽에도 마찬가지입니다. 단순히 필요한 용량보다 부족한 워크로드는 어떤 백오프 전략으로도 해결되지 않습니다.

대부분의 업그레이드는 세 가지 워크로드에서 비롯됩니다: 앱이 사용자를 늘려가면서 발생하는 지속적인 성장, 엔드포인트가 허용하는 한 최대한 빠르게 히스토리를 가져오는 인덱싱 백필, 그리고 에어드롭, 토큰 런칭, 민팅 같은 예정된 이벤트입니다. 첫 번째는 영구적이고 나머지 둘은 일시적이며, 이것이 이 플로우가 구매만큼이나 깔끔하게 취소를 지원하는 이유입니다.

언제 저희와 직접 대화해야 하나요?

셀프서브는 일반적인 경우를 다루지만 모든 경우를 다루지는 않습니다. 다음의 경우 문의해주세요:

• 플랜의 셀프서브 최대치를 넘어섰고 계속 성장하고 있는 경우.
• 처리량을 월간 애드온이 아니라 계약에 협상해 넣고 싶은 경우.
• 워크로드 내 특정 체인, 앱, 또는 메서드 하나가 나머지보다 훨씬 크게 스파이크를 일으켜서, 팀 전체 용량보다 맞춤형 처리량이 더 적합한 경우.

이런 것들은 규모와 구조에 관한 대화이며, 저희 전문가 팀이 이를 도와드릴 수 있습니다. 스파이크를 넘기기 위해 5,000 CU/s의 여유 용량을 구매하는 것은 더 작은 결정이므로, 스스로 원하는 일정에 맞춰 처리할 수 있도록 대시보드에 남아 있습니다.

몇 초 만에 더 많은 처리량 확보하기

지금 Alchemy 대시보드에서 용량을 늘려보세요. 드롭다운 하나로 계약 변경 없이 즉시 적용됩니다. 아직 유료 플랜이 아니라면, 저희 RPC API는 무료로 시작할 수 있고 pay-as-you-go 요금제는 최소 약정이 없으므로, 첫 결제일부터 업그레이드 경로가 열려 있습니다.

트래픽이 실제로 어디로 가는지 확인하려면, Alchemy Monitor가 요청량, 오류, 지연을 한곳에서 보여주며, Alchemy CLI에서 동일한 사용량 데이터를 가져올 수도 있습니다.

셀프서브 범위를 넘어서는 규모로 확장 중이신가요? 저희 영업팀에 볼륨 요금제에 대해 문의하시면, 실제로 예상하는 트래픽에 맞춰 필요한 용량을 산정해드립니다.