今回は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を利用する方法の説明でした。
以上
【関連するリンク】