Temporal 스타트업 프로그램이 제공하는 혜택
Temporal은 내구성 있는 실행 플랫폼의 관리형 버전인 Temporal Cloud에 대해 최대 $6,000의 크레딧을 제공합니다. 이 크레딧은 Temporal이 청구하는 항목인 액션, 활성 스토리지 및 보존 스토리지에 적용됩니다.
AI Perks는 이를 194개 회사에 걸쳐 $7.7M의 크레딧과 함께 추적합니다.
$6,000이 얼마나 많은 범위를 커버하는지를 결정하는 경계를 먼저 명시하십시오. Temporal Cloud는 코드를 실행하지 않습니다. 워커는 자체 인프라에서 실행되며 상태, 타이머 및 이벤트 기록을 보유하는 Temporal 서비스에 연결됩니다. 크레딧은 해당 서비스 요금만 부담하며, 워커가 실행되는 컨테이너, 활동이 기록하는 데이터베이스, 에이전트 워크플로우가 호출하는 모델 API는 포함되지 않습니다. 자격은 단계와 자금 조달에 따라 다르며, 현재 조건은 getaiperks.com에 나와 있습니다.
Temporal의 실제 용도
Temporal은 내구성 있는 실행입니다. Go, TypeScript, Python, Java 또는 .NET으로 일반 코드로 다단계 프로세스를 작성하면 해당 코드를 실행하는 머신이 중간에 중단되더라도 플랫폼에서 반드시 완료를 보장합니다.
중요한 결정은 Temporal과 경쟁 오케스트레이터 간의 비교가 아닙니다. 이는 내구성 있는 실행 대 재시도 테이블, cron 작업 및 이미 Postgres에 가지고 있는 상태 열과의 비교입니다.
대부분의 팀은 우연히 같은 것을 구축합니다. 행에 있는 status 열거형, 중단된 레코드를 스캔하는 백그라운드 작업, 재시도 카운터, 데드 레터 테이블, 그리고 4단계가 성공했지만 5단계가 시간 초과되었을 때 발생하는 상황에 대한 점점 늘어나는 엣지 케이스 세트. 그것은 작동합니다. 또한 결코 멈추지 않고 계속 늘어납니다.
Temporal이 대체하는 것:
- 상태 기계. 진행 상황은 해석해야 하는 열이 아니라 코드 내의 위치입니다.
- 재시도 로직. 통합마다 다시 작성하는 대신 한 번 선언된 단계별 재시도 정책 (백오프 및 시간 초과 포함)
- 스케줄러. 배포 및 다시 시작 후에도 유지되는 내구성 있는 타이머를 통해 워크플로우는 30일 동안 잠들었다가 올바르게 깨어날 수 있습니다.
- 복구 이야기. 충돌, 재배포 또는 제로 스케일링 시 프로세스는 처음부터가 아니라 마지막으로 완료된 단계부터 재개됩니다.
- 가시성. 모든 단계, 입력, 출력 및 실패는 워크플로우 기록에 있으며, 대부분의 팀은 사고 발생 후에만 구축하는 디버깅 표면입니다.
가장 빠르게 성장하는 사용 사례는 에이전트 루프입니다. 모델 호출, 도구 호출, 유효성 검사, 재시도, 때로는 사람의 승인까지 몇 분 또는 며칠 동안 실행됩니다. 그 모양은 내구성 있는 실행이 구축된 것과 정확히 일치하며, 이것이 AI 팀이 Temporal에 원래 사용자가 알지 못했던 방향으로 도달하는 이유입니다.
솔직한 휴리스틱: 프로세스가 한 단계라면 큐를 사용하십시오. 돈, 불안정한 타사 API 또는 상대방의 사람이 관련된 5단계라면, 대신 수작업으로 작성할 상태 기계가 비싼 것이지 Temporal 인보이스가 아닙니다.
Temporal Cloud 가격이 확장될 때 작동하는 방식
Temporal Cloud는 경과 시간이 아니라 상태 전환에 대해 청구합니다. 30일 동안 잠자는 워크플로우는 거의 비용이 들지 않지만, 300밀리초 내에 완료되는 수다스러운 워크플로우는 상당히 더 많은 비용이 들 수 있으며, 이는 창업자들이 서버리스 청구에서 가져오는 직관을 뒤집습니다.
| 미터 | 무엇이 구동하는가 | 무엇이 급증하게 하는가 |
|---|---|---|
| 액션 | 상태 전환: 워크플로우 시작, 단계 예약 및 완료, 타이머 트리거, 신호 전달 | 대규모 일괄 처리의 각 항목에 대해 하나의 자식 워크플로우를 생성하는 팬아웃 |
| 활성 스토리지 | 현재 실행 중인 워크플로우의 이벤트 기록 | 새로 계속되지 않고 기록을 축적하는 장기 실행 워크플로우 |
| 보존 스토리지 | 보존 기간 동안 유지되는 완료된 워크플로우 기록 | 고유량 워크플로우에 적용된 관대한 보존 설정 |
| 네임스페이스 | 프로비저닝하는 각 격리된 네임스페이스 | 서비스당 환경당 하나의 네임스페이스, 곱해짐 |
| 지원 등급 | 사용량과 무관한 플랜 레벨 | 응답할 것이 있기 전에 응답 시간 보장을 위해 업그레이드 |
요율, 허용량 및 청구 가능한 액션의 정확한 목록은 변경됩니다. 모델링하기 전에 Temporal 자체 가격 책정 페이지를 기준으로 현재 수치를 확인하십시오.
청구서를 결정하는 산술은 실행당 액션 수입니다. 활동 8개, 타이머 2개, 신호 1개가 있는 주문 처리 워크플로우를 생각해보십시오. 각 활동에는 최소한 예약 전환과 완료 전환이 포함되므로, 실행당 비용은 대략 20 액션입니다. 월 100,000회 실행의 경우 약 2백만 액션입니다.
이제 디자인 결정 하나를 변경해 보겠습니다. 주문당 4개 항목의 자식 워크플로우를 팬아웃하면 동일한 사용자 동작으로 액션 수가 몇 배로 늘어납니다. 신규 고객 없음, 신규 기능 없음, 실질적으로 더 큰 청구서.
두 가지 제어가 대부분의 작업을 수행합니다. 각 항목에 대해 자식 워크플로우를 생성하는 대신 단일 활동 내에서 일괄 처리하고, 폴링 루프 대신 신호를 사용하십시오. 왜냐하면 조건을 확인하기 위해 매분마다 깨어나는 루프는 하루 종일 타이머 전환을 낭비하기 때문입니다. AI Perks는 크레딧 금액을 나열하며, 배율은 사용자가 제어할 수 있습니다.
Temporal 크레딧은 무엇과 함께 적용되는가
Temporal은 오케스트레이션에 대해서만 청구하기 때문에 Temporal 크레딧은 비정상적으로 깔끔하게 결합됩니다. 워크플로우가 실제로 터치하는 모든 것, 즉 컴퓨팅, 데이터베이스, 타사 API는 스타트업 프로그램을 운영하는 다른 사람에 의해 청구됩니다.
워커는 자체 인프라에서 실행되므로 클라우드 크레딧과 Temporal 크레딧은 거의 완벽하게 상호 보완적입니다.
- 클라우드 크레딧은 워커가 실행되는 컴퓨팅을 포함하며, Temporal Cloud가 흡수하지 않는 가장 큰 단일 비용입니다.
- 데이터베이스 크레딧은 활동이 읽고 쓰는 저장소를 포함하며, Temporal은 워크플로우 상태를 유지하지만 비즈니스 데이터는 유지하지 않습니다.
- 관측 가능성 크레딧은 메트릭, 추적 및 로그를 포함하며, Temporal은 수집 기반 청구에서 중요한 만큼 충분히 내보냅니다.
- 모델 및 API 크레딧은 에이전트 워크플로우 내의 LLM 호출을 포함하며, 오케스트레이션이 무료인 경우 지출이 이루어지는 곳입니다.
이 네 가지 중 세 가지를 보유한 팀은 동일한 기간 동안 전체 백엔드를 자금 조달했습니다. 어떤 보조금이 호환되고 어떤 보조금이 조용히 서로를 배제하는지는 AI Perks가 추적하는 내용입니다.
창업자들이 내구성 있는 실행에 대해 잘못 이해하는 점
가장 비싼 실수는 Temporal을 작업 큐로 사용하는 것입니다. 고유량, 단일 단계, 발사 후 망각 작업은 SQS 또는 Redis가 저렴하게 처리하는 것이며, 이를 내구성 있는 실행 엔진을 통해 라우팅하면 큐가 필요했던 것에 대해 오케스트레이션 비용을 지불하게 됩니다.
다섯 가지 실패 패턴 (비용 순서대로):
큐로 취급하는 것. 내구성 있는 실행은 길고, 다단계이며, 실패에 민감한 프로세스에서 가격 대비 가치를 발휘합니다. 썸네일 생성은 그런 것이 아닙니다.
비용 절감을 위해 자체 호스팅하는 것. 서버는 오픈 소스이며 무료이지만, 그 뒤의 지속성 계층은 그렇지 않습니다. 자체 클러스터를 실행하는 것은 데이터베이스, 업그레이드 및 모든 것을 복구하는 시스템에 대한 온콜 교대 근무를 소유해야 함을 의미합니다. 초기 단계에서는 일반적으로 관리형 요금보다 더 많은 비용이 들며, 크레딧은 전체 기간 동안 비교를 불공정하게 만듭니다.
기본적으로 팬아웃하는 것. 자식 워크플로우는 "각 항목에 대해 이 작업을 수행"을 표현하는 자연스러운 방법이며 액션 수를 곱하는 가장 빠른 방법입니다. 각 항목이 실제로 독립적인 재시도 및 가시성을 필요로 하는지, 또는 하나의 활동 내의 루프가 충분할지 결정하십시오.
결정론을 무시하는 것. 워크플로우 코드는 기록에서 재생되므로 결정론적이어야 하며, 이미 실행 중인 워크플로우를 편집하는 것은 버전을 변경하지 않으면 재생을 중단합니다. 첫 번째 프로덕션 배포가 아닌 첫 번째 사고 중에 버전 관리 이야기를 배우십시오.
종료 계획을 너무 늦게 하는 것. 워크플로우 정의는 일반 코드이지만 런타임 보장은 그렇지 않습니다. SDK를 가져오지 않는 함수에 비즈니스 로직을 유지하고, 첫 번째 전체 청구서에서 발견하는 대신 크레딧의 70% 소진 시점에 구독되지 않은 오케스트레이션이 어떻게 보이는지 결정하십시오.
개발 도구 예산에서 Temporal의 위치
Temporal은 CI, 관측 가능성, 데이터베이스 및 워커가 실행되는 컴퓨팅을 포함하는 개발 도구 예산의 한 줄입니다. Temporal 라인뿐만 아니라 전체 라인의 크기를 조정하는 것이 고정 크레딧이 의미 있는지 여부를 결정합니다.
getaiperks.com는 Temporal이 CI, 관측 가능성 및 플랫폼 프로그램과 함께 현재 금액과 함께 배치되는 개발 도구 범주를 추적합니다.
두 가지 디자인 결정이 다른 어떤 것보다 더 많은 비용을 이동시키며, 둘 다 따라잡기 어렵습니다.
- 팬아웃 모양. 항목당 자식 워크플로우 또는 활동 내의 루프는 액션 수에 대한 가장 큰 단일 승수입니다.
- 보존 기간. 완료된 기록은 보존되는 동안 청구되므로, 고유량 워크플로우에 대한 관대한 설정은 디버깅 편의성을 스토리지 라인으로 조용히 전환합니다.
자주 묻는 질문
Temporal 스타트업 프로그램의 가치는 얼마인가요?
Temporal Cloud에 대한 최대 $6,000의 크레딧으로, 관리형 서비스의 액션 및 스토리지에 적용됩니다. 월 수십만 건의 워크플로우 실행을 처리하는 초기 단계 제품의 경우, 이는 일반적으로 오케스트레이션에 대한 긴 런웨이입니다. 현재 금액 및 자격은 getaiperks.com에서 추적됩니다.
Temporal이 실제로 필요한가요, 아니면 작업 큐로 충분한가요?
큐는 단일 단계, 발사 후 망각 작업에 충분하며 단위당 더 저렴합니다. Temporal은 프로세스가 여러 단계이고, 돈 또는 불안정한 타사 API를 처리하고, 사람을 위해 며칠 동안 기다려야 하거나, 처음부터가 아니라 충돌 후 올바르게 다시 시작해야 하는 경우 가격 대비 가치를 발휘합니다.
내 Temporal 액션 수가 워크플로우 수보다 높은 이유는 무엇인가요?
Temporal은 워크플로우가 아닌 상태 전환에 대해 청구하기 때문입니다. 단일 실행에는 시작, 활동당 예약 및 완료 전환, 각 타이머 트리거 및 각 신호 전달이 포함됩니다. 실행당 20개 이상의 액션은 일반적이며, 항목당 자식 워크플로우를 생성하는 팬아웃 패턴은 이를 더욱 증폭시킵니다.
Temporal 크레딧은 컴퓨팅 또는 데이터베이스 요금을 포함하나요?
아니요. Temporal Cloud는 오케스트레이션 서비스를 실행하며, 워커는 자체 인프라에서 실행됩니다. 코드를 실행하는 컨테이너, 활동이 기록하는 데이터베이스, 워크플로우가 호출하는 모델 API는 별도의 인보이스입니다. Temporal 보조금과 함께 클라우드 보조금을 보유할 계획이며, getaiperks.com에서 추적됩니다.
Temporal 크레딧을 다른 스타트업 크레딧과 결합할 수 있나요?
예, 청구서가 전혀 겹치지 않기 때문에 특히 잘 결합됩니다. 클라우드 크레딧은 워커를 포함하고, 데이터베이스 크레딧은 데이터를 포함하며, 관측 가능성 크레딧은 메트릭 및 추적을 포함하고, 모델 크레딧은 에이전트 워크플로우 내의 LLM 호출을 포함합니다. AI Perks는 194개 회사에 걸쳐 $7.7M을 추적합니다.
Temporal 자체 호스팅이 Temporal Cloud보다 저렴한가요?
초기 단계에서는 드뭅니다. 서버는 오픈 소스이지만, 지속성 계층, 업그레이드, 용량 계획 및 모든 다른 시스템을 복구하는 시스템에 대한 온콜 교대 근무를 상속받습니다. 엔지니어링 시간이 실제 비용이며, 작은 규모 동안 관리형 요금을 흡수하는 크레딧은 비교를 바꿉니다.
워크플로우를 작성하세요. 작을 때는 다른 사람이 오케스트레이션 자금을 지원하도록 하세요.