要約

  • 主レコードと副レコードの両方にヘルスチェックがある場合、双方が不健康になると Route 53 は主レコードを返す。
  • AWS は誤った検査や連鎖的な過負荷でも接続の機会を残す。そこで業務をどこまで受け付けるかは、利用企業が決める必要がある。

バックアップのさらに後ろ

予備の拠点は安心を売る。主系を止める。待機系に切り替わる。デモの画面が緑に戻れば、予算の説明も終わる。だが待機系まで赤になったとき、案内係は何をするのか。

Route 53 の文書には、その答えがある。フェイルオーバー用の主レコードと副レコードの双方にヘルスチェックを関連付けている場合、主が健康なら主を返す。主が不健康で副が健康なら副を返す。そして両方が不健康なら、主を返す。レコードの選択方法

赤い札を二枚付けたあと、主系の住所をもう一度渡す。主系の健康判定を合格に変更する手続きではなく、DNS の回答先を選ぶ手続きである。その住所に着いた要求を処理できるかは、アプリケーション側に残された仕事だ。

この順番が重要なのは、容災設備の見栄えよりも、最後の判断を誰が持つかを示すからだ。「不健康なら通さない」と思って購入した側と、「全滅という観測でも試行の余地を残す」と設計した側では、赤色の意味が違う。

検査が間違える余地を買う

AWS は最後の回答を残す理由を説明している。ヘルスチェックの設定を誤っても、アプリケーション自体は利用者を処理できる場合がある。全候補を外して回答先をなくせば、検査の誤りがそのまま利用停止になる。フェイルオーバーの問題と設計理由

同じ文書は過負荷の連鎖も例に挙げる。三つの宛先のうち一つが不健康になり、残り二つに負荷が集まる。その二つも倒れたら、全てを除外し続けるより、再び三つに配分するほうが成功の余地を残せる。これは AWS が設計を説明するための例であり、特定企業の障害を測定した数字ではない。

理屈は筋が通っている。観測には誤りがあり、測定器に絶対的な閉鎖権を与えると、測定器自身が停止原因になれる。まだ動く窓口へ住所を返すことには価値がある。

その価値は業務によって変わる。資料をもう一度読み込む試行と、取り消しにくい取引を確定する試行では、失敗の勘定が違う。案内先を残す判断と、そこで契約や注文を成立させる判断は、それぞれ担当者を必要とする。

予備拠点の代金で購入できるのは、まず別の経路や処理容量だ。「両方が怪しいときに、何を営業し続けるか」という方針は、追加のサーバーと一緒に配送されない。

健康という名札の寸法

Route 53 のエンドポイントチェックでは、プロトコル、間隔、失敗しきい値などを設定する。連続失敗がしきい値に達すると不健康となり、その前に成功すれば失敗回数はリセットされる。CloudWatch や SNS による通知を設定する仕組みもある。ヘルスチェックの動作

チェック間隔には十秒と三十秒があり、各チェッカーは独立して動く。DNS の質問を一件受けるたび、その利用者のために業務を最初から試験する仕組みではない。周期的な観測を、回答の選択に使う。健康判定の条件

HTTP や HTTPS の接続と応答が条件を満たしても、利用者の一連の作業が完了するとは限らない。AWS は HTTPS チェックで SSL/TLS 証明書を検証しないとも記している。緑色は定義された試験への合格であり、サービスの全機能について押された万能の印鑑ではない。

副レコードにチェックを付けない場合にも、別の注意が要る。チェックのないレコードは健康と見なされる。主が不健康になると、副の実際の状態に問題があっても副を返し得る。観測を省くことで選考は簡単になるが、設備の体力は増えない。

そこで買い手は、予備容量、観測能力、劣化した状態でも正しい業務結果を出す能力を分けて評価する必要がある。二つの入口が同じ不可欠な後方システムを頼っていれば、入口の数ほど独立した仕事場を買えていない可能性がある。

検収にもう一場面を足す

主だけが赤くなる試験に加え、双方のチェックが不健康になる場面を、管理された試験環境で確認する。そのとき記録するのは、チェックの判定、実際の DNS 回答、アプリケーションが完了させた操作だ。三者を同じ時間軸で並べて初めて、最後の案内が業務上どんな意味を持ったか分かる。

コンソールでは、対象となるチェックの状態、直近の失敗理由、チェッカーの IP アドレスや時刻などを確認できる。計算型チェックには表示上の例外がある。チェック状態の確認

また AWS は、ネットワーク分断によって Route 53 の場所ごとに健康の見え方が違い、CloudWatch の表示とも食い違い得ると説明する。一枚の画面を全利用者の経験として扱うと、説明のほうが先に故障する。

公式文書には、ある顧客が両方不健康の状態で何割の業務を成功させたかというデータはない。実際の障害を評価するには、当時の DNS 回答とアプリケーションの結果が必要だ。

それでも購入時の論点は明確である。AWS は最後に返す住所を決めている。企業は、その住所で最後まで受け付ける仕事を決めなければならない。案内板を増やす予算だけでは、窓口の権限までは買えない。