사용자 식별 방법 - 세션

사용자 식별 방법

1. 세션: 서버에서 관리하는 정보를 이용하여 사용자를 식별하는 방법. 일반적으로 로그인 시 사용자의 아이디와 패스워드를 인증받아 세션을 생성하고, 세션 ID를 쿠키에 저장.
2. 쿠키: 클라이언트에 저장되는 정보를 이용하여 사용자를 식별하는 방법. 사용자의 브라우저에 쿠키가 저장되며, 서버에서는 클라이언트의 쿠키값을 이용하여 사용자를 식별.
3. 토큰: 사용자 인증 정보를 담고 있는 문자열로, 서버와 클라이언트 간에 인증 정보를 주고받을 때 사용. 일반적으로 로그인 시 서버에서 토큰을 생성하여 클라이언트에 전달하고, 이후에는 클라이언트에서 서버로 요청을 보낼 때 토큰을 함께 전달하여 인증을 수행.
4. 핑거프린트: 브라우저의 고유한 정보를 이용하여 사용자를 식별하는 방법. 브라우저의 특징을 이용하여 고유한 식별자를 생성하고, 이를 서버에서 관리.
5. IP 주소: 사용자의 IP 주소를 이용하여 사용자를 식별하는 방법. 하지만 IP 주소는 공유기와 같은 네트워크 환경에서는 사용자 식별에 한계. 주 식별 방법이 될 수 없음

 

세션의 단점

1) 서버 메모리 부담: 세션은 서버에서 관리되므로, 많은 사용자가 접속하면 서버 메모리를 많이 차지하여 부하가 발생할 수 있음.

2) 확장성 제한: 세션은 서버에서 관리되기 때문에, 서버의 확장성이 제한됨. 만약 서버의 부하가 많아져서 새로운 서버를 추가해야 한다면, 새로운 서버에서도 세션 데이터를 공유해야 하므로 복잡해질 수 있음.
3) 데이터 전송 부하: 세션은 서버에서 생성되기 때문에, 클라이언트와 서버 간에 세션 데이터를 주고 받아야 함. 만약 세션 데이터가 많거나, 사용자 수가 많아진다면 데이터 전송 부하가 증가할 수 있음.
4) 보안 취약성: 세션은 서버에서 관리되기 때문에, 서버가 해킹당하면 세션 데이터가 유출될 가능성이 있음. 또한 세션 ID가 탈취될 경우, 다른 사용자로 위장하여 접근할 수 있는 보안 취약성이 있음.

 

해결

(1) 세션 아웃캐스팅 : 세션을 쿠키나 웹 스토리지 등으로 이전하여 메모리 부담 감소.

(2) 세션 클러스터링 : 여러 대의 서버가 하나의 세션 스토어를 공유하도록 구성하는 방식으로, 서버 장애 시 다른 서버에서 세션 정보를 제공하여 세션 유지를 가능하게 함.
- 로컬 세션 클러스터링(Local Session Clustering): 하나의 물리적 서버에 여러 개의 WAS를 띄워서, 각 WAS 내부에 세션 정보를 저장하는 방식. WAS 간 세션 정보 공유가 필요 없으므로, 구현이 단순하고 성능이 우수하지만 WAS 장애 시 세션 정보가 유실될 가능성이 있음.
- 공유 세션 클러스터링(Shared Session Clustering): 여러 대의 물리적 서버가 하나의 세션 스토어를 공유하는 방식. 세션 정보를 모든 서버가 공유하기 때문에, WAS 장애 시에도 세션 정보가 유지됨. 하지만, 세션 정보 공유를 위해 별도의 네트워크 대역이 필요하고, 노드 추가/제거 시 세션 정보 이전 작업이 필요하여 구현이 복잡함.
- 클라우드 세션 클러스터링(Cloud Session Clustering): 클라우드 서비스를 활용하여 세션 클러스터링을 구현하는 방식. 클라우드 서비스의 로드 밸런싱 기능과 세션 스토어 서비스를 이용하여, 노드 추가/제거 및 서버 장애 대응이 쉽고, 대규모 트래픽 처리에 유리.
* 최근에는 클라우드 세션 클러스터링이 많이 활용되고 있다고 함. 클라우드 기반으로 서비스를 제공하면 인프라 운영 비용이 절감되고, 노드 추가/제거 등의 작업이 간단하며, 대규모 트래픽 처리에 유리하기 때문.

 

클라우드 세션 클러스터링(Cloud Session Clustering)

- 클라우드 환경에서 세션을 유지하고 관리하기 위한 기술. 클라우드 환경에서는 여러 대의 서버가 동작하고, 서버를 추가하거나 제거하는 등 유동적인 상황이 발생할 수 있기 때문에 세션 클러스터링을 이용하여 이러한 상황에 대응.

클라우드 세션 클러스터링 기술
- Sticky session
로드 밸런서가 클라이언트의 요청을 받아서 특정 서버에게 전달할 때, 해당 클라이언트의 세션 ID를 사용하여 항상 같은 서버로 전달하는 방식. 이 방식은 로드 밸런싱 알고리즘을 간단하게 유지할 수 있으며, 클라이언트의 요청이 항상 같은 서버로 전달되므로 세션 정보가 유지됨.
- Session replication
서버 간의 세션 정보를 동기화하여 사용하는 방식. 로드 밸런서가 클라이언트의 요청을 받아서 특정 서버에게 전달할 때, 해당 서버에 세션 정보가 없다면 다른 서버에서 세션 정보를 가져와서 사용. 이 방식은 서버 간의 세션 정보를 실시간으로 동기화해야 하므로 성능 저하가 발생할 수 있음.
- Distributed caching
여러 대의 서버 간에 세션 정보를 공유하는 방식. 세션 정보를 별도의 캐시 서버에 저장하고, 서버에서는 해당 캐시 서버에 접근하여 세션 정보를 사용함. 이 방식은 세션 정보를 공유함으로써 성능을 향상할 수 있으나, 캐시 서버에 장애가 발생할 경우 전체 시스템에 영향을 줄 수 있음.
* Database-based session management
세션 정보를 데이터베이스에 저장하는 방식. 서버에서 세션 정보를 생성하고, 데이터베이스에 저장한 후, 클라이언트의 요청이 올 때마다 해당 세션 정보를 데이터베이스에서 읽어와 사용. 이 방식은 데이터베이스의 확장성에 따라서 성능이 결정되므로, 데이터베이스 환경에 따라 성능이 크게 달라짐.
* 요즘은 분산 캐싱 기술이 발전하면서 Distributed caching 방식을 주로 사용한다고 함. 클라우드 환경에서의 세션 클러스터링은 클라우드 제공 업체에서 제공하는 분산 캐싱 서비스를 이용하는 것이 일반적임. 대표적으로 AWS의 ElastiCache, Google Cloud Platform의 Memorystore, Microsoft Azure의 Azure Cache for Redis 등이 있음.
* 이러한 분산 캐싱 서비스를 이용하면, 여러 대의 서버 간에 캐시 데이터를 공유하여 빠른 세션 처리 속도를 보장할 수 있음. 예를 들어, AWS의 ElastiCache를 사용하는 경우, Redis 또는 Memcached와 같은 인메모리 캐시 엔진을 사용하여 세션 정보를 저장하고 관리.
* 또한, 이러한 분산 캐싱 서비스는 클라우드 제공 업체에서 자동으로 서버를 추가하거나 제거하여 확장성을 보장할 수 있음. 따라서 사용자 수가 급증하여 세션 처리 부하가 증가하는 경우에도 자동으로 서버를 추가하여 대응할 수 있음. 이러한 장점으로 인해, 클라우드 환경에서의 세션 클러스터링은 비교적 간편하고 안정적으로 구현할 수 있음.

 

Distributed caching - Non Cloud Session Clustering

Tomcat Clustering
- Tomcat은 웹 어플리케이션애플리케이션 서버이며, Clustering 기능을 제공. Tomcat Clustering은 고가용성과 확장성을 제공하는 방법 중 하나. Tomcat Clustering을 사용하면 여러 대의 Tomcat 서버를 하나의 논리적인 그룹으로 묶어서 웹 애플리케이션을 실행할 수 있음.
Redis Cluster
- Redis는 In-memory 데이터 저장소로, Redis Cluster를 사용하여 분산된 Redis 노드들을 묶어서 하나의 논리적인 그룹으로 만들 수 있음. Redis Cluster를 사용하면 서버 장애가 발생했을 때 다른 서버로 자동으로 이전되며, 데이터 일관성도 유지됨.
Apache Ignite
- Apache Ignite는 In-memory 데이터 그리드로, 클러스터링을 지원. Apache Ignite 클러스터는 여러 대의 노드로 구성되며, 데이터를 분산하여 저장하고 처리. 또한, 클러스터링을 사용하여 고가용성 및 확장성을 제공.

 

Redis Cluster

Redis는 인메모리 데이터 구조 스토어로서, 높은 성능과 확장성을 제공함. Redis를 사용하면 세션 정보를 분산 저장하고, 빠르게 가져올 수 있음. 또한 Redis는 클러스터 모드로 여러 노드를 구성하여 데이터를 분산 저장할 수 있기 때문에 확장성도 높음.
Redis를 사용하여 세션 분산 캐싱을 구현하는 방법

1. Redis를 직접 사용하는 방법 : Redis 클라이언트 라이브러리를 이용하여 Redis 서버에 직접 접속하여 세션 정보를 저장하고 가져옴. 이 방법은 간단하고 직관적이지만, 코드를 직접 작성해야 하기 때문에 복잡도가 높을 수 있음.
2. Spring Session은 Spring 프레임워크 기반의 세션 관리 프레임워크로, Redis를 통해 세션 정보를 분산 저장하고 가져올 수 있음. Spring Session은 Spring Boot와 같은 스프링 기반 애플리케이션에서 쉽게 사용할 수 있으며, 설정이 간단하고 코드 복잡도가 낮음. 이 방법은 개발자가 직접 Redis 클라이언트 라이브러리를 사용하여 세션 정보를 저장하고 가져오지 않아도 되기 때문에 생산성이 높음.

 

Apache Ignite
Apache Ignite는 분산 캐시 및 컴퓨팅 플랫폼으로, 대용량 데이터 처리, 분산 캐싱, 분산 트랜잭션 처리 등에 사용됨. 세션 분산 캐싱을 위해서도 Apache Ignite를 사용할 수 있음.
요즘은 Redis와 Memcached 같은 분산 캐시 솔루션과 함께 인기가 있는 기술 중 하나로 In-Memory 기술을 사용하여 데이터를 빠르게 캐시하고 분산 처리를 수행함. 따라서, 대규모 트래픽을 다루는 웹 애플리케이션에서 많이 사용됨.

세션 분산 캐싱의 경우, Ignite를 사용하여 세션 데이터를 클러스터 전체에 분산 저장하고 처리할 수 있음. 이를 위해 Ignite 클러스터를 구성하고, 클러스터의 노드들은 모두 같은 Ignite 캐시를 공유함. 세션 ID를 키로 사용하여 세션 데이터를 캐시에 저장하고, 클라이언트 요청이 들어오면 해당 세션 ID를 기반으로 캐시에서 세션 데이터를 조회함. 이렇게 함으로써, 세션 데이터의 분산 저장과 조회가 가능해지며, 세션 장애 대응 및 확장성도 높아짐.

 

Memcached
Memcached는 여전히 많은 기업에서 세션 분산 캐싱을 위한 기술로 사용되고 있음. 특히, Memcached는 분산 캐싱에 최적화된 고성능 메모리 객체 캐시 시스템으로, 높은 처리량과 낮은 지연 시간을 제공함. 또한 Memcached는 오픈소스로 무료로 사용할 수 있으며, 다양한 언어와 플랫폼에서 사용 가능함.
그러나 최근에는 Redis와 같은 다른 분산 캐싱 기술들의 등장으로 인해, Memcached의 사용은 다소 줄어들고 있지만, 여전히 단순하고 가볍기 때문에, 높은 처리량이 필요한 웹 애플리케이션에서 여전히 인기가 있음..