Site search / サイト内検索

必要な情報を探す

ページ内の言葉を探す検索と、意味が近い内容を探す検索を使い分けられます。

「検索する」を実行すると、入力した検索語をCloudflare Workers AIで数値表現に変換し、その数値表現をCloudflare Vectorizeで当サイトの公開情報と照合します。あわせて、Acecore共通検索API(acecore.net)へ送信し、 Acecore関連サイトの公開情報を下部に表示することがあります。個人情報や機密情報は入力しないでください。個人情報の取り扱い

Insights / 技術解説

公開画像のエッジキャッシュとAPIの閲覧制限を分ける

画像付きコンテンツの連続閲覧で、本文APIと画像取得が同じ制限枠を使っていた事例。公開画像の再利用、正常応答の検証、WAFとアプリの境界、本番確認を整理します。

  • Cloudflare
  • Performance
  • Web
公開画像のエッジキャッシュとAPIの閲覧制限を分ける
この記事の目次
  1. 連続閲覧を一枚の画像から再現する
  2. 本文と画像が同じ枠を消費していた
  3. 共有できる公開画像だけを再利用する
  4. 検証した200応答を保存する
  5. 動的APIの制限を独立して扱う
  6. 本番では画像の内容まで照合する

画像付きの日記やカタログでは、日付やページを切り替えるたびに本文APIと画像の取得が発生します。連続閲覧時に画像が止まった事例を、運用URL・内部ルート・制限値を伏せて紹介します。

連続閲覧を一枚の画像から再現する

同じ公開画像を繰り返し取得し、初回と再取得でbodyのハッシュ、status、キャッシュ状態を比べます。次に本文と複数画像を通常のページ切替で取得し、どの要求が制限枠へ数えられるか確認します。HITだけを成功基準にせず、画像内容とAPI保護の両方を確認する試験です。

Cloudflare Cache API:条件付き取得と拠点ごとのキャッシュ

本文と画像が同じ枠を消費していた

この事例では、動的APIへのリクエストと公開画像のGETをWAFの同じ制限枠で数えていました。普通のページ切替でも複数の取得が重なり、本文は取得できても画像だけが制限される場合がありました。

画像のエッジキャッシュを追加しても、WAFで先に止められるリクエストは届きません。配信元の負荷を減らす変更と、何を同じ制限枠で数えるかの変更を別々に行いました。既存のアプリ側制限や生成処理のquotaは、それぞれの目的に沿って維持します。

共有できる公開画像だけを再利用する

ここで扱う画像は、同じ公開asset IDなら同じ内容を返す不変の画像です。asset IDの形式、リクエスト境界、Service Bindingの設定を確認してから、同一hostとasset IDに対応するキャッシュを参照します。キャッシュが温まっていても、この入口の確認を飛ばしません。

内容に影響しないquery stringや利用者のヘッダーで同じ画像のキャッシュを分割しない設計にしました。この判断は、不変の公開画像という前提があるために可能です。利用者や組織ごとに内容が変わる非公開画像へ、そのまま適用することはできません。

検証した200応答を保存する

キャッシュがなければ、非公開のService Binding先から画像を取得します。HTTP status、画像のContent-Type、Content-Length、応答bodyを検証し、条件を満たす200応答だけを保存します。部分応答、空のbody、不正なmetadata、障害応答は保存対象にしません。

画像の実体を保存する処理と、ETag一致による304応答は分けます。キャッシュへの書込みはwaitUntilへ登録し、読取りや書込みの障害では、配信元から取得できた正常な画像の返却を妨げないようにしました。再取得時にキャッシュが使えれば、Service Binding先の取得処理を省けます。

Cloudflare Cache APIでは、ETagを使った条件付き取得と、拠点ごとのキャッシュの性質を確認できます。ある拠点のHITは全拠点のHITを意味しません。Pages Functionsの応答ヘッダーは静的ファイル用の_headersだけでは設定できないため、Function側で管理します。

動的APIの制限を独立して扱う

動的APIの保護は、画像をキャッシュできることとは別の要件です。この事例ではWAFの集計対象から公開画像のGETを外し、対象となる動的API、制限期間、action、有効状態を適用後に読み直しました。変更前の設定も切戻し用に保存しています。

閾値は通常閲覧で発生する取得数と、保護する処理の負荷に合わせて選びます。Cloudflareのレート制限のplan別条件も確認が必要です。リポジトリの運用メモに値があるだけで、本番ruleが有効だとは判断できません。

公開画像と動的APIの境界 不変の公開画像の再利用と、動的APIの保護を別に設計します。非公開画像は対象外です。
  1. 公開画像GET 入口を確認し、同じ画像をcacheで再利用。保存は検証した200だけ。
  2. 動的API WAFとアプリquotaで処理を保護。画像cacheとは別に制限する。

本番では画像の内容まで照合する

単体テストでは、同じ公開画像の再利用、host・asset IDの分離、キャッシュ利用前の境界確認、304、キャッシュ障害、保存してはいけない応答を確認しました。CIの後にGitHub pushによる本番deploymentとcustom domainを確認し、代表画像のHTTP結果、アプリが示すHIT・MISSなどの状態、取得したbytesのhashを照合しました。

本番では本文と複数画像の連続取得も行い、その通常閲覧の試験条件では制限に当たらないことを確認しました。これは限定した取得条件での確認であり、高負荷時の境界まで試した結果ではありません。

キャッシュ状態の表示だけでは、正しい画像を返した証明にはなりません。本文の取得、画像の取得、WAFの設定、画面上の閲覧結果を別々に確認します。この記録は代表画像の配信確認までで、全利用者・全拠点の連続閲覧や高負荷時の性能改善率まで実証したものではありません。

サイト全体の静的・動的な分担はAstroとCloudflareの全体設計、画像・CSSなどの配信最適化はAstroのパフォーマンス調整も参照してください。