質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
Redis

Redisは、オープンソースのkey-valueデータストアで、NoSQLに分類されます。すべてのデータをメモリ上に保存するため、処理が極めて高速です。

ロードバランサー

ロードバランサー【負荷分散装置】は、複数のサーバへアクセス要求を分散する装置です。 要求を分散することで各サーバが快適な応答速度を保つことを目的としており、 アクセスの多い大規模サイト等は、この装置により 複数のサーバに負荷を分散する事で安定な運用が可能です。

Elastic Load Balancing

Elastic Load Balancingは、Amazon社が提供する、 EC2インスタンス間で自動的にトラフィックの負荷分散を行うサービスです。

Amazon EC2

Amazon EC2は“Amazon Elastic Compute Cloud”の略称です。Amazon Web Services(AWS)の一部であり、仮想化されたWebサーバーのコンピュータリソースをレンタルできるサービスです。

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

Q&A

解決済

3回答

9756閲覧

【AWS】複数サーバーをまたがったセッション共有について【Spring】

ami613

総合スコア20

Redis

Redisは、オープンソースのkey-valueデータストアで、NoSQLに分類されます。すべてのデータをメモリ上に保存するため、処理が極めて高速です。

ロードバランサー

ロードバランサー【負荷分散装置】は、複数のサーバへアクセス要求を分散する装置です。 要求を分散することで各サーバが快適な応答速度を保つことを目的としており、 アクセスの多い大規模サイト等は、この装置により 複数のサーバに負荷を分散する事で安定な運用が可能です。

Elastic Load Balancing

Elastic Load Balancingは、Amazon社が提供する、 EC2インスタンス間で自動的にトラフィックの負荷分散を行うサービスです。

Amazon EC2

Amazon EC2は“Amazon Elastic Compute Cloud”の略称です。Amazon Web Services(AWS)の一部であり、仮想化されたWebサーバーのコンピュータリソースをレンタルできるサービスです。

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

0グッド

0クリップ

投稿2020/05/11 07:50

編集2020/05/11 07:53

前提・実現したいこと

AWSを利用したアプリケーション開発を学習中の者です。
現在、学習の一環としてSpring(Java11)でECサイトを作っております。

ALB(Application Load Balancer)を利用し、
EC2を2台ぶら下げる構成をしたいと思っております。

こういった複数サーバーの構成で、
例えばユーザーの商品カート情報などをセッションで管理する場合、
ユーザーが複数のサーバーを行ったり来たりしないように設定が必要だと思います。

設定方針として、下記2つのアクションプランを考えたのですが、どちらがベターと考えられますでしょうか?

案① ロードバランサ―側でパーシステンス方式を設定
下記のような設定を、ALBのオプションで設定できないかと考えております。
https://milestone-of-se.nesuke.com/sv-advanced/appliance-server/load-balancer/

案② セッションストアをelasticacheに外出しする
下記のように、Session情報をRedis等に保存しておいて、各サーバーで参照させる方法もできるのかなと思っております。
https://amg-solution.jp/blog/15219

とりあえず2つほど案を絞り出しましたが、
インフラ・クラウドに関しては特に知識がないという自覚があり、
他にも「こういった方法があるよ」といったものがあれば、ぜひ教えていただけると幸いです。
何卒よろしくお願い致します。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

案1はスティッキーセッションの設定で実現できます。
が、これは同じサーバを見続けるだけなので「セッション共有」ではないですね。
この方法の難点は、アクセスが片方のサーバに偏る可能性があることです。

案2は複数台でセッションを共有する際にはよく取られる典型的な手段なので、ElastiCacheのインスタンスを立てることで問題ないのなら無難です。
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと

AWSなら他にDynamoDBを使う方法もあります。
Amazon DynamoDBによるTomcatセッション永続化とフェイルオーバー
かなり前の記事なので参考になるかわかりませんが…。

これも結構前の記事ですが、AWSでセッション管理をする際のパターンについてまとまっています。
AWSでマルチAZなセッション管理DBを構築する5つのプラクティス

※追記
ちなみに、ElastiCache for RedisではMulti−AZ構成を容易に取ることができます。
マネージドサービスの利点ですね。
もちろん、費用はかかりますが。

投稿2020/05/11 08:09

編集2020/05/11 08:23
yu_1985

総合スコア7411

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ami613

2020/05/13 00:10

ご回答ありがとうございます! > 案2は複数台でセッションを共有する際にはよく取られる典型的な手段 そうなのですね、現場経験に乏しく、そういったご意見助かります...! > スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと この記事も拝見しました。 セッション管理を外出しすると、やはり障害に強そうですね...! 大変勉強になりました、ありがとうございました!
guest

0

ベストアンサー

設定方針として、下記2つのアクションプランを考えたのですが、どちらがベターと考えられますでしょうか?

どんな選択肢でも多くの場合要件次第で何がベターなのかは変わるので、要件を知らない他人がベターな方法を選ぶことは極めて困難です。(要件を1から聞き出して~ となるとコンサルティング的な業務依頼になるので、有償で専門家に依頼すべき事項になります)

それぞれメリットデメリットを考え得る限り挙げてみて、要件と突き合わせて決めてみてください。

勉強目的の開発だと、そもそも要件が存在しないこともあるでしょうから、その場合は仮想要件を定義するか、とりあえず実装出来る方法で実装してみてデメリットに当たったら悩む と言うのでも良いと思います。

例えば要件に
複数人のユーザーがログインしている最中に片方のインスタンスが落ちた場合でもセッションを切らしたくない
と言うものがあった場合、案2しか選択肢は無くなります。
インスタンスが落ちると書くとめったにない事の様に見えますが、これをメンテナンスする等に置き換えても同じです。
セッションを切らしたくないだけだと分かりにくいですが購入中の人のセッションが切れると売り上げや顧客満足度が下がるので出来る限りセッションを切ってはいけないという様に具体化していくと、どの辺りまで求めればいいのかというところの設定がしやすいと思います。
(学習段階であれば、まずはそれっぽいものをそれっぽく動くようにとにかく作る というのもありだと思います。その場合はどっちでもいいです)


ざっと考えられるメリットデメリットとしては以下の様なものがあります。
(これらは一通り調べれば出てくるようなことでもあるので、詳細は調べてみてください。)

案① ロードバランサ―側でパーシステンス方式を設定
下記のような設定を、ALBのオプションで設定できないかと考えております。
https://milestone-of-se.nesuke.com/sv-advanced/appliance-server/load-balancer/

メリット: アプリケーション側は何も考えなくていいので工数が少なく済む。楽ちん等
デメリット: 原理的に、均等に負荷をバランシングが出来ない(負荷が高いユーザーがいる場合、負荷が偏る)、インスタンスが落ちるとセッションが切れるのでAutoScalingしにくい等

案② セッションストアをelasticacheに外出しする
下記のように、Session情報をRedis等に保存しておいて、各サーバーで参照させる方法もできるのかなと思っております。
https://amg-solution.jp/blog/15219

メリット: AutoScalingしやすい。負荷が均等にバランシングされる 等
デメリット: アプリケーション側で対応しないといけない。外部ストレージ用のコストがかかる 等

投稿2020/05/11 08:07

編集2020/05/11 08:33
tanat

総合スコア18706

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ami613

2020/05/13 00:06

ご回答ありがとうございます! > 仮想要件を定義する > 購入中の人のセッションが切れると売り上げや顧客満足度が下がるので出来る限りセッションを切ってはいけないという様に具体化していくと、どの辺りまで求めればいいのかというところの設定がしやすい この辺りの観点が大変勉強になりました。 勉強目的の開発といえど、この観点でも考えてみようと思います。 ありがとうございました!
guest

0

下記2つのアクションプランを考えたのですが、どちらがベターと考えられますでしょうか?

案①をおすすめします。

案②を採用すると、セッション情報を保存するサービスを冗長化、あるいはミラーリングする必要があり、難易度が上がります。

案①のデメリットは片方で障害が発生した場合にセッションが失われる(ECサイトではその瞬間にカートに入れていたものが失われる)ということです。
しかし、案②にかかるコストと障害発生の確率を天秤にかけて案①をおすすめします。

他にも「こういった方法があるよ」といったものがあれば、ぜひ教えていただけると幸いです。

ローカルストレージや Cookie などを使用してアプリケーションを完全ステートレスに作るという案も考えられます。
つまり、認証情報はJWTにして Cookie に保存し、カートの内容は HTML5 LocalStorage に保存するというような案です。

投稿2020/05/11 08:05

mit0223

総合スコア3401

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ami613

2020/05/13 00:03

ご回答いただきありがとうございます! >案①のデメリットは片方で障害が発生した場合にセッションが失われる(ECサイトではその瞬間にカートに入れていたものが失われる)ということです。 しかし、案②にかかるコストと障害発生の確率を天秤にかけて案①をおすすめします。 なるほど、そういうことですね。 今回の場合、セッション層を使うのはカート機能くらいなので、ご提案いただいた通り案①が現実的に思っております。 ありがとうございました!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問