🐛

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

2024/06/02に公開

loadbalancer

cloudflared

replica

tech

はじめに

以前に 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 hostname （CLI）でなく、Private network （CLI）を利用します。

適用デザイン

適用例

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