さくらのCDN料金体系の裏をかいた激安AWS Firehoseとして使う「ずるい使い方」

CDNといえば、大量のアクセスを高速・安定的にさばくためのインフラである。しかし、さくらインターネットのCDNサービス「ウェブアクセラレータ」には、料金体系の特性を活かした「ずるい使い方」がある。

それは、AWSでいうAmazon Data Firehoseのようなストリーミングデータの収集基盤としてほぼ無料で使うという方法だ。

弊社のサービスでも実際に活用しているので、その仕組みを紹介したい。

ウェブアクセラレータにログ収集機能が追加 ​

少し前になるが、さくらインターネットは2024年11月にウェブアクセラレータへアクセスログ機能を追加した。

この機能では、ユーザーからのリクエスト内容やレスポンスステータスなどを記録したアクセスログが、さくらのクラウドオブジェクトストレージに定期的にアップロードされる。フォーマットはgzip圧縮されたJSON Lines形式である。

以前はCDNとしてトラフィックを分散・配信する機能のみで、生ログを取得する手段がなかった。このログ機能の追加により、新たな活用の道が開けた。

料金体系の特徴 ​

ウェブアクセラレータの料金は非常にシンプルである。

• 課金対象はアウトバウンド転送量のみ
• 5円/GiB（税込）
• インバウンド転送量は無料
• リクエスト数による課金もなし
• 初期費用・固定費もなし

この「アウトバウンドのみ課金」という特性が、ずるい使い方の鍵となる。

ストリーミングデータ収集の仕組み ​

通常、ユーザーの行動データを大量に収集するには、Amazon Data Firehoseのようなストリーミングデータ基盤を使う。しかしこれらはリクエスト数に応じて課金されるため、トラフィックが増えるとコストも膨らんでしまう。

ウェブアクセラレータを使ったアプローチは異なる。

データ送信の流れ ​

ユーザーのブラウザ
    ↓ GETリクエスト（URLパラメータにデータを含める）
CDN（ウェブアクセラレータ）
    ↓ ログに記録
オブジェクトストレージ
    ↓ ログファイルを解析
集計結果

1. JavaScriptでユーザーの行動データを収集
2. データをGETパラメータとしてCDNにリクエスト
3. CDNは1x1ピクセルの透過GIFなど最小限のレスポンスを返す
4. リクエストURLはログに記録される
5. 後でログを解析してデータを集計

なぜコストが抑えられるのか ​

ポイントは、ユーザーからのインバウンドデータ（GETパラメータ）は課金されない点にある。

GETパラメータにどれだけデータを詰め込んでも、それはインバウンドトラフィック。一方、レスポンスとして返すのは1x1ピクセルの画像（数十バイト）程度。アウトバウンドはほぼゼロに近い。

// 例：ユーザーの行動データを送信
const data = {
  event: 'click',
  target: 'buy_button',
  timestamp: Date.now(),
  viewport: `${window.innerWidth}x${window.innerHeight}`
}
const params = new URLSearchParams(data)
new Image().src = `https://your-cdn.sakura.ad.jp/track.gif?${params}`

このリクエストがログに残り、後で集計できる。

オリジン問題との相性 ​

ブラウザのセキュリティ制約（同一オリジンポリシー）により、JavaScriptは基本的に配信元と同じオリジンにしかデータを送信できない。これが意外とCDN活用の追い風になるのだ。

つまり、JavaScriptライブラリ自体をCDNで配信し、同じドメインでデータも受け取るという構成にすれば、オリジンの問題をクリアしつつ、すべてがCDN上で完結する。

• JavaScriptファイルのサイズが小さければ、アウトバウンド課金はわずか
• ユーザーからのデータ送信（インバウンド）は無料
• 別途APIサーバーを用意する必要もない

この構成は非常に収まりがよく、後述するSpeed is MoneyやRanklet4でも採用している。

実際の活用事例 ​

弊社ではこの手法を2つのサービスで活用している。

Speed is Money ​

Speed is Moneyは、Webサイトの体感スピードとコンバージョンの相関を可視化するサービスである。

サイトに埋め込んだタグが、訪問者ごとの体感時間やコンバージョン状況をストリーミングデータとして収集する。以前は自前のインフラで処理していたが、ウェブアクセラレータのログを活用することで、大幅にコストを削減できた。

Ranklet4 ​

Ranklet4は、Webサイトのアクセスランキングを提供するサービスだ。

ランキングの表示回数や、どの順位がクリックされたかといったインタラクションデータを収集する必要がある。月間数億PV規模のトラフィックを扱うが、このログ収集にかかるコストは月額数百円〜数千円程度で済んでいる。

同等のトラフィックをData Firehoseで処理したらどうなるか。コストは桁違いに膨らむだろう。

Amazon Data Firehoseとの比較 ​

Data Firehoseは柔軟で高機能だが、トラフィックに比例してコストが増える。ウェブアクセラレータは制約があるものの、大量のリクエストを低コストでさばける。

CloudFrontでは同じ手が使えない ​

同じCDNでも、AWS CloudFrontでこの手法を真似るのは要注意である。

CloudFrontの料金体系では、データ転送量に加えてリクエスト数に応じた課金が発生する。HTTPSリクエストの場合、1万リクエストあたり$0.01程度（リージョンにより異なる）だ。

一見わずかに思えるが、ストリーミングデータの収集では数百万〜数億リクエストになることも珍しくない。1億リクエストなら$100程度のリクエスト課金が上乗せされる計算になる。

一方、さくらのウェブアクセラレータはリクエスト数による課金がない。アウトバウンド転送量のみで課金されるため、レスポンスを最小限に抑えれば、リクエスト数がいくら増えてもコストに影響しない。この料金体系の違いが、今回の「ずるい使い方」を成立させている。

注意点と制約 ​

1時間のタイムラグ ​

ログは1時間ごとに生成・アップロードされる。リアルタイムやニアリアルタイムの処理が必要な用途には向かない。

ただし、日次や週次で集計するようなユースケースなら、1時間のラグは許容範囲だろう。

データサイズの制限 ​

GETパラメータには実質的に約2KB程度の制限がある。大きなデータを送る場合は、複数のリクエストに分割するか、データを圧縮する工夫が必要になる。

ログ解析の実装 ​

Firehoseと異なり、ログの解析ロジックは自前で実装する必要がある。JSON Linesをパースし、URLパラメータをデコードして集計する処理を用意する。

# ログ解析の例（Python）
import gzip
import json
from urllib.parse import parse_qs, urlparse

with gzip.open('access_log.json.gz', 'rt') as f:
    for line in f:
        record = json.loads(line)
        url = record.get('request_uri', '')
        params = parse_qs(urlparse(url).query)
        # データを集計...

まとめ ​

CDNの料金体系は通常、大容量のコンテンツ配信を前提に設計されている。しかしウェブアクセラレータの「アウトバウンドのみ課金」という特性を逆手に取ると、ストリーミングデータの収集基盤としてほぼ無料で活用できる。

やや「ずるい」使い方ではあるが、公式に禁止されているわけではない。大量のユーザーデータを収集したいが、Data Firehoseのようなサービスのコストが気になる——そんなときの選択肢として覚えておいて損はないのではないだろうか。

なお、さくらインターネットがこの使い方を想定しているかは定かではない。将来的に料金体系が変わる可能性もあるので、本番導入の際はその点も考慮してほしい。