マルチクラウドの可用性と経路切替設計

読み：まるちくらうどのかようせいとけいろきりかえせっけい　／　英語表記：Multicloud availability and routing migration design

複数のクラウドと接続回線を利用し、障害時にも業務を継続するための設計である。サーバの配置だけでなく、名前解決、BGPの経路選択、ゲートウェイの冗長化、出口変更に伴う送信元IPアドレスの変化を一体として検討する。

イマシルちゃんの解説

マルチクラウドの可用性設計は、複数のクラウドを使って障害時も業務を続けられる構成を考えることだよ。
サーバを分けても両方への回線が一本だけなら、その回線の故障でどちらも使えなくなるんだ。
だからサーバと通信経路を合わせて備えるよ。
例えばBGPは、宛先への経路情報を交換するプロトコルだよ。
VRRPは、端末の出口を担当するルータを切り替えるプロトコルなんだ。
切替え先のルータにも必要な経路がなければ、通信は続けられないよ。
インターネットの出口を変えると、送信元IPアドレスの変化によって外部サービスの許可条件から外れることもあるんだ。
経路がつながるだけでなく、切替え後も業務サービスを使えるか確かめることが大切だよ。

より深い解説

継続したい業務から共通の弱点を探す

複数のクラウドを利用するときは、どの故障でもう一方へ切り替えたいのかを先に決める。同じアプリケーションを二か所に置くこと、両方へ通信できること、利用者が接続先を切り替えられることは別の条件である。

一方のクラウドが停止しても、もう一方へ必要なデータが複製されていなければ業務は継続できない。また、両方への通信が同じ回線やファイアウォールを通るなら、その装置は単一障害点として残る。DNSや認証基盤への依存関係も含めて、どこまで同時に使えなくなるかを確認する。

サーバの配置、利用者からの経路、データと認証の三つをつなげて読む。停止を許容する時間と、失ってよい更新の範囲も決める。可用性の目標は、装置が応答することだけでなく、必要な業務を続けられることである。

接続先を選ぶ方法と監視を合わせる

複数のプロキシを使う場合、端末がどの装置を選ぶかを決める必要がある。DNSラウンドロビンは一つの名前に複数のアドレスを対応させる。PACファイルは対応するアプリケーションへプロキシ候補や直接接続の判断を返す。名前解決の結果と、アプリケーションの再試行という違う段階を扱っている。

どちらの方法でも、停止した接続先を選び続けないことが重要になる。個々の装置を監視するときは、共通名だけでなく個別のIPアドレスや専用の名前を使い、どの実体を確認したかを明確にする。共通名が正常な別サーバへ解決されれば、一部の故障を見落とす可能性がある。

pingに応答してもプロキシのプロセスが動いているとは限らない。サービスの状態を試すヘルスチェックを設計し、TCP接続や中継処理まで確認するかを選ぶ。具体的な確認方法と限界は死活監視の記事で扱う。

DNS情報から故障先を除外しても、受信済みのキャッシュはすぐには消えない。DNSのTTLを計画的に短くする方法と、利用者側が再試行する条件を組み合わせて考える。また、既存のTCP接続はDNSの変更だけでは別の装置へ移らない。切替え時間は、検出、情報の更新、接続先の再選択、新しい接続の確立に分けて確認する。

引き継ぐ装置に転送の準備を整える

BGPとVRRPは役割が異なる。BGPは宛先への到達情報を交換し、VRRPは共通の出口を担当するルータを選ぶ。次の二つが両方成立して初めて、切替え先へ渡したパケットを先へ運べる。

確かめる状態	必要な内容
出口を引き継げる	VRRPの仮想IPアドレスを担当できる
宛先へ転送できる	必要な経路を採用し、ネクストホップへ到達できる

VRRPはBGPの経路情報やルーティングテーブルを同期しない。各ルータが自分の実IPアドレスを使って個別にBGP接続する構成なら、待機側も経路を学習しておく。共有アドレスの担当が移ってから経路を用意する構成では、利用者の通信を受け取っても転送できない時間が生じる。

BGPセッションの成立、経路の受信、経路表への採用、実際の転送を順に確認する。同じ宛先への静的ルーティングの設定が優先されていれば、BGPで経路を受信していても転送先は変わらない。情報源の優先順位と、転送時のロンゲストマッチを混同しない。

導入時は新しい装置への通信と経路学習を確認し、利用者の通信を渡せる状態を整えてから出口の切替えを行う。個々のメッセージや選出規則はBGPとVRRPの記事で確認する。

移行の途中でも経路を追う

変更前と変更後の構成が正しくても、途中の状態が正しいとは限らない。例えばAの出口をBへ変更した時点で、Bがまだ同じ宛先をAへ転送する設定なら、パケットが戻り続けるルーティングループになる。

この不整合はリンクの接続状態だけでは分からない。同じ宛先のパケットについて、各段階でどの経路が選ばれ、次にどの装置へ渡るかを追う。行きの通信だけでなく戻りの通信も調べる。

新しい出口側の到達性を先に用意するなど、設定の依存関係に沿って作業順を決める。旧経路を外す前には、新しい経路が受信できるだけでなく採用・利用できることを確かめる。作業に失敗した場合、どの設定をどの順に戻すかも用意する。

外部から見える接続元を確かめる

NAPTを行う出口が変わると、内部の端末が同じでも外部から見えるアドレスは変わる場合がある。外部のSaaSが接続元の許可リストを使っていれば、経路が正常でも送信元IPアドレスの変化によって利用できなくなる。

プロキシを経由する場合は、端末からプロキシへの接続と、プロキシから外部への接続を分ける。外部が確認するのは、後者が通った出口での変換後アドレスである。端末のアドレスだけを調べて移行が完了したと判断しない。

まず業務で使う外部サービスとその管理者を確認し、新しい出口のアドレスを許可する。変更が間に合わない通信だけ旧出口へ残す場合には、ポリシーベースルーティングで送り手と宛先の条件を定める。送信元だけで広く選ぶと社内DNSや管理通信まで外へ向ける可能性があるため、対象を必要な通信に限定する。

例外を設けた後も、旧出口を使う通信が残っていないかをログや管理者への確認で調べる。移行を終えたら例外規則と旧設備を撤去できる状態にする。新しい通信が成功することと、既存のTCP接続を維持できることも分けて確認する。

故障の箇所と確認結果を対応させる

冗長化の試験では、装置停止、利用者側リンク断、上流側リンク断を分ける。例えばLAN側ではVRRPの広告を送れていても、上流への経路だけ失う場合がある。何を検出したら担当を移すかは、経路やインタフェースの監視との連携も含めて決める。

試験で起こす事象	変化を確かめる場所
ルータの停止	出口の担当と、代替装置からの転送
上流の回線断	経路の撤回・再選択と、切替え後の到達性
プロキシ機能の停止	ヘルスチェックと、端末の接続先選択
インターネット出口の変更	外部が見るアドレスと、業務サービスの利用可否

停止操作を行える範囲と事業者が担当する範囲は、運用上の分担に従う。切替え後のpingだけで完了にせず、パケット損失、経路表、アプリケーションの処理結果、復旧後の切戻しを対応付ける。残った回線やサーバの容量で必要な業務を運べるかも確認する。

午後での問われ方

応答があることとサービスを利用できることを区別し、監視方法を選ぶ。
経路学習と出口の切替えの関係から、設定順序が必要になる理由を説明する。
変更途中の経路を追い、通信できない技術的原因を特定する。
外部サービスに到達できても利用できない理由を、接続元と許可条件から判断する。