AWSのElastiCacheを自製品サービスで利用する際に、検討する内容について記載します。
使用用途など
Laravelを利用したプロジェクト管理ツールを開発しています。Laravelではそのセッション管理にRedisを使用可能です。このRedisをAWSのElastiCacheで対応します。
Laravelで利用する場合の対応手順などは以下を参照して下さい。
Laravelのセッション機能では、色々な情報をセッションに保有することも可能になっていますが、現時点ではそのような利用の仕方はあまりしていません。主にサインインしているか、してないかが主な利用用途となっています。セッション情報が失われた場合、再度サインインが必要になるという影響があります。
セッション数やのサイズなど
ElastiCacheのモニタを確認し、セッション1つ当りのサイズを1kとして仮定した。サービス開始時の接続セッション数は cache.t2.micro でもキャパシティは問題ないものとする。
サービスの運用開始後にセッション数やサイズの状況を確認し、必要に応じてスケールアップする。
構成を検討する際に関連する各種機能の概要
キャッシュノードタイプは cache.t2.micro でも問題ないものと仮定するが、t2では利用できない機能がある。また課金はノードの数となるため、レプリカノード数やシャード数により増えていくので注意する。
またプリイマリーノードのアベイラビリティーゾーン（以下、AZ）はEC2（EC2が1台の場合）と同じにする。
同じアベイラビリティーゾーン内での Amazon EC2 と Amazon ElastiCache 間のデータ転送は無料です。
レプリケーション
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について自製品サービスで利用する際の設定方針でした。
以上
【関連するリンク】
