캐시 서버

 

 

ComputerScience

 

No Cash
Cache ! :)

 

 

What ?

캐시 서버

sddd

dddfs

캐시란?
컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간없이 더 빠른 속도로 데이터에 접근할 수 있다.

정리하자면 사용자에게 동일한 서비스를 제공시, 그 서비스를 제공하는 데이터를 미리 저장해 두었다가 요청시 빠른 속도로 응답하기 위한 시스템이라고 이해하시면 될 것 같습니다.

 

웹캐시서버(Web Cache Servers)

chache의 사전적 의미는 저장소.

웹브라우저를 보면 “캐시파일”이라고 있는데, 브라우저에서 저장하고 있는 내용을 보면 이미지, css, js 등의 파일들이다. 흔히 웹페이지에서 서비스하고 있는 컨텐츠들인데 이는 웹페이지의 로딩속도를 좀 더 빠르게 하기 위해 사용되어진다.

웹 캐시 서버란?

웹 캐시 서버는 프록시서버의 한 형태라고 할 수 있다. 웹 캐시 서버는 클라이언트가 요청한 컨텐츠들을 기억하고 있다가 어느 한 클라이언트 (동일사용자 일수도 있고, 다른 사용자 일수도 있는)가 웹 캐시 서버가 기억하고 있는 동일한 컨텐츠를 또 다시 요청하는 경우 이를 직접 응답하여 웹 서버의 부하를 절감시켜 주는 역할을 한다.

어느 클라이언트가 웹 서버의 특정 컨텐츠를 최초로 요청한 경우의 동작이다.

위 동작 방식에서 볼 수 있듯이 웹 캐시 서버의 동작 흐름이 프록시 서버와 같은 것을 볼 수 있다. 프록시 동작이 기본이기 때문에 프록시 서버의 특별한 하나의 형태라고 부른다.

웹 캐시 서버 역시 클라이언트에게는 웹 서버의 역할을 대신 수행하고, 웹 서버에게는 클라이언트의 역할을 대신 수행하는 중계자가 된다.

프록시와 차이점이 있다면 실제 서버에서 응답해준 컨텐츠를 웹 캐시 서버는 자신의 디스크나 메모리에 저장한 후 클라이언트에게 제공한다는 것이다. ( 웹 캐시 서버의 핵심 !)

다음 두번째!
같은 클라이언트 또는 다른 클라이언트가 웹 캐시 서버에서 저장된 동일한 컨텐츠를 요청하는 경우(보통 같은 웹사이트를 접속하는 경우)의 동작 흐름이다.

그림에서와 같이 트와이스 이미지를 다시 요청하는 경우, 웹 캐시 서버는 이를 직접 클라이언트에게 응답하게 된다.
실제 서버로 요청이 전달되지 않기 때문에 실제 서버 측면에서는 부담이 줄어든다.

웹 캐시 서버의 고민거리

이처럼 웹 서버 측면에서 보면 웹 캐시 서버라는 것은 대단히 좋다.
하지만 항상 좋은것은 아니다. 때로는 실제 웹 서버를 괴롭히기도 한다.
예를 들어,
웹 캐시 서버와 웹 서버가 정상적으로 아무 문제 없이 서비스를 훌륭하게 하고 있다고 가정하고 어느날 웹 개발자가 겨울이 되었으니 여름옷을 입은 트와이스의 이미지를 겨울 복장의 이미지로 바꾸게 되었다. 하지만, 미쳐 이 내용을 웹 캐시 서버에게 알리진 못했다. 이 경우 클라이언트들이 요청한 이미지의 내용은 어땠을까?

실제 웹 서버에서 서비스 이미지를 변경했으나 클라이언트에게는 이 내용이 반영되지 않게 된다. 서비스 장애라고 할 수 있다.

이처럼 웹 캐시 서버는 자신이 메모리나 디스크에 저장한 컨텐츠가 유효한지 아닌지를 체크해야 하는 숙제가 있다.
웹 캐시 서버 제품별로 컨텐츠가 유효한지 아닌지를 체크하는 알고리즘이 있고, 이를 계산할 수 있게 HTTP 헤더에 관련 정보들이 존재한다.

정리

• 웹 캐시는 프록시 서버와 동작 방식이 같다. 클라이언트와 서버 중간에 위치하여 요청과 응답에 대한 중간 대리인 역할을 한다.
• 프록시 동작외에 서버가 응답한 컨텐츠를 직접 저장하고 이후 동일한 요청에 대해 직접 응답함으로써 웹 서버의 부담을 줄인다.

 

데이터 베이스가 있는데도 Redis라는 인메모리 데이터 구조 저장소를 사용하는 이유는 무엇일까요?

 

데이터 베이스는 데이터를 물리 디스크에 직접 쓰기 때문에 서버에 문제가 발생하여 다운되더라도 데이터가 손실되지 않습니다. 하지만 매번 디스크에 접근해야 하기 때문에 사용자가 많아질수록 부하가 많아져서 느려질 수 있는데요.

일반적으로 서비스 운영 초반이거나 규모가 작은, 사용자가 많지 않은 서비스의 경우에는 WEB - WAS - DB 의 구조로도 데이터 베이스에 무리가 가지 않습니다.

하지만 사용자가 늘어난다면 데이터 베이스가 과부하 될 수 있기 때문에 이때 캐시 서버를 도입하여 사용합니다.

그리고 이 캐시 서버로 이용할 수 있는 것이 바로 Redis 입니다.

 

캐시는 한번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결괏값을 받을 수 있도록 도와주는 공간입니다.

같은 요청이 여러 번 들어오는 경우 매번 데이터 베이스를 거치는 것이 아니라 캐시 서버에서 첫 번째 요청 이후 저장된 결괏값을 바로 내려주기 때문에 DB의 부하를 줄이고 서비스의 속도도 느려지지 않는 장점이 있습니다.

 

 

 

캐시 서버는 Look aside cache 패턴과 Write Back 패턴이 존재합니다.

 

- Look aside cache

1. 클라이언트가 데이터를 요청

2. 웹서버는 데이터가 존재하는지 Cache 서버에 먼저 확인

3. Cache 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 Cache 서버에 있는 결과값을 클라이언트에게 바로 반환 (Cache Hit)

4. Cache 서버에 데이터가 없으면 DB에 데이터를 조회하여 Cache 서버에 저장하고 결과값을 클라이언트에게 반환 (Cache Miss)

 

- Write Back 

1. 웹서버는 모든 데이터를 Cache 서버에 저장

2. Cache 서버에 특정 시간 동안 데이터가 저장됨

3. Cache 서버에 있는 데이터를 DB에 저장

4. DB에 저장된 Cache 서버의 데이터를 삭제

 

* insert 쿼리를 한 번씩 500번 날리는 것보다 insert 쿼리 500개를 붙여서 한 번에 날리는 것이 더 효율적이라는 원리입니다.

* 이 방식은 들어오는 데이터들이 저장되기 전에 메모리 공간에 머무르는데 이때 서버에 장애가 발생하여 다운된다면 데이터가 손실될 수 있다는 단점이 있습니다.

 

 

---

 

본격적인 Redis의 특징,

 

• Key, Value 구조이기 때문에 쿼리를 사용할 필요가 없습니다.
• 데이터를 디스크에 쓰는 구조가 아니라 메모리에서 데이터를 처리하기 때문에 속도가 빠릅니다.
• String, Lists, Sets, Sorted Sets, Hashes 자료 구조를 지원합니다.

    String : 가장 일반적인 key - value 구조의 형태입니다.

    Sets : String의 집합입니다. 여러 개의 값을 하나의 value에 넣을 수 있습니다. 포스트의 태깅 같은 곳에 사용될 수 있습니다.

    Sorted Sets : 중복된 데이터를 담지 않는 Set 구조에 정렬 Sort를 적용한 구조로 랭킹 보드 서버 같은 구현에 사용할 수 있습니다.

    Lists : Array 형식의 데이터 구조입니다. List를 사용하면 처음과 끝에 데이터를 넣고 빼는 건 빠르지만 중간에 데이터를 삽입하거나 삭                 제하는 것은 어렵습니다.

 

• Single Threaded 입니다.
  : 한 번에 하나의 명령만 처리할 수 있습니다. 그렇기 때문에 중간에 처리 시간이 긴 명령어가 들어오면 그 뒤에 명령어들은 모두 앞에 있는 명령어가 처리될 때까지 대기가 필요합니다.
  (하지만 get, set 명령어의 경우 초당 10만 개 이상 처리할 수 있을 만큼 빠릅니다.)

 

 

Redis 사용에 주의할 점으로는

• 서버에 장애가 발생했을 경우 그에 대한 운영 플랜이 꼭 필요합니다.
  : 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있기 때문입니다.
• 메모리 관리가 중요합니다.
• 싱글 스레드의 특성상, 한 번에 하나의 명령만 처리할 수 있습니다. 처리하는데 시간이 오래 걸리는 요청, 명령은 피해야 합니다.

 

 

이 외에도 Master-Slave 형식의 데이터 이중화 구조에 대한 Redis Replication, 분산 처리를 위한 Redis cluster, 장애 복구 시스템 Redis Sentinel, Redis Topology, Redis Sharding, Redis Failover 등의 Redis를 더 효율적으로 사용하기 위한 개념들이 존재합니다. 

 

이번 포스팅은 Redis의 기본적인 개념 정도만 알아보기 위해 공부했기 때문에 후에 직접 사용해보며 해당 부분에 대한 포스팅을 추가할 계획입니다.