load balancer로 2개의 ec2(A, B)를 돌리고 있는데요, 1개(A)를 stop하려고 하는데,…

load balancer로 2개의 ec2(A, B)를 돌리고 있는데요,

1개(A)를 stop하려고 하는데, 해당 서버(A)에 접속해있던 사람들에게는 어떻게 뜨게 되나요?

그리고 A에 stickiness가 있던 사람은 다음부터 B로 접속하게 되는 건가요?

22 thoughts on “load balancer로 2개의 ec2(A, B)를 돌리고 있는데요, 1개(A)를 stop하려고 하는데,…

  1. 네. 그러나 a 에 발급된 세션값은 더이상 b 에서 쓸모가 없겠죠. 결국 a 에 접속한 사용자들은 로그인이 풀리는 현상을 맞게 되겠죠

  2. A에 접속해있던 사람들이던 아니던 A가 elb에서 제거된 이후의 모든 요청은 (B만 남아있다는 가정 하에) B로 전달됩니다. 웹 서버가 stateless 하게 구현되어 있는 경우, 세션이 어디서 발급되었는지는 중요치 않고 클라이언트에서 본인의 정보를 모두 지니고 있기 때문에 로그인이 풀릴 일은 없을겁니다.

  3. 김현준 이해가 좀 안 되서 질문드립니다. 제가 tomcat 쪽만 좀 경험이 있긴하지만 다른 언어로 된 어플리케이션도 마찬가지일거로 생각되는데요. 제가 알고 있기론 ELB 에서 발행된 sticky session 용 쿠키값은 routing 역활만 하는 걸로 알고 있는데요. A 서버에 접속한 사용자를 state 하게 다룰려면 일반적인 상황에서 A 서버에서 발행한 세션쿠키값밖에 없을텐데 A 서버가 stop 된 상황에서 A 서버에 로그인했던 사용자가 B 에서도 어떻게 로그인을 유지할 수 있는지 궁금합니다. 다시 말해 세션 클러스터링이 되지 않은 상황이라면 B 서버에서는 A 서버에 로그인했던 사용자를 어떻게 알 수 있는지 궁금합니다.

  4. “세션이 어디서 발급되었는지는 중요치 않고 클라이언트에서 본인의 정보를 모두 지니고 있기 때문에 로그인이 풀릴 일은 없을겁니다” ->이 말이 정확히 이해가 되지 않습니다. 또한 클라이언트에서 본인의 정보를 어떻게 다 지니고 있다는 건지 잘 이해가 되지 않습니다.

  5. (세션 쿠키를 말씀하셨기에) 인증 정보를 쿠키에 담는다고 가정하면, 쿠키는 클라이언트에 저장되는 것이므로, 클라이언트에서 본인의 정보를 지니고 있는 것이 맞습니다. 웹 서버가 stateless하게 구현되어 있는 경우 매 요청은 이전의 다른 어떤 요청들과도 독립적이게 처리될 것이고 그 경우에 요청을 보낸 유저의 인증/로그인 정보를 판단할 때 사용할 수 있는 정보는 해당 요청에 포함되어 온 쿠키 값일 것입니다. 따라서 A에서 쿠키에 넣어놓은 값을 B에서 읽고 처리할 수 있다면 세션이 어디에서 발급되었는지는 중요치 않을 것이라는 이야기입니다.

  6. 김현준 님 질문자님께 뭔가 오해를 불러일으킬 수 있을 거 같아 정리를 좀 해야 될 거 같습니다. 제가 답변한 부분은 웹서버가 state 할 때 , 김현준님께서 답변하신거는 stateless 하게 웹서비스를 구현했을 때입니다. 즉 제가 답변한 부분 즉 일반적인 대부분의 웹서비스일 때는 A 가 stop 되었을 때 로그인이 풀립니다. 하지만 웹서버가 stateless 하게 구현되어 있다면 로그인이 안 풀리겠죠… 근데 로그인이 안 풀리다는 표현이 맞는 표현인가요? stateless 라면 사실 매 request 마다 로그인 인증을 처리하는 형태일 텐데요…

  7. 네. 맞습니다. 애초에 stateless 한 경우 “로그인이 되어있는 상태”/”로그인이 갑자기 풀리는 것”이 (기술적으로는) 말이 안될 것입니다. 말씀해주신대로 웹서버가 stateful/less하느냐에 따라 상황이 다를 것이므로 처음 댓글에서도 이미 “웹 서버가 stateless 하게 구현되어 있는 경우” 라고 앞에 붙여두었습니다. 그런데 Oh Jong Am님께서도 “사용자를 state 하게 다룰려면 일반적인 상황에서 A 서버에서 발행한 세션쿠키값밖에 없을텐데”라고 말씀하셨는데, 이 경우는 제가 이야기한 케이스와 같은 것으로 보이고, 웹서버를 stateless하게 구현하는 방법으로 보입니다.

  8. 변조할 수 없도록 signing을 하면, 서버측 저장소 없이도 쿠키에 세션 정보를 저장하는 것이 가능합니다. 이런 경우라면 어느 서버에 붙는지 크게 중요하지 않겠죠 (물론 모든 세션을 대체할 수 있는건 아니지만…)
    자바 쪽에선 잘 안쓰이는 방법인 것 같습니다.

  9. 김태호 님 같은 경우는 sticky session 을 쓰지 않는 경우라서 질문자님의 의견과는 별 관계가 없는 거 같습니다. 서버측 저장소가 없이 로긴세션정보를 쿠키에 저장한다면 로그인 완료 여부도 쿠키에 저장하신다는 말씀이신지요? 서버측 저장소 없이 어떻게 로그인 유효성을 판단하나요? 자바가 아닌 다른 언어에서는 어떻게 하는지 궁금합니다. 자바라서 잘 안 쓴다는 말은 더욱 이해가 되지 않네요. http spec 은 언어 독립적인데 말이죠.

  10. Signed cookie라고 찾아보시면 많이 나올거구요. 자바’라서’ 안쓴다는 말이 아니고, 자바 기반 웹 스택에서는 흔히 쓰는 기법은 아닌 것 같다는 뜻이었습니다. (sticky session과 관계 없는 이야기이긴 하네요 ㅠㅠ 죄송합니다.)

  11. 김태호 님 signed cookie 든 signed http header 든 어차피 user 정보를 얻을 수 있는 key 값을 cookie or header 에 저장해서 서버측에서 그 key 값으로 해당 user 정보를 저장소에서 찾는게 일반적일텐데요.그 저장소가 웹 어플리케이션 local cache 든 또는 db 든 아니면 cache server 든지요. 말씀하신것처럼 sigined 라도 변조를 막는 용도에 불과할텐데요. 세션은 그 사용자와의 1:1 연결정보를 담는 거로 알고 있습니다. signed 인지 unsigned 인지는 별 관계가 없어보여서여. 제가 궁금한 점은 쿠키에 어떤 세션정보들을 저장하기에 서버 저장소가 필요없냐는 점입니다.

  12. 참고로 저는 둘다 사용합니다. 웹일때는 signed cookie 에서 user id 를 뽑아오고 앱일때는 signed http header 에서 user id 를 뽑아옵니다. session expire 여부는 cache server expire time 으로 하고 있습니다.

  13. 쿠키에 모든 값을 저장하지 않고, 어디에 저장되어있는지 session key만 전달하고, 다시 서버측 저장소에서 실제 정보인 session value를 얻어오는 식으로 구현하더라도, key: value 는 1: 1이고, key는 client side state이지요. 그럼 결국 서버는 stateless인 것이 아닌가요? 덧붙여서 저기서 (웹서버마다의) local storage를 session 스토리지로 사용하면 그건 stateless한 구조가 아니어보이는데요.

  14. 김현준 님 말씀하신거는 맞습니다. 그런 구성이라면 stateless 하죠.제가 궁금한 점은 김태호 님께서 말씀하신 부분 중 “서버측 저장소없이” 라는 말이 잘 이해가 안 되어서요. client 에 날아온 값이 그게 어떤 mapping 값이던 mapping 되는 대상이 있을 거고 그게 저장소 meta data 든지 그 어떤 값이던지 특정 사용자인지를 판단하려면 서버 저장소에 access 해야 될 거라 생각되는데 다른 방법이 있는지 아니면 제가 잘 못 이해한 부분인지 궁금해서 댓글을 남긴 겁니다.

  15. Taeho Kim님이 말씀하신 서버측 저장소는 server-side session(HTTP session) 저장소를 말씀하시는 것 같습니다. 말씀하신대로 유저 데이터베이스는 당연히 있는 것이 맞습니다.

  16. 제 생각으로는 server-side session = 웹어플리케이션 local cache. = 서버 저장소. 이렇게 생각되서 자꾸 오해가 생기는 거 같습니다. 그리고 클러스터링 되지 않는 local cache 인 상황에서 어떤 서버에 붙어도 상관없다는 말이 이해가 되지 않는다는 거죠.

  17. 뭔가 간단한 문제를 깊게 들어간 것 같네요, 기본적으로 로드밸런싱을 염두해 두었다면 쿠키로 처리하는 것이 속편하지 않겠습니까? 쿠키를 쓴다는게 말 그대로 stateless 하게 구현한다는 것을 말하는거겠죠? 어찌 구현하던 방법은 많으니 상황과 개발자 스타일대로 하는 것이 좋을 듯 싶습니다.

Comments are closed.