ホーム>Laravel>LaravelプロジェクトにElastiCacheのRedisのクラスタモードでパスワード認証をする方法
Laravel

LaravelプロジェクトにElastiCacheのRedisのクラスタモードでパスワード認証をする方法

いつもご利用ありがとうございます。
この記事には広告が掲載されており、その広告費によって運営しています。

目次

  1. 検証した環境
  2. 今回実装する仕様
  3. まず、AWS のコンソールで ElastiCache の Redis キャッシュを新規作成する
  4. Laravel の設定
  5. EC2 での作業
  6. セッションも Redis で管理したい場合
  7. 補足情報
  8. まとめ

LaravelプロジェクトにElastiCacheのRedisのクラスターモードでパスワード認証をする方法についてまとめました。

PR

検証した環境

今回検証した環境については以下の環境ですが、Laravel8 以降のドキュメントを参照して実装しているので、predis のバージョンさえ一致していれば同じやり方で実装が可能だと思います。

predis 2.2
クラスターモード

参考ドキュメント

今回実装する仕様

  1. PHP Laravel(EC2)
  2. ElastiCache Redis(AWS)
  3. クラスターモード
  4. パスワード認証
  5. 転送中の暗号化(TLS)
  6. その他（価格をできるだけ抑えた設定）

まず、AWS のコンソールで ElastiCache の Redis キャッシュを新規作成する

この記事では、実験的に環境を構築するためお金がかからないであろう設定をしています。

AWS に使い慣れていない人は参考にしてみてください。

キャッシュを作成で Redis を選択する

設定

  • デプロイオプション「独自のキャッシュを設計」

  • 作成方法「クラスターキャッシュ」

クラスターモード

  • 有効

クラスター情報

  • 名前と説明を入力（日本語入力不可だと思います）

ロケーション

  • ロケーション「AWS クラウド」

  • マルチ AZ 「無効（有効のチェックを外す）」

クラスター設定

  • エンジンバージョン「7.1」

  • ポート「6397」

  • パラメーターグループ「default.redis7.cluster.on」

  • ノードのタイプ「cache.t3.micro」

※記事作成中で無料枠のノードタイプを選んでいます（無料枠についてはこちら）

  • シャード数「1」

  • レプリカ数「0」

接続性

  • ネットワークタイプ「IPv4」

  • サブネットワーク「新しいサブネットグループの作成」 → 適当な名前で、EC2 と同じ VPC に作成する。

アベイラビリティーゾーンの配置

  • スロットおよびキースペース「均等分散」
  • アベイラビリティーゾーンの配置「指定がありません」

セキュリティ

この項目で、パスワードを設定します。パスワードを設定するためには転送を暗号化する必要があるようです。

  • 保管中の暗号化「有効化」
  • 転送中の暗号化「有効化」
  • アクセスコントロール「Redis 認証デフォルトユーザーアクセス」
  • Redis 認証トークン → 使いたいパスワードを入力してください。この記事では、「password」と入力

セキュリティグループ

セキュリティグループに関しては、

  1. インバウンドに、使用する EC2 のセキュリティグループ、使用ポート（6379)

ElastiCacheのエンドポイント

  1. アウトバウンド、「なし」

自動バックアップ

  • 自動バックアップを有効化しない

自動バックアップをテストしたい場合は有効化してください。

メンテナンス

  • メンテナンス期間 「指定がありません」

  • マイナーバージョンの自動アップグレード「有効化」

  • Amazon SNS 通知のトピック「通知を無効化」

ログ

  • スローログ「無効」

  • エンジンログ「無効」

タグ

なし

以上で、「作成」します。

Laravel の設定

パッケージをインストールする

今回は、predis というパッケージを使います。

参考

コマンドで、パッケージを入れます。

composer require predis/predis

config/database.php

redis の項目を変更します。

client のところを、predis しか使わないので書き換えました。

'redis' => [

    'client' => env('REDIS_CLIENT', 'predis'),

    'options' => [
        'cluster' => env('REDIS_CLUSTER', 'redis'),
    ]

    'clusters' => [
        'default' => [
            [
                'host' => env('REDIS_HOST', 'localhost'),
                'password' => env('REDIS_PASSWORD', null),
                'port' => env('REDIS_PORT', 6379),
                'database' => 0,
                'read_write_timeout' => 0,
                'scheme' => 'tls', //暗号化対応。これがないとパスワード認証できません
            ],
        ],
    ],
],

EC2 での作業

ElastiCache は、ローカルサーバーでの接続検証はできない

ElastiCache は、ローカルサーバーでの接続検証はできず以下のようなエラーが出るようになっています。

No connections available in the pool

Laravel の Redis で「No connections available in the pool」とエラーが出た時の解決方法

※ 本来は、ローカルサーバに redis を構築して、ローカルサーバーで Laravel 側の設定を確認した後に本番環境にて.env を書き換えて実装するのが理想だと思いますが、ローカルに redis を構築するのは記事がややこしくなるので割愛してます。

.env を書き換える

EC2 内の、Laravel プロジェクト内の.env ファイル（環境は人によって違うと思うので、ファイルパスなどは割愛します）を編集してください。

コマンドでファイルを編集します。

sudo vim .env
CACHE_DRIVER=redis

REDIS_HOST=?????????????.cache.amazonaws.com
REDIS_PASSWORD=password
REDIS_PORT=6379

コマンドで反映させます。

php artisan config:cache

CACHE_DRIVER を file から redis へ

この項目を変更することで、さきほど設定した redis を使うようになります。

REDIS_HOST には:6379 をつけない。

AWS のコンソールでエンドポイントをコピーしようとすると、

エンドポイント:6379

とポートがついてきてしまうので、その:6379 は不要で、エラーの原因になるのでその部分は削除してください。

詳しくそのエラーについて書いた記事

REDIS_PASSWORD

ElastiCache の設定をした際のセキュリティの項目で作ったパスワードを入力してください。

以上で実装は完了です。お疲れ様でした。

セッションも Redis で管理したい場合

今回の設定でやれば、.env を同様に書き換えて反映させれば実装できます。

SESSION_DRIVER=redis
php artisan config:cache

今回のように default の項目で設定していればこれだけで完了します。

connection 先を default ではなく cache など別の名前で実装している場合、これだけではうまくいかないと思います。

今回の記事のように default の項目で実装したら問題ないと思います。

補足情報

今回 ElastiCache を触っていて自分が知った情報についてまとめます。

ノードの数で金額が決まる

例えば、「cache.t3.micro」であれば、１台につき「約 2700 円」ほど掛かりますが、ノードの数だけ掛け算となります。

月額 = 2700 * ノード数

クラスタモードの場合、ノードの数は

ノード数 = (1 + レプリカ数) * シャード数

となります。

レプリカとは、レプリカノードを指しこれも一つのサーバーですので安易にレプリカを１にすると２倍お金かかります。

常識なのかもしれませんが、知らないとアカンことになりますね。

Redis のノードとシャード

ネットワーク帯域幅

大きいキーを使用したい場合、micro や small など弱いノードだと

No connections available in the pool

というエラーが発生する可能性があります。

このエラーは、大きかったら発生するし、小さかったら正常に作用するためなかなか発見しづらい不具合となりますが、ネットワーク帯域幅についても把握した上で運用した方が良さそうで、

実際のワークロードでノードをテストすることをオススメされています。

ネットワークスループット: 帯域幅の決定: ElastiCache ノードのネットワーク帯域幅は、ノードサイズに比例します。アプリケーションの特性が異なるため、結果はワークロードに応じて異なる場合があります。たとえば、小さなリクエストの割合が高いアプリケーションは、ネットワークのスループットよりも CPU 使用率に影響を及ぼす傾向がありますが、キーが大きいほどネットワーク使用率が高くなります。そのため、制限をよりよく理解するために、実際のワークロードでノードをテストすることをお勧めします。

引用：AWS のユーザーズガイド

まとめ

以上です。誰かの参考になればと思います。

このブログは広告のクリックによって支えられています。

参考になったという方はぜひ、ぜひともよろしくお願いします！

フィードバックのお願い
この記事のフィードバックがありましたらYoutubeの適当な動画にコメントしていただいたり、お問い合わせからご連絡ください。