whipで何ができる？具体的な事例と活用術

By /

はい、承知いたしました。Fastlyのwhipツールについて、約5000語の詳細な解説記事を作成します。

Fastly whip徹底解説：ローカルVCL開発・テストのための強力ツール

はじめに

Fastlyのようなエッジクラウドプラットフォームを利用する開発者にとって、VCL（Varnish Configuration Language）はサービスの振る舞いを制御する非常に強力なツールです。しかし、VCLの開発とテストには特有の課題が伴います。特に、変更を試すたびにデプロイが必要になり、開発サイクルが遅くなることは珍しくありません。また、本番環境に近い形でテストを行うには、実際のトラフィックを流す必要があり、これが難しい場合やリスクを伴う場合もあります。

こうした課題を解決するために、Fastlyはwhipというコマンドラインツールを提供しています。whipは、Fastlyサービスにデプロイすることなく、ローカル環境でVCLの動作をシミュレーションし、テストを行うことができる革新的なツールです。これにより、開発者はVCLの変更を迅速に反復し、意図した通りに動作するかどうかを確認できます。

本記事では、Fastly whipの機能、使い方、具体的な事例、そして開発ワークフローへの統合方法まで、詳細に解説します。約5000語というボリュームで、whipを最大限に活用するためのあらゆる側面を網羅することを目指します。

第1章 whipとは？その目的と基本概念

1.1 VCLテストの課題

FastlyのVCLは、HTTPリクエスト/レスポンスの処理、キャッシュ制御、バックエンドの選択、エラーハンドリングなど、多岐にわたる処理を記述できます。この柔軟性と能力がFastlyの大きな強みですが、その反面、開発・テストにはいくつかの困難が伴います。

  • デプロイメントの必要性: VCLの変更をFastlyサービスに反映させるためには、アクティベートというプロセスが必要です。このプロセスは通常数十秒から数分かかります。小さな変更を何度も試す場合、この待機時間が開発効率を著しく低下させます。
  • 本番環境への影響: テストのためにVCLをアクティベートすると、その変更は本番環境のトラフィックに影響を与える可能性があります。慎重なテスト計画とロールアウト戦略が必要になります。
  • 依存関係の再現: VCLはバックエンドサーバーからのレスポンスや、Fastlyが提供する各種機能（Dictionaries, ACLs, GeoIPなど）に依存して動作することがあります。これらの依存関係を含めたテスト環境をローカルで構築するのは容易ではありません。
  • デバッグの難しさ: Fastlyサービス上でのVCLのデバッグは、ログの確認やFastlyのトレース機能を利用して行いますが、ローカルでのステップ実行や詳細な変数の確認のような、よりインタラクティブなデバッグ手法は限定されます。

1.2 whipの登場とその解決策

whipは、これらの課題に対するFastlyからの回答です。whipは、Golangで書かれたコマンドラインツールであり、ローカル環境でVCLパーサーとエンジンをエミュレートすることで、FastlyサービスのVCL処理フローをシミュレーションします。

whipが提供する主な解決策は以下の通りです。

  • ローカルでのVCL実行: Fastlyサービスにデプロイすることなく、手元のVCLファイルを直接指定して実行できます。これにより、デプロイ待ちの時間をなくし、即座に結果を確認できます。
  • Fastly環境のシミュレーション: HTTPリクエスト、レスポンス、バックエンドへのアクセスなどをコマンドラインオプションで定義・シミュレーションできます。これにより、様々な条件でのVCLの振る舞いをテストできます。
  • 詳細なデバッグ情報: VCLの実行パス、変数の値の変化、ステートメントごとの処理結果などを詳細に出力する機能を持ち、デバッグを容易にします。

1.3 ローカルでのVCL実行環境

whipはFastlyのエッジクラウド環境そのものを完全に再現するものではありません。特に、以下の点はシミュレーションされません。

  • Fastlyのネットワーク: Anycastルーティング、エッジロケーションの近接性などは考慮されません。
  • グローバルな分散システム: Edge Dictionaries, ACLs, Rate LimitingなどのFastlyが提供する分散システム機能のリアルタイムな状態はシミュレーションされません（ただし、-dictionaryなどのオプションで特定の状態を模擬することは可能です）。
  • パフォーマンス: whipはテストツールであり、実際の Fastly サービスでのパフォーマンスやレイテンシを測定するためのものではありません。

しかし、HTTPリクエストの処理、キャッシュ制御、バックエンドの選択、Synthレスポンスの生成など、VCLの中心的なロジックのテストには非常に有効です。ローカルでVCLを何度も実行し、期待通りの処理パスを辿っているか、ヘッダーが正しく操作されているかなどを確認することで、デプロイ後の問題を大幅に減らすことができます。

第2章 インストール

whipのインストールは非常に簡単です。様々なOSに対応しており、バイナリのダウンロードやパッケージマネージャーを利用できます。

2.1 バイナリダウンロード

FastlyはGitHubのリリース (https://github.com/fastly/whip/releases) で各OS・アーキテクチャ向けのバイナリを提供しています。

  1. リリースページにアクセス: ブラウザでFastly whipのGitHubリリースページを開きます。
  2. 最新リリースを選択: 通常は最新のリリース（”Latest”またはバージョンの高いもの）を選択します。
  3. 適切なバイナリをダウンロード: ご利用のOSとアーキテクチャ（例: macOS AMD64, Linux AMD64, Windows AMD64）に合ったwhip_...という名前のアーカイブファイル（.tar.gzや.zip）をダウンロードします。
  4. アーカイブを展開: ダウンロードしたファイルを展開します。中にwhip（Windowsの場合はwhip.exe）という実行ファイルが含まれています。
  5. パスの通った場所に配置: 展開したwhip実行ファイルを、システムがコマンドとして認識できるように、PATH環境変数に含まれるディレクトリ（例: /usr/local/bin や C:\Windows\System32 など）に移動させます。または、現在のディレクトリで実行します。

2.2 パッケージマネージャー

macOSではHomebrewを利用するのが最も簡単な方法です。

bash
brew install fastly/tap/whip

これにより、Homebrewが自動的にダウンロード、展開、適切な場所への配置を行ってくれます。

Linuxの場合、ディストリビューションによってはFastlyのリポジトリが提供されていることがありますが、多くの場合バイナリダウンロードが手軽です。

2.3 Goからのビルド (開発者向け)

Go言語の開発環境が整っている場合は、ソースコードからビルドすることも可能です。

bash
go install github.com/fastly/whip@latest

このコマンドは、最新版のwhipのソースコードをダウンロードし、コンパイルし、通常は$GOPATH/binまたは$HOME/go/binディレクトリに実行ファイルを配置します。これらのディレクトリがPATHに含まれていれば、すぐにwhipコマンドとして利用できます。

2.4 インストールの確認

インストールが成功したかを確認するには、バージョン情報を表示するコマンドを実行します。

bash
whip version

または

bash
whip --version

バージョン番号が表示されれば、インストールは成功です。

whip version x.y.z (build hash)

第3章 whipの基本コマンドと使い方

whipの最も基本的な使い方は、VCLファイルとテスト対象となるURLを指定して実行することです。

bash
whip main.vcl http://example.com/path

このコマンドは以下の処理を行います。

  1. main.vclファイルをVCLとして読み込みます。
  2. http://example.com/path というURLに対するHTTPリクエストをシミュレーションします（デフォルトはGETメソッド）。
  3. 読み込んだVCLがそのシミュレーションされたリクエストを処理します。
  4. VCLの実行結果（バックエンドへのリクエスト、合成レスポンス、最終的なレスポンスなど）を出力します。

3.1 VCLファイルの指定 (-vcl)

テストしたいVCLファイルは、コマンドライン引数として直接指定できます。複数のVCLファイル（例えば、main.vclとincludeされるファイル）がある場合は、-vclオプションを複数回使用します。Fastlyサービスでは、main.vclがエントリーポイントとなりますが、whipでは最初に指定したVCLファイルが読み込まれるVCLの開始点となります。

bash
whip main.vcl included.vcl other.vcl http://example.com/

または

bash
whip -vcl main.vcl -vcl included.vcl -vcl other.vcl http://example.com/

通常は、Fastlyサービスにアップロードする際のエントリーポイントとなるmain.vclを最初に指定します。

3.2 テスト対象URLの指定

VCLが処理する対象となるリクエストのURLを指定します。これはVCLのreq.url, req.host, req.requestなどの変数に影響します。スキーム（http://またはhttps://）、ホスト名、パス、クエリパラメータを含めることができます。

bash
whip main.vcl https://www.example.com/path?query=value

3.3 出力の見方

whipのデフォルト出力は、VCLがリクエストをどのように処理したかの概要を示します。通常は以下の情報が含まれます。

  • Request: whipがシミュレーションした最初のリクエスト情報（メソッド、URL、ヘッダーなど）。
  • Backend Request: VCLがバックエンドへのリクエストを生成した場合の、そのリクエスト情報。
  • Backend Response: VCLがバックエンドからのレスポンスを受け取ったとシミュレーションした場合の、そのレスポンス情報。
  • Final Response: VCLが最終的にクライアントに返す（または返そうとした）レスポンス情報。

例として、シンプルなVCLでバックエンドにリクエストをパスし、レスポンスを返す場合の出力を見てみましょう。

main.vcl:

“`vcl
vcl_recv {
// Pass all requests to the backend
return(pass);
}

vcl_fetch {
// Deliver the backend response
return(deliver);
}
“`

コマンド:

bash
whip main.vcl http://example.com/test -backend default:http://localhost:8080

出力例:

“`
— Request —
GET http://example.com/test
Host: example.com
User-Agent: whip/x.y.z

— Backend Request —
GET http://localhost:8080/test
Host: localhost:8080
User-Agent: whip/x.y.z

— Backend Response —
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13

Hello, World!

— Final Response —
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13

Hello, World!
“`

この例では、whipはまず指定されたリクエストをシミュレーションし、VCLのvcl_recvでreturn(pass)が実行されたため、バックエンドへのリクエストを生成しています（Backend Request）。次に、シミュレーションされたバックエンドからのレスポンス（Backend Response）を受け取り、VCLのvcl_fetchでreturn(deliver)が実行され、最終的なレスポンス（Final Response）としてその内容を返しています。

第4章 リクエストの制御

whipは、シミュレーションするHTTPリクエストを詳細に制御するための様々なオプションを提供します。これにより、特定のHTTPメソッド、ヘッダー、ボディを持つリクエストに対するVCLの動作をテストできます。

4.1 HTTPメソッドの指定 (-X)

デフォルトはGETメソッドですが、-XオプションでPOST, PUT, DELETEなどの任意のHTTPメソッドを指定できます。

bash
whip main.vcl http://example.com/submit -X POST

4.2 ヘッダーの追加/変更 (-H)

-Hオプションを使って、リクエストヘッダーを追加したり、既存のヘッダーを変更したりできます。このオプションは複数回指定可能です。

bash
whip main.vcl http://example.com/api -H "Content-Type: application/json" -H "X-API-Key: YOUR_KEY"

特定のヘッダーを削除したい場合は、値を空に指定することが可能です。

bash
whip main.vcl http://example.com/resource -H "User-Agent:" # User-Agentヘッダーを削除

4.3 リクエストボディの指定 (-d, --data-binary, -F)

POSTやPUTリクエストなどでボディを含めたい場合、curlライクなオプションが利用できます。

  • -d <data> または --data <data>: シンプルな文字列データをボディとして送信します。application/x-www-form-urlencoded形式でエンコードされます。複数指定すると&で連結されます。
    bash
    whip main.vcl http://example.com/login -X POST -d "username=test&password=secret"
  • --data-raw <data>: 文字列データをそのままボディとして送信します。エンコードされません。
    bash
    whip main.vcl http://example.com/api -X POST --data-raw '{"key":"value"}' -H "Content-Type: application/json"
  • --data-binary <file>: ファイルの内容をそのままボディとして送信します。バイナリデータにも対応します。ファイルパスの前に@を付けます。
    bash
    echo '{"key":"value"}' > body.json
    whip main.vcl http://example.com/api -X POST --data-binary @body.json -H "Content-Type: application/json"
  • -F <name>=<value> または --form <name>=<value>: multipart/form-data形式でデータを送信します。ファイルアップロードのシミュレーションにも使えます (-F "[email protected]")。
    bash
    whip main.vcl http://example.com/upload -X POST -F "username=test" -F "[email protected]"

これらのオプションを使い分けることで、様々な種類のリクエストボディを持つリクエストに対するVCLの処理をテストできます。

4.4 スキームの指定 (http/https)

URLにスキームを含めることで、req.is_sslなどの変数やTLS関連のVCLロジックをテストできます。

“`bash

httpとしてシミュレーション

whip main.vcl http://example.com/

httpsとしてシミュレーション (req.is_sslがtrueになる)

whip main.vcl https://example.com/
“`

第5章 バックエンドのシミュレーション

VCLは通常、バックエンドサーバーからのレスポンスに依存してキャッシュ、配信、変更などの処理を行います。whipでは、実際のバックエンドサーバーにアクセスすることなく、バックエンドからのレスポンスをシミュレーションできます。これは、テストの独立性を高め、外部依存を排除する上で非常に重要です。

5.1 なぜバックエンドシミュレーションが必要か

  • テストの安定性: 実際のバックエンドが停止している、遅延している、予期しないレスポンスを返すといった要因からテスト結果が影響を受けるのを防ぎます。
  • 特定のレスポンスのテスト: 特定のステータスコード（例: 404, 500）、ヘッダー（例: Cache-Control, Set-Cookie）、ボディを持つレスポンスに対するVCLの動作を簡単にテストできます。
  • 開発中のバックエンド: まだ開発中の、存在しないバックエンドに対するVCLのロジック（例: 代替バックエンドへのフェイルオーバー）をテストできます。

5.2 デフォルトの挙動（バックエンドアクセスなし）

whipはデフォルトでは実際のネットワーク接続を行いません。バックエンドへのリクエストが発生した場合、それをシミュレーションとして内部的に処理します。バックエンドからのレスポンスが指定されていない場合、デフォルトの空の200 OKレスポンスが返されたものとしてVCLは続行します。

5.3 -backend オプション

VCL内で定義されたバックエンド（backendディレクティブやDirector）へのアクセスをシミュレーションするために、-backendオプションを使用します。

  • 名前付きバックエンドの定義: VCL内で定義したバックエンド名と、そのバックエンドが応答するとシミュレーションされるURLを指定します。
    bash
    whip main.vcl http://example.com/ -backend api_backend:http://api.internal
    この例では、VCL内でapi_backendという名前のバックエンドが参照された場合、そのリクエスト先はhttp://api.internalとしてシミュレーションされます。

  • デフォルトバックエンド: VCL内で特にバックエンドが指定されずにリクエストがパスされた場合などに参照されるデフォルトバックエンドを定義できます。
    bash
    whip main.vcl http://example.com/ -backend default:http://origin.external

-backendオプションは複数指定することで、複数の名前付きバックエンドをシミュレーションできます。

bash
whip main.vcl http://example.com/ -backend api_v1:http://api.internal/v1 -backend api_v2:http://api.internal/v2

5.4 -backend-response オプション

バックエンドからのレスポンスの内容を具体的にシミュレーションするには、-backend-responseオプションを使用します。このオプションは非常に強力で、ステータスコード、ヘッダー、ボディを指定できます。

-backend-response <backend_name>:<status>[:<headers>][:<body>]

  • <backend_name>: レスポンスをシミュレーションするバックエンドの名前。-backendオプションで定義した名前、またはdefaultを指定します。
  • <status>: HTTPステータスコード（例: 200, 404, 500）。
  • <headers> (オプション): レスポンスヘッダー。カンマ区切りで指定します。例: "Content-Type: application/json,X-Cache: MISS"。ヘッダー名と値の間はコロンで区切ります。値にカンマが含まれる場合は注意が必要です。必要に応じて--data-binaryでボディをファイルから読み込む形式と組み合わせるなど工夫します。
  • <body> (オプション): レスポンスボディ。文字列リテラルで指定するか、ファイルパスを@付きで指定します。

例1: シンプルな200 OKレスポンス

bash
whip main.vcl http://example.com/test -backend default:http://origin -backend-response default:200

例2: JSONボディと特定のヘッダーを持つ200 OKレスポンス

bash
whip main.vcl http://example.com/api/user -backend api:http://user.service -backend-response api:200:"Content-Type: application/json,X-Request-ID: abc123":"{\"id\":1,\"name\":\"test\"}"
ヘッダーやボディが複雑な場合は、ファイルから読み込むのが便利です。

例3: ファイルからボディを読み込む404レスポンス

bash
echo '{"error":"not found"}' > 404.json
whip main.vcl http://example.com/item/999 -backend item:http://item.service -backend-response item:404:"Content-Type: application/json":@404.json

-backend-responseオプションも複数回指定することで、異なるバックエンドからのレスポンスをシミュレーションできます。

5.5 複数のバックエンドとフェイルオーバーのテスト

VCLで複数のバックエンドを定義し、プライマリが失敗した場合にセカンダリにフェイルオーバーするロジックを記述している場合、-backend-responseを組み合わせてテストできます。

例えば、vcl_recvでreq.backend = backend.primary;とし、vcl_fetchでif (beresp.status >= 500) { restart; }として、Directorがセカンダリバックエンドを選ぶようにしている場合：

“`bash

primaryバックエンドが500を返した場合のテスト

whip main.vcl http://example.com/data -backend primary:http://p.origin -backend secondary:http://s.origin -backend-response primary:500 -backend-response secondary:200
“`

このテストでは、whipは最初にprimaryへのリクエストをシミュレーションし、-backend-response primary:500によって500レスポンスを返したとします。VCLはrestartし、Directorが次にsecondaryバックエンドを選び、-backend-response secondary:200によって200レスポンスが返される、という一連のフローをシミュレーションできます。

5.6 リアルなバックエンドへのアクセス (--pass-through)

ほとんどのテストシナリオではバックエンドのシミュレーションで十分ですが、どうしても実際のバックエンドと通信するVCLロジックをテストしたい場合があります。例えば、特定の認証ヘッダーが正しく追加されているか、タイムアウトの挙動などです。

--pass-throughフラグを使用すると、whipはバックエンドへのシミュレーションではなく、実際のネットワーク接続を試みます。

bash
whip main.vcl http://example.com/live-test -backend api:http://your-real-api.com --pass-through

注意: --pass-throughを使用する場合、指定したバックエンドのURLは実際にアクセス可能なものである必要があります。また、テストの再現性や独立性が損なわれる可能性があるため、必須の場合のみ使用し、シミュレーションで可能なテストはシミュレーションで行うことを推奨します。

第6章 レスポンスの制御

VCLはバックエンドからのレスポンスを操作したり、場合によってはバックエンドにアクセスせずにSynthetic Response（合成レスポンス）を生成したりします。whipはこれらのレスポンス生成の側面もテストできます。

6.1 合成レスポンスの生成 (-synth)

VCLのreturn(synth(<status>))を使用してSynthetic Responseを生成するロジックをテストしたい場合があります。-synthオプションを使うと、VCL内でreturn(synth())が実行された際に返されるデフォルトのレスポンス内容を指定できます。

-synth <status>[:<headers>][:<body>]

これは-backend-responseと似た形式ですが、バックエンド名ではなく、VCLのsynthステートメントで指定されたステータスコードに対して適用されます。

例1: デフォルトのsynthレスポンスを指定

“`bash

main.vcl内で return(synth(403)); が実行されると想定

whip main.vcl http://example.com/forbidden -synth 403:”Content-Type: text/plain”:”Access Denied”
“`

VCL内でreturn(synth(403))が実行されると、whipは指定されたヘッダーとボディを持つ403レスポンスを生成します。

例2: 異なるステータスコードに対するsynthレスポンス

VCLがリクエストやエラーの種類によって異なるステータスコードでsynthする場合、-synthオプションを複数指定できます。

“`bash

main.vcl内で return(synth(400)); または return(synth(503)); が実行されると想定

whip main.vcl http://example.com/bad-request -synth 400:”Content-Type: text/plain”:”Bad Request” -synth 503:”Content-Type: text/html”:”

Service Unavailable

”
“`

VCLがreturn(synth(400))を実行した場合は最初の-synthオプションが、return(synth(503))を実行した場合は二番目のオプションが適用されます。VCLで指定されたステータスコードに対応する-synthオプションがない場合、whipはデフォルトのSynthレスポンス（シンプルなステータスラインとエラーメッセージ）を生成します。

6.2 レスポンスヘッダーの確認

VCLでレスポンスヘッダー（resp.http.*, beresp.http.*など）を操作するロジック（追加、削除、変更）をテストする場合、whipの最終出力でこれらのヘッダーが期待通りになっているかを確認します。

“`bash

main.vclで resp.http.X-Cache = “HIT” if … のようなロジックをテスト

whip main.vcl http://example.com/cached-item -backend default:http://origin -backend-response default:200:”Cache-Control: max-age=60″:@body.html
“`

whipの出力の--- Final Response ---セクションで、X-Cache: HITのようなヘッダーが存在するか、または別のヘッダーが正しく追加・変更されているかを確認します。

6.3 レスポンスボディの確認

同様に、最終的なレスポンスボディがVCLの処理（例: Edge-Side Includesの置換、Synthetic Responseのボディ生成）によって期待通りになっているかを確認します。

“`bash

main.vclで return(synth(200, “Custom body”)); のようなロジックをテスト

whip main.vcl http://example.com/custom-body -synth 200:”Content-Type: text/plain”:”This is a custom response body.”
“`

whipの出力の--- Final Response ---セクションで、ボディの内容が指定した（またはVCLで生成された）内容と一致するかを確認します。ファイルからボディを読み込んだ場合は、そのファイル内容と比較します。

第7章 デバッグと詳細出力

whipの最も強力な機能の一つは、VCLの実行パスと状態を詳細に追跡するデバッグ機能です。これにより、VCLがなぜ期待通りの動作をしないのか、どのような順序でステートメントが実行されているのか、変数の値がどう変化しているのかなどを把握できます。

7.1 詳細出力 (-vv, -vvv)

-vフラグは、whipの出力をより詳細にします。複数指定することでさらに詳細な情報が得られます。

  • -vv: シミュレーションされたリクエスト/レスポンスの詳細に加えて、VCLの各サブルーチン (vcl_recv, vcl_fetch, vcl_deliver, vcl_error, vcl_synth) へのエントリーとエグジットが表示されます。
  • -vvv: -vvの情報に加えて、バックエンドの選択、キャッシュの状態（HIT/MISS）、リスタートの発生など、VCLエンジン内部のより詳細な処理ステップが表示されます。

デバッグの際は、まず-vvや-vvvを付けて実行し、どのサブルーチンが実行され、どのようなステートメントが実行されたか（ただし、ステートメント単位のトレースではない）の概要を掴むのが有効です。

7.2 VCL実行トレース (--trace)

--traceフラグは、VCLの実行をステートメント単位で詳細に表示します。どのVCLファイルの何行目のどのステートメントが実行されたか、その結果何が起こったか（例: 変数の値が変更された、サブルーチンからリターンした）が時系列で出力されます。

bash
whip main.vcl http://example.com/trace-test --trace

出力例の一部：

vcl_recv[main.vcl:5] if (req.url == "/foo") {
vcl_recv[main.vcl:5] -> true
vcl_recv[main.vcl:6] return(pass);
vcl_recv[main.vcl:6] -> pass

この出力は、main.vclの5行目のif (req.url == "/foo")が実行され、結果がtrueであったため、6行目のreturn(pass)が実行され、vcl_recvサブルーチンがpassで終了したことを示しています。

--traceは、VCLの制御フローが期待通りに分岐しているか、特定の条件が正しく評価されているかを確認するのに非常に役立ちます。

7.3 変数の値の確認 (--vcl-state-trace)

VCLデバッグで最も重要な情報の一つは、実行中の変数の値です。--vcl-state-traceフラグを使用すると、VCLステートメントが実行されるたびに、そのステートメントでアクセスされた、または変更された変数の名前と値が出力されます。

bash
whip main.vcl http://example.com/state-test -H "X-My-Header: initial" --vcl-state-trace

VCL:
vcl
vcl_recv {
if (req.http.X-My-Header) {
set req.http.X-My-Header = "modified";
}
return(pass);
}

出力例の一部：

vcl_recv[main.vcl:2] if (req.http.X-My-Header) {
req.http.X-My-Header: "initial"
vcl_recv[main.vcl:2] -> true
vcl_recv[main.vcl:3] set req.http.X-My-Header = "modified";
req.http.X-My-Header: "modified"
vcl_recv[main.vcl:5] return(pass);

この出力は、2行目でreq.http.X-My-Headerが評価された際のその値（”initial”）と、3行目のsetステートメントによってその値が”modified”に変更されたことを示しています。

--vcl-state-traceは、変数の値がなぜ期待と異なるのか、どのステートメントが変数の値を変更しているのかなどを特定するのに極めて強力な機能です。

7.4 デバッグフラグの組み合わせ

これらのデバッグフラグは組み合わせて使用できます。例えば、whip main.vcl <url> -vvv --trace --vcl-state-traceと実行すると、VCLエンジンの詳細なステップ、ステートメント単位の実行トレース、そして変数の値の変更すべてが出力されます。出力量は膨大になりますが、複雑な問題を診断する際には非常に役立ちます。

第8章 高度な使い方と活用術

whipはその基本機能に加えて、様々な応用的な使い方があります。

8.1 ローカルファイルからのリクエストボディ読み込み

セクション4.3で触れたように、-d, --data-raw, --data-binary, -Fオプションで@ファイルパスを指定することで、ローカルファイルの内容をリクエストボディとして使用できます。これは、大きなファイルやバイナリファイル、構造化されたデータ（JSON, XMLなど）をボディとするリクエストのテストに便利です。

“`bash

JSONファイルをボディとして送信

whip main.vcl http://example.com/api -X POST –data-binary @request.json -H “Content-Type: application/json”

マルチパートフォームデータとしてファイルをアップロード

whip main.vcl http://example.com/upload -X POST -F “[email protected]” -F “metadata=some value”
“`

8.2 テストスクリプトとの連携

whipはコマンドラインツールなので、シェルスクリプト、Pythonスクリプト、Node.jsスクリプトなど、任意のスクリプト言語から容易に実行できます。これにより、複数のテストケースを自動化できます。

例えば、シェルスクリプトで複数のURLやヘッダーの組み合わせをテストし、whipの出力（特に最終レスポンスのステータスコードやヘッダー）をチェックするスクリプトを作成できます。

“`bash

!/bin/bash

VCL=”main.vcl”
BASE_URL=”http://test.example.com/”

テストケース1: 基本的なGETリクエスト

echo “— Test Case 1: Basic GET —”
whip “$VCL” “$BASE_URL”

テストケース2: 特定のヘッダーを含むリクエスト

echo “— Test Case 2: Request with custom header —”
whip “$VCL” “$BASE_URL” -H “X-Custom-Header: test-value”

テストケース3: POSTリクエストとJSONボディ

echo “— Test Case 3: POST with JSON body —”
echo ‘{“status”:”active”}’ > post_body.json
whip “$VCL” “${BASE_URL}update” -X POST -H “Content-Type: application/json” –data-binary @post_body.json
rm post_body.json

テストケース4: バックエンドエラーのシミュレーション

echo “— Test Case 4: Backend error simulation —”
whip “$VCL” “${BASE_URL}data” -backend default:http://origin -backend-response default:500

出力をgrepなどでフィルタリングして検証する例 (部分)

echo “— Verifying X-Cache header —”
whip “$VCL” “$BASE_URL” -vvv | grep “X-Cache:”
“`

このようなスクリプトを作成することで、手動での繰り返しテストの手間を省き、VCLの変更による意図しない副作用を早期に発見できます。

8.3 CI/CDパイプラインへの組み込み

テストスクリプトとwhipを組み合わせることで、継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインにVCLの自動テストを組み込むことができます。

GitリポジトリにVCLファイルとテストスクリプト（例えば、前述のシェルスクリプト）を配置し、GitHub Actions, GitLab CI, JenkinsなどのCIツールから、コードがプッシュされるたびにこれらのテストスクリプトを実行します。

CIの設定ファイル（例: .github/workflows/ci.yml）に以下のようなステップを追加します。

“`yaml
name: VCL Test

on:
push:
branches:
– main
pull_request:
branches:
– main

jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v3

  - name: Set up Go
    uses: actions/setup-go@v4
    with:
      go-version: '1.20' # whipがサポートするGoバージョンを指定

  - name: Install whip
    run: go install github.com/fastly/whip@latest
    env:
      GOPATH: /home/runner/go # GitHub ActionsでのデフォルトGOPATH

  - name: Add GOPATH to PATH
    run: echo "/home/runner/go/bin" >> $GITHUB_PATH

  - name: Run VCL tests
    run: ./run_tests.sh # 前述のテストスクリプトを実行
    working-directory: ./vcl # VCLファイルとスクリプトがあるディレクトリ

“`

これにより、VCLの変更がプッシュされるたびに自動的にテストが実行され、問題があれば開発者にフィードバックが送られます。これは、VCLの品質を維持し、本番環境でのトラブルを防ぐ上で非常に効果的です。

8.4 特定のディレクターテスト

VCLで複数のDirector（Random, RoundRobin, Hashなど）を定義している場合、whipはDirectorのロジック（ヘルスチェックの状態などを含む）をシミュレーションして、どのバックエンドが選択されるかをテストできます。-backendオプションで複数のバックエンドを定義し、-backend-responseでそれぞれの状態をシミュレーションすることで、Directorのフェイルオーバーや重み付けなどの挙動を確認できます。

“`vcl
// main.vcl
backend primary { .host=”primary.origin”; .port=”80″; .probe = { .url = “/health”; } }
backend secondary { .host=”secondary.origin”; .port=”80″; .probe = { .url = “/health”; } }

director my_director random {
{ .backend = primary; .weight = 1; }
{ .backend = secondary; .weight = 1; }
}

vcl_recv {
set req.backend = my_director;
return(pass);
}
// … probe definition …
“`

“`bash

primaryが正常な場合（probeが200を返す）

whip main.vcl http://example.com/ -backend primary:http://primary.origin -backend secondary:http://secondary.origin -backend-response primary:/health:200

primaryが異常な場合（probeが500を返す）

whip main.vcl http://example.com/ -backend primary:http://primary.origin -backend secondary:http://secondary.origin -backend-response primary:/health:500 -backend-response secondary:/health:200
“`

-backend-responseでprobe URLに対するレスポンスを指定することで、whipはヘルスチェックの結果をシミュレーションし、Directorがそれに応じてバックエンドを選択するロジックをテストできます。

8.5 Edge Dictionaries, ACLs, GeoIPの扱い

whipはこれらのFastly固有の機能を完全にライブで利用することはできません。しかし、テスト用に特定の状態を模擬するオプションがいくつか提供されています。

  • -dictionary <name>=<json_file>: Edge Dictionaryの内容をローカルのJSONファイルから読み込んでシミュレーションします。
    bash
    # dictionary_data.json: {"key1":"value1", "key2":"value2"}
    whip main.vcl http://example.com/ -dictionary my_dict=@dictionary_data.json
    VCLでstd.cache_lookup("my_dict", "key1")のような操作を行った際に、指定したJSONファイルの内容が参照されます。
  • -acl <name>=<acl_file>: ACLの内容をローカルファイルから読み込んでシミュレーションします。ファイル形式はFastlyのACL定義と似ています。
    bash
    # acl_data.txt: deny 192.168.1.0/24; allow 10.0.0.0/8;
    whip main.vcl http://example.com/ -acl my_acl=@acl_data.txt -H "X-Forwarded-For: 192.168.1.10"
    VCLでclient.ip ~ my_aclのような操作を行った際に、指定したACLファイルの内容が参照されます。X-Forwarded-Forヘッダーを指定することでクライアントIPをシミュレーションできます。
  • -geoip <json_file>: GeoIPデータをローカルのJSONファイルから読み込んでシミュレーションします。
    bash
    # geoip_data.json: {"country_code":"US", "city":"New York"}
    whip main.vcl http://example.com/ -geoip @geoip_data.json -H "X-Forwarded-For: 203.0.113.1"
    VCLでclient.geo.country_codeのような変数を参照した際に、指定したJSONファイルの内容が使用されます。

これらのオプションを使うことで、Fastlyの特定の機能に依存するVCLロジックも、ある程度ローカルでテストすることが可能になります。ただし、ライブデータとの完全な一致を保証するものではない点に注意が必要です。

第9章 whipを使う上での注意点と制限

whipは非常に有用なツールですが、万能ではありません。使用する上で知っておくべき制限事項があります。

9.1 Fastlyの全機能を完全に再現するわけではない

前述のように、whipはVCLエンジンとHTTPリクエスト/レスポンスのシミュレーションに特化しています。Fastlyが提供するすべての機能や、エッジクラウド環境の特性（ネットワーク、分散システムの状態など）を完全に再現するものではありません。

9.2 エッジロケーション、Anycastの挙動はシミュレートしない

リクエストがどのエッジロケーションに到達するか、Anycastルーティングによってネットワーク的にどのように処理されるかといった挙動はwhipのスコープ外です。これらの側面を含むテストが必要な場合は、Fastlyサービスのテスト環境や本番環境を利用する必要があります。

9.3 特定のVCL機能のシミュレーション限界

  • Rate Limiting, Edge Rate Limiting: これらの機能はFastlyの分散システムに依存しており、whipで完全にシミュレーションするのは困難です。特定のシナリオを模擬するために変数やヘッダーを手動で操作することは可能かもしれませんが、リアルな挙動のテストには向きません。
  • Logging: logステートメント自体はVCLとしてパースされますが、実際にログエンドポイントへの送信がシミュレーションされるわけではありません。ログの内容をテストしたい場合は、ログメッセージをヘッダーに追加するなど、別の方法で出力して確認する必要があります。
  • TLS関連の詳細: クライアント証明書の検証など、TLS接続のより低レベルな側面はwhipではシミュレーションされません。

9.4 パフォーマンス測定には向かない

whipはVCLロジックの正確性を検証するためのツールです。VCLの実行速度、バックエンド通信のレイテンシ、キャッシングによるパフォーマンス改善効果などを測定するためのものではありません。パフォーマンスチューニングには、実際のFastlyサービス上での計測が必要です。

9.5 リアルなバックエンドアクセス時の注意

--pass-throughを使用して実際のバックエンドにアクセスする場合、以下の点に注意が必要です。

  • バックエンドがインターネット経由でアクセス可能である必要があります（またはwhipを実行している環境からアクセス可能である必要があります）。
  • バックエンドへの不要な負荷をかけないよう注意が必要です。特にCI/CDなどで頻繁に実行する場合は、テスト用のバックエンドを用意するなどの対策が推奨されます。
  • 外部ネットワークへの依存が発生するため、テストの安定性が損なわれる可能性があります。

これらの制限を理解した上でwhipを利用することで、その強みを最大限に活かしつつ、限界を超えるテストが必要なケースでは他の手法（Fastly APIのテスト機能、ステージング環境、本番環境での canary release など）を適切に選択できるようになります。

第10章 他のテスト方法との比較

VCLのテストにはwhip以外にもいくつかのアプローチがあります。それぞれの特徴を理解し、whipと組み合わせて使うことが重要です。

10.1 curlとの比較

curlは汎用的なコマンドラインHTTPクライアントであり、Fastlyサービス上のライブエンドポイントやステージング環境のエンドポイントに対してHTTPリクエストを送信し、レスポンスを確認するのに広く使われます。

  • curlの利点:
    • 実際のFastlyサービス（または他のHTTPサーバー）との通信をテストできる。
    • ネットワークレベルの挙動やパフォーマンスの一部を確認できる。
    • 広く普及しており、使い慣れている開発者が多い。
  • curlの欠点:
    • VCLの内部処理を直接テストできない。どのサブルーチンが実行されたか、変数の値はどうなったかといった情報は得られない。
    • テストのためにVCLの変更をデプロイする必要がある。
    • バックエンドからの特定のレスポンスやエラーをシミュレーションするには、それらを実際に返すテスト用バックエンドが必要になる。

whipとcurlの使い分け:

whipはローカルでのVCLロジックの高速な反復テスト、デバッグ、特定シナリオのシミュレーションに最適です。一方、curlはデプロイされたVCLが実際の環境で期待通りのレスポンスを返すか、ネットワークレベルの問題がないかを確認するための最終確認や外形監視に使われます。両者は補完的な関係にあります。

10.2 FastlyのAPI (fastly test) との比較

FastlyはAPIを通じてVCLをテストする機能も提供しています（fastly testコマンドなど）。これは、VCLをFastlyサービスにアップロードせずにテスト用の環境で実行できる機能です。

  • Fastly APIテストの利点:
    • Fastlyが管理する環境で実行されるため、よりFastlyサービスに近い環境でのテストが可能。
    • 特定のFastly機能（Dictionariesなど）のライブデータの一部にアクセスできる可能性がある。
  • Fastly APIテストの欠点:
    • テスト実行にFastly APIへのリクエストが必要であり、ローカルでの即時フィードバックよりも時間がかかる場合がある。
    • APIコール数の制限や費用が発生する可能性がある。
    • whipのように詳細なVCL実行トレースや変数の状態確認が容易ではない場合がある。

whipとFastly APIテストの使い分け:

whipは日常的なローカル開発、VCLロジックの単体テスト、高速なデバッグサイクルに適しています。Fastly APIテストは、ローカルテストを通過したVCLを、デプロイ前にFastly側の環境で最終確認する用途に適しています。

10.3 ローカルVarnishとの比較

VCLはVarnish Cacheというオープンソースソフトウェアから派生した言語であり、ローカルにVarnishをインストールしてVCLをテストするという方法も理論上は考えられます。

  • ローカルVarnishの利点:
    • ローカル環境でVCLを実行できる。
  • ローカルVarnishの欠点:
    • Fastly VCLには、Fastly独自の拡張や組み込み関数、変数（例: fastly.*, req.is_ipv6, Director types unique to Fastlyなど）が多数含まれています。これらのFastly固有の機能は、標準のオープンソースVarnishではサポートされていません。
    • Fastlyのバックエンド、キャッシング、ロギングなどのアーキテクチャはVarnishと異なる部分が多く、完全に同じ挙動を再現することは不可能。

whipとローカルVarnishの比較:

whipはFastly VCLに特化して開発されており、Fastly固有の構文や機能を理解し、それらのシミュレーションに注力しています。そのため、Fastlyサービス向けに書かれたVCLをテストするには、ローカルVarnishよりもwhipの方がはるかに適しています。

第11章 トラブルシューティング

whipを使っていて問題が発生した場合の一般的な原因と対処法について説明します。

11.1 VCL構文エラー

VCLファイルに構文エラーがある場合、whipはVCLの読み込み時にエラーを報告します。

bash
whip main.vcl http://example.com/

出力例：

Error parsing VCL: main.vcl:10: unexpected token "invalid_statement"

エラーメッセージは通常、問題のあるファイル名、行番号、そしてエラーの原因となった構文を示してくれます。この情報をもとにVCLファイルを修正してください。

11.2 バックエンドシミュレーションの問題

  • 指定したバックエンド名が見つからない: -backend-responseで指定したバックエンド名が、VCL内で定義されていないか、-backendオプションでシミュレーション対象として定義されていない場合に発生します。VCL内のバックエンド名とコマンドラインオプションの名前が一致しているか確認してください。
  • --pass-through時のネットワークエラー: --pass-throughフラグを使用している場合、指定したバックエンドURLに実際にアクセスできない（ネットワーク接続の問題、バックエンドサーバーがダウンしているなど）場合にエラーが発生します。curlコマンドなどで直接バックエンドURLにアクセスしてみて、問題なく応答があるか確認してください。

11.3 オプション指定のミス

whipのオプションは多数あり、間違った使い方をすると期待通りの結果が得られないことがあります。

  • ヘッダー形式: -Hオプションでヘッダーを指定する際は、"Header-Name: value"のようにコロンで区切り、必要に応じて引用符で囲むのが一般的です。
  • ボディ形式: -d, --data-raw, --data-binary, -Fなどのボディ指定オプションはそれぞれ動作が異なります。特にファイルパスは@で始める必要があります。
  • パスとURL: テスト対象のURLは完全な形式（スキーム、ホスト、パス）で指定する必要があります。

これらのオプションの正しい使い方は、whip --helpコマンドで確認できます。

11.4 デバッグフラグ (-vvv, --trace, --vcl-state-trace) の活用

問題の原因がVCLロジックにあると思われる場合、迷わずデバッグフラグを有効にしてください。特に--traceと--vcl-state-traceは、VCLがどのように実行され、変数の値がどう変化したのかをステップバイステップで確認できるため、非常に強力です。大量の出力になるため、必要に応じてgrepなどのツールでフィルタリングしながら確認すると良いでしょう。

11.5 コミュニティリソース

Fastlyのドキュメント、Fastlyコミュニティフォーラム、GitHubリポジトリのIssueやDiscussionも有用な情報源です。過去に他のユーザーが同じ問題に遭遇しているかもしれません。

結論

Fastly whipは、Fastly VCLをローカルで効率的に開発・テストするための不可欠なツールです。デプロイメントサイクルを待つことなく、VCLの変更を即座に検証し、様々なシナリオでの振る舞いをシミュレーションできる能力は、VCL開発のワークフローを劇的に改善します。

本記事で解説した基本的な使い方から、リクエスト/レスポンス/バックエンドの制御、詳細なデバッグ機能、そしてテストスクリプトやCI/CDへの統合といった高度な活用術まで、whipの持つ可能性は多岐にわたります。

VCL開発に携わるすべてのエンジニアは、whipを使いこなすことで、より迅速に、より自信を持ってVCLの変更を本番環境に投入できるようになるでしょう。本記事が、あなたのwhip活用の一助となれば幸いです。

VCLはPowerfulかつ柔軟ですが、その挙動は複雑になりがちです。whipを積極的に活用し、コードの品質を高め、安定したサービス運用を実現してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール