Masahiko Kitamura

Failover(1): オリジンサーバが異常動作・ダウンした時のアカマイの動作

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

これから数回に渡って,オリジンサーバから5xxのレスポンスステータスコード(以後,レスポンスコード)が返る場合や,オリジンサーバからのレスポンスがない場合に適用されるFailoverについて説明したいと思います.

 

アカマイでは,オリジンサーバがダウンした場合でも,利用可能なキャッシュデータを利用してクライアントにレスポンスを返すことや,あらかじめ用意してある別のオリジンサーバに問い合わせるなど,オリジンサーバの異常時の処理をFailoverという機能で提供しています.例えば,オリジンサーバがダウンしてクライアントにレスポンスが返せない状態に陥った場合であっても,アカマイからユーザーフレンドリーな代替コンテンツ(カスタムエラーページ,別ホストへのリダイレクト等)を配信可能になり,ユーザー体験の低下によるビジネスインパクトを最小限に抑える事ことができます.

 

今回の記事では,アカマイのひとつのエッジサーバがオリジンサーバから正常ではないレスポンスを受けた場合にどのようにFailoverと判断するのかを説明し,その後,Failover時の動作について説明します.

 

 

1. Failoverの適用

Failoverは主にエッジサーバが送信したリクエストに対して,

  • オリジンサーバが5xxレスポンスコードを返したとき
  • オリジンサーバからのレスポンスがないとき(オリジンタイムアウト)

の2つの場合に適用されます.

 

オリジンが5xxのレスポンスコードを返す場合は,エッジサーバは即座にオリジンサーバのエラーとしてFailoverの判断をします.一方で,オリジンからのレスポンスがない場合(オリジンタイムアウト)は,何回かアクセスを試みてタイムアウトした結果によってFailoverの判断をします.このプロセスをフローチャートを使って見ていきましょう.

 

 

  1. [Client Request] まずエッジサーバの動作は,クライアントからのリクエストを受信するところから始まります.
  2. [In Cache?] リクエストのオブジェクトがキャッシュ(TTLが切れてない状態)されていればそれをクライアントに返して処理は終わります. もしキャッシュにない場合はオリジンサーバーに問い合わせることになります.
  3. [Name Resolution(DNS Cache)] そのために,エッジサーバはオリジンサーバのIPアドレスの名前解決を行います.名前解決が既にキャッシュされていれば,それらの結果を用いることになります.その結果,オリジンサーバのIPアドレスを一つ,もしくは,複数取得し,リスト化します.
  4. [Available IP?] 続いて,オリジンサーバのIPアドレスリストから利用可能なもの(Available IP: 後述するBad-IPマーキングされていないIP,初期状態ではすべてのIPがAvailable)を一つピックアップし,そのIPに対してリクエストを送信します.ここで,利用可能なIPが見当たらない場合,Failover(オリジンタイムアウト)と判断します.
  5. [Origin Response/Response to Client] 上記で送信したリクエストに対してオリジンサーバからレスポンスがあった場合,その結果を基にクライアントへレスポンスを返し,一連の動作は終了します(正常な場合).オリジンサーバからレスポンスがない場合(タイムアウト)は後述の動作になります.
  6. [Increment Reconnect Count/Reconnect Count Over?] もしエッジサーバのリクエストに対してオリジンサーバからレスポンスが一定期間なかった場合,再接続カウンタ(Reconnect Count)を+1した後,再接続数が上限値チェックします.上限値を超えている場合は,Failoverと判断されます.上限値を超えていない場合は再度,利用可能なオリジンサーバのIPに対して同様のリクエストが送信されます.

 

6.で用いられる再接続数の上限値はデフォルトで4回(通常の接続 1回 + Max Reconnect Count 3回)に設定されています.この上限値は次回説明するOrigin Health Detectionビヘイビアによって変更可能になっています.

 

やや複雑でしたが,以上がオリジンタイムアウトによるFailover適用のプロセスになります.

 

2. Failover時の動作

オリジンサーバから5xxのレスポンスが返ってきた場合,もしくは,オリジンタイムアウトが発生した場合,エッジサーバはFailoverの動作をします.Failover動作は下記のフローチャートに示す通り,以下の順で評価されクライアントにレスポンスが返されます.

 

  1. [No-Store or Must Validation?] もし,オブジェクトがNo-Storeもしくは"Must Revalidate"の場合,[Failover Config]へ進む."Must Revalidate"はCachingビヘイビア内で"Force Revalidation of Stale Object"が"Always revalidate with origin"が選択された場合に相当します.
  2. [Stale Cache?] もし,TTL有効期限切れのキャッシュが残っていれば,そのオブジェクトデータをクライアントに返す(Serve Stale Cache).
  3. [Failover Config?] もし,Site Failover設定(Site Failoverビヘイビア)があれば,その動作を行う(Failover Action).
  4. (Default) それ以外の場合,オリジンエラーの結果に応じて5xxレスポンスをクライアントに返す(オリジンタイムアウト場合は504 Gateway Timeoutを返す)

 

 

こららの動作を見るとわかる通り,no-storeに設定されたオブジェクトはSite Failover設定がない場合,デフォルトの5xxエラーをクライアントに返すことになり,ユーザー体験を著しく損なう結果になります.逆に,Site Failoverを設定することにより,ユーザーフレンドリーな代替コンテンツをクライアントに提供可能になります.そのため,Site Failover設定を強くお勧めいたします.

 

 

3. Site Failover設定

Site Failoverビヘイビアを用いることでFailover時の動作を規定することができます. 今回はSiteFailover設定の例として,一番シンプルなリダイレクト処理を行う設定を見ていきましょう. ここで注意すべき点は,Failover先を同じオリジンサーバに向けないようにすることです.オリジンサーバが異常なときに,代わりのリクエストをオリジンサーバにするのは意味がありません.ここでは,別のオリジンサーバ上で動作しているwww.akamai.comにリダイレクトするようにしましょう.

 

 

この設定によって,キャッシュにないオブジェクトへのリクエストに対してオリジンサーバが503, 504のレスポンスを返す,もしくはオリジンタイムアウトが発生した場合に,www.akamai.comへ302リダイレクトされるようになります.

 

 

4. オリジンタイムアウトによるレスポンス遅延

これまで見てきたFailoverの処理プロセスは,一つのリクエストに対するものでした.実際の場面を想定すると,ユーザーが同時に同一オリジンへの複数のリクエストを出すことになります.この場合,複数のリクエストに対して,どのようにFailoverの処理が実施されることになるのでしょうか.

 

実は,エッジサーバに到着する全てのリクエスト毎に毎回Failover判断のプロセスが実施されることになります.つまり,オリジンサーバがダウンしてしまい,オリジンタイムアウトが発生し,さらにFailover判断までのタイムアウト処理が全体で30秒かかるとすると,エッジサーバに到着する全てのリクエストに対して30秒経過しないとFailoverの動作が適用されないことになります.よって,たとえSite FailoverビヘイビアによってFailover動作が定義してあったとしても,毎回30秒間はユーザーのブラウザになんのレスポンスも返されない状態になります.

 

これでは,SiteFailoverの効果が半減してしまします.そもそも,オリジンサーバがタイムアウトしている場合,毎回Failoverの判断をせずに,一度オリジンタイムアウトになったオリジンサーバのIPを覚えておくことはできないのでしょうか.そうすることで,一定期間は問い合わせにいかずに,即時にFailover動作を発動させることで上記のレスポンス遅延の問題が解消できるはずです.アカマイではこの機能をOrigin Health Detection(OHD)という機能で提供しています.OHDに関しては,次回の記事で詳しく説明していく予定です.

 

5. むすび

今回は,エッジサーバからのリクエストに対してオリジンサーバが5xxレスポンスを返す場合や,そもそも応答しない場合の異常時に発動するFailover動作を説明しました.特に,オリジンサーバからのレスポンスがない場合に,エッジサーバはどのようにオリジンタイムアウトと判定するのかのプロセスについて解説しました.次回は,オリジンサーバがタイムアウトを発生させた場合に,一定期間オリジンサーバに問い合わせることなく即時的にFailover動作を発動させるOrigin Health Detectionについて説明します.

 

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

Outcomes