분산 처리 환경에서 대용량 트래픽을 견디기 위한 로그인 기능 구현-3. 세션 스토리지로 어떤 것이 더 적합한가? - Disk Based Database VS In Memory Database

3. 세션 스토리지로 어떤 것이 더 적합한가? - Disk Based Database VS In Memory Database

저번 글에서는 Scale Out의 데이터 불일치 문제를 해결하기 위한 Sticky Session, Session Clustering, 세션 스토리지 분리

의 다양한 방법에 대해 알아보았다. 그 중 Sticky Session의 특정 서버로 트래픽이 집중되어 발생하는 과부하 문제나

Session Clustering의 세션 복제로 인한 성능적인 한계를 극복하면서도 서버를 추가하는데 용이하다는 점이 Scale Out과

상성이 좋아 세션 스토리지를 분리하기로 했다. 그렇다면 이제 세션 스토리지로 사용할 저장소를 선택해야 한다.

 

Session

그 전에 먼저 우리가 저장하려고 하는 세션에 대해서 알아보자. 세션은 사용자들의 상태 정보를 가지고 있다. 이전 글에서

도 살펴본 것처럼 웹 어플리케이션에서는 사용자들이 서비스를 이용하는데 불편함을 느끼지 않도록 상태 정보를 유지하

는데에 주로 사용된다. 그럼 이 세션이 영구적으로 유지되는게 좋을 것 같은데 왜 만료 시간이 지나거나 브라우저가 종료

되면 삭제되도록 고안된 것일까?

 

 

바로 세션이 서버에 저장되기 때문이다. 사용자가 많고 세션에 저장되는 데이터가 많아질수록 서버 리소스를 많이 차지하

고 이로 인한 부하가 매우 커지게 된다. 따라서, 더 이상 우리 서비스를 사용하지 않는다고 판단되는 사용자들의 세션은 삭

제하여 리소스가 낭비되지 않도록 관리하는 것이다. 또한, 세션을 오랫동안 유지하게 되면 서비스 사용자의 세션에 부적

절한 공격이 가해져 해당 사용자의 권한을 탈취할 수 있는 위험이 증가하므로 위와 같은 관리가 필요하다. 따라서, 이러한

이유로 세션은 영구적으로 저장되는 데이터가 아니다.

 

위에서 알아본 세션의 특징을 기억하며 어떤 것이 세션을 저장하는데 적합할지 살펴보자.

 

Disk Based Database

디스크 기반 데이터베이스는 데이터를 디스크에 저장, 관리하는 데이터베이스이다. 우리가 흔히 알고 있는 Oracle,

MySQL, MS-SQL 등이 여기에 해당된다. 디스크에 저장된 데이터는 지속성 및 안정성이 보장되고, 메모리에 비해 가격이

저렴하여 쉽게 확장이 가능하기 때문에 대용량 데이터를 처리하는데 용이하다. 그러나 디스크 기반 데이터베이스는 접근

속도 면에서 한계가 드러난다.

 

이러한 문제를 해결하기 위해 디스크 기반 데이터베이스 시스템은 메모리에 임시 저장소(버퍼)를 마련하여 데이터를 관

리한다. 메모리 I/O는 디스크 I/O에 비해 굉장히 속도가 빠르기 때문이다. 그래서 디스크에 가기 전에 버퍼를 경유하여

읽고자 하는 데이터를 먼저 버퍼에서 찾아보고, 찾지 못할 때만 디스크에서 찾는다. 즉, 필요한 데이터만 메모리로 로딩

시켜 처리하는 것이다. 따라서, 기존 데이터베이스 시스템에서는 성능을 향상시키기 위해 자주 사용하는 데이터를 버퍼

에 저장하는 등 다양한 방식으로 디스크 I/O는 최소화하고 버퍼를 효율적으로 활용하는 것에 초점을 맞춘다.

 

그러나 처리 능력을 강화해도 DB 연산 처리 시간 외에 디스크에서 데이터를 찾을 때 발생하는 대기 시간, 디스크에서 버

퍼로의 데이터 전송 시간 등이 발생하기 때문에 방대한 I/O 작업을 처리하는 경우 결국 병목 현상이 생기게 된다. 기술의

발전으로 실시간으로 데이터가 급증하고, 이에 대한 빠른 처리 성능이 요구되는 환경에서 이러한 데이터 I/O 측면에서

발생하는성능 저하는 치명적인 단점이라고 할 수 있다.

 

In Memory Database

반면 인메모리 데이터베이스는 디스크가 아닌 메모리에 모든 데이터를 저장하고 관리한다. Redis, H2, memcached 등이

이에 속한다.인메모리 데이터베이스는 모든 작업을 메모리에서 수행하여 디스크 I/O가 발생하지 않기 때문에 디스크 기반

데이터베이스보다 데이터 접근 속도가 굉장히 빠르다. 또한, 불필요한 임시 데이터가 생기지도 않는다. 디스크에 비해 가

격이 다소 높다고는 하지만 메모리의 가격 또한 지속적으로 내려가고 있기 때문에 비용적인 측면에서는 큰 문제가 없다.

 

다만 인메모리 데이터베이스의 주 저장소인 메모리가 휘발성이라는 한계가 있다. 만약 서버에 장애가 발생하여 서버가 다

운되면 메모리에 저장되어 있던 모든 데이터가 소실될 수 있는 위험이 있다는 것이다. 따라서, 인메모리 DB는 데이터를

안전하게 유지하고, 오류 발생 시 데이터를 복구하는데에 주로 초점을 맞추고 있다. 이러한 문제를 해결하기 위해 인메모

리 DB는 보조 저장소로 디스크를 사용한다. 일정 시점에 메모리에 저장되어 있는 데이터를 디스크에 저장하거나 데이터

변경 작업을 처리할 때마다 해당 명령을 로그 파일에 작성하는 등 다양한 방식을 사용하여 데이터를 백업한다.

 

비록 이런위험성을 가지고 있을지라도 인메모리 DB의 작업 속도가 디스크 기반 DB의 작업 속도를 훨씬 뛰어넘기 때문

에 영구적으로 저장되어야 하는 데이터나 저장만이 목적인 데이터를 다루지 않는 이상 인메모리 DB를 사용하는 것이 유

리하다.

 

세션 스토리지로 어떤 것이 더 적합할까?

이제 두 가지 데이터베이스 중에 어떤 것이 더 나을지 비교해보자. 일단 두 가지 데이터베이스의 큰 차이점은 속도와 휘발

성이다. 내가 진행하고 있는 프로젝트를 기준으로 생각해보면 SNS 서비스는 속도가 굉장히 중요하다. SNS에서는 수많은

사람들이 실시간으로 무수히 많은 요청들을 보내기 때문이다. 같은 시간동안 더 많은 요청을 처리하기 위해서는 각각의

응답시간을 줄여야 한다.

 

 

위의 짤만 봐도 두 데이터베이스의 속도가 얼마나 차이가 나는지 바로 체감할 수 있다. 인메모리 데이터베이스는 모든 작

업을 메모리에서 수행하므로 디스크 I/O가 발생하는 디스크 기반 데이터베이스보다 데이터 접근 속도가 빠를 수 밖에 없

다.이런 측면에서 봤을 때, 디스크 기반 데이터베이스보다는 인메모리 데이터베이스가 훨씬 유리하다.

 

또한, 우리가 저장할 데이터는 세션이다. 세션은 가장 첫 문단에서도 살펴봤듯이 서버 리소스를 차지하고 보안상 위험이

생길 수 있다는 이유로 영구적으로 저장하지 않는다. 언젠가는 삭제해야 할 데이터를 소실될 수도 있다는 위험을 방지한

다는 이유로 빠른 처리 속도까지 포기해가면서 디스크 기반 데이터베이스를 선택하기에는 우리가 얻을 수 있는 이점이 거

의 없다는 것이다. 만약에 인메모리 데이터베이스에 세션을 저장하고 서버에 장애가 생겨 세션 데이터가 모두 날아간다

해도 사용자들은 로그인만 한 번 더 하면 될 뿐 서비스 사용에도 큰 불편이 생기지 않는다.

 

 

지금까지 두 가지 방식의 데이터베이스를 비교해보았고 내가 진행하는 SNS 서비스 프로젝트에는 인메모리 데이터베이

스가 세션 스토리지에 적합하다고 판단했다. 이제 마지막으로 인메모리 데이터베이스 중에서도 어떤 종류의 데이터베이

스가 좋을지 알아볼 것이다.

 

 

---

• 진행 프로젝트

https://github.com/f-lab-edu/sns-itda

f-lab-edu/sns-itda

 

• 이어지는 글

chagokx2.tistory.com/92

분산 처리 환경에서 대용량 트래픽을 견디기 위한 로그인 기능 구현-1. 서버를 어떻게 확장시킬 �

chagokx2.tistory.com/93

분산 처리 환경에서 대용량 트래픽을 견디기 위한 로그인 기능 구현-2. 여러 대의 서버에 흩어져