🐛

cloudflared オリジンサーバーの可用性を高める

2024/06/02に公開

はじめに

以前に cloudflared トンネルの監視方法について書きましたが、今回はトンネルを冗長化し可用性を上げる方法を考えてみます。

出発点は cloudflared を使ってオリジンサーバーを保護している構成とします。

- 点線は cloudflared が開設したトンネルの中をリクエストが転送されるイメージ
- cloudflared と Web App は同じホストでも違っても可(IP到達性は必要)

この環境の可用性を高めていきます。

前提: cloudflared にあらかじめ備わる可用性

まず、cloudflared で最初から有効になっている可用性デザインを見ておきます。

ダッシュボードcloudflare tunnlel list で確認すると、一つの cloudflared が 2 ヶ所以上の Cloudflare データセンターに計 4 本のトンネルを張っているのがわかります。

~ $ cloudflared tunnel list
*Tunnel_UUID* replica0 2024-05-29T08:35:29Z  1xnrt01, 1xnrt05, 2xnrt07

Eyeball(クライアント)の 公開サーバー に対するリクエストは一番近い Cloudflare データセンターに到着し、cloudflared とトンネルを張っているデータセンターからオリジンに抜けていきます。

万一 NRT01 データセンターがダウンしても、通信が継続するようなデザインになっています。
一方、オリジンサーバー側は単一障害点なので、こちらを解消します。

オリジンサーバーの可用性を高める(replica)

cloudflared に備わっている replica 機能は一つのトンネルを複数のサーバーに複製します。これを利用し、可用性とフェイルオーバーを備えたデザインにできます。
Dev docs の Recommendation でもその利用が推奨されています。

replica の動き

replica の選択には Load balancing のようなトラフィックステアリング(random, hash, or round-robin)の組み込みはなく、着信データセンターから地理的に近い replica に転送されます。コネクション不通や近さの計算ができない場合は他の replica にリトライします。

replica の展開

展開の仕方は cloudflared の管理方法によって変わります。

  • Remote managed(ダッシュボード)運用の場合
    元となるトンネルの展開用コマンドを他の cloudflared サーバーでコピペ実行。

  • Locally managed(CLI)運用の場合
    元となるトンネルの設定ファイル認証トークンを他の cloudflared サーバーにコピーして起動。

Eyeball が接続する公開サーバーは DNS で定義されています。CNAME のコンテンツに <UUID>.cfargotunnel.com (自身のアカウントの DNS あるいは Load balancer からのみ参照可能な cloudflared の Public hostname)が入ります。

動作確認

トラフィックステアリングはできませんが、片方の cloudflared を落としても、公開サーバーへの通信が継続しています。

高度な可用性とトラフィックステアリングを追加する(Load balancing)

オリジンサーバーの手前に Load balancer を追加すれば、より柔軟な可用性設計とトラフィックステアリングが狙えます。cloudflared も利用できます

公開サーバーは DNS ではなく Load balancing(トラフィックアプリ)で定義されます。

  • DNS
  • Load balancing

前提: Pool と Origin

Load balancing の基本に Pool と Origin という考えがあります。
Pool はデータセンター、Origin はその中にあるサーバーのようなイメージです。

転送先オリジンサーバーの決定は、まず設定されたロジックで Pool が選択され(Traffic steering)、次に別のロジックで Pool 内の Origin が選択(Origin steering)されます。

それぞれに適用できるステアリングポリシーはこちら

Load balancing 適用デザイン

cloudflared の Load balancing 適用デザインは下記のようになります。

  • Pool の選択(Traffic Steering)
  • Origin の選択(Origin Steering)

replica を併用する場合は注意が必要です。

Load balancing 適用例

  • cloudflared 設定
    Networks > Tunnels > Public hostname
    1 つのトンネルで複数の Public hostname を処理する例

  • Load balancing 設定
    Pool 2 個、Pool ごとに Origin 1 個の例
    オリジンアドレスに cloudflard の <UUID>.cfargotunnel.com
  • 動作確認
    cloudflared、Web App をそれぞれ Down/Up
    (切替時にエラーを出してますが Load balancing のオプション機能で救えるものです)

トンネル背後のオリジンサーバーを直接 Load balancing する

Local Traffic Manager(LTM)を使えば、トンネルの先にあるプライベートネットワーク内オリジンサーバーへの負荷分散を Load Balancer で実施できます。

前項同様に公開サーバーへの接続になりますが、cloudflared 設定は上述の Public hostnameCLI)でなく、Private networkCLI)を利用します。

適用デザイン
適用例
  • cloudflared 設定
    Networks > Tunnels > Private network > Virtual networks

  • Load balancing 設定
    オリジン設定でオリジンサーバーのプライベート IP アドレスを指定し、かつ、Private network で対象サブネットに設定された Virutual network も指定します
  • 動作確認
    cloudflared を Down/Up
  • Load Blanancing Anaylytics の例
    プライベート IP への負荷分散状況を確認できます

補足

トンネルを外に出す場合は下記のようになるでしょう。

以上、cloudflared の可用性を高める方法についてでした。

Discussion