AWSでマルチAZなセッション管理DBを構築する5つのプラクティス | DevelopersIO
はじめに セッション管理が必要なWebアプリケーションサーバをロードバランシングやクラスタリングなどで負荷分散構成とした場合、セッション情報をデータベースに保持し共有化する方法が一般的です。しかしAWSのインフラストラクチャ障害などでAZが丸ごとダウンするようなケースを考慮した場合、Webアプリケーションサーバと共に、セッション管理DBも複数のAZに分散配置するのが望ましいでしょう。 ではAWSでセッション管理DBを複数のAZに分散配置する場合、どのような手段が考えられるのでしょうか。というのが今回のスタート地点です。 1.AZ分散配置しない いきなり前提を覆すような話をしますが、そもそもAZ分散配置が必要なケースは、AZが丸ごとダウンしセッション管理DBが使えなくなることがサービス停止に直結する場合です。 つまりアプリケーションが「セッション管理DBに接続出来ない場合はローカルのDBやフ
Amazon DynamoDBによるTomcatセッション永続化とフェイルオーバー | DevelopersIO
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました！ スティッキーセッション ロードバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
