49ドルのStarterプランに申し込み、まさにその金額で予算を組んだ。ところが2枚目の請求書はその倍の額で届き、ダッシュボードのどこにも理由が書かれていない。プラン価格は決して本当の価格ではなかった。本当の価格は、クラウドから出ていくバイト数のほうだった。Synadia Cloudは、アプリケーションがNATSサービスから引き出す1ギガバイトごとに課金する。そして超過分こそが、定額サブスクリプションを、トラフィックに比例して膨らむ変動請求へと変える場所だ。
タイミングが重要だ。NATSは2026年11月10日にCNCFを卒業し、ダウンロード数は4億件を超え、2,000社以上が本番運用している。今まさに多くのチームが、セルフホストのNATSからマネージドクラウドへ移行し、運用の手間と引き換えに、これまで見たことのないメーターを手にしている。この記事では、Synadia Cloudがネットワークデータをどう価格設定するのか、現実的なボリュームでいくらになるのか、なぜ本番メッセージングは間接費ではなく売上原価に属するのか、そして粗利益率が真実を語るようにどう計上するのかを解説する。
Synadia Cloudがネットワークデータをどう価格設定するか
Synadiaはプランをチームに適用し、すべてのチームは無料のPersonalプランから始まる。有料プランのはしごは短い。Starterが月額49ドル、Proが月額199ドル、Enterpriseは個別契約だ。各ティアは、コネクション、ストリーム、ストレージの上限に加えて、一定量のネットワークデータをバンドルしている。Personalは10 GiB、Starterは100 GiB、Proは1 TiB、Enterpriseは2 TiBを含む。
含まれる枠がすべてを決める。なぜなら、それを超えた後に何が起きるかはプラン次第だからだ。無料のPersonalプランでは超過課金が一切ない。チームが10 GiBを超えると、次の請求サイクルまで、またはプランをアップグレードするまで、アクティブなコネクションも新規クライアントコネクションも切断される。デモ当日のトラフィック急増は、Personalではお金がかからない。代わりに可用性が犠牲になる。
すべての有料プランでは、超過分は計測され、請求サイクルの終わりに、トラフィックの種類ごとの料率で請求される。3つの料率があり、その差はほぼ1桁に及ぶ。
- クライアントおよびleafのegress: 1 GiBあたり9セント
- Gateway egress: 1 GiBあたり2セント
- Route ingress/egress: 1 GiBあたり1セント
このリストに何が欠けているかに注目してほしい。クラウドへのパブリッシュは計測されない。メーターが回るのは外へ流れるバイト数であり、つまりファンアウトがSynadiaの請求書すべてにおける乗数になる。1つのメッセージを1回パブリッシュし、10のコンシューマーに配信すれば、それはegressの10回分の配信であり、1回分ではない。
クライアントおよびleafのegressは1 GiBあたり9セント
これが実際の請求書を支配する料率であり、システムがデータを消費する2つの方法をカバーしている。クライアントegressは、クラウドからアプリケーションへ配信されるすべてのバイトだ。サブスクライバーへの配信、request-replyの応答、ストリームの読み取りが含まれる。leaf egressは同じ考え方をエッジへ拡張したものだ。leafノードは、自社ネットワーク上にあってクラウドハブへ外向きに接続し、そのリンクを越えてサブジェクトのinterestをブリッジするNATSサーバーであり、これによってファイアウォール背後の工場フロアや小売店舗が、インバウンドのファイアウォールルールなしでパブリッシュとサブスクライブを行える。
請求上の帰結は、エッジはタダではないということだ。クラウドがleafリンク経由で転送するすべてのバイトが、最高料率のegressになる。orders.createdのような絞り込んだサブジェクトに限定したleafサブスクリプションは、まさにそのサブジェクトだけを引く。すべてを引く怠惰なサブスクリプションは、9セントのリンクにファイアホース全体を流し込む。エッジでのinterestのスコープ設定は、単なる行儀の良さではなくコスト管理なのだ。
Gateway egressは1 GiBあたり2セント
Gatewayはクラスタをスーパークラスタへ結合する。通常はリージョンをまたいで結合し、あるリージョンのワークロードが別のリージョンのサブジェクトに到達できるようにする。Gateway egressは、それらのクラスタ間のレプリケーションおよびリージョン間トラフィックであり、1 GiBあたり2セントで計測される。
2セントは取るに足らないように聞こえるが、その下にあるクラウドプロバイダー自身の転送料金に積み重なることを忘れてはいけない。Synadia自身の運用ガイダンスは、gatewayトラフィック比率が高いことを修正すべき問題として指摘しており、アベイラビリティゾーン間の転送だけで各方向1ギガバイトあたり約1セントかかると述べている。リージョン間で大量にレプリケーションするチームは、同じバイトに対してプロバイダーの転送コストとSynadiaのgatewayメーターの両方を支払う。アーキテクチャが本当に地理的分散を必要としない限り、パブリッシャー、ストリーム、コンシューマーを1つのリージョンに留めよう。
Routeトラフィックは1 GiBあたり1セント
RouteはNATSサーバー間のクラスタ内リンクであり、クラスタを一貫した状態に保つルーティングとレプリケーションの通信を運ぶ。両方向で1ギガバイトあたり1セントというのは、意図的にこのページで最も安いメーターだ。これは、耐障害性のあるマルチサーバー構成を運用しても罰せられないようにするために存在する。routeトラフィックが請求書の意味のある行として現れるなら、何か構造的な問題がある。クライアントegressの1ドルに匹敵するには9倍のボリュームが必要なのだから。
現実的なボリュームでいくらになるか
ギガバイト単位の料率は掛け算して初めて意味を持つので、現実的な3つの形を見てみよう。
サービスが数個のサイドプロジェクトは、何も考えずにStarterの100 GiBに収まる。1日1万件の小さなメッセージを、それぞれ2つのコンシューマーに配信すると、月におよそ20 GiBが流れる。請求書は49ドルの定額で超過ゼロ、含まれるデータに対する実効料率は1 GiBあたり約49セントだ。この規模での間違いは、必要のない余裕のためにProへアップグレードすることだ。触れることのないギガバイトを保持するために月150ドルを余計に払うことになる。
中規模のSaaSプラットフォームが、注文と通知のイベントをワーカーと2つのエッジleafノードへストリーミングすると、月に約1.2 TiBのクライアントおよびleaf egressが流れる。Starterでは、これはおよそ1,129 GiBの超過で9セントを掛けると約102ドル、49ドルの基本料に上乗せして請求書は151ドルになる。それでもProの199ドルより安く、損益分岐点はほとんどのチームが推測するより遠い。StarterからProへの150ドルのステップがネットワークデータだけで元を取れるのは、月の超過が約1.6 TiBを超えてからだ。その線より下では、コネクション、ストリーム、ストレージのためにアップグレードするのであって、データ枠のためではない。アップグレードをクリックする前に、その割り算をしよう。
ここで地理的レプリケーションを加えよう。同じプラットフォームが災害復旧のためにストリームをリージョン間でミラーし、500 GiBのgateway egressが加わり、Proプランでクライアントegressの合計は2 TiB弱になる。クライアント超過は、含まれる1テラバイトを超えた960 GiBに9セントを掛けて86.40ドル。Gateway超過は500 GiBに2セントを掛けて10ドル。請求書は199ドルに96.40ドルを加えた295.40ドルとなり、超過の3分の2は、ホワイトボードに描いたときに誰も値付けしなかったレプリケーショントポロジーから来ている。これが驚くべきSynadia請求書の繰り返し現れる形だ。1つの大きな数字ではなく、ファンアウトとレプリケーションが小さな料率を増幅させるのだ。
なぜ本番メッセージングは間接費ではなく変動COGSなのか
製品を有料顧客に届けるメッセージングは、直接的な売上原価だ。それは利用量に比例し、何も売れなければ消える。そして投資家は、本番向けのコンピュート、データベース、ストレージ、帯域幅と並んで、粗利益率の線より上にそれが表示されることを期待する。
会計基準はここに余地を残している。一般に認められた原則は売上原価を厳密に定義しておらず、SaaSの粗利益率の実務が直接費テストでその隙間を埋めている。その支出が本番で顧客にサービスを提供するために存在するかを問うのだ。注文イベントを運ぶストリーム、顧客向けワーカーへファンアウトする配信、顧客にサービスを提供するエッジ拠点へ供給するleafリンクは、すべて該当する。先週のトラフィックを再生するステージングアカウント、ロードテストのトピック、開発者サンドボックスのサブスクリプションは該当しない。それらは研究開発または一般間接費に属する。
本番の境界線がすべてだ。1枚のSynadia請求書は、すべてのアカウントとすべてのトラフィック種類をまとめてしまうので、ダッシュボードのアカウント別利用量を使って毎月分割する。分割を省くチームは、たいてい都合の良い方向に間違え、インフラを間接費に埋め、ユニットエコノミクスでは正当化できない粗利益率を報告する。デューデリジェンスのレビューはそれを半日で再分類し、修正後の利益率が高くなることは決してない。
実際に支払う正味額を計上しよう。未使用の含まれるデータは資産ではなく、無料のPersonalティアは収益ではないので、総額に戻したり繰り越したりするものは何もない。余裕を可視化したいなら、消費ギガバイトと含まれるギガバイトをメトリクスで追跡し、元帳の仕訳は現金コストのままにしておこう。
利益率が真実を語るように計上する方法
メッセージングには、一般的なクラウドやソフトウェアの行に混ぜ込むのではなく、独自の売上原価アカウントを与えよう。cloud messagingのような専用アカウントを設ければ、その月の支出をその月のegressギガバイトで割り、真の1 GiBあたりコストを見ることができる。これは、ファンアウトの成長が利益率を食っているかどうかを教えてくれる数字だ。
Synadiaの請求は月末後に確定するので、見越し計上する。締めの時点でegressメトリクスから本番部分を見積もり、請求書が届いたら精算し、非本番部分は売上原価に入れない。以下は1月の完全なサイクルで、本番が推定291.20ドル、実際の請求書が295.40ドル、開発用に別の49ドルのStarterチームがある場合だ。
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Expenses:CostOfSales:Cloud-Messaging USD
2026-01-01 open Expenses:Research:Cloud-Sandbox USD
2026-01-01 open Liabilities:Accrued:Synadia USD
2026-01-31 * "Synadia" "1月本番見積、Pro基本料にクライアント・leaf超過とgateway超過を加算"
Expenses:CostOfSales:Cloud-Messaging 291.20 USD
Liabilities:Accrued:Synadia -291.20 USD
2026-02-03 * "Synadia" "1月請求が295.40で確定、加えて開発チーム49.00"
Liabilities:Accrued:Synadia 291.20 USD
Expenses:CostOfSales:Cloud-Messaging 4.20 USD
Expenses:Research:Cloud-Sandbox 49.00 USD
Assets:Cash:Operating -344.40 USD見越し額は、少なくとも月次でダッシュボードのアカウント別ネットワーク利用量と照合し、クライアント、gateway、routeトラフィックを別々の行にして、1つの急増が他の横ばいのトレンドに隠れないようにしよう。元帳をプレーンテキストで管理しているなら、ドキュメントのコスト追跡パターンは、トラフィック種類別のメッセージング分割へ自然に拡張できる。
避けるべき分類の罠が1つある。追加のleafノード、接続パッケージ、ストレージといったアドオンは、本番に供するものであれば依然としてメッセージングコストだが、自前のセルフホストNATSシステムを接続するRemote Systemアドオンはハイブリッドアーキテクチャの選択だ。そのリンクが現在の顧客にサービスを提供するためではなく、レガシーのオンプレミスシステムを存続させるために存在するなら、それはそのシステムのコストが存在する場所に属し、売上原価には属さない。
Egressに利益率を食わせない5つの管理策
ファンアウトの規律とペイロードサイズから始めよう。この2つで乗数と被乗数の両方に対処でき、どちらも午後ひとつで終わる修正だ。
1. すべての配信を購入として扱う
各サブスクライバーへの配信はそれぞれ個別に計測されるegressなので、誰が何を受け取るかを監査しよう。各コンシューマーが処理するイベントだけを受け取るよう、厳密なサブジェクトスコープを設定し、廃止されたワーカーの死んだサブスクリプションを削除しよう。フィルタリングされていないファンアウトは、コンシューマーが到着時に捨てるメッセージの配信に対しても支払う。これは、サブスクリプションごとに1行の修正で済む純粋な無駄だ。
2. ペイロードをダイエットさせる
イベントはスリムに保とう。完全なドキュメントはオブジェクトストレージに保存し、コンシューマーが必要とする識別子とともに参照を送る。クレームチェックパターンだ。埋め込まれたBLOB、重複した顧客レコード、冗長なデバッグコンテキストをホットパスから取り除こう。削除した1ギガバイトごとに、それを運んだすべてのメッセージのすべての配信で9セントを節約できる。だからこそ、ペイロードサイズは節約のレバーとしてはプランの見直しよりもたいてい勝るのだ。
3. leafノードのinterestを厳密にスコープする
leafリンクは、反対側にinterestがあるサブジェクトだけを転送する。だからこそエッジのサブスクリプションが9セントのパイプのバルブになる。四半期ごとにすべてのleafサブスクリプションを見直し、それぞれが今も稼働中のエッジワークロードに供していることを確認しよう。1つの店舗に残った忘れられたキャッチオールのサブスクリプションが、請求書で最も高価なリンクにサブジェクト空間全体を静かに引きずり込むことがある。
4. ストリームをコンシューマーの近くに保つ
アーキテクチャが許す限り、パブリッシャー、ストリーム、コンシューマーを1つのリージョンに併置しよう。リージョン間レプリケーションは、同じバイトに対してgateway超過とプロバイダーの基礎的な転送料金の両方を支払うので、すべてのgatewayギガバイトは必要が証明されるまで有罪として扱おう。災害復旧が本当に第2リージョンを必要とするなら、復旧目標を満たす最小のサブジェクト集合をレプリケーションし、アカウント全体を複製しないこと。
5. プランを適正化し、バーンレートを監視する
消費ギガバイトと含まれるギガバイトを月次ではなく週次で追跡しよう。超過はサイクルが締まるまで静かに積み上がるからだ。データ上の理由でStarterをProにアップグレードする前に1.6 TiBの損益分岐点を忘れずに、逆方向のPersonalの崖も忘れないこと。無料ティアでプロトタイピングするチームは、気にするトラフィックの急増の前にアップグレードすべきだ。Personalは超過に対して請求書ではなくコネクションの切断で応じるのだから。
メッセージングコストの月末チェックリスト
数字が信頼できる状態を保つために、毎月同じようにループを閉じよう。
- アプリケーションログの論理メッセージ数ではなく、ダッシュボードからトラフィック種類別のegressギガバイトを取得する。
- 各種類の支出をそのギガバイトで割り、9セント、2セント、1セントのベンチマークと比較する。
- 配信数をパブリッシュ数で割って、サブジェクトごとの配信ファンアウトを計算する。設計比率を超えるものはサブスクリプションレビューの価値がある。
- 本番、ステージング、サンドボックスの利用量をアカウント別に分割し、売上原価に入ったのが本番のみであることを確認する。
- 先月の見越し額を確定した請求書に精算し、差異を見積もりに繰り越す。
- 総egressに占めるgatewayトラフィックの割合を確認し、すべてのリージョン間フローに今もアーキテクチャ上の理由があることを確認する。
- その月中に作成されたすべての新しいアカウント、ストリーム、leafノードが本番タグ付けと厳密なサブジェクトスコープを引き継いでいることを確認する。
今日、ダッシュボードから今月のSynadiaネットワークの行を取得し、総egressギガバイトを含まれる枠と比較しよう。超過が顧客利用量より速く成長しているなら、ファンアウトかレプリケーションが料率を増幅させている。最も安く手に入る利益率の改善は、より大きなペイロードと緩いサブスクリプションではなく、より小さなペイロードと厳密なサブスクリプションだ。
