頑張れIP anycast

概要

IP anycastはサーバ側で利用されている技術で、クライアントの要求に応じて、その一番近くのサーバがよろしく答えてくれるというものです。その実装はルーティングを使っているので技術的に枯れている上に、負荷分散や遅延の軽減、障害の局所化などが見込めるため、DNSを始めとするいくつかのアプリケーションで広く利用されるようになってきました。IP anycastはうまく運用すればとても効果的な手法ですが、その設計や運用、トラブルシュートなどで注意する点が多く、手間もかかります。

このセッションでは実装事例やトラブル事例を見つめて、IP anycastを実装する側や使う側が知っておいた方が良いことを話しながら、その有効利用や制限事項について議論したいと考えています。

発表者: 松崎吉伸 (株式会社インターネットイニシアティブ)

資料: 頑張れIP anycast (松崎)

ログ: Q: 会場からの質問

A: 発表者からの回答/コメント

C: 会場からのコメント

C: とあるサービスのGatewayとして、IP anycastを使っている。災害対策等を考慮し、東京と大阪で同じアドレスを使っている。

A: それはやはり、ステートレスだからなせる技か。

C: その通り。

Q: 社内のサーバ向け参照用DNSにIP anycastを使っている。 anycastは経路広報をどうするかより、障害時にどうやって経路を消すか、ということを会場を含めお聞したい。

A: interface shutdownとかBGPを使っている場合は、neighbour shutdownを行っている。

C: ちなみに私たちは消していない。というのも、LBの後ろに実サーバが何台も並んでいるため、DCが壊滅しない限りは落ちないと考えている。良い方法があったら消したい。

Q: 参照用キャッシュDNSに使っている。運用の悩みは尽きない。どこからアクセスがきているのかとか、障害時の影響はどうなのかとか。また、サーバについている実IPとanycastのIPとで挙動が異なる。anycastのアドレスに対する振る舞いを調べたいときに、どこから調べてよいか悩んでいる。この辺りについて、うまい解決策があれば教えてほしい。

A: anycastのインスタンスを導入する際に、監視用やリモートから入れるホストも近くに一緒に導入する方法が考えられる。

C: 10年ぐらいIP anycastの運用実績があるが、UDP anycastとTCP anycastとで異なる挙動を示す。UDPはパケットがドロップしても問題ないが、TCPはドロップすると再送が面倒になる。

Q: IP anycastをしているノードを監視する方法について、近くにサーバを設置するソリューション以外で何か案はあるか。

A: 現状、ない

C: 昔、6to4をやっていた。その時のバッドノウハウの共有。6to4は、srcとdst、両方がanycastになるためトラブルシューティングが困難になる。例えば、srcとdst、どちらでパケットがロストしているか、ルーティングがおかしくなっているかのトレースが困難になる。

Q: 複数のサービスで同じPrefixを使った場合、障害が発生した時に経路を消すと道連れになってしまうのではないか

A: 非常に悩ましい問題。道連れにするか、ほっとくかになる。道連れにする場合は、anycastのインスタンスを十分に分散しておくことが望ましい。ほっとく場合は、アプリケーションレベルで救済できる、といった工夫が必要になる。

Q: 昔、anycastのサービスを使っていた。問題が起こった時に、物理サーバの管理アドレスを教えてほしいと聞いたことがあるが、これはNGなのか。

A: 攻撃の標的になる他、色々な管理系に利用している可能性があるため、教えたくはないと思う。

C: anycastを使うプロトコルの例として、AMT(Automatic Multicast Tunnel)がある。サービスとして安定させるためにAMTはどうか。

C: ツールとして、RIPEのAtlasが使えるのではないかと考えている。

ハッシュタグ: このプログラムのハッシュタグは #acast です。Twitterなどでつぶやく際にお使い下さい。

→プログラムへ戻る