はじめに
グループ会社のイタンジ株式会社に出向している、新卒1年目の田渕です。
AWSを用いて静的サイトをホスティングするという業務を担当し、構成を考えるところから始めて実際にホスティングすることに成功しました。
静的サイトなのにリダイレクトを設定しなければならないという要件があったため、検索してもドンピシャな構成は出てこなかったのですが、試行錯誤したところ比較的良さそうな構成に行き着いたので、共有したいと思います。
要件
新サービスの発表にあたって、LPとして静的サイトをホスティングする必要がありましたが、以下のような要件が与えられました。
-
配布するURLからLPにリダイレクトする
本番デプロイ後には配布したURLからtopページにアクセスしてほしいが、まだ本番サイトが存在しないので、現状はLPに遷移させておきたい。 -
なるべく手間を掛けずにHTTPS通信ができる形でホスティングする
静的サイトのためにサーバーを立てるとかはできる限り避ける。
選択肢
手間の面からすると、CloudFrontとS3を使うことはほぼ確定だと考えました。リダイレクト周りの詳細をどうするかについて調査したところいくつかの選択肢がありました。
-
CloudFrontのルーティングで、
/
から/lp
を表示させる設定にする
一番ラクなのですが、URLは遷移してくれないようでした。単に/
にアクセスした場合に/lp
が表示されるだけです。(display urlは/
のままになってしまう)
本番サイト公開前後で同じURLなのにも関わらず、LPとtopページが変化してしまうので、「コンテンツに対してURLが一意であるべき」という思想にも反してしまいます。
検索エンジンのことなどを考えても、あまり良い選択肢とは言えなさそうでした。 -
htmlまたはJSでリダイレクトするだけのページを作る
meta refreshやlocation.hrefを使えば良いのですが、検索エンジンがどのように判断するかもわかりませんし、クライアント側の環境によってはリダイレクトができなかったりして真っ白なページに取り残される心配などもありました。
いずれも微妙で、やはりSEO的な観点からもサーバーサイドでのリダイレクトが推奨されていそうでした。
そこでGA technologiesのSREの方に相談したところ、ALBを使えばリダイレクトができるのではないかというお話を聞き、試してみることになりました。
- ALBをリダイレクトサーバーとして利用する
ALBはロードバランサーだと思っていたためかなり意外でしたが、実はリダイレクトサーバーとしても活用できるそうです。
今回はこの方針で行くことにしました。
構成
構成の概略は以下のようなものになりました。
- topページにアクセスすると、CloudFrontはALBにアクセスします。
- ALBは302 redirectを返します。
- lpにリダイレクトした場合には、CloudFrontはS3にアクセスし、目的の静的ページを返します。
ALB側の設定は以下のように/lp
にリダイレクトするリスナーだけを設定します。
一方、CloudFrontの設定は以下のようになっています。
/lp
など、リストにマッチするパスにアクセスした際には、そのままS3のファイルが表示されます。
この際にはALBにはアクセスされませんので、ALBではすべてのアクセスを/lp
にリダイレクトするだけの設定で問題ありません。
注意点
CloudFrontとALBの間でSSL通信をするためには、ALBにもエンドポイントも設定しなければなりません。
今回の構成の利点
本番サーバーのネットワークを設定するときに、変更が大きくならないという点を気に入っています。
本番環境では、ALBの設定だけ変更し、リダイレクト設定を外して、本番サーバーをtarget groupに設定すれば済むはずです。
また、CloudFrontを使ったことによって、S3のパブリックアクセシビリティを有効にする必要もなく、AWS Lambdaと併用してBasic認証をかけることによって、公開時期のコントロールも容易でした。
問題点
予め静的ファイルのパスを決めておかなければ、本番サイト公開後に衝突してしまって意図しない動作になる可能性があります。
本番の構成ではwebpackを用いるので、本番サイトの静的ファイルはすべて/packs
以下に存在するため、今回は衝突が起こらないだろうと判断しています。
また、faviconが二重管理になってしまい、本番変更後にLPページでの変更が漏れるなど、少し考えることが増えるかもしれません。
最後に
公開したサイトは以下になります。
今後も技術的に面白い業務をした際には、積極的にブログにしていこうと思います。よろしくお願いします!