この記事の対象読者
- Fastly を CDN として利用している方
- アクセス集中対策をエッジで実装したい方
- 仮想待合室やトラフィック制御の導入を検討している方
※ 特に記載がない限り本記事の記載内容はデフォルト設定での挙動となります。
Fastly の正式なサポート情報については、公式ドキュメントをご参照ください。
この記事の概要
CDN を利用している環境では、アクセス集中時の影響をできるだけオリジンに到達させない設計が重要になります。
本記事では、Fastly Compute 上で動作する NetFUNNEL の Fastly エージェントを例に、エッジでトラフィック制御を行う際の考え方と実装手順を整理します。
1. なぜエッジでアクセス集中対策を行うのか
従来の課題
アクセス集中が発生した際、アプリケーションやロードバランサー側で制御を行おうとすると、次のような課題が発生します。
- リクエストがオリジンに到達してから制御される
- DB やバックエンドが先に悲鳴を上げる
- スパイク時に影響範囲が一気に広がる
エッジで制御するという考え方
Fastly Compute を利用することで、
- オリジンに到達する前にトラフィックを制御
- 低レイテンシで即時に判定
- 既存のキャッシュ構成と制御ロジックを分離
といった設計が可能になります。
Fastly では、配信と制御を同じエッジ上で扱えるため、既存構成を大きく変更せずにアクセス集中対策を組み込める点が特徴です。
2. NetFUNNEL Fastly エージェントの特徴
NetFUNNEL の Fastly エージェントは、Fastly Compute 上で動作する WebAssembly ベースのエージェントです。
主な特徴
- WebAssembly ベースで高速かつセキュアに実行
- Fastly Compute の実行モデルに沿った実装
- Fastly 経由のリクエストをオリジン到達前に制御可能
Fastly Compute では、各リクエストが独立した Sandbox 環境で実行され、リクエストごとにインスタンスの生成・破棄が行われるステートレスな実行モデルを採用しています。
この仕組みにより、ユーザーコードは常に安全な状態で実行されます。
また、Fastly Compute は Rust、Go、JavaScript などの汎用的なプログラミング言語で実装できるため、開発者にとって導入コストが低い点も特徴です。
役割分担
-
Fastly Compute (NetFUNNEL エージェント)
- 制御対象リクエストの判定と振り分け
-
NetFUNNEL サーバー
- 待機制御、進入制御、キー管理
Fastly 側では「いつ制御するか」を判断し、
状態管理や待機制御は NetFUNNEL 側に委ねる構成になります。
3. 全体構成イメージ
Fastly は高速なゲートとして動作し、NetFUNNEL は制御ロジックを担います。
Fastly のエッジ実行モデルでは、このように責務を明確に分けた構成が取りやすい点が特徴です。
4. 実装手順
4.1 Compute Service の作成
Fastly コンソールから Compute を選択し、以下の流れで作成します。
- Create service をクリック
- Use starter kit を選択
- 適用するドメインを指定
- Default starter for Rust を選択
- Finalize and deploy でデプロイ
4.2 CNAME 設定と TLS
Compute Service 作成後、以下を設定します。
- Point your custom domain to Fastly
- TLS 証明書の発行
- DNS 側で CNAME 登録
これで、Fastly Compute がリクエストを受け取れる状態になります。
5. Origin Host の定義
Fastly の「Service configuration > Origins」で以下の 3 つの Hosts を定義します。
5.1 nf_core (NetFUNNEL コアサーバー)
- NetFUNNEL サーバーとの通信
| 項目 | 値 |
|---|---|
| Name | nf_core |
| Hostname (Address) | NetFUNNEL コアサーバーのアドレス |
5.2 nf_setting (NetFUNNEL 設定取得)
- NetFUNNEL 設定情報の取得
| 項目 | 値 |
|---|---|
| Name | nf_core |
| Hostname (Address) | NetFUNNEL 設定取得用のアドレス |
5.3 origin (アプリケーションオリジン)
- アプリケーションへのリクエスト転送
| 項目 | 値 |
|---|---|
| Name | nf_core |
| Hostname (Address) | オリジンサーバーのアドレス |
この 3 つを分けて定義することで、役割が明確になり、運用時の影響範囲も把握しやすくなります。
また、HTTPS で接続する場合、Certificate hostname や SNI hostname が自動的に入力されるケースもありますが、実際の運用ではこれらの値が正しいことを確認する必要があります。
6. Config Store を使った設定管理
NetFUNNEL の Fastly エージェントでは、Config Store を利用します。
6.1 Config Store 作成
- Fastly コンソールで Config Store を作成
- Store name：nf_config_store
6.2 必要な設定キー
最低限必要なキーは以下です。
| 項目 | 値 |
|---|---|
| CLIENT_ID | NetFUNNEL の テナント ID |
6.3 Config Store のリンク
- Config Store を Compute Service にリンク
- Activate して設定を有効化
7. NetFUNNEL エージェントのデプロイ
7.1 Fastly CLI の準備
ローカル環境で Fastly CLI をインストールします。
# macOS の場合
brew install fastly/tap/fastly
# インストール確認
fastly version
7.2 認証設定
# Fastly API トークンで認証
fastly profile create
7.3 fastly.toml の編集
NetFUNNEL エージェントの fastly.toml を編集します。
authors = []
cloned_from = "Compute service の ID"
description = "Fastly agent for NetFUNNEL - Rust implementation"
language = "rust"
manifest_version = 3
name = "NetFUNNEL-Fastly-Agent-Rust"
service_id = "Compute service の ID"
[local_server]
- NetFUNNEL のコンソールからダウンロードしたエージェントファイルを解凍し、fastly.toml を開きます。
- Fastly コンソールで Compute service の ID をコピーします。
- cloned_from と service_id にコピーした ID を設定します。
7.4 Compute へのデプロイ
NetFUNNEL のエージェントはソースコード形式で提供されるため、デプロイ前にビルドが必要になります。
fastly compute build
fastly compute deploy
これでエッジに NetFUNNEL エージェントが配置されます。
Fastly では、ローカルでビルド・確認したアーティファクトをそのままエッジに配備できるため、挙動をイメージしながら作業しやすい点も特徴です。
補足：Setup 機能について
Fastly Compute の fastly.toml には Setup 機能があります。
この機能を利用すると、初回デプロイ時のみ、
- Config Store の作成
- Backend（Host）の定義
といったセットアップ処理を自動化できます。
今回のように複数の設定が必要な連携では、作業効率の向上や設定ミスの削減に役立つ仕組みです。
8. トリガールールの考え方
待機列を適用する条件は、
NetFUNNEL コンソール側の「セグメント > トリガールール」で設定します。
8.1 設定例
トリガールールでは、以下のような条件設定ができます。
- ドメイン全体を指定
- 特定パスや URL を除外
- 下位パスを指定
- 特定 URL を指定
- 複数条件の組み合わせ
9. 動作確認とモニタリング
9.1 動作確認
- 通常アクセスの確認：制御対象外の URL にアクセスし、正常に表示されることを確認
- 制御対象の確認：トリガールールに該当する URL にアクセスし、待合室が表示されることを確認
- ログの確認：Fastly Compute の Real-Time Stats でリクエスト数や傾向を確認
Fastly 側では、エッジ通過時点のリクエスト数や傾向を把握できます。
オリジン側のメトリクスと組み合わせることで、
どこで負荷が発生しているかを切り分けやすくなります。
また、NetFUNNEL ではオリジンサーバーへ影響を与えず、簡易的な負荷テストを行うことも可能です。
9.2 モニタリング
- Fastly の Observability でリクエスト数などをモニタリング
- NetFUNNEL のモニタリング画面で待機状況と進入数をモニタリング
- 本番では、オリジン側でアプリケーションや DB などの使用率もモニタリング
10. 実装して感じたポイント
実際に実装して感じたメリットと注意点をまとめます。
メリット
-
オリジンの安定性が向上
- エッジで制御することで、オリジンへの負荷が大幅に軽減
- DB やアプリケーションサーバーの過負荷を防止
-
運用効率の向上
- シンプルな設定手順
- Fastly の Purge により設定変更を高速に反映
-
顧客体験の向上
- 順番待ち表示でユーザの不安や離脱を防止
- 秒単位のリアルタイム制御による顧客体験の向上
注意点
- 初回デプロイ時は Fastly CLI の認証設定を実施しておく
- NetFUNNEL の進入許容数やトリガールールの設計は慎重に行う
まとめ
Fastly Compute と NetFUNNEL を組み合わせることで、
- オリジン前での確実なトラフィック制御
- 低レイテンシな判定
- 柔軟でシンプル運用
が実現できます。
Fastly Compute は、配信基盤としてだけでなく、制御ロジックを実装するプラットフォームとしてもご活用いただけます。
アクセス集中対策を「アプリケーションの問題」ではなく「エッジで解決する設計」として考える際の一例として、参考になれば幸いです。