1.2. 주요 기능
도입하면 무엇이 좋아지는가
접속이 몰려도 응답 시간을 유지합니다
세션을 데이터그리드에 두면 저장 공간과 WAS 처리 능력을 따로 늘릴 수 있습니다. 예상보다 많은 사용자가 들어와 세션이 늘어나면 데이터그리드 노드를 추가해 저장 공간만 넓힙니다. WAS 설정을 바꾸거나 애플리케이션을 다시 배포할 필요가 없습니다.
WAS 자체 복제 방식은 세션이 각 인스턴스의 힙 메모리를 함께 차지하므로, 접속이 늘면 애플리케이션이 쓸 메모리가 줄고 가비지 컬렉션(GC)이 길어집니다. 세션을 밖으로 빼면 이 영향이 없어집니다.
WAS 인스턴스가 멈춰도 세션이 남습니다
세션이 데이터그리드에 저장되어 있고 노드 사이에 백업본이 있으므로, WAS 인스턴스 한 대가 멈춰도 그 사용자의 세션은 없어지지 않습니다. 다른 인스턴스가 요청을 받아 같은 세션을 이어서 처리합니다. 사용자는 다시 로그인하지 않고, 장애 직후 재접속이 몰리는 부하도 생기지 않습니다.
배포도 같습니다. 인스턴스를 재시작해도 세션은 데이터그리드에 남아 있어 로그인 상태가 유지됩니다.
애플리케이션 코드를 고치지 않습니다
Java EE 표준 서블릿 필터로 만들어졌습니다. web.xml 에 필터 설정을 넣고 라이브러리를 추가하면 되며, HttpSession 을 쓰는 기존 코드는 그대로 둡니다.
세션에 넣는 객체가 직렬화(Serializable)되어 있어야 한다는 조건 하나만 확인하면 됩니다(2부 참고).
운영 작업이 줄어듭니다
- WAS 인스턴스끼리 세션을 복제하는 설정을 하지 않습니다. 인스턴스를 늘리거나 줄일 때 그 설정을 다시 손볼 일도 없습니다.
- 로드 밸런서가 특정 사용자를 특정 인스턴스로 고정해 보낼 필요가 없어(고정 세션 불필요) 부하가 고르게 나뉩니다.
- 세션 개수·메모리 사용량을 MBean 으로 확인할 수 있어, 문제가 생겼을 때 세션이 원인인지 아닌지 바로 판단합니다(3부 참고).
서로 다른 애플리케이션이 로그인 상태를 함께 씁니다
세션 쿠키의 경로(path)를 / 로 두면 서로 다른 웹 애플리케이션이 같은 세션을 봅니다. 애플리케이션마다 따로 로그인하지 않아도 되고, 서로 다른 WAS 제품 사이에서도 동작합니다.
제공하는 기능
- Java EE 표준 Servlet Filter를 사용하여 Servlet 2.5 이상을 지원하는 WAS 에서 사용할 수 있음 (WebLogic, JEUS, Tomcat, JBoss EAP 등)
- 서로 다른 웹 애플리케이션 간의 세션 공유 기능
- 웹 애플리케이션의 중복 로그인 방지 기능
- 세션에서 사용하는 메모리 사용량 모니터링
- Active 세션 개수, 세션 생성/소멸 개수, 중복 로그인 횟수, 초당 세션 생성/소멸/중복로그인 횟수에 대한 MBean 모니터링
- 주요 Static Contents에 대해 세션을 생성하지 않도록 필터링
- In Memory Data Grid(IMDG) 기술을 사용하여 안정적이며 세션에 대한 확장성이 높음.
- SessionStore의 종류
- 라이브러리 모드 — 데이터그리드를 WAS 안에 두는 방식
- 원격 데이터그리드 모드 — 데이터그리드를 별도 서버에 두는 방식
WAS 세션 클러스터링과 비교
OPENMARU Cluster 는 데이터그리드로 세션을 관리해 WAS 의 안정성·성능·확장성을 확보합니다. WAS 가 자체로 제공하는 세션 클러스터링과 견주면 다음과 같습니다.
| 항목 | WAS 세션 클러스터링 | OPENMARU Cluster 세션 클러스터링 | ||
|---|---|---|---|---|
| 안정성 | ○ | * 해당 인스턴스와 다른 인스턴스에 세션 데이터를 복제하고 동기화하여 관리 * 과도한 세션 사용시 OOM 메모리 장애 발생 * 세션데이터에 의한 GC가 장시간 발생 | ● | * 세션 데이터를 데이터그리드에 저장하고 공유하기 때문에 거래가 증가되어도 가용성을 유지한 채 안정적으로 분산 관리 가능 * WAS 노드 장애 시 상호 공유된 세션 정보를 통해 세션유실방지 |
| 성능 | ◑ | * WAS 인스턴스 관리 세션 복제와 동기화에 따른 성능 이슈 | ● | * 세션 복제나 동기화 과정이 생략되어 신속한 WAS 관리 작업이 가능 |
| 확장성 | ◑ | * WAS 인 스턴스 확장 | ● | * 애플리케이션 메모리와 세션 메모리를 분리하여 예측 가능한 확장성 보장 |
| 세션 관리 | ○ | * WAS 인스턴스 재시작시 세션 동기화와 복제 * 애플리케이션 배포시 세션 동기화와 복제 * 애플리케이션 별 세션 정보 관리 | ● | * WAS 인스턴스 재 시작시 세션 복제 작업 제거 * 애플리케이션 재배포 시 세션 복제 작업 제거 * 복수의 애플리케이션 간 세션 정보 공유 |
WAS 세션 클러스터링 아키텍처
WAS 제품이 자체로 제공하는 방식입니다. 아래 그림에서 오른쪽의 붉은 화살표가 세션 복제입니다.
요청은 로드 밸런서를 거쳐 웹 서버(WEB)로 가고, 웹 서버는 뒤에 있는 WAS 인스턴스 가운데 하나로 넘깁니다. 세션은 요청을 처리한 그 인스턴스의 메모리에 만들어집니다. 그대로 두면 그 인스턴스가 멈출 때 세션이 함께 없어지므로, 인스턴스들끼리 세션을 서로 복사해 둡니다.
여기서 두 가지가 따라옵니다.
첫째, 인스턴스를 늘릴수록 복제가 늘어납니다. 세션을 만들거나 바꿀 때마다 다른 인스턴스에 알려야 하는데, 인스턴스가 많아지면 알릴 곳 도 많아집니다. 처리 능력을 늘리려고 인스턴스를 추가했는데 그만큼 복제 통신이 늘어 이득이 줄어듭니다.
둘째, 세션이 애플리케이션과 같은 메모리를 씁니다. 세션은 WAS 의 힙 메모리에 있으므로, 접속자가 늘면 애플리케이션이 쓸 메모리가 줄어듭니다. 세션 데이터가 쌓인 상태에서 가비지 컬렉션(GC)이 돌면 시간이 길어지고, 그동안 응답이 늦어집니다. 심하면 메모리 부족(OOM)으로 인스턴스가 멈춥니다.
그리고 서로 다른 WAS 제품 사이나 서로 다른 웹 애플리케이션 사이에서는 이 방식이 동작하지 않습니다. 복제는 같은 제품의 같은 클러스터 안에서만 이루어지기 때문입니다.
Cluster 세션 클러스터링 아키텍처
OPENMARU Cluster 를 적용한 모습입니다. 앞 그림에 있던 인스턴스 사이의 복제 화살표가 없어지고, 오른쪽에 데이터그리드가 생겼습니다.
요청이 로드 밸런서와 웹 서버를 거치는 부분은 같습니다. 달라지는 것은 그다음입니다. WAS 인스턴스는 세션을 들고 있지 않고, 필요할 때마다 데이터그리드에서 읽고 씁니다.
그래서 앞의 두 가지 문제가 함께 없어집니다.
인스턴스 사이의 복제가 사 라집니다. 세션이 한곳에 있으므로 서로 알릴 일이 없습니다. 인스턴스를 늘리면 늘린 만큼 처리 능력이 늘고, 줄이거나 재시작해도 세션은 그대로 남습니다.
애플리케이션 메모리와 세션 메모리가 분리됩니다. 접속자가 늘어도 WAS 의 힙 사용량은 크게 변하지 않으므로 필요한 메모리를 예측할 수 있습니다. 세션이 늘면 데이터그리드 노드를 추가해 저장 공간만 넓힙니다.
어느 인스턴스가 요청을 받아도 결과가 같습니다. 로드 밸런서가 같은 사용자를 같은 인스턴스로 보낼 필요가 없어 부하가 고르게 나뉘고, 서로 다른 WAS 제품이나 서로 다른 웹 애플리케이션도 같은 세션을 함께 볼 수 있습니다.