CDNetworks の CDN Pro は、CPU コストで CDN 価格モデルに革命をもたらします

インセンティブ

今日のコンテンツ配信ネットワーク (CDN) は、キャッシングとビットプッシュだけではありません。すべての主要なプレーヤーは、ビジネスをエッジ コンピューティングの領域にまで拡大しようとしています。などの高度なプラットフォーム CDNetworks の CDN Pro、 オファー プログラマビリティ エッジ サーバーで高度なロジックをサポートします。暗号化アルゴリズム、正規表現操作、データ圧縮などの一部のロジックは、計算負荷が非常に高くなる可能性があります。それらを CDN エッジで実行すると、リソースを大量に消費するこれらのアクティビティがオリジンからオフロードされるだけでなく、待ち時間が大幅に短縮され、エンドユーザーに満足のいくエクスペリエンスが提供されます。

ただし、この傾向は常に業界の価格モデルに反映されているわけではありません。ほとんどの CDN プロバイダーは、主にトラフィック量 (配信されたバイト数) または帯域幅 (ほとんど 95p) に基づいて課金を続けています。このモデルは、CDN コストの大部分が ISP から調達した帯域幅に基づいていた数十年前に作成されました。このモデルは、CDN が高度にキャッシュ可能な大容量ファイル (HCLF) を配信するためだけに使用された場合にうまく機能しました。ただし、これは今日では当てはまりません。たとえば、最新のサーバーは 40Gbps の HCLF を簡単に配信できます。ただし、太平洋全体で同じ帯域幅の動的 API サービスを高速化するには、500 台のサーバーが必要になる場合があります。データセンターのコストは、サーバーの数に大きく比例します。さまざまなサービスによるリソース消費のこの大きな格差は、CDN プロバイダーとその顧客の両方に多くの価格設定の課題をもたらします。

収益性を確保するために、CDN プロバイダーはすべての追加コストを GB あたりまたは Mbps あたりの価格に統合する必要があります。しかし、サービスが完全に導入される前に、発生する追加コストを正確に見積もることは現実的ではありません。顧客は通常、トラフィック量または帯域幅の概算値を提供できますが、必要なサーバーの数はわかりません。言うまでもなく、セルフサービス インターフェイスを介していつでもビジネス ロジックを変更できます。従来のモデルに基づいて価格を設定するには、多くの当て推量が必要です。その結果、すべての顧客とサービス タイプに公平な価格表を作成することはほとんど不可能です。解決策は非常に簡単です。CPU 消費に対する料金を導入することです。 CPU は、クラウドの開始以来、クラウド コンピューティングの請求項目でした。したがって、CDN が進化しているエッジ コンピューティングに採用されても驚くことではありません。

それはどのように機能しますか？

CDN プラットフォームのリソースは複数の顧客間で共有されるため、個々の顧客の使用状況を測定することは容易ではありません。最も一般的に使用される課金項目であるトラフィック量についても、正確に計算できるのはアプリケーション レイヤーからのデータだけです。下位層でネットワーク オーバーヘッドを収集し、それを各顧客に帰するのは非常に難しいため、ほとんどのプロバイダーはこれを気にしないことにします。各顧客の CPU 使用率を測定することは、さらに困難な場合があります。ただし、2016 年の CDN Pro プロジェクトの開始時に、これは必須の機能であると特定しました。NGINX に基づいてエッジ サーバーを構築することを決定したとき、私たちのチームはオープンソース バージョンの NGINX に大幅な変更を加えました。

NGINX has an “event-driven, non-blocking” architecture. Every request is “put to sleep” when waiting for I/O, awakened when some data is ready to be processed, and then put to sleep again when the processing is completed. This can occur many times during the lifecycle of a request. We use the function clock_gettime() on Linux to obtain the amount of CPU time, in nanoseconds, spent on each active interval of each request and accumulated along the way. At the end of the request’s lifecycle, we write the total CPU time consumed into the access log, the same way we treat the number of bytes transferred. The CPU time is included in the traffic summary log to generate low-latency, per-domain reports.

この方法では、各リクエストで NGINX プロセスが消費する CPU 時間を正確に測定できますが、以下は含まれません。
● ネットワーク インターフェイス カードまたはその他の I/O デバイスからの割り込みを処理するカーネル。
● NGINX メイン プロセスによって実行される一般的なタスク。
● ログの前処理や監視など、同じサーバーで実行されている他のサービス。

データ

前述のように、CDN Pro プラットフォームは、各ドメインで消費された CPU 時間を示す時系列レポートを提供します。指定された粒度の時間間隔ごとに、このメトリックを秒単位で返します。詳細については、 API ドキュメント.このレポートは、各間隔で配信されたバイト数を返すトラフィック量レポートに似ています。この場合、値を間隔の幅で割り、トラフィック帯域幅を決定します。 CPU レポートの場合、除算の結果は、各間隔で消費された CPU コアの数になります。もう 1 つの興味深い指標は、リクエストあたりの平均 CPU 時間です。この値は、CDN Pro が提供するさまざまなドメイン間で、数マイクロ秒から数秒の間で異なります。この値に影響を与える主な要因のいくつかを次に示します。

TLS ハンドシェイク: 次のグラフは、接続の順序別にグループ化されたリクエストごとの平均 CPU 時間を示しています。ラベル「1」の曲線は、各接続の最初の要求に対応します。それと後続のリクエスト「2」、「3」、および「4」との差は、TLS ハンドシェイクによって消費された CPU 時間を反映しています。 RSA-2048 証明書を使用した RSA 接続では、平均で約 2.0 ミリ秒が消費されていることがわかります。対照的に、ECDSA-256 証明書を使用した EC 接続は、約 0.9 ミリ秒を使用します。

TLS 再利用係数: TLS 接続が複数のリクエストで再利用される場合、ハンドシェイクのコストはそれらすべてのリクエストで共有されます。

キャッシュヒット状況: 通常、次のグラフに示すように、ヒットにかかる CPU 時間は少なくなります。

応答のサイズ: 応答が大きいほど、配信に必要な CPU パワーが大きくなります。

一定量のデータを配信するために必要な CPU リソースの量を決定するには、CPU 時間をトラフィック量で割ります。ドメインごとに大きな違いがあります。以下の表に示すように、HCLF を使用するドメインでは、1 GB あたり 1 秒未満しか必要としない場合がありますが、非常に動的な API サービスでは、数百倍の CPU が必要になる場合があります。

以下は、ギガバイトのトラフィックを持つ CDN Pro 顧客ドメインからの最近の統計です。 CPU 時間列は、各 GB のデータを処理するために必要な CPU 時間を示します。

(プライバシー保護のため、ドメイン名は非表示にしています。)

請求する

上記のデータは、最初のセクションで述べた点を明確に示しています。 CDN サービス料金をネットワーク トラフィックのみに基づいて設定するのは公平ではありません。このアプローチは、重量だけに基づいてスーパーマーケットですべての商品を課金するのと似ています。 CPU 時間による課金を導入することで、各顧客が使用したリソースに対して公平に課金されるようになります。 CDNetworks の Web サイトは、この新しい請求方法を正式に導入しました。その結果、関連するコストがより正確にカバーされるため、HTTPS リクエストの料金は削除されます。同時に、 すべてのサーバー グループのトラフィック量の価格 大幅に削減されます。どうぞご期待ください！