Google Cloud PlatformからAWSへ移行した

Introduction

かれこれ、５年くらい前の事だろうか。

Mukai Systemsを立ち上げるにあたって、Google Domainsでmukai.systemsのドメインを取得し、GCP（Google Cloud Platform）のCloud DNSでDNSサーバを建て、mukai.systemsのドメインでメールの送受信が行えるようにGoogle Workspaceでカスタムメールの設定をし、Cloud Storageを用いてこのウェブサイトを配信する仕組みを構築したのは。

そう。全部Googleだ。

さて、これらのサービスのうち、Google Domainsは１年くらい前にSquarespace Domainsという会社に買収されちゃってる。買収が発表されたときから、もう少し馴染みのあるレジストラにドメイン移管しようかな―ってずっと思っていたんだけど最近ようやく作業を終えた。あまりにも放置していたので、作業をはじめたときは既にGoogle DomainsからSquarespace Domainsへドメイン移管が行われてしまっていた。レジストラの候補が沢山あったのが作業が難航した理由の一つだ。お名前.comはメジャーだけど販促がうるさくてあんまりいい記憶がないなーとか、さくらインターネットでもドメイン取れるのかーとか。他にもバリュードメインやムームードメイン、エックスドメインに…。

結局、仕事で触れる機会が増えたという理由でAWS Route 53に移管することにした。

先述したように、Mukai SystemsのインフラはすべてGoogleで構築していたんだけど、ドメインのレジストラがAWSになったので、これを機に他のサービスもAWSに移行しちゃえっ。というのがこの記事の内容。

Description

ドメイン移管

ドメイン移管は移管元と移管先で作業が必要になる。

まずは、移管元のSquarespace Domainsでドメイン移管の手続きを行った。

公式の文書にあるように、基本的には「Enable registrar lock 」をアンロックしただけ。

移管先となるAWSではこの辺の文書に従って、移管作業を進めた。

数日かかったけど特に問題なく移管終了。

この画像は全作業を終えた後のものなので、ネームサーバにAWS Route 53で構築したDNSサーバが指定されているけど、ドメイン移管直後はドメイン移管前に設定しているGCPのCloud DNSで構築したDNSサーバが参照されていた。

移管にあたって、レジストラが用意しているDNSサーバを用いている場合は、ドメイン移管と共にDNSサーバが使用できなくなり、したがって、名前解決できなくなることがある。利用者からするとシステムがダウンしていることになるので、一般的には移管前にDNSサーバを建てておくのが無難なようだ。

今回はGCPに建てたDNSサーバを用いているために、この問題はなかった。いずれにしても、Mukai Systemsの場合は数日間ウェブサイトがダウンしたところで誰も困らないから気楽なものだけど笑

DNSサーバの構築

AWS Route 53を用いてDNSサーバを構築する。ドメインのネームサーバを変更するまでは、GCPのCloud DNSが参照されているのでこの時点ではまだ何も影響はない。

基本的にはGCPのCloud DNSのレコードをAWSのRoute 53に設定すればOK。このとき、誤設定の被害を最小限にするために、一時的にTTLは短めにしておくとよい。

ウェブサイトの移行

Mukai SystemsのウェブサイトはGCP Cloud Storageを用いて静的に構築していた。これを、AWSの同等なサービスであるS3に移行した。

S3のバケットの作成は少し試行錯誤した。

普通に静的ウェブサイトを構築するなら「静的ウェブサイトホスティング」というオプションを有効にしてパブリックアクセスを許可しておしまいなんだけど、https接続のためにCloud Frontを使うことは確定していたし、ウェブサイトエンドポイント経由でアクセスされるのがなんとなく嫌だったので、次のように設定して後に構築するCloud Front経由でのみアクセスできるようにする。

パブリックアクセスをすべてブロック
静的ウェブサイトホスティングは無効

バケットを作ってしまえば、データの移行は簡単。Cloud Storageで管理していたファイルをS3に放り込めばいい。AWSにはGCPと同様に似たようなCLIがあるので、運用は変わらない。

gsutil -m rsync -rd ./mukai.systems gs://mukai.systems/
aws s3 sync ./mukai.systems s3://mukai.systems --exact-timestamps --delete

どうでもいいけど、awsコマンドはオプションが末尾なのはなぜ？笑

CLIでS3にファイルをアップロードすれば、静的ウェブサイトの器は完成。

S3は直接外部からアクセスできないように構築したので、Cloud Frontを構築して外部からのアクセスできるようにする。Cloud FrontはいわゆるCDNで、S3との連携もしっかりサポートされている。手順に設定していけば簡単に作成できた。

作成中にAWS Certificate Managerで証明書を発行することができるので、指示に従って事前に作成したDNSサーバにCNAMEレコードを追加すればいい。

S3の静的ウェブサイトホスティングを有効にしていた場合の最大のメリットとして、インデックスドキュメントのサポートがある。

これは、以下のようなリクエストに対して、

https://mukai.systems/about/

以下のようなリソースへのリクエストと見做して処理してくれるような仕組みだ。

https://mukai.systems/about/index.html

Mukai Systemsのウェブサイトはこの仕組みを大いに活用していたので、これをCloud Frontで実現しないといけない。幸いCloud FrontにはCloudFront Functionsという仕組みがあって、CloudFront を通過するリクエストとレスポンスの操作などができる。開発者ガイドに今回の目的を満たすコード片があったので速攻で適用。

async function handler(event) {
    const request = event.request;
    const uri = request.uri;
    // Check whether the URI is missing a file name.
    if (uri.endsWith('/')) {
        request.uri += 'index.html';
    } 
    // Check whether the URI is missing a file extension.
    else if (!uri.includes('.')) {
        request.uri += '/index.html';
    }
    return request;
}

CloudFront Functionsは課金対称なサービスなんだけど、月当たり200万件のリクエストは無料という太っ腹ぶり。Mukai Systemsのウェブサイトを配信する用途では料金は到底発生しえませんな。

DNSサーバの移行

いよいよドメインのネームサーバをRoute 53に構築したホストゾーンのNSレコードの値に変更する。

Mukai Systemsのウェブサイトが閲覧できているか、カスタムドメイン「mukai.systems」のメールアドレスで送受信ができるかを確認して移行終了。

Conclusion

GCPにロックインされてなくてよかった。

Mukai Systems