Temporal Startup Programで得られるもの
Temporalは、耐久性のある実行プラットフォームのマネージドバージョンであるTemporal Cloudの利用に対し、最大6,000ドルのクレジットを提供します。このクレジットは、Temporalが課金する以下の項目をカバーします：アクション、アクティブストレージ、および保持ストレージ。
AI Perksは、これを194社で770万ドルのクレジットとともに追跡しています。
まず、6,000ドルがどの程度役立つかを決定する境界線を述べます。Temporal Cloudはあなたのコードを実行しません。あなたのワーカーは独自のインフラストラクチャ上で実行され、状態、タイマー、イベント履歴を保持するTemporalサービスに接続します。クレジットは、そのサービス料金のみをカバーし、それ以外はカバーしません：ワーカーを実行するコンテナ、アクティビティが書き込むデータベース、エージェントワークフローが呼び出すモデルAPIなどは含まれません。適格性は、あなたのステージと資金調達状況によって異なり、現在の条件はgetaiperks.comに記載されています。
Temporalの実際の用途
Temporalは耐久性のある実行です：Go、TypeScript、Python、Java、または.NETで通常のコードとして複数ステップのプロセスを記述すると、実行中のマシンが途中でクラッシュしてもプラットフォームは完了を保証します。
重要なのは、Temporalと競合するオーケストレーターのどちらかではなく、耐久性のある実行と、Postgresにすでに存在するリトライテーブル、cronジョブ、ステータスカラムのどちらかです。
ほとんどのチームは偶然同じようなものを作ります。行のstatus列挙型、停止したレコードをスキャンするバックグラウンドジョブ、リトライカウンター、デッドレターテーブル、そしてステップ4は成功したがステップ5がタイムアウトした場合の状況に関する、ゆっくりと増え続けるエッジケースのセット。これは機能します。しかし、それは決して成長を止めません。
Temporalが置き換えるもの：
- **ステートマシン。**進捗は、解釈する必要のある列ではなく、コード内の位置です。
- **リトライロジック。**インテグレーションごとに書き直すのではなく、一度宣言された、バックオフとタイムアウト付きのステップごとのリトライポリシー。
- **スケジューラ。**デプロイや再起動に耐える耐久性のあるタイマー。これにより、ワークフローは30日間スリープし、正しくウェイクアップできます。
- **リカバリストーリー。**クラッシュ、再デプロイ、またはゼロへのスケールダウン後も、プロセスは最初からではなく、最後に完了したステップから再開します。
- **可視性。**すべてのステップ、入力、出力、および障害はワークフロー履歴に記録され、ほとんどのチームがインシデント後にのみ構築するデバッグサーフェスとなります。
最も急速に成長しているユースケースはエージェントループです：モデル呼び出し、ツール呼び出し、検証、リトライ、時折の人間による承認、数分または数日かけて実行されます。この形状はまさに耐久性のある実行が構築された理由であり、AIチームがTemporalにたどり着くのは、その当初のユーザーとは異なる方向からです。
正直なヒューリスティック：プロセスが1ステップの場合は、キューを使用します。お金、不安定なサードパーティAPI、または反対側の人間が関わる5ステップの場合は、手書きで作成するステートマシンが高価なのであり、Temporalの請求書ではありません。
Temporal Cloudの価格設定はスケールするとどのように動作するか
Temporal Cloudは、経過時間ではなく状態遷移に対して課金します。30日間スリープするワークフローはほとんどコストがかかりませんが、300ミリ秒で完了するチャッティなワークフローはかなりコストがかかる場合があり、これは創業者たちがサーバーレス課金から持ち込む直感に反します。
| メーター | 何がそれを駆動するか | 何がそれを急増させるか |
|---|---|---|
| アクション | 状態遷移：ワークフローの開始、ステップのスケジュールと完了、タイマーの発火、シグナルの配信 | 大規模バッチの各項目に対して1つの子ワークフローを生成するファンアウト |
| アクティブストレージ | 現在実行中のワークフローのイベント履歴 | 新規として継続するのではなく、履歴を蓄積する長寿命ワークフロー |
| 保持ストレージ | 保留期間中保持されるクローズドワークフロー履歴 | 高ボリュームワークフローに適用される寛大な保持設定 |
| 名前空間 | プロビジョニングする各分離された名前空間 | サービスごとに環境ごとに1つの名前空間、それに倍率をかけたもの |
| サポートティア | プランレベル、使用量とは無関係 | 応答すべきものがなくても、応答時間保証のためにアップグレードする |
レート、許容値、および課金対象のアクションの正確なリストは変更されます。モデリングを行う前に、Temporal独自の価格ページで現在の数値を検証してください。
請求額を決定する計算は、実行あたりのアクション数です。8つのアクティビティ、2つのタイマー、1つのシグナルを持つ注文履行ワークフローを例にとります。各アクティビティには、少なくとも1つのスケジュール遷移と1つの完了遷移が含まれるため、実行あたりのコストは約20アクションです。月間100,000実行では、約200万アクションになります。
ここで、設計上の決定を1つ変更します。注文あたり4つのアイテムを、アイテムあたり1つの子ワークフローにファンアウトすると、同一のユーザー行動でもアクション数が数倍になります。新規顧客なし、新機能なしで、請求額が大幅に増加します。
2つのコントロールがほとんどの作業を行います。アイテムごとに子ワークフローを生成するのではなく、単一のアクティビティ内でバッチ処理を行い、ポーリングループではなくシグナルを使用します。なぜなら、条件を確認するために毎分ウェイクアップするループは、一日のタイマー遷移を無駄にするからです。AI Perksはクレジット額をリストしていますが、倍率はあなた次第です。
Temporalクレジットはどのクレジットとスタックできるか
Temporalクレジットは、Temporalがオーケストレーションにのみ課金するため、異常にきれいにスタックします。ワークフローが実際に触れるもの、つまりコンピューティング、データベース、サードパーティAPIは、スタートアッププログラムを実行している他の誰かが請求します。
ワーカーは独自のインフラストラクチャ上で実行されるため、クラウドクレジットとTemporalクレジットはほぼ完全に補完的です：
- クラウドクレジットは、ワーカーが実行されるコンピューティングをカバーします。これはTemporal Cloudが吸収しない最大のコストです。
- データベースクレジットは、アクティビティが読み書きするストアをカバーします。Temporalはワークフローの状態を永続化しますが、ビジネスデータは永続化しません。
- オブザーバビリティクレジットは、メトリクス、トレース、ログをカバーします。Temporalは、インジェスト価格の請求書で重要となる十分な量を生成します。
- モデルおよびAPIクレジットは、エージェントワークフロー内のLLM呼び出しをカバーします。これは、オーケストレーションが無料になった後の支出先です。
これらの4つのうち3つを保持しているチームは、同じ期間、バックエンド全体を資金調達しています。AI Perksは、どの付与が互換性があり、どれが静かに互いを排除するかを追跡しています。
耐久性のある実行について創業者たちが誤解していること
最も高価な間違いは、Temporalをジョブキューとして使用することです。高ボリューム、単一ステップ、ファイアアンドフォーゲットの作業は、SQSやRedisが安価である理由であり、耐久性のある実行エンジンを介してルーティングすると、キューが必要だったものに対してオーケストレーション料金を支払うことになります。
5つの障害パターン（コスト順）：
**キューとして扱うこと。**耐久性のある実行は、長くて複数ステップで、障害に敏感なプロセスでその価格に見合う価値を発揮します。サムネイル生成はそうではありません。
**節約のためにセルフホストすること。**サーバーはオープンソースで無料ですが、その背後にある永続化レイヤーは無料ではありません。独自のクラスターを実行することは、データベース、アップグレード、および他のすべてを復旧するシステムのオンコールローテーションを所有することを意味します。初期段階では、通常、マネージド請求書よりもコストがかかり、クレジットは全期間にわたって比較を歪めます。
**デフォルトでのファンアウト。**子ワークフローは「各アイテムに対してこれを実行する」を表現する自然な方法であり、アクション数を増やす最も速い方法です。各アイテムが独立したリトライと可視性を本当に必要とするのか、それとも1つのアクティビティ内のループで十分なのかを決定してください。
**決定論を無視すること。**ワークフローコードは履歴から再生されるため、決定論的である必要があります。すでに実行中のワークフローを編集すると、バージョン管理されていない変更は再生を壊します。最初のインシデントではなく、最初の本番デプロイ前にバージョン管理のストーリーを学んでください。
早期すぎる時期の出口計画。ワークフロー定義は通常のコードですが、実行時保証はそうではありません。SDKをインポートしない関数にビジネスロジックを保持し、クレジットの70%が消費された時点で、最初の完全な請求書で発見するのではなく、サブスクリプションなしのオーケストレーションがどのようになるかを決定してください。
開発ツールの予算におけるTemporalの位置づけ
Temporalは、CI、オブザーバビリティ、データベース、およびワーカーが実行されるコンピューティングも含まれる開発ツール予算の1行です。Temporalの行だけでなく、ライン全体をサイジングすることが、固定クレジットが意味をなすかどうかを決定します。
getaiperks.comは、TemporalがCI、オブザーバビリティ、およびプラットフォームプログラムとともにその現在の金額で位置づけられている開発ツールカテゴリを追跡しています。
2つの設計上の決定は、他の何よりも請求額に影響を与え、どちらも後付けするのは困難です：
- **ファンアウト形状。**アイテムごとに子ワークフロー、または1つのアクティビティ内のループは、アクション数に対する最大の単一乗数です。
- **保持期間。**クローズド履歴は保持されている間課金されるため、高ボリュームワークフローでの寛大な設定は、デバッグの利便性をストレージラインに静かに変換します。
よくある質問
Temporalスタートアッププログラムの価値はどれくらいですか？
Temporal Cloudのクレジットとして最大6,000ドルで、マネージドサービスでのアクションとストレージをカバーします。月間数百 ألفのワークフロー実行を実行する初期段階の製品の場合、これは通常、オーケストレーションに特化した長いランウェイとなります。現在の金額と適格性はgetaiperks.comで追跡されています。
Temporalは本当に必要ですか、それともジョブキューで十分ですか？
キューは、単一ステップのファイアアンドフォーゲット作業には十分であり、ユニットあたりのコストは低いです。Temporalは、プロセスが複数ステップあり、お金や不安定なサードパーティAPIに触れ、人間を数日待つ必要があり、またはクラッシュ後に最初からではなく正しく再開する必要がある場合に、その価格に見合う価値を発揮します。
なぜ私のTemporalアクション数がワークフロー数より多いのですか？
Temporalはワークフローではなく状態遷移に課金するためです。単一の実行には、開始、アクティビティごとのスケジュールおよび完了遷移、各タイマーの発火、および各シグナルの配信が含まれます。実行あたり20以上のアクションが一般的であり、アイテムごとに子ワークフローを生成するファンアウトパターンはさらにそれを乗算します。
Temporalクレジットは私のコンピューティングまたはデータベースの請求をカバーしますか？
いいえ。Temporal Cloudはオーケストレーションサービスを実行し、ワーカーは独自のインフラストラクチャ上で実行されます。コードを実行するコンテナ、アクティビティが書き込むデータベース、およびワークフローが呼び出すモデルAPIは、個別の請求書です。AI Perksで追跡されているように、Temporalグラントと並行してクラウドグラントを保持することを計画してください。
Temporalクレジットを他のスタートアップクレジットと組み合わせることはできますか？
はい、請求が重複しないため、特にうまくスタックします。クラウドクレジットはワーカーをカバーし、データベースクレジットはデータをカバーし、オブザーバビリティクレジットはメトリクスとトレースをカバーし、モデルクレジットはエージェントワークフロー内のLLM呼び出しをカバーします。AI Perksは194社で770万ドルを追跡しています。
Temporalをセルフホストすることは、Temporal Cloudよりも安価ですか？
初期段階ではまれです。サーバーはオープンソースですが、永続化レイヤー、アップグレード、容量計画、および他のすべてのシステムを復旧するシステムのオンコールローテーションを引き継ぐことになります。エンジニアリング時間は実際のコストであり、小規模である間にマネージド請求書を吸収するクレジットは、比較を変えます。
ワークフローを記述してください。小規模な間は、オーケストレーションは他の誰かに資金提供させてください。