Masahiko Kitamura

Failover(2) Origin Health Detection

Blog Post created by Masahiko Kitamura Employee on Mar 27, 2017

今回はFailover機能において欠かせない要素であるOrigin Health Detectionについて解説します.

 

1. はじめに

前回の記事では,オリジンサーバが障害時にアカマイエッジサーバがどのようにFailoverの動作を行うかを見てきました.しかし,デフォルトの機能では,エッジサーバはクライアントからのリクエストを受信する度に毎回ダウンしているオリジンサーバに問い合わせをするため,レスポンスまでの遅延時間が大きく,ユーザー体験を低下させてしまう問題がありました.この問題は,数回のトライアルを行ってもオリジンがダウンしていると判断したら一定期間はオリジンへリクエストを出さないようにすることで回避できそうです.

 

そして,アカマイプラットフォームでこの機能を実現するのが今回の主題であるOrigin Health Detection(以下,OHD)になります.はじめにOHDの動作原理を説明し,実際の配信設定で具体的な値を設定した場合にどのように動作するのかを見ていきたいと思います.

 

2. OHDの動作原理

それでは,今回もフローチャートを用いてOHDの動作を追ってみましょう. OHDはFailover動作の中で機能しますので,前回説明したFailoverが発生した場合にその処理の一部として追加される形になります.図中の緑の部分がOHDに関わる部分です.OHD以外の部分に関しては前回の記事を参照してください.

 

OHDでは,基本的にオリジンサーバのIPアドレスごとにタイムアウト発生回数カウンタ(以下,Bad-IPカウンタと呼ぶことにします)を用意して健康状態を識別します.

 

  1. [Increment Bad-IP Retry Count] アクセス失敗が発生した場合,そのIPのBad-IPカウンタ値を+1します.
  2. [Bad-IP Retry Count] 
    • Bad-IPカウンタの値が設定された閾値(Bad-IP閾値)を超えた場合は, "Marking as Bad-IP"に進みます. このBad-IP閾値は後述するOHDビヘイビアの"Retry Count"によって設定可能です.例えば,"Retry Count=3"と設定した場合,Bad-IP Retry Countが4回(通常の接続1回 + Retry Count設定値 3回)になった時に"Marking as Bad-IP"の動作が発生します.
    • Bad-IP閾値を超えない場合は,"Reconnect Count Over?"へ進みます.
  3. [Marking as Bad-IP] オリジンサーバIPを"Bad-IP"として一定期間マーキングします.マーキングされたIPは"Name Resolusion"で解決されたIPリストから除外されます.このBad-IPとしてマーキングする期間も後述のOHDビヘイビアの"Retry Interval"で設定可能です.この期間がすぎると,Bad-IPマーキングが解除され利用可能なオリジンサーバIPとして扱われます.

 

このBad-IPの扱いは,一台のエッジサーバ上でグローバルに管理されるため,そのエッジーサーバに届くリクエスト全体に適用されます.よって,続く"Available IP?"において他に利用可能なオリジンサーバIPがない場合は,即時的にFailoverになります.一方,他に利用可能なオリジンサーバIPがある場合は,"Pick up an IP, Request to Origin"において,Bad-IP以外のオリジンサーバにリクエストを送信することになります.

 

3. 配信設定とFailover動作

続いて,Luna Control CenterでのOHDの配信設定を見ていきましょう.下図がOHDのビヘイビアになります.

ご覧の通り,3種類のパラメータが設定できるようになります.それぞれのパラメータの意味は下記の通りです.

  • Retry Count: OHDのBad-IP閾値
  • Retry Interval: OHDで"Bad-IP"としてマーキングする期間
  • Maximum Reconnects: Failover判断までのオリジンサーバへの再接続数の上限値(前回説明)

 

具体的にオリジンサーバのIPのAレコードが1つ("10.20.30.40")のみの場合にOHDを下記のように設定したと仮定しましょう.

  • Retry Count = 2
  • Retry Interval = 60秒
  • Maximum Reconnects = 2

 

この設定下でオリジンサーバがダウンしている時に,単体のエッジサーバがブラウザからのリクエストをどう処理するかを見ていきましょう.

 

[Request 1]

はじめにクライアント(Webブラウザ)から最初のリクエストが届きます(オリジンサーバに問い合わせが必要なリクエストとする).エッジサーバはオリジンサーバへリクエストを出し,応答を待ちますが,オリジンサーバがダウンしているためタイムアウトします(origin timeout).エッジサーバは応答をOHDビヘイビアで設定した値に従って,3回(初回の1回+OHD Maximum Reconnects 2回)の接続を試みます.3回目の接続がタイムアウトした時点でFailover動作を発動します.そして,最終的にレスポンスがクライアントへ返されます(Response1).

 

一方,オリジンサーバIP(10.20.30.40)への接続が失敗する度にBad-IPカウンタ(図中では"Bad-IP Retry")値を+1していきます.3回目の接続タイムアウトでBad-IP閾値であるOHDビヘイビア内"Retry Count"設定値(=2)を超えるため,この時点からオリジンサーバIPの10.20.30.40はBad-IP期間に入ります.Bad-IPにマーキングされている期間はOHDビヘイビア内の"Retry Interval"値である60秒間続きます.60秒後にはBad-IPマーキングが解除されるとともに,Bad-IPカウンタもゼロクリアされます.

 

[Request 2-4]

唯一のオリジンサーバIP(10.20.30.40)がBad-IPになっており,利用可能なオリジンIPが存在しないため(No Available Origin IP),即時的にFailover動作が適用されます.

 

[Request 5]

Bad-IP期間が終わり,オリジンサーバIPが再び利用可能になります.よってRequest1の場合と同様の動作になります.

 

 

ここまでは,オリジンサーバIPがひとつだけ(単一オリジン)の場合を見てきました.それでは,オリジンサーバIPが複数ある(複数オリジン)場合はどうなるでしょうか.先ほどのケースと照らし合わせて考えてみると,オリジンサーバのうちダウンしているIPのみがBad-IPにマーキングされ,その期間は他のオリジンサーバのみが利用されるようになります.

 

ここまでの話をまとめると,OHDの効果として次の2点を挙げることができます.

  1. 単一オリジンの場合,アクセスユーザーへ即時にFailoverのコンテンツが提供でき,ユーザー体験低下を回避できる.
  2. 複数オリジンの場合,ダウンしているオリジンサーバを除外して,正常動作しているオリジンサーバのみを利用し,ユーザー体験を損なわずにサービスを提供できる.

 

上記の通りオリジンサーバ異常時のユーザー体験の損失を回避する機能であるFailoverを考えるうえで,OHDは欠かせない要素といえます.

 

4. むすび

今回は,Failover機能を強化する機能としてOHDについて説明しました.オリジンサーバが障害等でダウンしてしまったという異常時であっても,アカマイのFailoverとOHDの機能を用いることでウェブサービスを続行し,ユーザー体験の低下を回避することで,ビジネスインパクトを最小限に抑えることが可能になります.

 

ここまでの連載では,Failoverの動作原理に着目し,どうのような場合にFailover動作が発動するのかについて解説をしてきました.次回からは,Failoverが発生した後に配信する代替コンテンツの設定方法ついて具体的に解説していきます.

 

注意: LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

Outcomes