Fastly オリジンサーバの冗長化
Fastly ではオリジンサーバの可用性を高めるために冗長化設定を行うことができます。
冗長化には2種類の方法が考えられます。Active - Active(ロードバランス) の設定と Active - Standby(フェイルオーバー) の設定です。ここではこの両者の設定について説明します。
ロードバランス
ロードバランスの設定は単純で、複数のオリジンサーバを作成し、Auto load balance を有効にし、それぞれに配信の割合を設定します。その具体的な設定方法を見ていきます。
オリジンの作成は CONFIGURE
- ORIGINS
- + CREATE HOST
ボタンから行います。Description や Address 設定の下に Auto load balance
の設定があるため、ここを Yes
とします。この設定を変更すると Weight
の項目が表示されるので、この項目をここでは 100
と設定します。
Weight は各オリジンへリクエストする割合を決める値です。2つのオリジンがあった場合に、両方とも 100 に設定すると、両者に均等にリクエストされ、100 と 50 に設定した場合には 2:1 でリクエストが送信されます。
この場合、注意が必要なのは、両方のオリジンが必ず同じ機能を持っており、同じ返答を返すことです。片方にはコンテンツが存在し、片方にはないという状態だとロードバランスとしての機能を満たさないため、予期した結果を得ることができません。
同様にオリジンを作成すれば、定義された割合でオリジンのロードバランスを実現することができます。
フェイルオーバー
設定の内容としては、プライマリとセカンダリのオリジンサーバを用意し、デフォルトをプライマリのオリジンに設定し、プライマリのヘルスチェックが NG の場合のみセカンダリのオリジンサーバを利用するという設定を行います。よって、設定の流れとしては、
1. ヘルスチェックの設定
2. オリジンの作成
3. デフォルトをプライマリに設定
4. ヘルスチェックが NG の場合にセカンダリを利用するように設定
となります。
ヘルスチェックの設定
オリジンの死活監視を行うためのヘルスチェック設定を行います。
CONFIGURE
- ORIGINS
- CREATE YOUR FIRST HEALTH CHECK
から設定を行います。
Create a health check
に必要となる項目を入力します。
- Description
識別可能な名称を入力します。
- Reqeust
ヘルスチェックに使用するリクエスト種別およびパスを設定します。リクエスト種別は GET/HEAD/POST から選択できます。死活監視であれば、HEAD によるチェック(応答がヘッダのみ)を選択するケースが多いです。
- Host header
ヘルスチェックに利用するホストヘッダを設定します。通常オリジンに接続する際に利用するホスト名と同じになります。
- Expected response
オリジンから期待される応答を選択します。通常は正常の応答を期待するので、200 OK
を選択します。
- Check frequency
ヘルスチェックの頻度を選択しますが、ここでは Low
を選択します。
入力が完了したら、CREATE
ボタンでヘルスチェックを作成します。
オリジンの作成
オリジンの作成はロードバランス時に作成した場合と同じです。プライマリ、セカンダリの2つを設定してください。ただし、プライマリでは Health check
の項目で作成したヘルスチェックを適用するのと、プライマリ、セカンダリの両設定で Auto load balance
を No
と設定してください。
デフォルトをプライマリに設定
利用されるオリジンは req.backend
という変数で設定されます。よって、ここでは req.backend
にプライマリオリジンを設定します。
CONTENT
- Headers
- CREATE YOUR FIRST HEADER
より設定画面を開きます。
- Description
識別可能な名称を入力します。
- Type / Action
Request
/ Set
を選択します。
- Destination
設定する変数の名前を選択します。ここではリクエストの backend
に設定するため、backend
と入力します。
- Source
ここには Fastly VCL で管理されているオリジンの名前を入力します。通常、F_<オリジンの名前>
となりますが、入力情報により異なるので、実際には Fastly VCL で定義されているオリジンの名前を確認する必要があります。
確認するには OPTIONS
- Show VCL
より VCL を開いてみましょう。すると、上部に下記のようなコードが見つかります。この F_primary
がオリジンの名前となります。
backend F_primary {
.first_byte_timeout = 15s;
.connect_timeout = 1s;
.max_connections = 200;
.between_bytes_timeout = 10s;
.share_key = "xxxxxxxxxxxxx";
.port = "80";
.host = "1.1.1.1";
- Ignore if set No のままとします。
- Priority 10 のままとします。
CREATE
で設定を追加します。
ヘルスチェックが NG の場合にセカンダリを利用するように設定
同様にセカンダリのための設定を行います。ここでポイントは Priority
の値を 11
としている点です。VCL においてこの Priority は実行の順序を表します。この値を先に設定した 10 よ大きな値にすることによって、本処理をプライマリより後に実施することができます。
この設定だけでは、セカンダリに backend が上書きされるため、常時セカンダリがオリジンとして選択されてしまいます。よって、この設定が行われるのはヘルスチェックに失敗した場合のみという条件を適用します。
先ほどの設定の右に Attach condition
のリンクがあるのでクリックし、設定を開きます。
- Type
Request を選択します
- Name
識別可能な名称を入力します。
- Apply if...
!req.backend.healthy
と設定します。
backend が正常でない場合という設定を入力します。
- Priority
11 に設定します。
以上で、プライマリオリジンが正常動作していない場合にセカンダリオリジンを利用するための設定が完了です。
Author And Source
この問題について(Fastly オリジンサーバの冗長化), 我々は、より多くの情報をここで見つけました https://qiita.com/Satoshi-Ishii/items/3c57431a79053fe31513著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .