サイトリニューアル時のURLリダイレクトをLambda@Edgeで実現する
弊社では昨年9月にコーポレートサイトをリニューアルしました。
リニューアルに伴いコンテンツの構成が変更になるため、URLも変更する必要がありました。
URLの変更はコンテンツの変更を伴ったサイトリニューアル時にはしばしば発生します。
その際、検索エンジンにしばらく旧URLがインデックスされていたり、旧URLのブックマークから直接アクセスされたりすることがあるので、新URLへリダイレクトする設定をしておきたいです。
今回は、サイトコンテンツのリニューアル時に関連するURLにリダイレクト (転送) する方法について書いてみたいと思います。
まず、大前提として旧URLと新URLのマッピングが必要です。例えば
旧サイトURL: https://mmmcorp.co.jp/solutions/aws_lambda/"
新サイトにおける類似コンテンツのURL: https://mmmcorp.co.jp/service/serverlessarchitecture/
のようなマッピングをエクセルなどで整理しておきましょう。
その上での技術的な話となりますが、リダイレクトの一般的な対応方法としてはWebサーバーでリダイレクトをかけることが多いかと思います。Webサーバーが例えばApacheであれば.htaccessファイルなどで設定します。
しかし、新コーポレートサイトにおいてはAWSのS3およびCloudFrontを利用して静的なコンテンツ配信を実施しています。静的コンテンツ配信はサイトスピード向上・可用性向上・運用コスト削減などメリットが非常に大きいのですが、それだけではWebサーバーでの転送ができないという問題があります。そこで、本ケースにおいて有効なLambda@Edgeを利用した転送を実施することにしました。
Lambda@Edgeとは
Lambda@Edgeの読み方はラムダアットエッジだと思います。(ただ、私はラムダエッジと呼んでいます。)
Lambda@EdgeとはAWSのCDNサービスであるAmazon CloudFrontの機能で、CloudFrontのエッジロケーションにおいてアクセスに対して任意のプログラム (AWS Lambda) を実行できる仕組みです。サーバーレスな仕組みであり、自前でサーバーを用意する必要はありません。
CloudFrontは静的なコンテンツ配信のサービスであり、Webサーバーで実現できる動的な制御が難しいのですが、Lambda@Edgeはその問題を解決できます。
今回のURLのリダイレクト以外にも非常に様々なことが実現できます。
- サイトにBasic認証をかける: これは以前の弊社ブログS3静的ウェブホスティング+CloudFront+Lambda@EdgeでBasic認証をかけるでも紹介しています。
- デバイスや国に応じたコンテンツの変更: こちらも以前の弊社ブログLambda@Edgeでアクセス元の国を判別してリダイレクトでも紹介しています。
- A/Bテスト: アクセスをバージョンA/Bにランダムに割り当てるようクッキーをセットし、ページを振り分けるといったことが可能です。
実際のプログラム例
それでは実際のプログラム例をご紹介します。
'use strict';
const baseURL = "https://mmmcorp.co.jp";
const urlMap = {
"https://mmmcorp.co.jp/services/aws/": "https://mmmcorp.co.jp/service/development/",
"https://mmmcorp.co.jp/solutions/aws_lambda/": "https://mmmcorp.co.jp/service/serverlessarchitecture/",
"https://mmmcorp.co.jp/services/aws/migration/": "https://mmmcorp.co.jp/service/migration/",
... (ここにURLのマッピングを愚直に設定しています。)
};
exports.handler = (event, context, callback) => {
const request = event.Records[0].cf.request;
let uri = request.uri;
if (request.uri.slice(-1) !== '/') {
uri += '/';
}
const key = ${baseURL}${uri}
;
let val = urlMap[key];
if (val == null) {
callback(null, request);
return;
}
const response = {
status: '302',
statusDescription: 'Found',
headers: {
location: [{
key: 'Location',
value: val,
}],
},
};
callback(null, response);
};
サイトアクセス (CloudFrontへのアクセス) 時に上記プログラムを実行するようにしており、マッピングに合致するURLへのアクセスであればリダイレクト、合致しないURLであればそのままアクセスできるようにしています。
Lambda@Edgeでページをリダイレクトする際の注意事項
Lambda@Edgeはプログラムを書いて動作させることになりますので、当然バグを作り込んでしまう可能性があります。
Lambda@Edgeはサイトアクセス時に必ず動作させるプログラムになりますので、サイトにアクセスできなくなってしまうというような重大バグを作り込んでしまう可能性も大いにあります。
バグを作り込まないように以下のような対応が考えられます。実際弊社でも後者2つの対応を実施しています。
-
テストコードを書く: これはかなり面倒で、今回は自社コーポレートサイトというサービスの事情も踏まえ、テストコードは書いていません。
-
ステージング環境でテストする: 本番と同様の環境を用意し、期待通りのリダイレクトが動いているかテストをしてから本番にリリースします。
-
本番サイトを監視する: 万が一、本番のLambda@Edgeプログラムを間違って書いて、サイトアクセスできない事態になってしまっても、それをすぐに検知できるように監視します。弊社ではDatadogを利用した監視を実施しています。
まとめ
今回、サイトリニューアル時にLambda@EdgeでURLのリダイレクトを実現する方法をご紹介いたしました。
弊社でサイトリニューアルのお手伝いをする場合、サイトの高速化や可用性、メンテナンスコストの削減のため、要件を踏まえた上で可能な限りS3, CloudFrontを利用した静的なサイトホスティングをご提案させていただいております。
これまで動的な部分が必要なためにS3, CloudFrontでの静的ホスティングが不可能だった案件においても、Lambda@Edgeを利用することで可能になるケースも増えてくると考えています。
AWS Lambdaを使った最適なアーキテクチャや、メンテナンスコストを考慮したサイトリニューアルについて、以下のページでご案内しています。
ご相談・ご質問も受けつけています。お気軽にお問い合わせください!