개요
지난 시간 다중 서버 환경에서 별도의 세션 스토리지를 구성하여 정합성 이슈를 해결하기로 하였습니다. 여기서 생각해볼 문제가 있습니다. 웹 서비스의 특성상 대부분의 요청은 인가된 사용자가 보내는 요청인지 확인하는 절차가 선행되어야 합니다. 즉, 대부분의 요청에서 로그인한 사용자인지 아닌지 확인하기 위해 매번 세션 스토리지를 방문해야 합니다. 이러한 특성을 고려한다면 세션 스토리지를 선정할 때, 성능에 영향이 미치지 않도록 빠르게 데이터를 찾아서 제공할 수 있는 데이터베이스를 사용해야 하겠죠?
지금부터 어떠한 데이터베이스가 세션 스토리지에 적합한지 알아보겠습니다.
매번 왕복하기에 디스크는 너무 느린걸?
데이터베이스는 데이터가 어느 곳에 저장이 되는가를 기준으로 디스크 기반의 데이터베이스와 In-Memory 데이터베이스로 분류됩니다. 이름 그대로 디스크 기반의 데이터베이스는 데이터를 Disk에 저장하여 관리하며, In-Memory 데이터베이스는 메모리에 데이터를 저장하고 관리하는 데이터베이스를 말합니다.
조금 더 구체적으로 알아볼까요? 우선, 디스크 기반 데이터베이스에는 우리가 흔히 사용하는 예로 MySQL, Oracle, MS-SQL 등과 같은 관계형 데이터베이스가 있습니다. 디스크 기반 데이터베이스의 특징은 데이터를 디스크에 저장하여 관리한다는 점입니다. 물론, 앞서 언급한 데이터베이스들도 스토리지 엔진에 따라서 데이터를 디스크에 저장하기도 하고, 메모리에 저장하기도 합니다.
디스크 기반 데이터베이스는 데이터를 디스크에 저장함으로써 전원이 공급이 되지 않더라도 영구적으로 보관이 가능하지만, 위 그림과 같이 내부 원판(Flatter)을 회전시켜서 데이터를 읽고 쓰는 기계식 방식을 사용하기 때문에 전자식 저장매체보다는 속도가 현저히 느립니다.
최근 들어, 하드디스크 대체하여 SSD 사용하는 이유도 SSD는 플래시 메모리를 사용한 전자식 저장매체이기 때문에 기계식 저장매체인 하드디스크보다 빠른 속도로 데이터를 읽고 쓸 수 있기 때문입니다. SSD가 Disk 기반의 데이터베이스보다 빠른 I/O를 처리할 수 있지만, 우리가 컴퓨터의 메모리로써 사용하는 RAM에 비해서는 역시 속도가 떨어집니다.
위에 보시는 표는 컴퓨터 주요 부품별 처리 속도를 나타냅니다. 보시는 바와 같이 SSD와 DISK는 약 1,000배 이상의 요청 처리 속도 차가 발생합니다. 표에서 보기에 DISK의 단위가 너무 커서 D-RAM과 SSD의 처리속도 차이가 미비해 보일지 모르지만, SSD의 경우에도 메모리와 1,000배 정도의 속도 차이를 발생시킵니다. 예를 들어, 메모리가 1초에 100만 건을 처리할 수 있는 작업이 있다고 한다면, 디스크의 경우에 이러한 100만 건의 작업을 처리하기 위해서 약 300시간이 걸리게 됩니다.
메모리와 Disk의 처리속도가 엄청난 차이를 보인다는 것을 알겠죠? 처음에 언급했다시피 데이터베이스 종류에는 데이터를 어디에 저장하는가에 따라 디스크 기반의 데이터베이스와 In-Memory 데이터베이스로 분류된다고 하였습니다.
In-Memory 데이터베이스는 메모리에 데이터를 저장하고 관리하기 때문에 I/O에 대한 부담을 덜 수 있습니다. 하지만, 메모리의 경우에도 단점은 존재합니다. 빠른 속도를 자랑하는 대신 전원이 공급되지 않는 순간, 기억하고 있는 데이터를 전부 잃어버리게 됩니다.
그렇다면, 세션 객체를 저장하기에 메모리도 안전하지 않은 것일까요?
지금부터 이에 대해 알아보겠습니다!
세션 저장소로써 In-Memory 데이터베이스는 적합할까?
이는 저장되는 데이터의 종류에 따라서 달라집니다. 잘 생각해보면 세션에 저장하는 데이터들은 영구적으로 저장하는 데이터가 아닙니다. 로그인한 사용자 정보를 예로 들어보면 로그아웃을 할 경우, 사용자의 세션 객체는 만료됩니다. 더 나아가 로그아웃을 하지 않더라도 개발자가 정한 일정 시간이 지나면 자동적으로 만료되게 됩니다. 만료된 이후에 다시 서비스를 사용하기 위해서는 재로그인을 하면 됩니다. 또한 로그아웃을 하지 않고, 브라우저를 종료한 경우에도 쿠키에 저장된 세션 ID가 사라지기 때문에 서버에 저장되어 있던 기존 세션 객체 사용이 불가하므로 다시 로그인을 해야 합니다.
이렇게 세션을 관리하는 이유는 다양합니다. 현재 사용 중이지 않는 사용자의 데이터를 계속해서 세션 저장소에 보관하게 된다면, 일정 시간 후에는 메모리 부족 현상이 발생할 수 있습니다. 또한 세션이 지속적으로 유지된다면 해커의 세션 기반 공격에 대한 노출이 증가하기 때문에 일정 시간 후 세션을 만료시키도록 해야 합니다.
세션에 저장되는 데이터가 이러한 특성을 지니기 때문에 상대적으로 서비스 장애로 인하여 데이터가 소멸됨에 있어서 피해가 적습니다. 계속해서 로그인한 사용자 데이터의 경우를 생각해보면 세션 객체에 저장되는 사용자 정보 역시 In-Memory 데이터베이스의 장애로 인해 내부에서 소멸하더라도 사용자가 다시 로그인 요청을 하여 세션에 저장될 정보를 가져온다면 서비스를 재사용할 수 있습니다.
물론 이러한 단점으로 발생하는 서비스 중단을 해결하기 위해서 일부 In-Memory 데이터베이스에서는 Replication이라는 기능을 통해 failover를 지원합니다. 아래 그림을 보시는 바와 같이 Master DB를 Slave DB에 복제함으로써 가용성을 높일 수 있습니다. 만일 Master DB에 장애가 발생하여 사용할 수 없을 시에는 Slave DB를 Master DB로 승격시켜 서비스를 중단 없이 지속적으로 제공할 수 있습니다.
지금까지 세션 스토리지를 위한 데이터베이스로 In-Memory 데이터베이스를 사용하면 된다는 걸 알게 되었습니다! 하지만 In-Memory 데이터베이스에도 종류가 다양합니다.
과연 어떤 In-Memory Database가 세션 스토리지로써 적합할까요?
이에 대해서는 다음 포스팅에서 알아보도록 하겠습니다!
정리해보기
1. 빈번한 Read/Write가 이루어지는 세션 저장소로써 Disk 기반의 데이터베이스는 상대적으로 I/O 속도가 느리기 때문에 적합하지 않습니다.
2. In-Memory 데이터베이스를 사용하면 데이터를 메모리에서 Read/Write 할 수 있다는 점에서 빠른 속도로 데이터를 처리할 수 있기 때문에 세션 저장소로써 적합합니다.
3. In-Memory 데이터베이스는 전원 공급이 중단되면 데이터를 잃어버리지만, 세션 저장소에 저장되는 데이터는 상대적으로 피해가 적기 때문에 In-Memory 데이터베이스 사용이 적합합니다. (일부 데이터베이스는 Replication을 지원하기 때문에 가용성을 확보할 수 있습니다.)
참고
- Real MySQL, 위키북스, 이성욱 지음, 2018년 12월 20일 5판 발행
프로젝트 참고
- Social Network Service AGORA, https://github.com/f-lab-edu/sns-project
f-lab-edu/sns-project
Contribute to f-lab-edu/sns-project development by creating an account on GitHub.
github.com
다음 포스팅에는!
'다중 서버 환경에서 세션을 어떻게 공유하고 관리할까? - 4편 (Redis vs Memcached)'에 대해 알아보겠습니다!
