TIL) 서버 언어의 자료구조와 레디스의 자료구조

자료구조는 데이터를 저장하고 조작하는 과정에서 발생하는 시간과 공간 측면(메모리)의 요구사항을 효율적으로 처리하기 위한 도구입니다.

큐(Queue)는 먼저 들어온 데이터를 먼저 꺼내는 선입선출 구조이며,

요청을 순차적으로 처리하거나, 이벤트 발생 순서대로 소비하는 상황에 주로 사용됩니다.

스택(Stack)은 가장 나중에 들어온 데이터를 가장 먼저 꺼내는 자료

재귀 호출, 실행 취소, 최근 방문 이력처럼 “최근 작업부터 되돌리는” 작업에서 유용하게 사용됩니다.

자료구조는 문제 해결을 위한 연산 집합으로 추상화된 개념입니다.

단일 서버에서는 모든 게 쉽다.Permalink

단일 서버 환경에서는 애플리케이션 메모리 내에 데이터를 저장하고 관리하는 것이 비교적 간단합니다.

초기에는 모든 상태(데이터)를 서버 내 코드로 처리할 수 있습니다.

세션, 장바구니, 인증 상태, 중복 요청 검사등 전부 서버 메모리 안에서 해결이 됩니다.

하지만 서비스가 커지면서 서버를 여러 대로 늘리게 되면, 방법을 변환해야합니다.

운영서버와 관리자 서버가 서로 상태가 다릅니다.

서버가 여러 대가 되면, 공유 자원이 문제가 됩니다.Permalink

단일 서버로 서비스를 운영할 수 있습니다. 다만 아래와 같은 상황을 해결하기 위해 여러 서버로 만들게 됩니다.

1. 장애 격리성 - 서버 하나가 장애가 발생해도 나머지 서버로 운영이 가능합니다.
2. 무중단 배포 - 배포중에는 잠시 서비스가 중단 될 수 있으므로 서버를 나누어 서비스 중단을 최소화할 수 있습니다.
3. 동적으로 서버 확장 - 서버 부하가 발생되기 전에 미리 동적으로 서버를 확장할 수 있습니다.

데이터 정합성을 유지하면서 서버 메모리 데이터 상태를 단순히 복제 할 수 없습니다.

그러면.. JWT, 쿠키처럼 클라이언트가 보관하는 방법은 없을까?

클라이언트에 저장할 수 없는 걸까?Permalink

일부 정보는 클라이언트 저장소(localStorage, Cookie 등)에 저장할 수 있습니다.

• 민감한 인증 상태
• 서버가 관리해야 하는 상태(선착순 마감등)
• 여러 클라이언트가 동시 접근하는 공유 상태(상품 정보 등)

분산 서버 환경으로 확장되며 발생되는 고려사항이 있다.Permalink

단일 서버 환경에서는 내장 자료구조로 사용하여 상태를 쉽게 관리할 수 있습니다.

하지만 가용성 확보를 위해 서버를 이중화하거나 다중화하게 된다면, 어플리케이션 내부에서만 유지되던 상태 공유가 어려워 집니다.

• 선착순 이벤트 (FIFO 처리 필요)
• 중복 요청 제거 (Set)
• 인증 상태 정보 (HashMap 기반)
• 장바구니처럼 세션 기반 사용자 상태 (Server side 저장)

여러 서버에서 상태를 공유하려면 클라이언트 저장 또는 외부 저장소 사용이 필요해집니다.

보안상 또는 신뢰성상으로 서버가 직접 소유하고 관리해야하는 데이터는 클라이언트에 저장할 수 없습니다.

로드 밸런서 정책중 동일한 클라이언트(사용자)로부터 오는 후속 요청들을 동일한 특정 서버로 계속 보내도록 설정할 수 있습니다.

Sticky Session으로 설정하면 가능합니다.

다만 로드 분산 효과가 감소되며 서버 유지보수/확장이 어렵습니다. 특정 서버를 내리거나 업데이트를 할 때 해당 서버에 세션이 고정된 사용자들의 서비스가 중단되기에 이중화를 통한 가용성의 효과가 줄어들게 됩니다.

결과적으로, 별도의 중앙 저장소가 필요합니다.

공유 저장소에 생기는 이슈Permalink

파일 처리 시스템, RDBMS처럼 디스크 기반 저장소를 사용하면 다음과 같은 문제가 있습니다.

1. 디스크 I/O - 메모리보다 많이 느림
2. 동시성 제어 문제 - 멀티쓰레드 기반 웹서버는 자원

레디스로 전환Permalink

별도의 중앙소 역할이면서 네트워크 통신 비용을 고려해도 빠른 성능을 자랑하는 인메모리 디비입니다.

서버에서 수 천개의 요청이 들어와도 서버 운영체제의 멀티 플렉싱을 활용하여 데이터 요청을 빠르게 받을 수 있습니다.

그리고 이벤트 루프를 통해 단일 쓰레드로 락으로 인한 성능 저하도 발생하지 않으며, 데이터 조작은 원자성이 보장됩니다.

레디스 전환시 고려사항Permalink

1. race condition 과 서비스 로직
2. SPOF과 가용성

race condition이 발생하는 이유는 데이터 읽기/ 연산 / 연산 결과 반영이 하나의 메서드 내에 있게 됩니다.

그래서 조회 시점과 연산 반영 시점이 달라지게 되므로 메서드 호출 시기에 따라 연산 결과가 달라집니다.

SPOF는 애플리케이션 서버가 레디스가 오류가 생기는 경우 서비스 중지가 될 수 있습니다.

이를 방지하기 위해 레디스의 가용성을 높일 고려방안도 생각해야합니다.

전체 지연이 발생할 수 있습니다.

• 단일 스레드라서 락 경합은 없습니다, 연산 단위가 복잡하여 처리가 오래 걸리는 경우에는 전체 지연이 발생됩니다.

TTL 설정과 데이터 크기 제한이 필요합니다.

레디스는 메모리 기반입니다. 디스크 기반이 아니기에 저장할 수 있는 자원은 제한됩니다.

TTL을 사용하여 일정 기간 사용하지 않는 데이터는 삭제처리하여 메모리를 효율적으로 사용해야합니다.