cloudflared オリジンサーバーの可用性を高める
はじめに
以前に 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 への負荷分散状況を確認できます
補足
トンネルを外に出す場合は下記のようになるでしょう。
以上、cloudflared の可用性を高める方法についてでした。
Discussion