商売力開発ブログ

非エンジニアがWebサービスの開発、運営によって商売力をつける記録、その他の雑記

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

【スポンサーリンク】