Scribble at 2020-10-25 22:39:16 Last modified: 2020-10-25 22:51:08

添付画像

或るキャンペーン・サイトのサーバとバックエンドを担当していて、それなりのアクセスへ備えるために、まずは SAKURA のクラウドで「ウェブアクセラレータ」(CDN)を使うことにした。最初の 500 GB は無料で使えるらしいから、実際に使ってみて無料の枠を超えそうなら、それだけ使われているという理由で逆に稟議を通しやすくなるし、クライアントにも請求しやすい。

ただし、手順としては SAKURA インターネットのドキュメントが貧弱だったので、ここに手順を書いておく。まず標準的な CDN では CNAME レコードをネーム・サーバへ設定して、本来の FQDN に対する別名のように扱う(今回は条件が特殊なので、後から紹介する ALIAS レコードを使った)。よって、CNAME レコードを使う場合は RFC で公開されている DNS の決まりによって、代わりに A レコードを削除しなくてはならない。A レコードが設定されていると、A レコードを使った名前の解決が優先されるからだ(当たり前だ)。したがって、A レコードを一時的にでも削除してしまうため、手順を慎重に決めて作業しなければいけない。テストで建てたサーバなら大して影響はないが、公開している最中のウェブ・サーバに対して作業すると、FQDN を使って DNS へリクエストしてきた UA がウェブ・サーバへアクセスできなくなる(名前が解決できなくなる)一定の時間ができてしまうからだ。

そのため、SAKURA のクラウドでは、ウェブアクセラレータのキャッシュ側から、ユーザが建てているウェブ・サーバ(CDN サービスでは「オリジン・サーバ」と言うことが多い)へコンテンツを取得するアクセスが成功するかどうかを、あらかじめ TXT レコードに記述した内容で確認できるようになっている。SAKURA インターネットだと、ウェブアクセラレータの管理画面で「サイト追加」の手順から初めて FQDN やオリジン・サーバの IP アドレスを入力しておく。そして、ドメインの確認をするために TXT レコードか CNAME レコードを DNS に登録するよう促される。いきなり CNAME レコードを登録すると A レコードを削除することになるため、まず最初は確認だけの目的で TXT レコードを設定してドメインの確認を済ませると良い(ドメインの確認ができないとウェブアクセラレータは有効にできない)。それに、TXT レコードは A レコードを共存できるため、A レコードを削除しなくても良いのだ。TXT レコードへは "webaccel=UNIQUE_ID.user.webaccel.jp" のように、"UNIQUE_ID" の箇所へ FQDN に対応して生成されたユニークな文字列を使った設定内容を登録する。これで、暫く待つとドメインの確認が取れてウェブアクセラレータを有効にできる。

さて、これだけでは A レコードが優先されるので、ウェブアクセラレータは実際には使われない。管理画面にログとして表示されるグラフでも全くアクセスが記録されていない筈だ。(1) UA の FQDN へのリクエスト、(2) DNS での名前解決、(3) ウェブアクセラレータのキャッシュ返送(返送するコンテンツが必要ならオリジン・サーバへコンテンツを取りにいく処理が含まれる)、という一連の流れで、(2) をオリジン・サーバではなく CDN のキャッシュ・サーバへ向けるには、A レコードを削除して DNS の名前解決を代行する CNAME レコードを有効にしなくてはならない。

しかし、実はこのやり方だと今回の与件に適していない。なぜなら、CNAME レコードはサブドメインにしか設定できないからである。example.jp へのアクセスをキャッシュしたいのに、www.example.jp しか CNAME を設定できないとなると、これはウェブ・サーバで example.jp から www.example.jp に Apache の Rewrite で FQDN を書き換えてからキャッシュを返すといった処理になるが、これは意図した動作とは言えない。どちらかと言えば、広告代理店案件で建てているウェブ・サーバでは www.example.jp から example.jp に書き換えている事例が大半を占める。すると、そもそも CNAME レコードは example.jp のウェブアクセラレータに対して DNS では設定できないということだ。

このような、example.jp のようにサブドメインを全く使わない FQDN を "zone apex" や "naked domain" と呼ぶ。そして CNAME は zone apex には設定できないという点を覚えておきたい。そして、zone apex の別名を設定したい場合は、CNAME の代わりに ALIAS レコードを使う。対応している DNS でなければ使えないレコードだが、SAKURA インターネットの DNS サービス(クラウドのアプライアンスとして建てるネーム・サーバも含む)や、AWS の Route53、それからムームードメインの「ムームーDNS」というサービスでも ALIAS レコードは設定できるようになっているため、それほど導入が困難なサービスでもない。それに、他のドメイン管理サービスでドメインを登録していて、ネーム・サーバの設定を自分で使っている SAKURA やムームードメインのネーム・サーバへ向けられるなら、ドメイン管理サービスの DNS ではなく、ALIAS をサポートしているそれらの DNS サービスを使ってしまってもよい。というわけで、ALIAS でウェブアクセラレータの FQDN を設定したら、これも CNAME と同じく A レコードを残したままだと A レコードで名前を解決されてしまうので、A レコードは削除しよう。

これで、DNS とウェブアクセラレータの設定は準備できた。あとは、SAKURA のクラウドでドキュメントに書かれているとおり、<Files/> ディレクティブでキャッシュしたいファイルを特定して Header set Cache-Control "s-maxage=86400, public" のようなキャッシュ用のヘッダーを Apache の .htaccess ファイルや virtual.conf, ssl.conf といった VirtualHost の設定に追加したり、他のウェブ・サーバ・アプリケーションを使っているなら nginx や IIS の設定ファイルへ追加したりする。そして逆に、HTML ファイルからはメタ・タグで使うことが多い <meta http-equiv="Cache-Control" content="no-cache"> だとか <meta http-equiv="Expires" content="-1"> だとかを削除しなくてはならない。ここまで終えると、該当するページやファイルに何度かスーパー・リロードしてリクエストを繰り返しておけば、ウェブアクセラレータの管理画面にキャッシュへのアクセスが記録されるだろう。

これでウェブのコンテンツについては問題なくキャッシュが使えるようになるとは思うのだが、DNS を変更しているので、他の通信にどのような影響があるかも検証しておかないといけない。たとえば MX レコードについては、メールの発信は SPF で IP アドレスを正規の送信元と宣言していれば問題ない。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook