현재 프로젝트에서 Spring Security 를 이용해 사용자 인증 부분을 처리했습니다.
개발환경에서는 문제가 없었는데 주말에 상용환경으로 포팅을 하면서 문제가 생겼습니다.
WEB 서버가 L4 밑으로 2대가 이중화 구성으로 되어 있는데, 사용자 인증을 못하고 있습니다. 내부 네트웍에서 web
server의 real ip로 접속하면 문제 없이 인증처리가 되는 것을 보면 문제는 L4의 vip로 접속하지만 tomcat은
real ip로 request를 받기 때문에 session 정보가 유지되지 않는 것 처럼 보입니다.
Spring을 처음 사용하는 것이라 정확하게 어떻게 문제를 해결해야 할 지 판단이 잘 안서는 군요. 구글신께 여쭤봐도 딱히 대답
도 않주시고..
오늘 오후부터 인수시험을 해야 하는데 난감하기 그지 없습니다. ㅜㅜ
참고고 Spring 2.5 의 security 의 필터는
context.HttpSessionContextIntergrationFiler를 사용해서 구현하였습니다.
비슷한 문제로 고민해 보신분이 계실것 같은데 조언해 주시면 감사하겠습니다.
On 6월15일, 오후1시33분, 용이 <yhle...@gmail.com> wrote:
On 6월15일, 오후2시23분, 신승한 <my.p...@gmail.com> wrote:
> 1. L4에서 같은 IP인지 구분해서 같은 IP이면 동일한 WAS로 전송을 해주도록 바꾸던가.
>
> 2. 2대의 WAS에 있는 session정보를 모두 복사하는 클러스터링을 하던가 해야 합니다.
> > > 비슷한 문제로 고민해 보신분이 계실것 같은데 조언해 주시면 감사하겠습니다.- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -
역시 스프링 시큐리티에서는 세션공유가 되지 않는군요..
역시 스프링 시큐리티에서는 세션공유가 되지 않는군요..
아~~ 위에분처럼 .. L4로 여러대의 was 를 연결할경우인증이 안되더라구요...그래서 여러포럼을 뒤져봐도 세션공유를 하는법을찾을수 없어 쿠키를 사용하는것으로 변경했는데...혹시 L4로 분배할경우에도 세션을 이용해서인증하는법이있을까요??
일단 위에서 말씀 하셨던 것과같이. 분산환경을 사용하는 경우
L4의 설정에 따라 사용자들이 어디로 접속될지 알수 없기 때문에 WAS들간의
Session 공유가 필요하게 됩니다.
Tomcat과 Jeus 등 대부분의 WAS Engine들이 이런 Cluster 기술들을 지원하는 것으로 알고 있습니다.
제가 알고 있기로는 이런 기술들을 지원하기 위해.
( WAS 들간의 Key 구분 ) jsessionid의 뒷부분에 ".jvmName" 이 추가된 것으로 알고 있습니다.
해다 WAS의 ID를 추가해서 어떤 WAS에 해당 정보가 저장되어있는지 알수있는 것이지요.
물론 이런 환경이 기본이지만....
사이트에서 적용한적이 있는 몇가지 를 말씀드리면.
1. 동일한 사용자가 다른 Cluster로의 이동을 최소화 한다.
1.1
L4 Switch 같은 경우 여러 조건으로 balance 를 하게 되어 있습니다.
기본적으로 L4는 해당 Server와의 connection개수를 기반으로 분산을 하게 되지만,
이런 방법 말고도 Client IP를 기반으로 Balance 할수 있습니다.
예를 들어 Cluster 서버가 5대 인경우 마지막 자라 IP를 기준으로
XXX.XXX.XXX.1/XXX.XXX.XXX.6/XXX.XXX.XXX.11 ==> 1번서버
XXX.XXX.XXX.2/XXX.XXX.XXX.7/XXX.XXX.XXX.12 ==> 2번서버
XXX.XXX.XXX.3/XXX.XXX.XXX.8/XXX.XXX.XXX.13 ==> 3번서버
XXX.XXX.XXX.4/XXX.XXX.XXX.9/XXX.XXX.XXX.14 ==> 4번서버
이런 식으로의 처리도 가능하다는 거죠.
그렇다면 사용자들이 IP대역에 골고루 분포한다면 사용자들은 Cluster를 돌아다니지 않고
일정한 서버로 계속 접속하게 되죠.
물론 해당 서버에 문제가 있을 경우 L4는 다른 Server로 접속을 전달하게 됩니다.
이때는 세션복제가 일어나겠죠..
1.2
또다른 방법으로는 Balance 작업을 한번만 하게 하는 거죠
사용자들이 처음 접속하는 혹은 로그인 하는 Page는 L4 IP로 접속하여
처리하게 하고 그런다음 실제 업무하는 Page로 변경될때 접속IP를 지금 접속한 HOST로 하는 거죠
이렇게 하려면 Cluster마다 소스 파일이 조금 달라져야 하죠.. ( 아주 조금 ㅋㅋ )
이렇게 하면, 처음에 Login 될때만 Balance되고 그다음 부터는 계속 해당 서버에 접속하게 되기
때문에 Session 복제는 필요하지 않습니다.
이 방법은 은행 사이트에서도 사용되어 지는 것으로 생각됩니다.
은행 사이트에 접속해보면 일반 Main Page와 계좌 이체를 하는 Page의 domain이 다르고
계좌이체같은 중요한 부분은 doamin뒤에 숫자같은 것들이 붙어 있는가 가끔 접속해 보면
그 숫자가 바뀌는 것으로 봐서는 아마도... 이런 방법을 사용하지 않을까 합니다.
이렇게 해서 세션복제를 최소화 하였습니다.
이렇게 까지 세션복제를 최소화 할려구 했던건 여러가지들의 다른 문제가 좀있었거든요
1. SESSION에 너무 많은 Data를 담고 있어서
session에는 최소한의 정보만 담아야 하는데.. 좀 필요한 정보를 많이 담다 보니 session양이 좀 무거워져
session 복제에 부담이되기도 했고
2. 특정 was 같은경우 session 복제하면 was 성능이 현저하게 떨어졌다는 사이트 엔지니어의 이야기를
들어본적도 있어서( 물론 was 자체의 문제가 아니라 다른 주변환경 의 문제였을수도 있지만, ) session 복제를
최소화 하는 방법을 고민해 보았습니다.
위의 두 제시안 모두 주의 사항이 있습니다.
1.1 의 경우는 적용을 시도하다가 포기한적이 있는데....
적용한 곳이 200군대 정도의 지사 를 가지고 있는 곳이었습니다.
이런 지사들은 각각 방화벽을 사용하고 내부 상용자들은 사설 IP를 사용하고 방화벽의 NAT 기능을 통해
외부와 연결되고 있었습니다.
문제는 대부분의 방화벽 담당자들이 방화벽의 IP를 XXX.XXX.XXX.254 아님. XXX.XXX.XXX.1 뭐 이
런식으로
특정 번호를 사용하고 있었던 것입니다. 이렇게 되면.
1.1 의 방법을 상요하게 되면, Load Balance가 되지 않고 한쪽으로 치우치게 됩니다.
그러서 1.1 은 포기한 적이 있죠.
1.2 의 경우는 Cluster 고유의 기능 때문에 약간 고민해야 합니다.
전체 부하를 여러 Cluster들이 분산하여 처리한다는 개념도 있지만, Cluster들 중 하나에 문제가 생겨도
다른 Cluster들이 해당 Request를 받아 처리해 줄수 있어야 하는데. 이에 문제가 되는거죠
사용자는 모르지만 이미 로그인 Page에서 사용자는 어떤 Cluster를 사용할지 결정을 했고
사용자는 계속해서 해당 Cluster를 사용하고 있기 때문에 해당 Cluster에 문제가 생기면, 서비스를 받지 못하게
됩니다.
물론 해결 방법은 간단 합니다. 다시 로그인 하면되죠.. ^^;;
하지만, 이렇게 서비스가 되지 않는 경우는 잘 없었기에 저희는 이 방법을 사용하고 있습니다.
위의 두방법으로 처리하였을 경우 특히 1.2를 사용하였을 경우는 세션복제가 필요하지 않습니다.
1.1의 경우도 거의 세션복제가 일어나지 않는다고 보여지지만,
가능성은 있기 때문에 세션복구기능을 구현해 두면 용의합니다.
세션복구기능은 세션복제기능과 유사합니다.
세션복제는 생성된 세션정보를 COPY하는 것이라면 세션복구는 세션KEY를 이용하여
세션을 다시 생성하는 것이라고 생각하면 됩니다.
위에서 언급한 것과 같이 세션에는 해당접속자 혹은 사용자의 고유정보가 저장되는 것이
일반적입니다. 그렇다면 사용자 ID 만으로 세션정보를 제생성하는 것이 가능합니다.
물런 그렇다고 사용자 ID를 세션복구의 KEY로 그대로 사용한다면 문제가 될것이고
SESSIONKEY --- USERID 뭐 이런 상관관계를 가지는 영속 Layer를 가지고 있다면
문제는 간단히 해결됩니다.
제가 관리하는 application의 경우 아침에 로그인해서 저녁에 로그아웃하기 전까지
session이 유지되어야 하고 사용자 수도 많아서 session 유효기간을 적당히 조절하고
세션 복구기능을 사용하여 휴지상태에 있던 사용자가 다시 서비스를 받고자 하면 세션을 복구
하는 방법을 사용하고 있었기에 위의
대안들을 생각하고 적용해 볼수 있었습니다.
그렇다고 WAS의 세션복제기능이 완전히 필요하지 않다는 것이 아니라
성능 향상을 위해 위의 사항들도 고려해 봐야 하지 않을까 하는 생각이고
제가 격었던 혹은 적용했던 내용을 정리해 보았습니다.
다른 분들은.. 어떠신가요.?
On 6월16일, 오전10시12분, 안영회 <ahnyoung...@gmail.com> wrote:
> > 아~~ 위에분처럼 .. L4로 여러대의 was 를 연결할경우
> > 인증이 안되더라구요...
>
> > 그래서 여러포럼을 뒤져봐도 세션공유를 하는법을
>
> > 찾을수 없어 쿠키를 사용하는것으로 변경했는데...
>
> > 혹시 L4로 분배할경우에도 세션을 이용해서
>
> > 인증하는법이있을까요??
>
> Layered 아키텍처 패턴을 이해하지 못하셨군요.
> TCP 나 OSI 7계층이 주는 이점을 아신다면 애플리케이션 계층에 속하는 SpringSecurity에서 네트워크 수준 제어를 하기
> 원하시나요?
> 위에 답변처럼 *세션복제*나 L4가 제공하는 기능을 쓰는 방법이 자연스러운 듯 합니다.
그룹스 홈에 파일이란 곳에
세션복제 최소화01.jpg
세션복제 최소화02.jpg
파일이 있으니 참고하시구요.
도움이 될려는지 모르겠지만,
각각 1번가 2번의 적용방법입니다.
참 위의 방법들이 세션복제를 하지 않아도 되는 방법은 아닙니다.
신중히 고려해서 적용하시기 바랍니다.
그리구 글에 파일 올릴수 있는 방법 좀 알려주세요.ㅋㅋ
그룹스에서 쓰면 본문에 어찌 그림을 넣을지 메뉴가 보이지 않네요. 도움말에도 파일 올리는 방법만 있고, 메시지에 넣는 방법은 설명하지 않고 있구요.
메일에서 이미지를 첨부하면 위 테스트 메시지처럼 보입니다.
--
------------------------------------
당신의 과거가 당신을 만든다.
그래서 저는 이것을 pound( http://www.apsis.ch/pound/ )라는 reverse proxy를 사용해서 해결
했습니다. 모든 reverse proxy에 이 기능이 있는지 모르겠지만 pound는 cookie의 session key로
session을 유지하는 기능이 있습니다. L4는 IP로만 할 수 있지만 reverse proxy는 소위 말하는 L7
switch에 해당하므로 http 프로토콜을 해석해서 더 정밀한 routing 정책을 수립할 수 있습니다.
요즘은 pound 말고 nginx가 대세인 것 같은데 nginx에서도 이런 기능이 있는 지 모르겠네요.
On 6월16일, 오후10시38분, superman <sup...@gmail.com> wrote:
> > 그리고 '세션 공유'는 적절한 표현이 아닌 듯 하네요.- 원본 텍스트 숨기기 -