AWSでマルチAZなセッション管理DBを構築する5つのプラクティス

佐々木大輔

2014.03.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

セッション管理が必要なWebアプリケーションサーバをロードバランシングやクラスタリングなどで負荷分散構成とした場合、セッション情報をデータベースに保持し共有化する方法が一般的です。しかしAWSのインフラストラクチャ障害などでAZが丸ごとダウンするようなケースを考慮した場合、Webアプリケーションサーバと共に、セッション管理DBも複数のAZに分散配置するのが望ましいでしょう。

ではAWSでセッション管理DBを複数のAZに分散配置する場合、どのような手段が考えられるのでしょうか。というのが今回のスタート地点です。

1.AZ分散配置しない

いきなり前提を覆すような話をしますが、そもそもAZ分散配置が必要なケースは、AZが丸ごとダウンしセッション管理DBが使えなくなることがサービス停止に直結する場合です。つまりアプリケーションが「セッション管理DBに接続出来ない場合はローカルのDBやファイルを使ってセッション管理する」ようなフェイルオーバー的仕様になっていれば、AZ分散配置をしなくて済みます。

とはいえ最初からそういった仕組みが用意されているアプリケーションは多くはないでしょうし、アプリケーションの改修が容易では無い場合も多いと思います。そこで以下のように構成で何とかする案を考えてみました。

2.ElastiCache(memcached)を使う

AWSが提供するメモリ内キャッシュシステムであるElastiCacheは二種類のエンジンをサポートしており、その一つがmemcachedです。memcachedはセッショッン管理データベースの用途としてはとてもメジャーであり、様々なWebアプリケーションフレームワークでモジュールが用意されています。しかしmemcachedにはレプリケーションなどの機構が無いため、アプリケーション側で考慮する必要があります。即ちAZ分散された複数のElastiCache(memcached)に、セッション情報をそれぞれ書き込む形で、情報を分散して配置します。こちらもアプリケーションの改修が必要な場合があり得るでしょう。

3.ElastiCache(Redis)を使う

ElastiCacheが対応するもう一つのエンジンがRedisです。Redisはレプリケーション機能を有しており、書き込みを受けるマスターノードと読み込み専用のリードレプリカノードに分かれます。このリードレプリカを複数のAZに分散配置することでAZ障害に対応することが出来ます。またリードレプリカはマスターノードに昇格することが出来ますので、マスターノードが配置されたAZがダウンした場合、生存しているリードレプリカをマスターノードに昇格することで、サービス継続が可能です。

4.RDS for MySQLとmemcached pluginを使う

少々トリッキーではありますが、MySQL5.6ではmemcached pluginが使えます。もちろんRDSでも使えます。そしてRDSはMultiAZ構成が出来るので、これでAZ分散はばっちり対応出来ます。

もちろんmemcachedと比較すると速度性能は劣化しますので、シビアな条件であればアプリケーション側でのチューニングが必要になります。

5.DynamoDBを使う

AWSが提供するフルマネージドNoSQLデータベースであるDynamoDBは、複数のAZに複数のAZに分散してデータを保持する仕組みであるため、強く意識をする事無く複数AZに分散配置されます。

DynamoDBを使ったセッション管理については弊社横田の力作Blogエントリ「Amazon DynamoDBによるTomcatセッション永続化とフェイルオーバー｜ Developers.IO」がありますのでそちらをご参照下さい。

まとめ

ミッションクリティカルなシステムの場合、このようにAWSリソースレベルのみならずAZレベル、リージョンレベルでの可用性まで考慮する必要があるでしょう。しかしその手法の選択肢が多いこと、またそれぞれの手法をお手軽に試せることが、AWSのようなIaaS型クラウドサービスの大きな利点です。皆さんのシステムに最適なプラクティスを是非様々な手法で検討して下さい。そして良い手があれば是非教えて下さい！