복잡한 애플리케이션을 위한 주요 데이터베이스로서의 Redis

먼저 Redis가 무엇이고 사용 방법 및 현대 복잡한 마이크로서비스 애플리케이션에 적합한 이유를 살펴보겠습니다. Redis가 모듈을 통해 다양한 목적을 위한 여러 데이터 형식을 저장하는 방법에 대해 이야기할 것입니다. 그 다음으로 Redis가 인메모리 데이터베이스로서 데이터를 영속화하고 데이터 손실로부터 복구하는 방법에 대해 살펴볼 것입니다. 또한 Redis가 Redis on Flash를 사용하여 메모리 저장 비용을 최적화하는 방법에 대해 이야기할 것입니다.

그런 다음 Redis의 확장 및 여러 지리적 영역에 걸쳐 복제하는 흥미로운 사용 사례를 살펴볼 것입니다. 마지막으로, 마이크로서비스를 실행하는 가장 인기 있는 플랫폼 중 하나가 Kubernetes이며, Kubernetes에서 상태 유지(stateful) 애플리케이션을 실행하는 것은 다소 어려운 작업이므로 Redis를 Kubernetes에서 쉽게 실행하는 방법에 대해 살펴볼 것입니다.

레디스가 이 복잡성을 단순화하는 이유

레디스와 같은 다중 모드 데이터베이스와 비교할 때, 대부분의 이러한 문제를 해결할 수 있습니다:

1. 단일 데이터 서비스. 하나의 데이터 서비스만 실행하고 유지 관리합니다. 따라서 애플리케이션은 단일 데이터 저장소와 통신해야 하며, 이는 해당 데이터 서비스에 대한 하나의 프로그래밍 인터페이스만 필요하다는 것을 의미합니다.
2. 지연 시간 감소. 단일 데이터 엔드포인트로 이동하고 여러 내부 네트워크 홉을 제거하여 지연 시간이 줄어듭니다.
3. 하나의 데이터베이스에서 여러 데이터 유형. 레디스와 같은 하나의 데이터베이스를 사용하면 다양한 유형의 데이터를 저장할 수 있으며(즉, 하나의 데이터베이스에서 여러 유형의 데이터베이스) 캐시 역할도 할 수 있어 이러한 문제를 해결합니다.

레디스가 여러 데이터 형식을 지원하는 방법

그럼 레디스가 실제로 어떻게 작동하는지 살펴보겠습니다. 우선, 레디스는 단일 데이터베이스에서 여러 데이터 형식을 어떻게 지원할까요?

레디스 코어 및 모듈

동작 방식은 이미 다양한 유형의 데이터를 저장하는 데 이미 지원하는 키-값 저장소 인 Redis core를 가지고 있습니다. 그런 다음 응용 프로그램이 다른 목적을 위해 필요로 하는 다른 데이터 유형을위한 모듈이라고 불리는 것으로 핵심을 확장 할 수 있습니다. 예를 들어:

• RedisSearch는 Elasticsearch와 같은 검색 기능을위한 것입니다.
• RedisGraph는 그래프 데이터 저장을위한 것입니다.

이것의 좋은 점은 모듈화되어 있다는 것입니다. 이러한 다른 유형의 데이터베이스 기능은 다른 다중 모델 데이터베이스와 같이 하나의 데이터베이스에 엄격하게 통합되어 있지 않고, 대신 응용 프로그램에 필요한 데이터 서비스 기능을 정확히 선택하고 그 모듈을 추가 할 수 있습니다.

내장 캐싱

물론, 주요 데이터베이스로서 Redis를 사용할 때는추가 캐시가 필요하지 않습니다 Redis를 사용하면 자동으로 제공되기 때문입니다. 즉, 캐시를 관리, 채우기 및 무효화하는 논리를 구현할 필요가 없으므로 응용 프로그램에서 복잡성이 줄어 듭니다.

고성능 및 빠른 테스트

마지막으로, 인메모리 데이터베이스로서 Redis는 매우 빠르고 성능이 뛰어나며, 이는 물론 애플리케이션 자체를 더 빠르게 만듭니다. 또한 Redis는 다른 데이터베이스처럼 스키마가 필요하지 않기 때문에 애플리케이션 테스트를 훨씬 더 빠르게 실행할 수 있습니다. 따라서 테스트를 실행하기 전에 데이터베이스를 초기화하고 스키마를 구축하는 데 시간이 필요하지 않습니다. 매번 빈 Redis 데이터베이스로 시작하고 필요에 따라 테스트를 위한 데이터를 생성할 수 있습니다. 빠른 테스트는 실제로 개발 생산성을 높일 수 있습니다.

Redis의 데이터 지속성

우리는 Redis가 어떻게 작동하는지와 그 모든 이점을 이해했습니다. 그러나 이 시점에서 당신은 궁금할 수 있습니다: 인메모리 데이터베이스가 데이터를 어떻게 지속시킬 수 있을까요?? Redis 프로세스나 Redis가 실행되고 있는 서버가 실패하면 메모리의 모든 데이터가 사라지지 않나요? 데이터가 사라지면 어떻게 복구할 수 있을까요? 기본적으로 내가 내 데이터가 안전하다는 것을 어떻게 확신할 수 있을까요?

데이터 백업을 얻는 가장 간단한 방법은 Redis를 복제하는 것입니다. 따라서 Redis 마스터 인스턴스가 다운되면 복제본은 여전히 실행되고 모든 데이터를 가지고 있습니다. 복제된 Redis가 있다면 복제본이 데이터를 가지고 있을 것입니다. 하지만 물론 모든 Redis 인스턴스가 다운되면 복제본이 남아 있지 않기 때문에 데이터를 잃게 됩니다.

우리는 실제 지속성이 필요합니다.

스냅샷(RDB)

Redis에는 데이터를 지속하고 안전하게 유지하는 여러 메커니즘이 있습니다. 첫 번째는 스냅샷으로, 시간, 요청 횟수 등을 기반으로 구성할 수 있습니다. 데이터의 스냅샷은 디스크에 저장되며, 전체 Redis 데이터베이스가 손실된 경우 데이터를 복구하는 데 사용할 수 있습니다. 그러나 일반적으로 5분마다 또는 필요에 따라 1시간마다 스냅샷을 찍기 때문에 마지막 몇 분의 데이터는 손실될 수 있습니다.

AOF (Append Only File)

대안으로 Redis는 AOF라고 불리는 것을 사용하는데, 이는 Append Only File의 약자입니다. 이 경우에는 모든 변경 사항이 지속적으로 디스크에 저장됩니다. Redis를 다시 시작하거나 장애가 발생한 후에는 Redis가 Append Only 파일 로그를 다시 재생하여 상태를 재구성합니다. 따라서 AOF는 스냅샷보다 내구성이 높지만 느릴 수 있습니다.

스냅샷과 AOF의 결합

또한, AOF와 스냅샷을 결합하여 사용할 수 있으며, 여기서 append-only 파일은 메모리에서 디스크로 데이터를 지속적으로 저장하고, 필요에 따라 데이터 상태를 복구해야 할 경우에 대비하여 정기적인 스냅샷을 사용합니다. 이는 Redis 데이터베이스 자체 또는 Redis가 실행 중인 서버, Redis가 실행되는 기본 인프라가 모두 실패하더라도 모든 데이터를 안전하게 보유하고 필요한 경우 모든 데이터를 사용하여 새로운 Redis 데이터베이스를 쉽게 다시 생성하고 다시 시작할 수 있음을 의미합니다.

지속적인 저장소의 위치

매우 흥미로운 질문은, 그 지속적인 저장소가 어디에 있는지입니다. 디스크는 Redis가 실행되는 서버와 같은 서버에 있습니까?

이 질문은 사실 클라우드 환경에서 데이터 지속성의 트렌드 또는 최선의 실천 방법으로 이어지는데, 언제나 애플리케이션 및 데이터 서비스를 실행하는 서버와 데이터를 저장하는 지속적인 저장소를 분리하는 것이 더 나은 것입니다.

구체적인 예를 들자면 AWS EC2 인스턴스와 같이 클라우드에서 애플리케이션 및 서비스를 실행하는 경우에는 EC2 인스턴스의 하드 드라이브에 저장하는 대신 EBS 또는 Elastic Block Storage를 사용하여 데이터를 지속시켜야 합니다. 왜냐하면 만약 해당 EC2 인스턴스가 다운되면 RAM이나 디스크 저장소든 무엇이든지 해당 저장소에 액세스할 수 없게 됩니다. 그래서 데이터에 지속성과 내구성을 원한다면 데이터를 인스턴스 밖의 외부 네트워크 저장소에 두어야 합니다.

그 결과, 이 두 가지를 분리함으로써 서버 인스턴스가 실패하거나 모든 인스턴스가 실패해도 디스크와 그 안의 모든 데이터는 영향을 받지 않은 채 남아 있습니다. 다른 인스턴스를 생성하고 EBS에서 데이터를 가져와서 그만입니다. 각 서버가 동등하기 때문에 인프라를 관리하기가 훨씬 쉬워집니다. 특별한 데이터나 파일이 있는 특수 서버가 없기 때문에 전체 인프라를 잃어도 상관하지 않습니다. 새로운 인프라를 다시 만들고 별도 저장소에서 데이터를 가져와서 다시 시작할 수 있습니다.

Redis 예로 돌아가면 Redis 서비스는 서버에서 실행되며 서버 RAM을 사용하여 데이터를 저장하고, append-only 파일 로그와 스냅샷은 해당 서버 외부의 디스크에 지속됨으로써 데이터를 더 내구성있게 만듭니다.

비용 최적화: Redis on Flash

이제 우리는 Redis로 데이터를 지속성 있게 유지하고 내구성 및 회복을 위해 RAM 또는 메모리 저장소를 사용하여 우수한 성능과 속도를 제공할 수 있다는 것을 알고 있습니다. 그래서 여기서 가지게 될 질문은 다음과 같습니다: 메모리에 데이터를 저장하는 것이 비싼가요? 왜냐하면 메모리는 크기가 제한되어 있기 때문에 디스크에 데이터를 저장하는 데이터베이스보다 더 많은 서버가 필요할 것입니다. 비용과 성능 사이에는 교환이 존재합니다.

실제로 Redis에는 이를 최적화하는 방법이 있습니다. 이것은 Redis on Flash라는 서비스를 사용하는 것인데, 이는 Redis Enterprise의 일부입니다.

Redis on Flash의 작동 방식

실제로 이는 매우 간단한 개념입니다: Redis on Flash는 RAM을 플래시 드라이브 또는 SSD로 확장하여 자주 사용되는 값은 RAM에 저장되고 드물게 사용되는 값은 SSD에 저장합니다. 따라서 Redis에게는 단순히 서버의 더 많은 RAM이 됩니다. 이는 Redis가 데이터를 저장하기 위해 RAM과 SSD 드라이브를 모두 사용하여 기본 인프라나 기본 서버 자원을 더 많이 활용할 수 있게 함으로써 각 서버의 저장 용량을 증가시키고 이를 통해 인프라 비용을 절약할 수 있습니다.

Redis 확장: 복제 및 샤딩

Redis 데이터베이스의 데이터 저장 및 모든 작동 방식, 그리고 최상의 방법에 대해 이야기했습니다. 이제 다른 매우 흥미로운 주제는 Redis 데이터베이스를 어떻게 확장할까요?

복제 및 고가용성

내 Redis 인스턴스 하나가 메모리를 모두 사용하여 데이터를 저장할 수 없게 되거나 Redis가 병목 현상이 되어 더 이상 요청을 처리할 수 없는 경우에는 어떻게 하면 Redis 데이터베이스의 용량과 메모리 크기를 늘릴 수 있을까요?

우리에게는 그에 대한 몇 가지 옵션이 있습니다. 먼저, Redis는 클러스터링을 지원하여 주 또는 마스터 Redis 인스턴스를 가질 수 있고 데이터를 읽고 쓸 수 있으며 해당 주 인스턴스의 여러 복제본을 데이터를 읽기 위해 가질 수 있습니다. 이렇게 하면 Redis를 확장하여 더 많은 요청을 처리하고 데이터베이스의 고가용성을 높일 수 있습니다. 마스터가 실패하면 복제본 중 하나가 이를 대신하고 Redis 데이터베이스는 문제 없이 계속 작동할 수 있습니다.

이러한 복제본은 모두 주 인스턴스의 데이터 사본을 보유하게 됩니다. 따라서 복제본이 많을수록 더 많은 메모리 공간이 필요합니다. 그리고 한 대의 서버에 모든 복제본이 충분한 메모리를 가지고 있지 않을 수 있습니다. 게다가 모든 복제본을 한 대의 서버에 두고 해당 서버가 실패하면 전체 Redis 데이터베이스가 사라지고 다운타임이 발생할 수 있습니다. 대신, 이러한 복제본을 여러 노드 또는 서버에 분산시키는 것이 좋습니다. 예를 들어, 주 인스턴스는 한 노드에 있고 다른 두 노드에 두 개의 복제본이 있습니다.

큰 데이터셋을 위한 샤딩

좋아 보이지만, 단일 서버의 메모리에 맞지 않을 정도로 데이터셋이 커진다면 어떻게 해야 할까요? 게다가 데이터베이스의 읽기를 확장했지만 모든 요청은 기본적으로 데이터를 조회하기만 하므로 주 인스턴스는 여전히 혼자이고 모든 쓰기를 처리해야 합니다. 그렇다면 이 문제에 대한 해결책은 무엇일까요?

그를 위해, 우리는 데이터베이스에서 일반적인 개념 인 sharding을 사용하며, Redis도 지원합니다. 샤딩이란 기본적으로 전체 데이터 세트를 가져와 더 작은 청크 또는 데이터 하위 집합으로 나누는 것을 의미하며, 각 샤드는 자체 데이터 하위 집합을 처리하는 데 책임이 있습니다.

이는 전체 데이터 세트에 대한 모든 쓰기를 처리하는 하나의 마스터 인스턴스 대신, 예를 들어 4개의 샤드로 분할하여 각각이 데이터 하위 집합에 대한 읽기 및 쓰기를 처리할 수 있다는 것을 의미합니다. 각 샤드는 또한 데이터의 1/4만 가지고 있기 때문에 더 적은 메모리 용량이 필요합니다. 이는 샤드를 더 작은 노드에 분산하고 실행하여 클러스터를 수평으로 확장할 수 있다는 것을 의미합니다. 물론 데이터 세트가 커지고 더 많은 리소스가 필요한 경우 Redis 데이터베이스를 다시 샤드 할 수 있으며, 기본적으로 데이터를 더 작은 청크로 분할하고 더 많은 샤드를 만드는 것을 의미합니다.

모든 샤드가 실행되는 여러 노드를 갖고 있는 Redis의 복제본이 많은 경우, 병목 현상을 만들지 않고 많은 요청을 처리할 수 있는 성능이 우수하고 고가용성인 Redis 데이터베이스를 얻을 수 있습니다.

지금 여기서 언급해야 할 점은 이러한 설정이 훌륭하지만 직접 관리해야하며, 스케일링, 노드 추가, 샤딩, 그리고 리샤딩 등을 수행해야 합니다. 애플리케이션 개발 및 비즈니스 로직에 보다 집중하고 데이터 서비스를 운영 및 유지하는 것보다 관심이 많은 팀에게는 원치 않는 노력이 될 수 있습니다. 따라서 Redis Enterprise에서는 이러한 종류의 설정을 자동으로 제공받을 수 있으므로 스케일링, 샤딩 등이 모두 자동으로 관리됩니다.

Redis와 함께 전역 복제: 활성-활성 배포

응용 프로그램에 대한 더 높은 가용성과 성능이 필요한 경우에 대한 또 다른 흥미로운 시나리오를 고려해 봅시다. 따라서 한 지역, 유럽 런던의 데이터 센터에 복제된 샤드된 Redis 데이터베이스 클러스터가 있다고 가정해 봅시다. 그러나 두 가지 사용 사례가 있습니다:

1. 사용자가 지리적으로 분산되어 있기 때문에 전 세계에서 응용 프로그램에 액세스합니다. 우리는 우리의 응용 프로그램과 데이터 서비스를 전 세계적으로 사용자에게 가까운 곳에 분산시켜 사용자에게 더 나은 성능을 제공하고자 합니다.
2. 예를 들어 유럽 런던의 완전한 데이터 센터가 다운되면 Redis 서비스가 계속 사용 가능하도록 다른 데이터 센터로 즉시 전환하고자 합니다. 다시 말하면, 여러 지리적 위치나 지역의 데이터 센터에 전체 Redis 클러스터의 복제본을 가져야 합니다.

지역 간 여러 Redis 클러스터

이는 단일 데이터가 여러 지역에 걸쳐 분산된 여러 클러스터로 복제되어야 하며 각 클러스터는 읽기 및 쓰기를 완전히 수용할 수 있어야 합니다. 이 경우 각 지역에서 로컬 Redis 인스턴스로 작동할 여러 Redis 클러스터가 있게 되며 데이터는 이러한 지리적으로 분산된 클러스터 간에 동기화됩니다. 이는 Redis Enterprise에서 제공되는 기능이며 액티브-액티브 배포라고 불리며 서로 다른 위치에 있는 여러 활성 데이터베이스가 있는 것입니다.

이 설정을 사용하면 사용자들에게 낮은 지연 시간이 제공됩니다. 그리고 한 지역의 Redis 데이터베이스가 완전히 다운되더라도 다른 지역은 영향을 받지 않습니다. 예를 들어, 네트워크 문제로 인해 지역 간 연결 또는 동기화가 잠시 끊어지면, 이러한 지역의 Redis 클러스터는 독립적으로 데이터를 업데이트할 수 있으며, 연결이 다시 설정되면 해당 변경 사항을 다시 동기화할 수 있습니다.

CRDTs(Conflict-free Replicated Data Types)를 사용한 충돌 해결

이제 물론, 이를 듣자마자 머릿속에 떠오를 수 있는 첫 번째 질문은 다음과 같을 것입니다: Redis는 여러 지역에서 동일한 데이터 집합에 대한 변경 사항을 어떻게 해결하나요? 따라서 여러 지역에서 동일한 데이터가 변경되면 Redis가 어떻게 데이터 변경이 손실되지 않고 데이터가 올바르게 동기화되고 데이터 일관성이 보장되는지 알아봅니다.

구체적으로, Redis Enterprise는 CRDTs(Conflict-free Replicated Data Types)라는 개념을 사용하며, 이는 데이터베이스 수준에서 충돌을 자동으로 해결하고 데이터 손실 없이 처리하는 데 사용됩니다. 따라서 기본적으로 Redis 자체에는 여러 소스에서 동일한 데이터 집합에 대한 변경 사항을 병합하는 메커니즘이 있어서 데이터 변경이 손실되지 않고 모든 충돌이 적절히 해결됩니다. 그리고 앞서 설명한 대로 Redis는 여러 데이터 유형을 지원하므로 각 데이터 유형은 해당 특정 데이터 유형에 가장 최적화된 데이터 충돌 해결 규칙을 사용합니다.

간단히 말해서, 하나의 소스에서 변경 사항을 덮어쓰고 나머지를 모두 버리는 대신, 모든 병렬 변경 사항이 유지되고 지능적으로 해결됩니다. 다시 말해, 이 활성-활성 지리적 복제 기능으로 자동으로 처리되므로 걱정할 필요가 없습니다.

쿠버네티스에서 Redis 실행하기

그리고 제가 Redis와 관련하여 다루고 싶은 마지막 주제는 쿠버네티스에서 Redis 실행하기입니다. 말씀드린 대로, Redis는 여러 데이터 유형을 지원해야 하고, 데이터 일관성에 대한 걱정 없이 데이터베이스를 쉽게 확장할 수 있는 복잡한 마이크로서비스에 적합합니다. 또한 마이크로서비스를 실행하는 새로운 표준이 쿠버네티스 플랫폼이라는 것도 알고 있습니다. 따라서 쿠버네티스에서 Redis를 실행하는 것은 매우 흥미롭고 일반적인 사용 사례입니다. 그렇다면 어떻게 작동할까요?

쿠버네티스에서 오픈 소스 Redis

오픈 소스 Redis를 사용하면 복제된 Redis를 Helm 차트나 쿠버네티스 매니페스트 파일로 배포할 수 있으며, 기본적으로 우리가 이미 이야기한 복제 및 확장 규칙을 사용하여 고가용성 Redis 데이터베이스를 설정하고 실행할 수 있습니다. 유일한 차이점은 Redis가 실행될 호스트가 EC2 인스턴스나 다른 물리적 또는 가상 서버 대신 쿠버네티스 포드라는 것입니다. 하지만 쿠버네티스에서 Redis 클러스터를 실행하려면 같은 샤딩, 복제 및 확장 개념이 적용됩니다. 기본적으로 이 설정을 직접 관리해야 합니다.

Redis 엔터프라이즈 운영자

그러나 말했듯이 많은 팀들은 응용 프로그램 개발이나 기타 작업에 시간과 자원을 투자하는 것을 선호하기 때문에 이러한 제3자 서비스를 유지하는 노력을 하고 싶어하지 않습니다. 따라서 더 쉬운 대안이 여기에 중요합니다. Redis Enterprise에는 Kubernetes 운영자로 배포할 수 있는 관리형 Redis 클러스터가 있습니다.

운영자를 모르는 경우 Kubernetes에서 운영자는 특정 응용 프로그램이나 서비스를 운영하는 데 필요한 모든 리소스를 번들로 묶어 직접 관리하지 않거나 운영하지 않아도 되는 개념입니다. 데이터베이스를 운영하는 대신에 인간이 아닌 데이터베이스를 운영하는 데 필요한 모든 논리가 자동화된 형태로 제공됩니다. 많은 데이터베이스에는 Kubernetes용 운영자가 있으며 각 운영자는 물론 작성자와 작성 방식에 따라 고유한 논리를 갖고 있습니다.

특히 Kubernetes 운영자에서 Redis Enterprise는 Kubernetes 클러스터 내에서 전체 Redis 데이터베이스의 배포와 구성을 자동화합니다. 또한 필요한 경우 스케일링, 백업 수행, Redis 클러스터 복구 등을 처리합니다. 따라서 Kubernetes 클러스터 내에서 Redis 클러스터의 완전한 운영을 맡습니다.

결론

이 블로그에서 많은 것을 배우셨기를 바라며 여러분의 많은 질문에 대답할 수 있었기를 바랍니다. 비슷한 기술과 개념을 더 알고 싶다면 AI, DevOps 및 클라우드 기술에 대해 정기적으로 블로그를 쓰는 저를 팔로우해주시기 바랍니다.

또한 Redis 또는 새로운 주제 제안에 관한 질문이 있으면 아래에 댓글을 남겨주세요. 그리고 읽어 주셔서 감사합니다. 다음 블로그에서 만나요.

LinkedIn에서 연락을 주세요!