Laravelのセッション管理にAWSのElastiCacheを利用する際の方針検討

AWSのElastiCacheを自製品サービスで利用する際に、検討する内容について記載します。

使用用途など

Laravelを利用したプロジェクト管理ツールを開発しています。Laravelではそのセッション管理にRedisを使用可能です。このRedisをAWSのElastiCacheで対応します。
Laravelで利用する場合の対応手順などは以下を参照して下さい。

www.prj-alpha.biz

Laravelのセッション機能では、色々な情報をセッションに保有することも可能になっていますが、現時点ではそのような利用の仕方はあまりしていません。主にサインインしているか、してないかが主な利用用途となっています。セッション情報が失われた場合、再度サインインが必要になるという影響があります。

セッション数やのサイズなど

ElastiCacheのモニタを確認し、セッション1つ当りのサイズを1kとして仮定した。サービス開始時の接続セッション数は cache.t2.micro でもキャパシティは問題ないものとする。

サービスの運用開始後にセッション数やサイズの状況を確認し、必要に応じてスケールアップする。

構成を検討する際に関連する各種機能の概要

キャッシュノードタイプは cache.t2.micro でも問題ないものと仮定するが、t2では利用できない機能がある。また課金はノードの数となるため、レプリカノード数やシャード数により増えていくので注意する。
またプリイマリーノードのアベイラビリティーゾーン（以下、AZ）はEC2（EC2が1台の場合）と同じにする。

同じアベイラビリティーゾーン内での Amazon EC2 と Amazon ElastiCache 間のデータ転送は無料です。

料金 - Amazon ElastiCache（キャッシュ管理・操作）| AWS

レプリケーション

ElastiCache クラスターの作成をする際に、読み書きするノード（以下、プライマリノード）とは別に1～5個の読み取り専用ノード（以下、レプリカノード）を作成しクラスターとして構成することができます。レプリカノードはAWSのドキュメントではリードレプリカ、セカンダリレプリカと記載されています。
クラスターとして構成すると、プライマリノードにデータが書き込まれると、変更が非同期的に全てのレプリカノードに反映されるように動作します。

シャード

シャードとはデータをグループ別けてして分割管理すること。水平分割と呼ばれます。

簡略化したイメージで説明します。現在、1GBの容量でデータを管理しているとし、更に1GBのデータ容量を追加して管理する必要がある場合を考えると、以下の方法があります。

• ①2GBをまとめて管理する
• ②1GBを2つ管理する

 ①も②もデータの内容は同じですが、管理の方法が違います。②は2つの領域で管理することになり、この領域をシャードと言います。この場合、2つのシャードで管理しており、シャード数2となります。このシャード毎にノードが存在することになります。①は1つの領域なので、シャード数1という言い方もできます。

②の場合、新しいデータが登録されるとどちらかのシャードに振り分けて登録されます。参照する場合はこの振り分けた情報を元に参照先のシャードを特定してアクセスします。①に比べ、②の場合は登録・参照の間に1アクション多いことになりますが、読み取り・書き込みは複数のノードに負荷が分散されることになります。

自動フェイルオーバを備えたマルチAZ

ノード障害を自動検知し、障害ノードを新しいノードを自動で置き換えることができる機能。
プライマリノードに障害が発生した場合、レプリカノードをプライマリノードに昇格させ、プライマリノードと置き換える。このときプライマリノードのエンドポイントの変更が必要ありません。レプリカノードに障害が発生した場合、ノードと新しいノードを置き換える。

マルチAZにするため、作成する際のサブネットグループは複数のAZにしておく。レプリカノードも同一AZにした場合、AZ全体で障害が発生した場合に対応できない。

クラスターモード

作成する際のクラスターモードの有無により機能の特徴がある。大きい機能差はシャードの設定の可否となります。クラスターモードは後から有無を変更することはできない。

クラスターモード無効の特徴

• シャードの設定ができない。
• レプリカの追加、削除ができる。
• ノードタイプのスケールアップができる。スケールダウンはできないので、その場合は新しくクラスタを作る必要がある。
• 自動フェイルオーバーを備えたマルチAZは、t2ノードタイプでは未対応となる。

クラスターモード有効の特徴

• シャードの設定ができる。
• レプリカの追加、削除ができない。
• ノードタイプの変更ができない。容量が足りない場合、ノードのスケールアップではなく、シャードの追加で対応することはできる。シャードは最大15個まで増やせる。
• 自動フェイルオーバーを備えたマルチAZが必須となる。マルチAZにするため、レプリカを1以上にする必要があるが、0としても作成することができてしまう。ただしレプリカがないとフェイルオーバーは対応できない。
• シャードが複数か、レプリカが1以上の場合、Laravelのクラスターモードとして設定する必要がある

構成の設定方針について

使用用途でも記載したが、今回の用途はLaravelのセッション管理です。また ノードタイプは cache.t2.micro でもキャパシティは問題ないものとします。
障害によりデータが消失した場合、サインインした状態が失われ再度サインインする必要があります。障害によりデータにアクセスできない場合、製品サービスは完全に利用できない状態となってしまいます。つまりサービス停止状態です。

今回の基本方針はサービス停止状態を極力避けるため、自動フェイルオーバを備えたマルチAZの機能を有効にする設定をベースにして考えていきます。

自動フェイルオーバを備えたマルチAZとその他の設定

自動フェイルオーバーを備えたマルチAZを利用するためには、以下の設定が必要になります。

• レプリカノードが1つは必要となる。
• クラスターモード無効の場合、t2ノードタイプは未対応なのでそれ以外のノードタイプを選択する必要がある。

コスト面から cache.t2.micro を選択したいが、クラスターモード無効の場合は選択できないのでクラスターモード有効で設定を行う。この他にマルチAZなどを考慮すると今回は次のような設定をする方針となる。

ElastiCacheの設定方針

• クラスターモード有効で設定する。自ずと自動フェイルオーバーを備えたマルチAZを利用することとなる。
• ノードタイプは cache.t2.micro とする。
• シャード数は1、レプリカ数は1とする。（ノード数は2となる。）
• サブネットグループは複数のAZを利用できるようにし、プライマリノードはEC2と同じAZ、レプリカノードは別のAZにする。
• バックアップは不要とする。

運用開始後に cache.t2.micro で収まらない場合はサービス停止期間を設けてクラスターを作り直して対応することとなる。セッション数やサイズをモニタリングしながら、必要に応じて検討する。Laravelのセッション継続時間の設定で微調整は可能。

まとめ

今回はElastiCacheについて自製品サービスで利用する際の設定方針でした。

以上

【関連するリンク】

www.prj-alpha.biz

ドメイン変更やHTTPS化などURLの変更時に、Search Console のアドレス変更によりグーグル検索への影響を減らす

今回は独自ドメインで運用していたウェブサイトのドメイン名などのURLの変更時の、グーグルの Search Console のアドレス変更の対応を紹介します。URLの変更はHTTPS化も含まれます。
※追記　HTTPをHTTPSにするだけの場合、 Search Console のアドレス変更はできませんでした。
今回はサブドメイン名を変更した状態を想定し、変更前のドメイン名を「旧ドメイン名」としその値を「old.domain.com」、変更後のドメイン名を「新ドメイン名」としその値を「new.domain.com」と記載していきます。

Search Console のアドレス変更による対応

これまで運用していたウェブサイトについてドメイン名を変更した場合のグーグル検索について考えます。この場合、グーグルで検索した結果には旧ドメイン名で表示されてしまいます。
旧ドメイン名ではなく新ドメイン名で表示されるようにするには、Search Console によるアドレス変更を利用します。このアドレス変更を利用することで、現在のグーグル検索の掲載順位への影響を最小限に抑えながら、新ドメイン名をインデックスに以降することができます。Search Console のアドレス変更によって既存のコンテンツの新しいURLがグーグルに通知され、インデックスを更新し新ドメイン名を反映することができます。

support.google.com

アドレス変更の対応はHTTPS化の際も必要です。Search Console ではHTTPとHTTPSは別の管理となるため、これらのプロパティのデータは Search Console で共有されません。 

support.google.com

Search Console のアドレス変更の前の作業

Search Console のアドレス変更の前の作業として、まず旧ドメイン名だけでなく新ドメイン名が Search Console で管理されている必要があります。事前に新ドメイン名も管理するように登録しておきます。

またアドレス変更できる条件として、旧ドメイン名から新ドメイン名に301リダイレクトされている必要があります。AWSのS3を利用して301リダイレクトするには以下を参照して下さい。

www.prj-alpha.biz

また301リダイレクトについては以下を参照して下さい。 

www.prj-alpha.biz

Search Console のアドレス変更を行う

Search Console からアドレス変更を行います。旧ドメイン名のプロパティを選択して、設定ボタンからアドレス変更を押します。

アドレス変更が表示されたら、新ドメイン名を選択します。

新ドメイン名を選択したら、後は確認ボタンを押していき問題なければ送信を行います。

正しくできれば変更リクエストのメッセージが届きます。

Search Console のアドレス変更の結果の確認

アドレス変更の依頼をした後の状態を、グーグル検索してみて新ドメインで表示されてるか確認できますが、今回は Search Console で確認します。変更の反映状況はグーグルのインデックスの量によって変更されるものと思われます。今回の場合は約2週間後の状態です。

ベータ版ですが新しい Search Console での表示結果を加工したもので示します。上が旧ドメインで下が新ドメインの表示結果となります。まずはクリック回数の状況で、青がクリック回数で、ターコイズブルーが表示回数です。

続いてグーグルのインデックスの状況です。棒グラフがインデックスに登録されたページ数で、折れ線グラフは表示回数です。

変更リクエストを行った日から約1週間程度でインデックスの移行が行われていき、約10日間で旧ドメインはグーグル検索結果では表示されなくなりクリックされなくなったことが確認できます。そして代わりに新ドメインでグーグル検索結果が表示されクリックされたことが確認できました。
これにより Search Console のアドレス変更が正しく行われ、グーグルで検索すると旧ドメインではなく新ドメインで表示されたことが確認できました。

まとめ

今回はドメイン変更やHTTPS化などURLの変更時の Search Console のアドレス変更の対応の紹介でした。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

www.prj-alpha.biz

目黒のバー

目黒の権之助坂近辺の路地の地下にあるバー奇奇（キキ）。10人以上は座れる長いカウンターとソファー席があり、ゆったりとした空間が広がる。マスターが一人で営業していて、目黒周辺で飲んだときにウィスキーが飲みたくなったときには利用していた。金曜や土曜に訪れるのがほとんどだったが、あまり他のお客がいなくてゆったりと飲むことができた。

お店に数ヶ月ぶりに訪ねたら、なくなっていた。聞くところによるとマスターが体調があまり優れなくなり閉じたとのこと。寡黙なマスターだったが、おススメを聞くと色々と出してくれた。中でも覚えてるのが、ホワイト&マッカイの年代物。黒地に２頭のライオンが輝く瓶で、一口含んだ瞬間にその香りとなめらかな味わいに驚いた思い出。「これ物凄くおいしいですね」とこっちが言うと「こんな年代物ならどんなウィスキーでも旨いに決まってますよ」と笑っていた。「こーいうの、うちは原価で出してるけど全然出ないから、これが最後の瓶ですね」とのことで、「それじゃあ」とおかわりを注文し最後の一杯を堪能した。他のも合わせて4杯飲んだが一人当たり8000円程度だったから本当にお得だった。

閉店してしまったのは残念ですが、良いお店でした。

JavaScriptのPromiseで処理の順番を制御する

今回はJavaScriptのPromiseについて、重めの処理をする際に順番を制御するのに利用したので説明します。

データ読込処理などで処理の順番を制御する

データの読込など時間のかかる処理を行う場合を考えてみます。例えば以下は我々の開発しているプロジェクト管理ツールにExcelのデータをコピーして、ペーストでデータを貼り付けるイメージです。

このままだとペーストした場合に、全ての処理が終わってからブラウザ側のDOMに反映されます。処理に時間がかかるり何もされてないように見えるので、良く考えられる対応は処理の完了前後にデータをロードしているスピナーのようなイメージ画像などを表示する対応です。処理の開始時にイメージ画像を表示、表示後にペースト処理、ペースト処理の完了後にイメージ画像を消去するといった流れです。
このようにJavaScriptで処理の完了を待ち、その順番を制御するのにPromiseを利用します。

Promiseについて

Promiseを使った非同期処理の基本構文はPromiseオブジェクトを作成して、then() でコールバックを登録していきます。then() で setTimeout() を実行しても良いですが、今回はコンストラクタで実行します。

// 1：new Promise()によりPromiseオブジェクトを作成
var promise = new Promise((resolve, reject) => {
    // 3： 非同期処理実行
    setTimeout(() => {
        console.log("対象処理の実行");
        var result="処理結果";
        // 4： 完了時にresolve()を実行、結果を渡すことも可能
        resolve(result);
    }, 500);
});
 
// 2：Promiseオブジェクトにthen()でコールバックを登録
promise.then((result) => {
    // 5：resolve() の引数を渡してコールバック実行
    console.log(result);
});

上記の書き方だと、gulp-uglifyでmin化したときにエラーとなってしまいました。ちょっと調べて解決策がわからなかったのですが、Promiseの引数や then() をfunction形式にして対応することができます。

// 1：new Promise()によりPromiseオブジェクトを作成
var promise = new Promise(function(resolve, reject){
    // 3： 非同期処理実行
    setTimeout(function(){
      console.log("対象処理の実行");
      var result="処理結果";
      // 4： 完了時にresolve()を実行、結果を渡すことも可能
      resolve(result);
    }, 500);
});
 
// 2：Promiseオブジェクトにthen()でコールバックを登録
promise.then(function(result){
    // 5：resolve() の引数を渡してコールバック実行
    console.log(result);
});

上記を基本構文として説明していきます。まず new Promise() でインスタンス化することでpromiseオブジェクトを作成しています。このpromiseオブジェクトには3つの状態があります。

1. pending：初期状態。成功も失敗もしていません。
2. fulfilled：処理が成功して完了したことを意味します。コールバック関数内で resolve() が呼ばれます。
3. rejected：処理が失敗したことを意味します。コールバック関数内で reject() が呼ばれます。

reject() は、明示的に reject() された場合だけでなく、コンストラクタでエラーがスローされた場合に暗黙的にも発生します。この成功の resolve() や失敗の reject() が呼ばれた場合の処理を then() で定義します。then() は上記の基本構文では1つの引数にしてますが、2つの引数をコールバックとして持つことができ、それぞれが成功と失敗に対応します。

promise.then(function(result) {
    console.log(result); // resolve()
}, function(err) {
    console.log(err); // reject()
});

また then() はPromiseオブジェクトを返すので連鎖させてメソッドチェーンにして記述することもできます。このとき値が返されると、その値を指定して次の then() が呼び出されます。

promise.then(function(result){
    // 1回目の処理
    var val=1;
    return val + 2; // returnして次の処理に渡す
}).then(function(val){
    // 2回目の処理
    console.log(val)// 3が表示される
});

then() の2つのコールバックの名前をonFulfilled,onRejectedとすると以下のようになります。

promise.then(onFulfilled, onRejected)

このように then() では成功と失敗の処理を同時に登録することができます。 また、エラー処理だけを書きたい場合には catch() を使用して以下のように記述することができます。

promise.catch(onRejected)

このは catch は以下と同じ意味となります。

promise.then(undefined, onRejected)

チェーンにして記述されている場合に reject() されるとどうなるか。失敗のコールバックを持つ then() または同等である catch() まで処理はスキップされます。その失敗のコールバックが正常に終了すれば、続く成功のコールバックを処理します。また then(onFulfilled, onRejected) と指定した場合、onFulfilled または onRejected が呼び出されますが、両方が呼び出されることはありません。

promise
    .then(func1) // resolve()
    .then(func2,func3) // func1が成功の場合はfunc2を実行、reject()かfunc1が失敗の場合はfunc3を実行
    .catch(func4) // 直前実行のfunc2またはfunc3が失敗の場合のみfunc4を実行
    .then(func5) // func2またはfunc3が成功の場合、または直前実行のfunc4が成功の場合はfunc5を実行
;

今回の対応方法

今回は基本構文を基にコンストラクタで非同期処理を行い、例外処理の中で reject() を明示して対応しました。

promise = new Promise(function(resolve, reject){
    //対処処理の開始前にimageを表示する
    console.log(”スピナー画像の表示”);
    
    //非同期処理
    setTimeout(function(){
        //対象処理
        try{
            //対象処理の実行
            console.log(”対象処理の実行”);
        }catch(e){
            //失敗の場合、reject() を呼び出す
            reject(e);
        }
        //成功の場合、resolve() を呼び出す
        resolve();
    }, 500);
});

promise.catch(function(e){
    //エラー処理
    console.error("エラー：", e.message);
}).then(function(){
    //成功、失敗の共通処理
    console.log(”スピナー画像の非表示”);
});

スピナー画像の対応後のイメージです。

IE11の対応

PromiseはIEでは未対応です。polyfillを読み込むことで対応できます。以下のリンクを参考にして、scriptタグを追加して対応しました。
https://www.promisejs.org/

<script src="https://www.promisejs.org/polyfills/promise-7.0.4.min.js"></script>

まとめ

今回はPromiseを利用しての、処理の順番の制御方法の説明でした。

以上

Laravelのセッション管理にRedisを指定し、AWSのElastiCacheを利用する

今回はLaravelのセッション管理について、Redisを指定しAWSのElastiCacheを利用する方法について説明します。

Laravelのセッション管理方法について

Laravelのセッション管理方法については以下の種類があります。

• file - セッションはstorage/framework/sessionsに保存されます。
• cookie - セッションは暗号化され安全なクッキーに保存されます。
• database - セッションはリレーショナルデータベースへ保存されます。
• memcached／redis - セッションはスピードの早いキャッシュベースの保存域に保存されます。
• array - セッションはPHPの配列として保存されるだけで、リクエスト間で継続しません。

初期状態は「file」で既定のパスに保存されます。この設定で問題になるのはウェブサーバが複数台になった場合です。それぞれのウェブサーバのパスでセッションが管理されることになるため、認証が必要なサイトの場合にあるウェブサーバで認証したのに別のウェブサーバに接続した際に再度認証を求められることになりまし、その他セッションに保存した情報が共有されなくなります。

cookie利用時に出た課題

「cookie」を設定した場合、クライアントに暗号化されたクッキーが保存されます。この設定をした場合、Nginx側で「400 Bad Request」のエラーが出るようになりました。クッキーのサイズが原因でNginxの設定で「large_client_header_buffers」を変更すれば発生する頻度が低減できることは確認できましたが、完全に防ぐことできるわけではあありません。セッションの機能を多く使ったつもりはないのですが、「large_client_header_buffers」が既定値のままだとある程度利用するとこのエラーが出ました。将来的にセッションの機能の利用方法を拡張することで、このエラーがより発生する可能性が高くなりそうなので他の方法で対応することにします。

Redisの利用

他の方法として「database」かインメモリ型の「memcached／redis」ですが、今回は「database」より高速な「memcached／redis」を利用します。AWSでは1年間以内であればElastiCacheの無料利用枠がありますので、「redis」をこれで活用することにします。気付いたら無料利用枠が色々広がってます。AWS凄いですね。

ElastiCacheの利用のための設定

Laravelが稼働しているEC2から、ElastiCacheに接続できるようにします。EC2とElastiCacheは同一VPCとして設定していきます。

セキュリティグループの追加

ElastiCacheに設定するセキュリティグループを追加しておきます。作成するときにVPCはEC2と同一のものを指定します。

作成したセキュリティグループのインバウンドのルールにRedis用のポート番号を指定します。デフォルトでは「6379」です。ソースに「0.0.0.0/0」を指定するとVPC内で起動した全てEC2からアクセスできます。

ステップ 4: アクセスを許可する - Amazon ElastiCache

ElastiCacheのサブネットグループの追加

ElastiCacheのメニューからサブネットグループを追加します。登録済みのサブネットからVPCに関連するものが選択できます。アベイラビリティーゾーン（以下、AZ）が複数になるようにすることが推奨されています。ElastiCacheの作成するときにレプリケーション数としてノードを複数作成ることがかのうで、それぞれのノードのAZを分散させることで障害に強くなります。

リージョンとアベイラビリティーゾーンの選択 - Amazon ElastiCache

ElastiCacheクラスターの作成

ElastiCacheの作成ボタンからRedisを選択して、作成します。今回はノードのタイプを無料枠の「t2.micro」にして、それ以外はデフォルトの設定のままとします。ポート番号を変更する場合はセキュリティグループの設定も変更して下さい。レプリケーション数は「2」のままとします。

作成ボタンを押した後に数分後にステータスが「available」となれば作成できた状態です。「有効なクラスターモード」としていないのでシャードは「1」です。ノードはプライマリとレプリケーション数の2を足した3となっています。
ちなみにAWSの無料枠はt2.microで750時間/月となってす。これは1ノードが1カ月稼働してる分には無料ですが、複数のノードとなると無料枠を超えることになるのでレプリケーション数には注意しましょう。

作成したクラスターの情報を確認し、プライマリエンドポイントをコピーしておきます。Laravelの設定で使用します。

ノードの状態を見るとAZが自動で振り分けられ複数のAZにノードがある状態となります。現在のロールが「primary」のエンドポイントを確認しておきます。先ほどのプライマリエンドポイントとは違うものとなっています。

「primary」がフェイルオーバーして他のノードが昇格した場合、「primary」のノードは変更され、「primary」のエンドポイントは変更されることになりますが、プライマリエンドポイントはそのままです。プライマリエンドポイントを利用することで、障害発生時もアプリケーション側の設定は変更せずに対応することができるようになります。

Laravelの設定

Laravelの設定として「APPDIR/config/database.php」のRedisに関する内容を確認します。

    'redis'=> [
        'client' => 'predis',

        'default' => [
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'password' => env('REDIS_PASSWORD', null),
            'port' => env('REDIS_PORT', 6379),
            'database' => 0,
        ],

    ],

標準では「client」に「predis」が設定され、「host」などはenvファイルで設定することができるようになっています。

まずpredisのインストールです。composerを利用してpredisをインストールします。以下のコマンドでrequireでインストールできます。

composer require predis/predis

または「composer.json」のrequireにpredis/predisを追加してアップデートします。

composer update

predisのインストールができたら、envファイルの設定です。SESSION_DRIVERには「redis」を設定し、REDIS_HOSTには先のプライマリエンドポイントを指定します。

SESSION_DRIVER=redis

REDIS_HOST="プライマリエンドポイント"
REDIS_PASSWORD=null
REDIS_PORT=6379

動作確認

Laravelのサイトにアクセスして問題ないか確認します。ノードの状況で接続のカウントなどに反映されていれば、とりあえずの動作は問題ない状態です。

まとめ

今回はLaravelのセッション管理について、Redisを指定しAWSのElastiCacheを利用する方法の説明でした。

以上

【関連するリンク】

www.prj-alpha.biz

AWS Certificate Manager (ACM)のアップデートのメールが来ていたので確認してみた

「Update on Certificate Transparency(CT) with AWS Certificate Manager(ACM)」という件名のメールがAWSから来ていたので確認してみた。

Google Chromeに対応したACMのアップデート

AWSのACMに関する今回のアップデートは、以前に内容を確認したCertificate Transparency（「証明書の透明性」、以下「CT」）に関連してGoogle Chromeに対応するためのものです。
www.prj-alpha.biz
AWSからのメールにも記載していありますが、簡単にGoogle Chromeに対応したACMのアップデート内容を要約すると以下のようになります。

• Google Chromeでは2018/04/30以降に発行されたSSL証明書では少なくとも2つのCTログに記録がない場合、Google Chrome上でエラーメッセージが表示される可能性があります。
• これに対応して、ACMで発行したSSL証明書の発行/更新時にCTログに記録するように更新しました。これは2018/04/24から対応しています。

Google Chromeの対応が2018/04/30以降ということで2018/05/01前後にアップデート情報がAWSよりメールで送られています。ACMを利用しているサイトはAWSが対応するので、特に何か作業を行う必要はありません。ただし、CTログにはサブドメインを含むドメイン名が記載されるので、CTログに記載され公開されることで何かしら問題がある場合のみ対応が必要です。

Google ChromeでACMでSSL証明書を発行したサイトを見てみる

ACMで発行したSSL証明書を使用しているサイトをGoogle Chromeでアクセスしてみてエラーメッセージが出るか確認してみます。今回は以下の我々が運営しているウェブサイトで確認してみました。
home.prj-alpha.biz
Google Chromeで表示すると以下のようになりました。


ブラウザのアドレスの部分には「保護された通信」と表示されているので、エラーメッセージが出ることなくAWSの対応が適用され問題なくできているようです。念のためサブディレクトリについても確認しましたが同様に特に問題ありませんでした。
CTログの状況はその提唱者でもあるグーグルが以下で提供しています。
Google Transparency Report
ドメイン名を入力してCTログ数を確認して下さい。
※実際に問題があるサイトの場合、エラーメッセージがGoogle Chrome上でどのような形式で表示されるかは確認できていません。

まとめ

今回はACMのCT対応に関するアップデートついて、Google Chromeで問題ないか確認しました。ACMを使用してSSL証明書の発行している方は、念の為問題がないか確認して下さい。またACMを使用していないサイトでもGoogle Chromeで確認しSSL証明書が問題ないかを確認した方が良いと思われます。
ACM以外のSSL証明書を使用している方は認証局に一応対応状況を確認した方が良いと思います。

以上

ドメインの変更時に、AWSのS3を利用して旧ドメインから301リダイレクトさせる方法

今回は独自ドメインで運用していたウェブサイトのドメイン名を変更した場合の対応を紹介します。
今回はサブドメイン名を変更した状態を想定し、変更前のドメイン名を「旧ドメイン名」としその値を「old.domain.com」、変更後のドメイン名を「新ドメイン名」としその値を「new.domain.com」と記載していきます。

ドメイン名を変更するとどんな影響があるか

これまで運用していたウェブサイトについてドメイン名を変更した場合の対応について考えます。運用サイトのドメイン名の変更作業自体は済んでいるものとします。

まずドメイン名を変更することで一番大きな影響は、旧ドメイン名でリンクした内容が問題になります。ユーザが旧ドメイン名でお気に入りに追加していたり、コンテンツの中に旧ドメイン名で設定されたリンクについて対応が必要になります。対応しないと旧ドメイン名に接続しに行きページが存在しませんという状態になってしまいます。
そしてグーグルの検索結果にも旧ドメイン名で表示されます。
今回はこの部分の対応について考えていきます。

法人などで変更対象のウェブサイトが名刺や会社案内などの印刷物に記載されている場合、刷り直しなどが必要になってくるものもあるでしょう。

対応方針

ドメイン名を変更した場合、旧ドメイン名から新ドメイン名に301リダイレクトさせるのが一般的な対応となります。301リダイレクトについては以下参照して下さい。 

www.prj-alpha.biz

旧ドメインにアクセスしてきたリクエストを新ドメインに301リダイレクトするには、Apacheなどのウェブサーバの設定の変更で対応することができますが、サーバの設定を変更できない場合があります。例えばこのはてなブログなどです。
このようなときに簡単な設定で301リダイレクトする方法を検討してみたいと思います。ドメインを取得する際に利用したドメイン登録サービスでリダイレクトするサービスを提供しているものがあります。ただしそのリダイレクトが301リダイレクトか確認する必要があります。例えばお名前ドットコムではURL転送Plusというサービスがありますが、これは302リダイレクトになっているようです。
AWSの Amazon S3（以下、S3）でリダイレクトができるようなので、今回はそれを利用することにします。

AWSのS3による301リダイレクト

S3はAWSのクラウドストレージサービスですが、静的ウェブホスティングの機能によりストレージにアップロードしたファイルをウェブサーバのように静的コンテンツとしてHTTP でやり取りすることができます。更にこの機能の中にはリダイレクトする機能があります。

S3のリダイレクト機能にはいくつかの方法がありますが、今回は一番簡単なバケットによるリダイレクト設定を行います。バケットの設定のみで、バケットにはファイルは不要です。
旧ドメイン名でS3の静的ウェブホスティングを行い、そこにきたリクエストを新ドメイン名にリダイレクトするように設定します。

S3を設定する

まずはバケットを作成します。名称は旧ドメイン名で作成します。これは独自ドメインでの静的ウェブホスティングするための制約です。

今回は「old.domain.com」となります。その他の設定はいったんなしで作成します。作成が完了した時点で、エンドポイントが確認できます。プロパティのタブを選択して、「Static website hosting」をクリックするとエンドポイントが表示されます。

Route53以外のドメイン登録サービスを利用している場合、独自ドメインのDNSにCNAMEレコードを作成して、このエンドポイントを登録することで独自ドメインでS3バケットが利用できます。

続いて、アクセス権限を設定します。アクセス権限のタブのベケットポリシーをクリックして以下のポリシーを設定して、パブリックユーザにGetObjectの権限を付与してアクセスできるようにします。Resourceの部分は旧ドメイン名となります。

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddPerm",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::old.domain.com/*"]
    }
  ]
}

この状態で保存するとパブリックアクセス権が付与されたことが明示されます。

最後にリダイレクトの設定を行います。プロパティのタブを選択して、「Static website hosting」をクリックして「リクエストをリダイレクトする」を選択し、リダイレクト先に新ドメイン名を入力します。http/httpsを指定したい場合はプロトコルに設定します。

これで旧ドメインへのリクエストはバケットの設定により、全て新ドメインのホストにリダイレクトされることになります。このリダイレクトの設定はサブディレクトリも含まれます。

その他のリダイレクト設定は公式ページを参照して下さい。

docs.aws.amazon.com

301リダイレクトの設定ができているか確認する

設定ができた後に問題ないか確認しましょう。一番簡単なのはブラウザで旧ドメイン名をURLに入力して新ドメイン名に変更されるか確認する方法です。

この他に以下のサイトでは301リダイレクトされているかステータスコードが確認することができます。

HTTP Header Response Status Codes Check Tool

URLに旧ドメイン名を入力して、Checkボタンを押してしばらく待った後に以下のように301と結果が出ていれば問題ありません。

新ドメイン名 - 301 Moved Permanently
旧ドメイン名 - 200 OK

サブディレクトリが問題ないかもこちらで確認することができます。

ドメイン名に変更に関連して、その他にやること

ドメイン名に変更に関連してURLを保持しているシステムなどの設定も変更が必要になります。SEO関連のツールではグーグルの Google Analytics 、 Search Console はきっちり変更しましょう。特に Search Console はグーグルの検索結果のインデックスに影響しますので必ず対応しましょう。

www.prj-alpha.biz

まとめ

今回はAWSのS3を利用しての301リダイレクトの紹介でした。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz