404エラー時のHAProxy URLの書き換え

最初のファイルにファイルがない場合、HAProxyを別のバックエンドに書き換えさせるにはどうすればよいですか？私が必要なのはerrorloc、リダイレクトの代わりに書き換えを行うことです。そのため、クライアントはリダイレクトを認識しません。

NginXを念頭に置いてアプリケーションを開発しました。これは、静的ファイル用のリバースプロキシとWebサーバーの両方の負荷分散でした。アプリケーションは、Cookieに基づくスティッキーセッションを必要とするOpaフレームワークに基づいています-NginXとHAproxyの両方でサポートされています。私たちが問題とするアプリケーション機能は、動的コンテンツ生成です。オンデマンドで画像を生成しますが、生成後はディスクに保存され、確定的なパスで静的にアクセスできます。

問題はNginXで簡単に解決されました-ローカルファイルを読み取って、ファイルが欠落している（まだ生成されていない）場合にのみ、負荷分散されたバックエンドを使用しようとします。

server {
  server_name wkaliszu.pl;
  location /thumb {
    root /path_on_disk/to_cached_content;
    expires 7d;
    # try to access already generated content
    try_files $uri @wkaliszu;
  }
  location / {
    # reverse proxy to the application
    [...]
  }
  location @wkaliszu {
    # reverse proxy to the application
    [...]
  }
}

サーバーは移行され、負荷分散にHAPproxyを使用します。これは、Webサーバーではなく、この機能をサポートしていません。これで、クライアントがリソースにアクセスしようとするたびに動的なソフトウェア生成が実行されますが、これは非常に遅く、リソースを浪費します。最初の（静的ファイル用の単純なキャッシングWebサーバー）がエラー404で失敗した場合、次のバックエンドを使用できれば問題ありませんが、簡単な方法を見つけることができません。/thumb静的ファイルの読み取りを試み、新しいHTTPヘッダーでHAproxyに再度書き込むNginXへのリダイレクトだけが思い浮かびますが、もっと良いものを見つけたいと思います。

HAProxyのバックエンドはアップまたはダウンしています（またはアップ/ダウンする途中です）。

バックエンドの状態を確認するにはさまざまな方法がありますが、リクエストごとの追跡を提供する方法は知りません。リクエストが失敗すると、そのバックエンドはダウンとしてマークされるか、失敗します（ダウンと見なされる途中）。

これは、リクエストごとにリクエストをルーティングしていたNginxセットアップとは非常に異なるロジックです。

ここにいくつかのオプションがあります：

• Caching ProxyとしてのNginx
• 静的コンテンツにAppsサーバーを使用する
• CDNを使用する

キャッシングプロキシ

HAProxyでは、ACLを使用して静的コンテンツ要求を特定のバックエンドにルーティングします。これらのバックエンドノードは、キャッシュプロキシを使用してnginxを実行します。nginxがファイルをキャッシュしていた場合、それはそれを提供するだけです。そうでない場合は、バックエンドを呼び出します。

静的コンテンツにアプリサーバーを使用する

アプリサーバーが静的コンテンツの提供に効率的である場合、リクエストをhaproxyに分割する必要がない場合があります。すべてのリクエストをアプリケーションのバックエンドに送信するだけです。利用可能な場合は静的コンテンツを提供し、そうでない場合はリクエストをバックエンドに送信するためのロジックをそれらに組み込みます。

CDNオプション

静的コンテンツ専用のドメインを使用できる場合は、CDNを使用できる場合があります。CDNでは、アプリケーションノードへのソースURLを指定するだけです。その後、CDNレベルでキャッシュを制御できます。これは、CDNプロバイダーが処理することを除いて、上記のNginxキャッシングに似ています。