初めてのガントチャートに適したサービスの提供

※Project-Alphaは2019年12月をもって、サービスの提供を終了します。

今回は我々が開発しているプロジェクト管理ツールProject-Alpha（プロジェクトアルファ）のガントチャートを中心にして紹介します。
※こちらの機能は2018/05時点のものとなります。最新の機能では変更されている可能性があります。

プロジェクト管理とガントチャート

プロジェクト管理・マネジメントを行う場合のツールの一つとしてガントチャートを利用していることが良くあります。ガントチャートは視覚的にある程度の進捗状況がわかることから、複数人で確認が必要な場合に利用される場面が多いと思います。世の中には色々なガントチャート作成ツールが存在しています。

www.prj-alpha.biz

ツールはいくつもありますが、見かけるケースが多いのはExcelで作成したのものです。特にビジネス領域ではExcelは誰でも利用できることが多いことから、取引先やお客様など外部組織のメンバーと共有する場合、Excelで作成したものや専用ツールから出力したExcelが使用されることが多いです。

Excelで作成している人や初めての人でもガントチャートでも簡単に

Excelのガントチャートを利用していることが多いことを踏まえ、我々が提供するサービスでは、現在はExcelでガントチャートを作成している人や初めてガントチャートを作成する人が簡単に使えるようなガントチャートの機能を提供しています。

Excelとの親和性

ガントチャートの入力はExcelと同じように一覧表にそのまま入力する形式になっています。日付についてはカレンダーから選択して設定することも可能です。

また、マウス操作で日付を設定することもできるようになっています。

ここまでは入力画面から一つ一つ入力していく方法ですが、Excelのデータがあればそれを利用することも可能です。Excelで作成したWBSなどをExcel上でコピーした範囲をガントチャート上でペーストすることができます。
以下では、ID列を含めたExcelからのコピペの例です。ID列の設定内容から自動で階層を判定してガントチャートが作成されます。

また登録したガントチャートはExcelとして出力することもできます。以下は出力したファイルの例です。

取引先やお客様など外部組織のメンバーと共有したい場合、Project-Alpha上で情報共有することもできますし、それができない場合はExcelに出力したファイルを利用することで共有することができます。Excelファイルを修正した場合はコピペで修正内容をProject-Alphaのガントチャートに反映させることができるので簡単です。

テンプレート利用でガントチャートをすぐに準備

Project-Alphaを利用で、特に力を発揮するのは同じようなプロジェクトをいくつも担当している場合です。このようなプロジェクトがある場合はテンプレート機能を利用して、ガントチャートを作成する際の元データを用意しておくことで準備することができます。

テンプレートを用意していおくことで、ガントチャートの編集画面から読み込むことができるようになります。以下は上記のテンプレートのデータを読み込んだときのイメージになります。

読み込んだデータは、テンプレートの設定になるので予定などの日付を変更する必要があります。このとき日付一括変更の機能を利用することで、日付の情報を簡単に修正することができます。

これによりガントチャートの準備が簡単にできます。ここからそのプロジェクトに応じて必要な調整を加えるだけで良いので、ガントチャートの作成に余計な時間をかけずに済むことができます。

利用に向いていないプロジェクト

ここまで紹介したように、Project-Alphaのガントチャート機能は直接入力していくことで作成していくタイプのものとなります。このような直接入力するタイプの場合、行数が多くなり過ぎるような細かい管理には向きません。厳密な管理が必要になりそうなプロジェクトの場合は別のツールを併用する方が良いと思われます。

また現在は簡単にガントチャートを作成できるための機能の拡充をめざしているため必要な機能がないと感じる人もいると思います。例えばクリティカルパスの設定は現在できません。

現在、β版としてフリー（無料）でサービスを提供しています。以下のリンクから、右上の「アカウント作成」か途中にある「β版を始める」のボタンからアカウントを作成していただくことができますので、ぜひご利用下さい。
home.prj-alpha.biz

まとめ

今回は我々が開発しているプロジェクト管理ツールProject-Alphaの紹介でした。β版としてフリー（無料）でサービスを提供していますので、ぜひご利用下さい。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

www.prj-alpha.biz

www.prj-alpha.bizhome.prj-alpha.biz

開発・提供しているサービスのガントチャートの機能紹介~その２

※Project-Alphaは2019年12月をもって、サービスの提供を終了します。

今回は我々が開発しているプロジェクト管理ツールProject-Alpha（プロジェクトアルファ）のガントチャートについて一部の機能を紹介します。
Project-Alphaは無料、フリーで利用できるプロジェクト管理ツールでガントチャートなどを利用して、複数のプロジェクトを平行して管理でき、一括して状況を把握することができます。

※こちらの機能は2018/05時点のものとなります。最新の機能では変更されている可能性があります。

以下は機能プレビューのリンクになります。

home.prj-alpha.biz

ガントチャートの一括編集機能

日数や日付を指定しての一括変更

ガントチャートに設定されている日付について、一括して変更することが可能です。変更の方法は表示開始日付を指定して変更する方法と日数を指定して変更する方法があります。

日数を指定しての変更画面はこちらです。日数にはマイナスを指定して、過去に移動することもできます。

表示開始日付を指定しての変更画面はこちらです。

ガントチャートのテンプレート管理機能 

ガントチャートの設定をテンプレートとして管理する機能があります。テンプレートとして保存したガントチャートのスケジュール設定について、読み込むことで一気にスケジュール設定を準備することができます。
テンプレートは複数利用でき、各テンプレートごとに公開設定がありますので、公開しているもののみ使用できガントチャートから選択可能となります。

テンプレートのガントチャートの入力方法は通常のガントチャートと同じです。

ガントチャートのメニューからテンプレートのデータを読込むことで、簡単にスケジュールの準備ができます。またデータを読込後に日数や日付を指定しての一括変更を行えば簡単に準備ができることになります。

マイルストーン設定とサマリ表

マイルストーンとして設定することで、いくつかの表示が変更されます。マイルストーンの設定方法は行選択した状態で右クリックして「マイルストーン設定」を押すことで設定されることになります。

カレンダー上での日付の列が着色されます。

このマイルストーンの設定はサマリ表でも影響します。

サマリ表機能

ガントチャートは一覧表形式なので行数が多くなり画面のスクロールが必要な程となると、どうしても見づらくなります。これらをまとめて表示するサマリ図の機能がありあます。表示する階層ごとにまとめて表示することや、階層や担当ごとに別けて表示することが可能です。
またマイルストーンについては縦の棒線として表現されます。

まとめ

今回はProject-Alphaのガントチャートについて一部の機能を紹介しました。
ご興味のある方はぜひ一度ご利用してみ下さい。β版としてフリー（無料）でサービスを提供していますので、ぜひご利用下さい。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

www.prj-alpha.biz

home.prj-alpha.biz

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