Q&A
ご回答ありがとうございます！
＞ 仮想要件を定義する
＞ 購入中の人のセッションが切れると売り上げや顧客満足度が下がるので出来る限りセッションを切ってはいけないという様に具体化していくと、どの辺りまで求めればいいのかというところの設定がしやすい
この辺りの観点が大変勉強になりました。
勉強目的の開発といえど、この観点でも考えてみようと思います。
ありがとうございました！
前提・実現したいこと
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つほど案を絞り出しましたが、
インフラ・クラウドに関しては特に知識がないという自覚があり、
他にも「こういった方法があるよ」といったものがあれば、ぜひ教えていただけると幸いです。
何卒よろしくお願い致します。
回答3件
0
案１はスティッキーセッションの設定で実現できます。
が、これは同じサーバを見続けるだけなので「セッション共有」ではないですね。
この方法の難点は、アクセスが片方のサーバに偏る可能性があることです。
案２は複数台でセッションを共有する際にはよく取られる典型的な手段なので、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
総合スコア7588
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
総合スコア18727
0
下記2つのアクションプランを考えたのですが、どちらがベターと考えられますでしょうか？
案①をおすすめします。
案②を採用すると、セッション情報を保存するサービスを冗長化、あるいはミラーリングする必要があり、難易度が上がります。
案①のデメリットは片方で障害が発生した場合にセッションが失われる（ECサイトではその瞬間にカートに入れていたものが失われる）ということです。
しかし、案②にかかるコストと障害発生の確率を天秤にかけて案①をおすすめします。
他にも「こういった方法があるよ」といったものがあれば、ぜひ教えていただけると幸いです。
ローカルストレージや Cookie などを使用してアプリケーションを完全ステートレスに作るという案も考えられます。
つまり、認証情報はJWTにして Cookie に保存し、カートの内容は HTML5 LocalStorage に保存するというような案です。
投稿2020/05/11 08:05
総合スコア3401
ご回答いただきありがとうございます！
＞案①のデメリットは片方で障害が発生した場合にセッションが失われる（ECサイトではその瞬間にカートに入れていたものが失われる）ということです。
しかし、案②にかかるコストと障害発生の確率を天秤にかけて案①をおすすめします。
なるほど、そういうことですね。
今回の場合、セッション層を使うのはカート機能くらいなので、ご提案いただいた通り案①が現実的に思っております。
ありがとうございました！
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/05/13 00:10