AWS Amplify Console + Hugoが想像以上に楽だった話

先日、HugoとAWS S3 + CloudFrontで作ったというエントリーを書きました。
ファイティングEXレイヤーの攻略サイトをHugoとAWS S3 + CloudFrontで作りました - 谷本心 in せろ部屋

まさにこのサイトをデプロイをしたその日、AWSのre:Inventで「AWS Amplify Console」というものが発表されたんです。
新サービス「AWS Amplify Console」登場！簡単3ステップでWebアプリのCI/CD環境を構築！ #reinvent ｜ DevelopersIO
あれだけ難儀して構築したHugo + S3 + CloudFrontの環境に、さらにCI/CDまで付いたものができると言うんです。

今回は、このAWS Amplify Consoleを使ってみたら、思った以上にというか衝撃的に使いやすかったという話です。特にHugoやJekyllを使っているユーザーにはオススメです。

自動デプロイ環境がほしくてAmplify Consoleに手を出す

前回作ったサイトは、人力でデプロイをしています。
MarkdownファイルをGitHubで共有して、プルリクをもらったら僕がマージして、PCでビルドして、S3にデプロイして、CloudFrontのキャッシュを無効化してエッジサーバに再取得を促す、という流れでした。これだと明らかに「僕」がデプロイのSPOFかつボトルネックになっているため、これを自動化することにしました。
最初はGitHub Actionsを勉強がてら使おうかなと思ってβ版に申し込んだのですが、承認までちょっと時間が掛かるようだったので、せっかくなのでAmplify Consoleを試してみることにしました。

やりたかった事がいきなり全部できた

とりあえず自分のGutHub（https://github.com/cero-t/hugo_example）にあるMarkdownファイル群をデプロイしようと進めることにしました。まずはデプロイだけできたら、次はビルドファイルを更新してhugoコマンドを打てるようにするのが良いかな、、、なんて考えながら進めている途中、Amplify Consoleがこんな設定ファイルを出してきました。

version: 0.1
frontend:
  phases:
    build:
      commands:
        - hugo
  artifacts:
    baseDirectory: public
    files:
      - '**/*'
  cache:
    paths: []

えっ、なんか勝手にhugoのサイトだということが認識されてる？？
このファイルを使ってそのままデプロイしてみたところ、、、ちゃんとしたHTMLになってamplifyapp.comのサーバにデプロイされました！

そうなんです、Amplify Consoleはリポジトリで管理されているファイル群を自動識別して、最適なビルドを提供するようなんです。つまりデフォルト設定のまま進めるだけで、GitHub リポジトリからソースを取ってきて、hugoコマンドでビルドして、CloudFrontのエッジサーバにデプロイされる、という、一連の流れが全部できるようになりました。

ちなみに前回作ったfexl.tokyoのサイトは、リポジトリ内のルートではなく、一段下がった /site ディレクトリでHugo向けのコードを管理しているため、ビルドスクリプトを少しだけ変える必要がありました。

version: 0.1
frontend:
  phases:
    build:
      commands:
        - cd site
        - hugo
  artifacts:
    baseDirectory: site/public
    files:
      - '**/*'
  cache:
    paths: []

たったこれだけですから、ホントに簡単です。

なぜか遅い、って思ったら、プロダクトマネージャーの方が教えてくれて解決

デプロイまではすぐにできたのですが、デプロイしたサーバにアクセスしてみると、なぜかとても重いのです。Amplify ConsoleはCloudFrontを使っているはずなのですが、自分でCloudFrontにデプロイしたサイトに比べて10倍ぐらい応答に時間が掛かります。
nslookupしてみると日本のエッジサーバっぽいものが返ってくるし、Pingを打っても10msぐらいで返ってくるし、遅い理由がちょっと分かりませんでしたが、その旨をツイッターでつぶやいてみたところ、Amplify Consoleのプロダクトマネージャーからリプが来ました（！！）
https://twitter.com/TheSwaminator/status/1069550788106575873

どうやらエッジサーバのTTLがデフォルト5秒に設定されていて、アクセスするたびにエッジサーバがオリジンサーバにデータを取りに行くような状況になっているようです。そりゃ遅いですよね、オリジンサーバがどこにあるかは分かりませんけども。
ということで、このTTLを600（10分）に延ばしてみたところ、エッジサーバのキャッシュが効くようになり、アクセスが高速になりました。

あとちなみに、GitHubにファイルをプッシュするだけでビルドが始まるのも楽で良いです。

最後に、Route 53を設定して独自ドメインでアクセスできるようにする

Amplify Consoleが期待通り、いや期待以上のものだと分かったので、S3とCloudFrontによる運用をやめて乗り換えることにしました。そのため、fexl.tokyoというドメインをCloudFrontからAmplify Consoleに紐づけ直すのですが、ここでちょっと手間取りました。
既に運用しているドメインをAmplify Consoleに紐づけるためには、いくつか事前にやっておくことがあるようです。

Route 53でAやCNAMEで追加していたものを削除する
CloudFrontからドメインの紐づけを外す
- （CloudFrontを事前に削除しておいたほうが良い？）

これを済ませておかなければ、ドメインとの紐づけがうまく行かないようです。その辺りで一時的にサイトにアクセスできなくなったり、SSL証明書の再発行が遅れて信頼できないサイト扱いになってしまったり、少しトラブってしまいました。正直、どうすればノンストップで移行ができたのか、正解が分からない感じですね。

何はともあれHugoユーザーがデプロイする環境を作るのは楽

という事で、拍子抜けするぐらい簡単にHugoで構築する静的ホスティングサイトの自動デプロイ環境が整いました。自分でビルドスクリプトを書かず、自動認識される辺りはホントにちょっと驚きました。もう少し凝った事が必要になるなら、個別にS3とCloudFrontを立てて設定する必要があるのでしょうけど、僕にはちょうど良い感じでした。
なんか細かいところでバグっぽいものがあったり、CloudFrontの実体が見えなくてアクセス数やキャッシュヒット率も分からないとか、デプロイ周りの挙動がよく分からないことがあるみたいな部分もありますが、ここまで簡単にできるということ自体が最高でした。しばらく使い続けてみたいと思います。