Disk Based Database, In Memory Database

진행중인 프로젝트

https://github.com/Hwangwonuk/cucumber-market

GitHub - Hwangwonuk/cucumber-market: 중고물품 거래사이트 오이마켓 토이프로젝트

https://wonuk.tistory.com/129

Sticky Session, Session Clustering, Session Storage

https://wonuk.tistory.com/120

Scale Up, Sacle Out 서버 확장

세션 스토리지로 어떤 것을 선택해야 하는가?

Sticky Session의 특정 서버로 트래픽이 집중되는 문제,

Session Clustering의 세션 복제로 인한 성능적인 한계를 극복하면서도

서버를 추가하는데 용이하다는 점에서 Scale Out과 상성이 좋은 세션 스토리지를 분리하기로 했습니다.

그렇다면 이제 세션 스토리지로 사용할 저장소를 알아보고자 합니다.

 

Session

그 전에 먼저 우리가 저장하려고 하는 세션에 대해서 알아봅시다.

세션은 사용자들의 상태 정보를 가지고 있습니다.

웹 어플리케이션에서는 사용자들이 서비스를 이용함에 있어서 상태 정보를 유지하는데에 주로 사용됩니다.

 

왜 세션은 사라지나요?

세션이 서버에 저장되기 때문입니다.

사용자가 많고 세션에 저장되는 데이터가 많아질수록 서버의 자원을 많이 차지하고

이로 인한 부하가 매우 커지게 됩니다.

따라서, 더 이상 서비스를 사용하지 않는다고 판단되는 사용자들의 세션은 삭제하여

리소스가 낭비되지 않도록 관리하는 것입니다.

 

또한, 세션을 오랫동안 유지하게 되면 해킹에 의해 사용자의 권한을 탈취할 수 있는 위험이 증가하므로

위와 같은 관리가 필요합니다.

따라서, 세션은 영구적으로 저장되는 데이터가 아닙니다.

이와같은 세션의 특징을 기억하며 어떤 것이 세션을 저장하는데 적합할지 살펴봅시다.

---

Disk Based Database

디스크 기반 데이터베이스는 데이터를 디스크에 저장, 관리하는 데이터베이스 입니다.

Oracle, MySQL, MS-SQL 등이 여기에 해당됩니다.

디스크에 저장된 데이터는 지속성 및 안정성이 보장되고,

메모리에 비해 가격이 저렴하여 쉽게 확장이 가능하기 때문에 대용량 데이터를 처리하는데 용이합니다.

그러나 디스크 기반 데이터베이스는 접근속도 면에서 한계 발생합니다.

 

이러한 문제를 해결하기 위해 디스크 기반 데이터베이스 시스템은

메모리에 임시 저장소(버퍼)를 마련하여 데이터를 관리합니다.

메모리 I/O는 디스크 I/O에 비해 굉장히 속도가 빠르기 때문입니다.

 

그래서 디스크에 가기 전에 버퍼를 경유하여 읽고자 하는 데이터를 먼저 버퍼에서 찾아보고,

찾지 못할 때만 디스크에서 찾게됩니다.

즉, 필요한 데이터만 메모리로 로딩시켜 처리하는 것입니다.

따라서, 기존 데이터베이스 시스템에서는 성능을 향상시키기 위해

자주 사용하는 데이터를 버퍼에 저장하는 등 다양한 방식으로

디스크 I/O는 최소화하고 버퍼를 효율적으로 활용합니다.

 

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

디스크에서 버퍼로의 데이터 전송 시간 등이 발생하기 때문에

방대한 I/O 작업을 처리하는 경우 결국 병목 현상이 생기게 됩니다.

 

실시간으로 데이터가 급증하고, 이에 대한 빠른 처리 성능이 요구되는 환경에서

이러한 성능 저하는 치명적인 단점이라고 할 수 있습니다.

 

In Memory Database

인메모리 데이터베이스는 디스크가 아닌 메모리에 모든 데이터를 저장하고 관리합니다.

Redis, H2, memcached 등이 속합니다.

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

디스크 기반 데이터베이스보다 데이터 접근 속도가 굉장히 빠릅니다.

 

또한, 불필요한 임시 데이터가 생기지도 않습니다.

디스크에 비해 가격이 다소 높다고는 하지만 메모리의 가격 또한 지속적으로 내려가고 있기 때문에

비용적인 측면에서는 큰 문제가 없다고 판단됩니다.

 

다만 인메모리 데이터베이스의 주 저장소인 메모리가 휘발성이라는 단점이 있습니다.

만약 서버에 장애가 발생하여 서버가 다운되면 메모리에 저장되어 있던

모든 데이터가 소실될 수 있는 위험이 있습니다.

 

따라서, 인메모리 DB는 데이터를 안전하게 유지하고,

오류 발생 시 데이터를 복구하는데에 주로 중점을 두어야 합니다.

이러한 문제를 해결하기 위해 인메모리 DB는 보조 저장소로 디스크를 사용합니다.

 

일정 시점에 메모리에 저장되어 있는 데이터를 디스크에 저장하거나 데이터

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

 

비록 이런위험성을 가지고 있을지라도 인메모리 DB의 작업 속도가

디스크 기반 DB의 작업 속도를 훨씬 뛰어넘기 때문에

영구적으로 저장되어야 하는 데이터나 저장만이 목적인 데이터를 다루지 않는 이상

인메모리 DB를 사용하는 것이 유리합니다.

 

결론

두가지 데이터베이스의 큰 차이점은 속도와 휘발성 입니다.

대용량 트래픽이 발생하는 상황을 가정한다면

같은 시간동안 더 많은 요청을 처리하기 위해서 각각의 요청에 대한 응답시간을 줄여야 합니다.

 

 

위의 예시만 보아도 두 데이터베이스의 속도가 얼마나 차이가 나는지 바로 체감할 수 있습니다.

디스크 기반 데이터베이스보다는 인메모리 데이터베이스가 훨씬 유리하다는 결론이 나오게 됩니다.

 

제가 저장할 데이터는 세션입니다.

세션은 가장 처음에도 살펴봤듯이 서버 리소스를 차지하고 보안상 위험이

생길 수 있다는 이유로 영구적으로 저장하지 않습니다.

 

언젠가는 삭제해야 할 데이터를 소실될 수도 있다는 위험을 방지한다는 이유로

빠른 처리 속도까지 포기해가면서 디스크 기반 데이터베이스를 선택하기에는

우리가 얻을 수 있는 이점이 거의 없습니다.

 

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

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

또한 이러한 단점에 대해 보완하는 방법도 존재합니다.

https://wonuk.tistory.com/118

Redis란 무엇인가?