Tencent Cloudで実現するIP AnyCastアーキテクチャ（をしたかった）

この記事は構築が完走していません。
というのも、AnyCast IPの利用にはSalesを通じた事前機能開放が必要でタイムアップとなり、AnyCastを利用した構築ができませんでした。
ただ、Tencent Cloudを利用したサーバ構築チュートリアルとしてはある程度使える内容と思うため、公開します。
AnyCastの性能をみたかったみなさん、申し訳ありません。
もし、サーバ構築チュートリアルでよいというみなさんはこの先もお読みいただければと思います。

アドベントカレンダーにて投稿した記事内で、Tencent CloudにAnycast IPアドレスを実現するサービスがあることを知りました。あの後再度調べてみて、確かに他のクラウドにもIP Anycastを実現する機能はあるようなのですが、

• 多人数参加するオンラインゲーム：データをキャッシュする量が少ないため単にCDNでは向かない。（というか後述のビデオチャットと同じくTURNサーバが必要なことも多い）
• ビデオチャットなど双方向通話：同じくキャッシュ量が少なく、さらにエンタープライズレベルでのモデレーションなどを利用しようとすると、TURNやSFUサーバが必要となる

など、Tencentが有力となるユースケースではIP Anycastを組みたい場合が多いように感じます。
そこで、
②あの有名なWebサービスをTencent Cloud使って作るならどんなアーキテクチャ？
のテーマとして、やや反則気味ですが、IP Anycastの最たる（Web?)サービスであるDNSをもとにアーキテクチャを考えて、軽く構築して みます。 みたかった記事です。

まずはTencent Cloudアカウントの登録

ここは住所、クレジットカード情報などなどお見せできな部分が非常に多いので細かいスクリーンショットは載せないのですが、初期登録後、一点大事な点があるので、、、

MFA登録しましょう

初期登録完了後、右上のユーザアイコンからセキュリティ設定へ移動して

SecuritySettingの最上段、MFA Deviceカラム右側の"bind"ボタンをクリックすることでMFAの登録に進むことができます。（私はすでに登録済みのためunbind表示になっていますが、未登録の場合はbindと書かれているはずです）

基本的に画面通りに入力すれば良いのですが、個人的には最後の選択肢で「Login Protection」にもチェックを入れておくのをお勧めします。

ここまででMFA Deviceの登録は完了です。

IP AnyCastなしでのDNSアクセス

Tencent Cloudには簡単にサーバを建てられるTencent Cloud Lighthouseというものがあるのですが、今回はDNS検証のためにbindを設定したり、IP AnyCastの検証のためにネットワーク設定をカスタマイズする必要があるため、VPCとCVM（Cloud Virtual Machine）で構成します。

構成図的にはかなり簡単で以下のような形です。
インターネットを経由してアクセスしているため、東京〜バージニアの接続でレイテンシなどが多く発生します。（IXなどの経由の関係などなどで迂回やホップが通常多く発生します）

VPCの作成

まずは東京リージョンにVPCを作成します。
VPCコンソールに移動して、左上のドロップダウンからリージョンを選択します。
その後CreateからVPCを作成します。東京リージョンのVPCは10.0.0.0/8系のCIDRで作成します。

同じ手順でリージョンを変えてもう一つのVPCを作成します。
もう一つのVPCは IP AnyCastの効果がわかりやすいように東京から遠いリージョンとして、EastUS（バージニア）リージョンを選択しておきます。こちらは今回の記事上区別がしやすいように172.16.0.0/16系のCIDRで作成しておきます。

SecurityGroupの作成

クラウドお馴染みのリソースごとのファイアウォールであるSecurityGroupを作っておきます。
まずは、東京リージョンにSecurityGroupを作ります。
東京リージョンはDNSリクエストを出す側として利用しようと思っているので、DNSアウトバウンドとパッケージダウンロード用のHTTP,HTTPSアウトバウンドあとはインスタンス接続用のSSHインバウンドを開けるように設定します。

次にバージニアリージョンにもSGを作成しますが、こちらはDNSのインバウンドとSSHインバウンドに加えて、パッケージのダウンロード用にHTTP,HTTPSを開けておきます。
（インバウンド系は私の今のPublicIPをもとに開けるように設定している関係であまりおみせできる画面がないので、東京リージョンのアウトバウンドの様子だけ掲載します）

CVMインスタンスの作成

Cloud Virtual Machineをいよいよ作成します。
他クラウドでは"起動"や"作成"をするとインスタンスが作成され、課金も開始されるという作りが多いと思いますが、Tencent Cloudは"購入"でインスタンスを購入し、起動するというような言葉選びになっています。

CVMコンソールページへ移動し、左側の購入を実施します（前述の通り、簡単に環境を立ち上げられるLighthouseは今回はVPC設定などを細かく指定する必要がある可能性があるので、選びません）

今回は実験用の軽いインスタンスなのでコスト削減のためにSpot Instancesを選択して作成します。
※途中スクショの撮り漏れがり、東京リージョンの作成画面とバージニアリージョンの作成画面を合わせて補完して掲載しています。

Spot Instanceのデフォルトででてくる、S5.Medium2がちょうどよいサイズなので、これを選択します。OSはせっかくなのでTencentOS、システムディスクは今回ほぼ利用しないはずなのでTencentOSの最小サイズである20GBに変更しておきます。

Spot Instanceの選択画面から遷移しようとすると、Spot Instanceについての注意事項が出てくるので同意し、ネットワークなどの設定へ。

ネットワーク設定については、これまでに作ったVPC・サブネットやSecurityGroupを選択して進めます。

ログイン方法にはセキュリティのためパスワードではなくSSH Key Pairを選択しますが、鍵をつくってこなかったのでここで「Create a new one」のリンクからSSH鍵を新規に作成しておきます。
作成したらVMの設定画面に戻り、Key Pair欄すぐ右の再読み込みボタンをクリックすれば作成した鍵が選べるようになっているはずです。

その他設定は特に変更せず、最後の確認事項に出てくる注意事項に再度チェックした上でインスタンスを作成。
支払い設定などが問題なければ、Instance画面に作成したVMが表示されるようになります。

バージニアリージョンのCVMへbindを設定

DNSのテストのために、バージニアリージョンのCVMにbindを設定します。
CVMコンソールから、確認できるPublic IPと、あらかじめ設定したSSH鍵を指定してSSHログインします。

ssh -l root -i advent_calender_key.pem <接続先CVM PublicIP>

CVMコンソールでインスタンスを選択し、「Log in」ボタンからの接続を試したくなりますが、Chromeなどの多くのブラウザは22番ポートを危険なポートとしてブロックするため、ブラウザ経由でのSSHは繋がりません。
別途CLIからのSSH接続をお勧めします。

bindのインストール

Tencent OSはCentOS系なのでyumでインストールします。
そしてインストール確認、

sudo yum install bind
named -v

<インストールログは省略>
BIND 9.11.36-RedHat-9.11.36-11.tl3 (Extended Support Version) <id:68dbd5b>

bindの起動

インストール直後だとサービスが起きていないので起こしておきます。

systemctl start named
systemctl status named

● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled)
   Active: active (running) since Sat 2023-12-23 22:07:22 CST; 3s ago
  Process: 53979 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
  Process: 53955 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAME>
 Main PID: 53981 (named)
    Tasks: 5 (limit: 10824)
   Memory: 15.2M
   CGroup: /system.slice/named.service
           └─53981 /usr/sbin/named -u named -c /etc/named.conf

bindの設定

長いので折りたたみますが、bindに設定を入れます。
日本語コメントを入れている部分と追加ファイルが変更箇所です（おそらくsshでTencentOSに持っていくと日本語は文字化けすると思うので、適宜削除ください。

named.conf

/etc/named.confを編集します。

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
    // SGで絞るので、bind側での問い合わせ元の絞り込みは実施しない。
	//listen-on port 53 { 127.0.0.1;};
	//listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	secroots-file	"/var/named/data/named.secroots";
	recursing-file	"/var/named/data/named.recursing";
    // SGで絞るので、bind側での問い合わせ元の絞り込みは実施しない。
	allow-query     { any;};

	/* 
	 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
	 - If you are building a RECURSIVE (caching) DNS server, you need to enable 
	   recursion. 
	 - If your recursive DNS server has a public IP address, you MUST enable access 
	   control to limit queries to your legitimate users. Failing to do so will
	   cause your server to become part of large scale DNS amplification 
	   attacks. Implementing BCP38 within your network would greatly
	   reduce such attack surface 
	*/
    //再帰問い合わせは切っておく
	recursion no;

	dnssec-enable yes;
	dnssec-validation yes;

	managed-keys-directory "/var/named/dynamic";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";

	/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
	include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
	type hint;
	file "named.ca";
};

// テスト用のローカルゾーンを作る。
zone "example" IN {
       file "example.zone";
       type master;
};


include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

example.zone

/var/named/example.zoneに以下ファイルを作成します。

$ORIGIN example.
$TTL      86400
@         IN       SOA     dns.example. test.example.com (
                                        2023122500 ; Serial
                                        28800      ; Refresh
                                        14400      ; Retry
                                        3600000    ; Expire
                                        86400 )    ; Minimum
          IN       NS      dns.example.
dns       IN       A       170.106.35.94
server    IN       A       192.168.0.2

設定ファイルを配置した上で、bindを再起動します。（設定ファイルに不備がある場合はrestartのタイミングでこけます）
その後、localhostを指定して名前解決を実施し、ちゃんと意図した解決がされるかを確認します。

sudo systemctl restart named
nslookup server.example 127.0.0.1

Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	server.example
Address: 192.168.0.2

東京リージョンのCVMからの名前解決レイテンシの測定

ということでまずは、IP AnyCastによる高速化なしで東京リージョンのCVMから名前解決を行なってみます。

東京のCVM->バージニアのCVMでのSGの穴あけを忘れずに。

10回DNSの名前解決をさせるスクリプトを書いて実行時間を計測します。
※(nslookup server.example を10回書いているだけ。
計測自体も2回やってみましたが、3.4秒ほどでした。

time ./query-10.sh > /dev/null

real	0m3.400s
user	0m0.051s
sys	0m0.035s

time ./query-10.sh > /dev/null

real	0m3.401s
user	0m0.054s
sys	0m0.032s

IP AnyCastありでのアクセス

次にIP AnyCastありでのアクセスに切り替えていきます。
構成図的には以下の通りのイメージです。

このちょっとした図だけを見るとあまり差がないように見えますが、AnyCast IPによって、早い段階でTencent CloudのNetwork内に入り、以降はTencent Cloudの最適化されたネットワークによって接続されるため通常のインターネット経由でのアクセスに比べ無駄な経路などが削減され、高速化することが期待されます。

バージニアリージョンのインスタンスにAnyCastIPを割り当て

ここから構築できていません。
IP AnyCastの機能は課金形態が特殊になっているため、Salesへの問い合わせと解放が必要です！
今回のアドベントカレンダーに間に合わなかった私のようにならないよう、事前に余裕をもって申請しましょう。

ということでAnyCastの設定をしていきます。
まずは、バージニアリージョンでAnyCast対応のEIPを取得します。

事前にSalesへコンタクトして解放されていれば
CVMのPublicIPを購入する際にAnyCast IPを選択することができます。
そこで作成したAnyCast IPを、今CVMに割り当てられている通常のIPと入れ替えて割り当てることで、AnyCast対応ができ、レイテンシなどが改善することが期待されます。

終わりに

IP AnyCastでの通信改善自体がみれなかったことは非常に心残りですが、VM構築などの部分については結構詳しく書けたと思いますので、誰かの役に立てば嬉しいなと思います。